All drivers already have a work item to run the hpd code, so we don't
need to launch a new one in the helper code. Dave Airlie mentioned
that the cancel+re-queue might paper over DP related hpd ping-pongs,
hence why this is split out.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Instead of reusing the polling code for hpd handling, split them up.
This has a few consequences:
- Don't touch HPD capable connectors in the poll loop.
- Only touch HPD capable connectors in drm_helper_hpd_irq_event.
- We could run the HPD handling directly (because all callers already
  use their own work item), but for easier bisect that happens in it's
  own patch.

The ultimate goal is that drivers grow some smarts about which
connectors have received a hotplug event and only call the detect code
of that connector. But that's a second step.

v2: s/hdp/hpd/, noticed by Adam Jackson. I can't type.

v3: Split out the work item removal as requested by Dave Airlie. This
results in a temporary mode_config.hpd_irq_work item to keep things
the same.

v4: In the hpd_irq_event handler don't bail out if other bits than HPD
are set. This is useful where e.g. hpd is unreliably, but mostly
works. Drivers can then set both HPD and POLL flags, and users get the
best of both worlds: Quick hotplug feedback if the hpd works, but
still reliable detection with the polling. The poll loop already works
the same, and doesn't bail if HPD is set.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch adds support for getting CEA Video ID Code for a given
display mode after matching with edid_cea_modes list. Its index in
the list added with one, gives the desired code.

This exported function will be used by hdmi drivers for composing
AVI info frame data.
Signed-off-by: NStephane Marchesin <marcheu@chromium.org>
Signed-off-by: NRahul Sharma <rahul.sharma@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

None of drm_mode_debug_printmodeline(), drm_mode_equal(), drm_mode_width()
or drm_mode_height() change the mode passed in, so make the arguments
const.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Only refer to the DRM UAPI headers (drm.h, drm_mode.h and drm_sarea.h) from
within drmP.h and drm_crtc.h, and use #include <...> to refer to them so that
when the UAPI split happens they can still be accessed.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

Tested-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For drivers that can support rotated scanout, the extra parameter
checking in drm-core, while nice, tends to get confused.  To solve
this drivers can set the crtc or plane invert_dimensions field so
that the dimension checking takes into account the rotation that
the driver is performing.

v1: original
v2: remove invert_dimensions from plane, at Ville's suggestion.
    Userspace can give rotated src coordinates, so invert_dimensions
    is not required for planes.
Signed-off-by: NRob Clark <rob@ti.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This simplifies drm fb lifetime, and if the crtc/plane needs to hold
a ref to the fb when disabling a pipe until the next vblank, this
avoids the need to make disabling an overlay synchronous.  This is a
problem that shows up when userspace is using a drm plane to
implement a hw cursor.. making overlay disable synchronous causes
a performance problem when x11 is rapidly enabling/disabling the
hw cursor.  But not making it synchronous opens up a race condition
for crashing if userspace turns around and immediately deletes the
fb.  Refcnt'ing the fb makes it possible to solve this problem.

v1: original
v2: add drm_framebuffer_remove() which is called in all paths where
    fb->funcs->destroy() was directly called before.  This cleans
    up the CRTCs/planes that the fb was attached to.  You should
    only directly use drm_framebuffer_unreference() if you are also
    using drm_framebuffer_reference() to keep a ref to the fb.
v3: add comment explaining the fb refcount
v4: remove duplicate 'list_del(&fb->filp_head)'

[airlied: v4.1: fix local rejection]
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Tested-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Limit printing bad edid information at one time per connector.
Connector that are connected to a bad monitor/kvm will likely
stay connected to the same bad monitor/kvm and it makes no
sense to keep printing the bad edid message.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

DRM_MODE() macro doesn't initialize the type of the base drm object.
When a copy is made of the mode, the object type is overwritten with
zero, and the the object can no longer be found by
drm_mode_object_find() due to the type check failing.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Neither the drm core nor any of the drivers really need the raw_edid field
of struct drm_display_info for anything. Instead of being useful, it
creates confusion about who is responsible for freeing the memory it points
to and setting the field to NULL afterwards, leading to memory leaks and
dangling pointers.

Remove the raw_edid field, and fix drivers as necessary.
Reported-by: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It's unused. At it confused me quite a bit until I've discovered that.

Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Before Kernel 3.5, no one was checking for the return value of
drm_connector_attach_property, so we never noticed that we were unable
to create some properties. Commit "drm: WARN() when
drm_connector_attach_property fails" added a WARN when we fail to
create a property, and the transition from "connector properties" to
"object properties" changed the warning message a little bit.

On i915 machines with many TV connectors we hit the maximum number of
properties (since each TV connector uses a lot of properties), so we
get a few backtraces in our logs. This commit increases the maximum
number of properties to 24 hoping we'll have enough room for
everybody.

Chris suggested that we convert this code to "lists", but I believe
this conversion can come after we make sure people's dmesgs are not
spammed by our driver.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reported-by: NDave Jones <davej@redhat.com>
Tested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The omapdrm driver uses this for setting per-overlay rotation.  It
is likely also useful for setting YUV->RGB colorspace conversion
matrix, etc.
Signed-off-by: NRob Clark <rob@ti.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

A bitmask property is similar to an enum.  The enum value is a bit
position (0-63), and valid property values consist of a mask of
zero or more of (1 << enum_val[n]).

[airlied: 1LL -> 1ULL]
Signed-off-by: NRob Clark <rob@ti.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The DRM mode config functions structure declared by drivers and pointed
to by the drm_mode_config funcs field is never modified. Make it a const
pointer.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Rob Clark <rob.clark@linaro.org>
Reviwed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The i915 driver needs this for the rotation and overscan compensation
properties. Other drivers might need this too.
Reviewed-by: NRob Clark <rob.clark@linaro.org>
Tested-by: NRob Clark <rob.clark@linaro.org>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This way, we don't need to count every time, so we're a little bit
faster and code is a little bit smaller.

