drm: Add support for alternate clocks of 4k modes

v2: Fix hmdi typo (Simon Farnsworth, Ville Syrjälä)

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
video/hdmi: Don't let the user of this API create invalid infoframes

To set the active aspect ratio value in the AVI infoframe today, you not
only have to set the active_aspect field, but also the active_info_valid
bit. Out of the 1 user of this API, we had 100% misuse, forgetting the
_valid bit. This was fixed in:

  Author: Damien Lespiau <damien.lespiau@intel.com>
  Date:   Tue Aug 6 20:32:17 2013 +0100

      drm: Don't generate invalid AVI infoframes for CEA modes

We can do better and derive the _valid bit from the user wanting to set
the active aspect ratio.

v2: Fix multi-lines comment style (Thierry Reding)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
video/hdmi: Derive the bar data valid bit from the bar data fields

Just like:

  Author: Damien Lespiau <damien.lespiau@intel.com>
  Date:   Mon Aug 12 11:53:24 2013 +0100

      video/hdmi: Don't let the user of this API create invalid infoframes

But this time for the horizontal/vertical bar data present bits.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
video/hdmi: Introduce helpers for the HDMI vendor specific infoframe

Provide the same programming model than the other infoframe types.

The generic _pack() function can't handle those yet as we need to move
the vendor OUI in the generic hdmi_vendor_infoframe structure to know
which kind of vendor infoframe we are dealing with.

v2: Fix the value of Side-by-side (half), hmdi typo, pack 3D_Ext_Data
    (Ville Syrjälä)
v3: Future proof the sending of 3D_Ext_Data (Ville Syrjälä), Fix
    multi-lines comment style (Thierry Reding)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
gpu: host1x: Port the HDMI vendor infoframe code the common helpers

I just wrote the bits to define and pack HDMI vendor specific infoframe.
Port the host1x driver to use those so I can refactor the infoframe code
a bit more.

This changes the length of the infoframe payload from 6 to 5, which is
enough for the "frame packing" stereo format.

v2: Pimp up the commit message with the note about the length
    (Ville Syrjälä)

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Terje Bergström <tbergstrom@nvidia.com>
Cc: linux-tegra@vger.kernel.org

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
drm/edid: Move HDMI_IDENTIFIER to hdmi.h

We'll need the HDMI OUI for the HDMI vendor infoframe data, so let's
move the DRM one to hdmi.h, might as well use the hdmi header to store
some hdmi defines.

(Note that, in fact, infoframes are part of the CEA-861 standard, and
only the HDMI vendor specific infoframe is special to HDMI, but
details..)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
video/hdmi: Hook the HDMI vendor infoframe with the generic _pack()

With this last bit, hdmi_infoframe_pack() is now able to pack any
infoframe we support.

At the same time, because it's impractical to make two commits out of
this, we get rid of the version that encourages the open coding of the
vendor infoframe packing. We can do so because the only user of this API
has been ported in:

  Author: Damien Lespiau <damien.lespiau@intel.com>
  Date:   Mon Aug 12 18:08:37 2013 +0100

      gpu: host1x: Port the HDMI vendor infoframe code the common helpers

v2: Change oui to be an unsigned int (Ville Syrjälä)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
video/hdmi: Use hdmi_vendor_infoframe for the HDMI specific infoframe

We just got rid of the version of hdmi_vendor_infoframe that had a byte
array for anyone to poke at. It's now time to shuffle around the naming
of hdmi_hdmi_infoframe to make hdmi_vendor_infoframe become the HDMI
vendor specific structure.

Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
drm: Add a helper to forge HDMI vendor infoframes

This can then be used by DRM drivers to setup their vendor infoframes.

v2: Fix hmdi typo (Simon Farnsworth)
v3: Adapt to the hdmi_vendor_infoframe rename

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
drm/i915/hdmi: Write HDMI vendor specific infoframes