Change suggested by Ville Syrjälä.
Reviewed-by: NRob Clark <rob.clark@linaro.org>
Tested-by: NRob Clark <rob.clark@linaro.org>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Useless for connector properties (since they already have their own
ioctls), but useful when we add properties to CRTCs, planes and other
objects.
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NRob Clark <rob.clark@linaro.org>
Tested-by: NRob Clark <rob.clark@linaro.org>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

For now, only connectors have it. In the future, all objects that need
properties should use it. Since the structure is referenced inside
struct drm_mode_object, we will be able to deal with object properties
without knowing the real type of the object.
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NRob Clark <rob.clark@linaro.org>
Tested-by: NRob Clark <rob.clark@linaro.org>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Also return void instead of int. We have more than 100 callers and
no one checks for the return value.

If this function fails the property won't be exposed by the get/set
ioctls, but we should probably survive. If this starts happening,
the solution will be to increase DRM_CONNECTOR_MAX_PROPERTY and
recompile the Kernel.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRob Clark <rob.clark@linaro.org>
Tested-by: NRob Clark <rob.clark@linaro.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Requiring the first byte of the EDID base block header to be 0 means we
don't fix up as many transfer errors as we could.  Instead have the
callers specify whether it's meant to be block 0 or not, and
conditionally run header fixup based on that.

Bugzilla: https://bugzilla.redhat.com/812890Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It won't find any, yet.  Fix up callers to match: standard mode codes
will look prefer r-b modes for a given size if present, EST3 mode codes
will look for exactly the r-b-ness mentioned in the mode code.  This
might mean fewer modes matched for EST3 mode codes between now and when
the DMT mode list regrows the r-b modes, but practically speaking EST3
codes don't exist in the wild.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

These functions return the chroma subsampling factors for the specified
pixel format.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This function returns the bytes per pixel value based on the pixel
format and plane index.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There will be a need for this function in drm_crtc.c later. This
avoids making drm_crtc.c depend on drm_crtc_helper.c.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Broken monitors and/or broken graphic boards may send erroneous or no
EDID data. This also applies to broken KVM devices that are unable to
correctly forward the EDID data of the connected monitor but invent
their own fantasy data.

This patch allows to specify an EDID data set to be used instead of
probing the monitor for it. It contains built-in data sets of frequently
used screen resolutions. In addition, a particular EDID data set may be
provided in the /lib/firmware directory and loaded via the firmware
interface. The name is passed to the kernel as module parameter of the
drm_kms_helper module either when loaded
  options drm_kms_helper edid_firmware=edid/1280x1024.bin
or as kernel commandline parameter
  drm_kms_helper.edid_firmware=edid/1280x1024.bin

It is also possible to restrict the usage of a specified EDID data set
to a particular connector. This is done by prepending the name of the
connector to the name of the EDID data set using the syntax
  edid_firmware=[<connector>:]<edid>
such as, for example,
  edid_firmware=DVI-I-1:edid/1920x1080.bin
in which case no other connector will be affected.

The built-in data sets are
Resolution    Name
--------------------------------
1024x768      edid/1024x768.bin
1280x1024     edid/1280x1024.bin
1680x1050     edid/1680x1050.bin
1920x1080     edid/1920x1080.bin

They are ignored, if a file with the same name is available in the
/lib/firmware directory.

The built-in EDID data sets are based on standard timings that may not
apply to a particular monitor and even crash it. Ideally, EDID data of
the connected monitor should be used. They may be obtained through the
drm/cardX/cardX-<connector>/edid entry in the /sys/devices PCI directory
of a correctly working graphics adapter.

It is even possible to specify the name of an EDID data set on-the-fly
via the /sys/module interface, e.g.
echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware
The new screen mode is considered when the related kernel function is
called for the first time after the change. Such calls are made when the
X server is started or when the display settings dialog is opened in an
already running X server.
Signed-off-by: NCarsten Emde <C.Emde@osadl.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In order to get correct ordering at hot-unplug for userspace,
we need to tear down all the sysfs bits at the correct time.

This adds a helper to allow drivers to remove the sysfs nodes
for all connectors.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add a helper function to copy a display mode. Use it in
drm_mode_duplicate() and nouveau mode_fixup hooks.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The blob property data is always allocated immediately after the object
header. No need for the extra indirection when accessing it, just use
a flexible array member.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Check drm_mode_object_get() return value everywhere.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Change drm_mode_attachmode_crtc() to take an "all or nothing" approach.
If an error is returned, there are no side effects visible.

Also change the function to always duplicate the mode passed in.

Also change the function to not give up when it finds the first
connector without and encoder.

A simpler approach would be to just remove the function completely as
it's unused currently.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The drm_display_mode type is a bitmask so it should be unsigned.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

For the simple KMS driver case we need some more info about what the preferred
depth and if a shadow framebuffer is preferred.

I've only added this for intel/radeon which support the dumb ioctls so far.

If you need something really fancy you should be writing a real X.org driver.

v2: drop cursor information, just return an error from the cursor ioctls
and we can make userspace fallback to sw cursor in that case, cursor
info was getting too messy, best to start smaller.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Creating a range property is a common pattern, so create
a convenience function for this and use it where appropriate.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Creating an enum property is a common pattern, so create
a convenience function for this and use it where appropriate.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

drm_mode_crtc_set_gamma_size returns boolean true for success
and false for failure. This is not very kernel conform, so
change it to return 0 for success and a propert error code
otherwise. Noone checks the return value, so no users have to
be fixed.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>