With all the common infoframe bits now in place, we can finally write
the vendor specific infoframes in our driver.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
video/hdmi: Rename HDMI_IDENTIFIER to HDMI_IEEE_OUI

HDMI_IDENTIFIER was felt too generic, rename it to what it is, the IEEE
OUI corresponding to HDMI Licensing, LLC.

http://standards.ieee.org/develop/regauth/oui/oui.txt

Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
drm: implement experimental render nodes

Render nodes provide an API for userspace to use non-privileged GPU
commands without any running DRM-Master. It is useful for offscreen
rendering, GPGPU clients, and normal render clients which do not perform
modesetting.

Compared to legacy clients, render clients no longer need any
authentication to perform client ioctls. Instead, user-space controls
render/client access to GPUs via filesystem access-modes on the
render-node. Once a render-node was opened, a client has full access to
the client/render operations on the GPU. However, no modesetting or ioctls
that affect global state are allowed on render nodes.

To prevent privilege-escalation, drivers must explicitly state that they
support render nodes. They must mark their render-only ioctls as
DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must
support clients without any attached master.

If filesystem access-modes are not enough for fine-grained access control
to render nodes (very unlikely, considering the versaitlity of FS-ACLs),
you may still fall-back to fd-passing from server to client (which allows
arbitrary access-control). However, note that revoking access is
currently impossible and unlikely to get implemented.

Note: Render clients no longer have any associated DRM-Master as they are
supposed to be independent of any server state. DRM core highly depends on
file_priv->master to be non-NULL for modesetting/ctx/etc. commands.
Therefore, drivers must be very careful to not require DRM-Master if they
support DRIVER_RENDER.

So far render-nodes are protected by "drm_rnodes". As long as this
module-parameter is not set to 1, a driver will not create render nodes.
This allows us to experiment with the API a bit before we stabilize it.

v2: drop insecure GEM_FLINK to force use of dmabuf

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/vmwgfx: fix error return code in vmw_driver_load()

Fix to return -ENOMEM in the fence manager init error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
drm/prime: double lock typo

There is a typo so deadlocks on error instead of unlocking.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
drm: Remove the dithering_mode_property field

Unfortunately, I haven't been thorough enough in:

  commit ddecb10cf402a8325579f298fd4986a90f33496b
  Author: Lespiau, Damien <damien.lespiau@intel.com>
  Date:   Tue Aug 20 00:53:04 2013 +0100

      drm: Remove drm_mode_create_dithering_property()

And forgot to remove the dithering_mode_property member of struct
drm_mode_config.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Merge tag 'drm-intel-fixes-2013-08-30' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

Just a one-line patch to fix a black screen issue on rare ivb machines,
cc: stable. Normally I'd just shovel this into the -next pull request this
late in the -rc cycle, but Linus was making noises about not getting real
fixes which are cc: stable. So here we go ;-)

* tag 'drm-intel-fixes-2013-08-30' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: ivb: fix edp voltage swing reg val
drm/vmwgfx: Split GMR2_REMAP commands if they are to large

This fixes the piglit test texturing/max-texture-size
causing the VM to die due to a too large SVGA command.

Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Biran Paul <brianp@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@gmail.com>
drm/prime: Remove PRIME handles only if supported

Drivers that don't support PRIME will not have initialized the PRIME
specific private component of struct drm_file. If called for such
drivers, the drm_gem_remove_prime_handles() function will crash. Fix
it by checking for PRIME support prior to removing the PRIME handles.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
drm/omap: tiler: clear buffer properly

We're taking the sizeof() the wrong thing so it doesn't clear the whole
buffer.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Merge branch 'pci/misc' into next

* pci/misc:
  PCI/ACPI: Fix _OSC ordering to allow PCIe hotplug use when available
  PCI: exynos: Add I/O access wrappers
  PCI: designware: Drop "addr" arg from dw_pcie_readl_rc()/dw_pcie_writel_rc()