date:20150509

On Sat, May 09, 2015 at 08:55:10PM +0300, Anssi Hannula wrote:
> 09.05.2015, 20:40, Russell King - ARM Linux kirjoitti:
> > Even VLC _doesn't_ if it's outputting to a standard audio - in other
> > words, if you don't tick the SPDIF direct output option which defaults
> > to disabled (which, when enabled, opens the device passing the AES
> > bits _and_ permits it to send a compressed audio stream.)  I've looked
> > at this in VLC many times...
> 
> That is my understanding as well. Same for pulseaudio, it doesn't set
> any AES bits except for passthrough (and most other applications never
> set them).

Right, so when you're dealing with HDMI, where it's required that the
AES bits contain accurate information, the only real option is to set
it appropriately in the driver if userspace doesn't specify the AES
data bits.

Now, with the dw-hdmi-ahb driver, I'm doing something sensible - and
yes, I do have a card file in /usr/share/alsa (see below).

What this does is ensure that linear PCM is converted to 24-bit PCM
(which makes the kernel conversion to the required hardware format
easier - I hate this, I'd much prefer it to be done in userspace.)

However, in the case of VLC, if it wants to send non-audio, it will
open the IEC958 device, which will use the iec958 plugin to configure
the AES bits for non-audio, and pass IEC958 data to the kernel (which
still needs to be reformatted to the hardware's special format.)

dw-hdmi-ahb-aud.pcm.default {
@args [ CARD ]
@args.CARD { type string }
type asym
playback.pcm {
type softvol
slave.pcm {
type plug
slave.pcm {
@func concat
strings [ "dmix:" $CARD ",FORMAT=S24_LE" ]
}
}
control {
name "PCM Playback Volume"
card $CARD
}
}
}



dw-hdmi-ahb-aud.pcm.iec958.0 {
@args [ CARD AES0 AES1 AES2 AES3 ]
@args.CARD { type string }
@args.AES0 { type integer }
@args.AES1 { type integer }
@args.AES2 { type integer }
@args.AES3 { type integer }
type iec958
slave.pcm {
type hw
card $CARD
device 0
}
slave.format IEC958_SUBFRAME_LE
status [ $AES0 $AES1 $AES2 $AES3 ]
}


-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Some issues with the new amdgpu driver

2015-05-09 Thread Brian Paterni

On 05/09/2015 03:34 AM, Michel DÃ¤nzer wrote:
> On 09.05.2015 11:44, Brian Paterni wrote:
>> On 05/07/2015 04:07 AM, Michel DÃ¤nzer wrote:
>>> On 06.05.2015 12:12, Brian Paterni wrote:

 I was on irc a few days ago trying to get the new amdgpu driver up and
 running on my system. I am able to get the kernel booted successfully,
 however X via amdgpu is turning out to be a real roadblock. It is the
 problem with amdgpu_drv.so seeing gbm_create_device as an undefined
 symbol. From what little I understand, I may be needing a more recent
 xserver to resolve this...
>>>
>>> I don't think that would help.
>>>
>>> Does the attached xf86-video-amdgpu patch fix the problem?
>>>
>>> If not, you can manually load the glamoregl module in /etc/X11/xorg.conf
>>> to pull in libgbm:
>>>
>>> Section "Module"
>>> Load"glamoregl"
>>> EndSection
>>>
>>>
>>
>> Hi Michel, thanks for the reply. I got around to recompiling the stack
>> from the latest trees as noted by Alex earlier. However, I'm afraid
>> something may have changed recently and I may be needing a newer xserver
>> after all. Loading amdgpu_drv.so now results in:
>>
>> [  1122.347] (EE) module ABI major version (19) doesn't match the
>> server's version (18)
> 
> That just means the driver it's trying to load wasn't built against the
> same version of xserver. Make sure the xf86-video-amdgpu build is
> picking up the xorg-server.pc and header files of the same version of
> xserver you're trying to run.
> 
> 

Oops! Looks like I forgot to cc the mailing list.

I think my version mismatch issues above may have been resolved by a
recent upload of xserver-xorg-core 2:1.17.1-2 to debian unstable(?)...

As a result, I could finally test Michel's patch, and I am happy to say
that X via amdgpu is now working for me! Thanks to Michel! :)

However, the two additional issues mentioned in my initial post are
still present:

*) Non-working DVI-I-0 -- even if I use xrandr to turn it off and on
again, a signal is never acquired.

*) System lockup on xen boot (even magic sysrq is not recognized)

[alsa-devel] [PATCH 12/13] drm: bridge/dw_hdmi-ahb-audio: add audio driver

On Sat, May 09, 2015 at 06:40:54PM +0100, Russell King - ARM Linux wrote:
> Even VLC _doesn't_ if it's outputting to a standard audio - in other
> words, if you don't tick the SPDIF direct output option which defaults
> to disabled (which, when enabled, opens the device passing the AES
> bits _and_ permits it to send a compressed audio stream.)  I've looked
> at this in VLC many times...

FYI, here's the code:

vlc_fourcc_t fourcc = aout->format.i_format;
bool spdif = false;
switch (fourcc)
{
... other linear float/integer codec IDs ...
case VLC_CODEC_U16B:
pcm_format = SND_PCM_FORMAT_U16_BE;
break;
case VLC_CODEC_U16L:
pcm_format = SND_PCM_FORMAT_U16_LE;
break;
...
default:
if (AOUT_FMT_SPDIF(>format))
spdif = var_InheritBool (aout, "spdif");
if (spdif)
{
fourcc = VLC_CODEC_SPDIFL;
pcm_format = SND_PCM_FORMAT_S16;
}
else
if (HAVE_FPU)
{
fourcc = VLC_CODEC_FL32;
pcm_format = SND_PCM_FORMAT_FLOAT;
}
else
{
fourcc = VLC_CODEC_S16N;
pcm_format = SND_PCM_FORMAT_S16;
}
}

/* Choose the IEC device for S/PDIF output:
   if the device is overridden by the user then it will be the one.
   Otherwise we compute the default device based on the output format. */
if (spdif && !strcmp (device, "default"))
{
unsigned aes3;

switch (aout->format.i_rate)
{
#define FS(freq) \
case freq: aes3 = IEC958_AES3_CON_FS_ ## freq; break;
FS( 44100) /* def. */ FS( 48000) FS( 32000)
FS( 22050)FS( 24000)
FS( 88200) FS(768000) FS( 96000)
FS(176400)FS(192000)
#undef FS
default:
aes3 = IEC958_AES3_CON_FS_NOTID;
break;
}

free (device);
if (asprintf (,
  "iec958:AES0=0x%x,AES1=0x%x,AES2=0x%x,AES3=0x%x",
  IEC958_AES0_CON_EMPHASIS_NONE | IEC958_AES0_NONAUDIO,
  IEC958_AES1_CON_ORIGINAL | IEC958_AES1_CON_PCM_CODER,
  0, aes3) == -1)
return VLC_ENOMEM;
}
...
/* VLC always has a resampler. No need for ALSA's. */
const int mode = SND_PCM_NO_AUTO_RESAMPLE;

int val = snd_pcm_open (, device, SND_PCM_STREAM_PLAYBACK, mode);

So, the result is:

* VLC opens the ALSA device _without_ AES information if the fourcc
  being passed if the format is a linear PCM type.

* If the format is not a linear PCM type _and_ it is a format which
  satisfies AOUT_FMT_SPDIF(), _and_ the SPDIF passthrough option is
  enabled, _then_ we open the IEC958 audio output device with the
  first four AES data bytes specified with SND_PCM_FORMAT_S16.
  Moreover, the first data byte always indicates that the stream is
  non-audio.

So, in the case of linear PCM, the AES data bytes are *not* specified
by VLC.

So, if we don't have the kernel driver specifying the IEC958 information
for HDMI/SPDIF outputs, and users of ALSA's userspace APIs don't generate
them for linear PCM, how are the required AES data bytes generated?

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[alsa-devel] [PATCH 12/13] drm: bridge/dw_hdmi-ahb-audio: add audio driver

On Sat, May 09, 2015 at 08:07:45PM +0300, Anssi Hannula wrote:
> 09.05.2015, 19:55, Russell King - ARM Linux kirjoitti:
> > On Sat, May 09, 2015 at 07:49:44PM +0300, Anssi Hannula wrote:
> >> (Of course having userspace set them requires that the device has a
> >> proper entry in /usr/share/alsa/cards and the pcm device is accessed via
> >> the standard "hdmi" or "iec958" device names which perform the channel
> >> status word setup. I guess the ARM SoC stuff generally doesn't bother
> >> with that, explaining a bit why some kernel drivers set them by 
> >> themselves).
> > 
> > I'm not sure that's sufficient - I haven't yet found where in the ALSA
> > userspace, the AES bits are appropriately set according to the sample
> > rate.
> 
> Right, that is left to the applications (e.g. VLC and Kodi do that). I'm
> under the impression that sinks do not normally care about this value,
> though, but that could just be because most desktop HW sets it by
> themselves.

No, that seems totally wrong to me.

What if you open the device using aplay?  Or pulseaudio?  Or madplay?
Or another audio application which thinks it's addressing a standard
PCM device.

Why should every audio user have some code in it to generate the IEC
bits?

Even VLC _doesn't_ if it's outputting to a standard audio - in other
words, if you don't tick the SPDIF direct output option which defaults
to disabled (which, when enabled, opens the device passing the AES
bits _and_ permits it to send a compressed audio stream.)  I've looked
at this in VLC many times...

I think you're a little confused about what userspace does here.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[alsa-devel] [PATCH 12/13] drm: bridge/dw_hdmi-ahb-audio: add audio driver

On Sat, May 09, 2015 at 07:49:44PM +0300, Anssi Hannula wrote:
> (Of course having userspace set them requires that the device has a
> proper entry in /usr/share/alsa/cards and the pcm device is accessed via
> the standard "hdmi" or "iec958" device names which perform the channel
> status word setup. I guess the ARM SoC stuff generally doesn't bother
> with that, explaining a bit why some kernel drivers set them by themselves).

I'm not sure that's sufficient - I haven't yet found where in the ALSA
userspace, the AES bits are appropriately set according to the sample
rate.

> HDMI_FC_AUDICONF2 register default value is 0x00, which means plain
> stereo (per CEA-861). If this is what goes on to the HDMI link as well,
> the audio sink should ignore the other channels.
> Did you check that multichannel PCM actually works? (maybe I'm just
> missing where CA is set)

I have no way to test multichannel support - not everyone has a plethora
of HDMI devices readily accessible.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD

https://bugs.freedesktop.org/show_bug.cgi?id=88152

--- Comment #39 from Arthur Marsh  ---
Somehow, for the most part I'm no longer experiencing lock-ups.

Kernel is Linus' is current git head:

Linux version 4.1.0-rc2+ (root at am64) (gcc version 5.1.1 (Debian 5
.1.1-4) ) #1700 SMP PREEMPT Sat May 9 14:01:46 ACST 2015

DDX is 1:7.5.0-1+b1
libdrm is 2.4.60-3
mesa is 10.4.2-2
libc6 is 2.19-18

vlc is 2.2.1-1+b1

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150509/a0bab379/attachment.html>

[PATCH libdrm 2/2] ioctl: Add new blob-property-creation ioctl

Signed-off-by: Daniel Stone 
---
 include/drm/drm.h  |  2 ++
 include/drm/drm_mode.h | 20 
 2 files changed, 22 insertions(+)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 44ef685..66028a6 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -766,6 +766,8 @@ struct drm_prime_handle {
 #define DRM_IOCTL_MODE_OBJ_SETPROPERTY DRM_IOWR(0xBA, struct 
drm_mode_obj_set_property)
 #define DRM_IOCTL_MODE_CURSOR2 DRM_IOWR(0xBB, struct drm_mode_cursor2)
 #define DRM_IOCTL_MODE_ATOMIC  DRM_IOWR(0xBC, struct drm_mode_atomic)
+#define DRM_IOCTL_MODE_CREATEPROPBLOB  DRM_IOWR(0xBD, struct 
drm_mode_create_blob)
+#define DRM_IOCTL_MODE_DESTROYPROPBLOB DRM_IOWR(0xBE, struct 
drm_mode_destroy_blob)

 /**
  * Device specific ioctls should only be in their respective headers
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index b333102..952e6b4 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -544,4 +544,24 @@ struct drm_mode_atomic {
__u64 user_data;
 };

+/**
+ * Create a new 'blob' data property, copying length bytes from data pointer,
+ * and returning new blob ID.
+ */
+struct drm_mode_create_blob {
+   /** Pointer to data to copy. */
+   __u64 data;
+   /** Length of data to copy. */
+   __u32 length;
+   /** Return: new property ID. */
+   __u32 blob_id;
+};
+
+/**
+ * Destroy a user-created blob property.
+ */
+struct drm_mode_destroy_blob {
+   __u32 blob_id;
+};
+
 #endif
-- 
2.4.0

[PATCH libdrm 1/2] Resync header files with kernel

Pull new drm.h and drm_mode.h definitions for client caps and atomic
ioctl.

Signed-off-by: Daniel Stone 
---
 include/drm/drm.h  | 23 ++-
 include/drm/drm_mode.h | 43 ---
 2 files changed, 62 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 229a29f..44ef685 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -635,6 +635,13 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_UNIVERSAL_PLANES 2

+/**
+ * DRM_CLIENT_CAP_ATOMIC
+ *
+ * If set to 1, the DRM core will expose atomic properties to userspace
+*/
+ #define DRM_CLIENT_CAP_ATOMIC  3
+
 /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
@@ -758,10 +765,11 @@ struct drm_prime_handle {
 #define DRM_IOCTL_MODE_OBJ_GETPROPERTIES   DRM_IOWR(0xB9, struct 
drm_mode_obj_get_properties)
 #define DRM_IOCTL_MODE_OBJ_SETPROPERTY DRM_IOWR(0xBA, struct 
drm_mode_obj_set_property)
 #define DRM_IOCTL_MODE_CURSOR2 DRM_IOWR(0xBB, struct drm_mode_cursor2)
+#define DRM_IOCTL_MODE_ATOMIC  DRM_IOWR(0xBC, struct drm_mode_atomic)

 /**
  * Device specific ioctls should only be in their respective headers
- * The device specific ioctl range is from 0x40 to 0x99.
+ * The device specific ioctl range is from 0x40 to 0x9f.
  * Generic IOCTLS restart at 0xA0.
  *
  * \sa drmCommandNone(), drmCommandRead(), drmCommandWrite(), and
@@ -807,6 +815,19 @@ struct drm_event_vblank {
 #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
 #define DRM_CAP_ASYNC_PAGE_FLIP 0x7

+/*
+ * The CURSOR_WIDTH and CURSOR_HEIGHT capabilities return a valid widthxheight
+ * combination for the hardware cursor. The intention is that a hardware
+ * agnostic userspace can query a cursor plane size to use.
+ *
+ * Note that the cross-driver contract is to merely return a valid size;
+ * drivers are free to attach another meaning on top, eg. i915 returns the
+ * maximum plane size.
+ */
+#define DRM_CAP_CURSOR_WIDTH   0x8
+#define DRM_CAP_CURSOR_HEIGHT  0x9
+#define DRM_CAP_ADDFB2_MODIFIERS   0x10
+
 #define DRM_PRIME_CAP_IMPORT 0x1
 #define DRM_PRIME_CAP_EXPORT 0x2

diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index a2ab88a..b333102 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -82,6 +82,11 @@
 #define DRM_MODE_SCALE_CENTER  2 /* Centered, no scaling */
 #define DRM_MODE_SCALE_ASPECT  3 /* Full screen, preserve aspect */

+/* Picture aspect ratio options */
+#define DRM_MODE_PICTURE_ASPECT_NONE   0
+#define DRM_MODE_PICTURE_ASPECT_4_31
+#define DRM_MODE_PICTURE_ASPECT_16_9   2
+
 /* Dithering mode options */
 #define DRM_MODE_DITHERING_OFF 0
 #define DRM_MODE_DITHERING_ON  1
@@ -340,18 +345,27 @@ struct drm_mode_fb_cmd2 {
 *   followed by an interleaved U/V plane containing
 *   8 bit 2x2 subsampled colour difference samples.
 *
-* So it would consist of Y as offset[0] and UV as
-* offset[1].  Note that offset[0] will generally
-* be 0.
+* So it would consist of Y as offsets[0] and UV as
+* offsets[1].  Note that offsets[0] will generally
+* be 0 (but this is not required).
+*
+* To accommodate tiled, compressed, etc formats, a per-plane
+* modifier can be specified.  The default value of zero
+* indicates "native" format as specified by the fourcc.
+* Vendor specific modifier token.  This allows, for example,
+* different tiling/swizzling pattern on different planes.
+* See discussion above of DRM_FORMAT_MOD_xxx.
 */
__u32 handles[4];
__u32 pitches[4]; /* pitch for each plane */
__u32 offsets[4]; /* offset of each plane */
+   __u64 modifier[4]; /* ie, tiling, compressed (per plane) */
 };

 #define DRM_MODE_FB_DIRTY_ANNOTATE_COPY 0x01
 #define DRM_MODE_FB_DIRTY_ANNOTATE_FILL 0x02
 #define DRM_MODE_FB_DIRTY_FLAGS 0x03
+#define DRM_MODE_FB_DIRTY_MAX_CLIPS 256

 /*
  * Mark a region of a framebuffer as dirty.
@@ -507,4 +521,27 @@ struct drm_mode_destroy_dumb {
__u32 handle;
 };

+/* page-flip flags are valid, plus: */
+#define DRM_MODE_ATOMIC_TEST_ONLY 0x0100
+#define DRM_MODE_ATOMIC_NONBLOCK  0x0200
+#define DRM_MODE_ATOMIC_ALLOW_MODESET 0x0400
+
+#define DRM_MODE_ATOMIC_FLAGS (\
+   DRM_MODE_PAGE_FLIP_EVENT |\
+   DRM_MODE_PAGE_FLIP_ASYNC |\
+   DRM_MODE_ATOMIC_TEST_ONLY |\
+   DRM_MODE_ATOMIC_NONBLOCK |\
+   DRM_MODE_ATOMIC_ALLOW_MODESET)
+
+struct drm_mode_atomic {
+   __u32 flags;
+   __u32 count_objs;
+   __u64 objs_ptr;
+   __u64 count_props_ptr;
+   __u64 props_ptr;
+   __u64 prop_values_ptr;
+   __u64 reserved;
+   __u64 user_data;
+};
+
 #endif
-- 
2.4.0

[PATCH libdrm v2 0/2] User-created blob properties

Hi,
This is the userspace component to:
http://lists.freedesktop.org/archives/dri-devel/2015-May/082530.html

Cheers,
Daniel

[PATCH 4/4] drm/mode: Add user blob-creation ioctl

Add an ioctl which allows users to create blob properties from supplied
data. Currently this only supports modes, creating a drm_display_mode from
the userspace drm_mode_modeinfo.

v2: Removed size/type checks.
Rebased on new patches to allow error propagation from create_blob,
as well as avoiding double-allocation.

Signed-off-by: Daniel Stone 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_crtc.c  | 139 +++-
 drivers/gpu/drm/drm_fops.c  |   5 +-
 drivers/gpu/drm/drm_ioctl.c |   2 +
 include/drm/drmP.h  |   4 ++
 include/drm/drm_crtc.h  |   9 ++-
 include/uapi/drm/drm.h  |   2 +
 include/uapi/drm/drm_mode.h |  20 +++
 7 files changed, 176 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index df4a3fb..9546aed 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4232,6 +4232,9 @@ drm_property_create_blob(struct drm_device *dev, size_t 
length,
if (!blob)
return ERR_PTR(-ENOMEM);

+   /* This must be explicitly initialised, so we can safely call list_del
+* on it in the removal handler, even if it isn't in a file list. */
+   INIT_LIST_HEAD(>head_file);
blob->length = length;
blob->dev = dev;

@@ -4249,7 +4252,8 @@ drm_property_create_blob(struct drm_device *dev, size_t 
length,

kref_init(>refcount);

-   list_add_tail(>head, >mode_config.property_blob_list);
+   list_add_tail(>head_global,
+ >mode_config.property_blob_list);

mutex_unlock(>mode_config.blob_lock);

@@ -4271,7 +4275,8 @@ static void drm_property_free_blob(struct kref *kref)

WARN_ON(!mutex_is_locked(>dev->mode_config.blob_lock));

-   list_del(>head);
+   list_del(>head_global);
+   list_del(>head_file);
drm_mode_object_put(blob->dev, >base);

kfree(blob);
@@ -4324,6 +4329,26 @@ static void drm_property_unreference_blob_locked(struct 
drm_property_blob *blob)
 }

 /**
+ * drm_property_destroy_user_blobs - destroy all blobs created by this client
+ * @dev:   DRM device
+ * @file_priv: destroy all blobs owned by this file handle
+ */
+void drm_property_destroy_user_blobs(struct drm_device *dev,
+struct drm_file *file_priv)
+{
+   struct drm_property_blob *blob, *bt;
+
+   mutex_lock(>mode_config.blob_lock);
+
+   list_for_each_entry_safe(blob, bt, _priv->blobs, head_file) {
+   list_del_init(>head_file);
+   drm_property_unreference_blob_locked(blob);
+   }
+
+   mutex_unlock(>mode_config.blob_lock);
+}
+
+/**
  * drm_property_reference_blob - Take a reference on an existing property
  *
  * Take a new reference on an existing blob property.
@@ -4513,6 +4538,114 @@ done:
 }

 /**
+ * drm_mode_createblob_ioctl - create a new blob property
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * This function creates a new blob property with user-defined values. In order
+ * to give us sensible validation and checking when creating, rather than at
+ * every potential use, we also require a type to be provided upfront.
+ *
+ * Called by the user via ioctl.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_mode_createblob_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+   struct drm_mode_create_blob *out_resp = data;
+   struct drm_property_blob *blob;
+   void __user *blob_ptr;
+   int ret = 0;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   blob = drm_property_create_blob(dev, out_resp->length, NULL);
+   if (IS_ERR(blob))
+   return PTR_ERR(blob);
+
+   blob_ptr = (void __user *)(unsigned long)out_resp->data;
+   if (copy_from_user(blob->data, blob_ptr, out_resp->length)) {
+   ret = -EFAULT;
+   goto out_blob;
+   }
+
+   /* Dropping the lock between create_blob and our access here is safe
+* as only the same file_priv can remove the blob; at this point, it is
+* not associated with any file_priv. */
+   mutex_lock(>mode_config.blob_lock);
+   out_resp->blob_id = blob->base.id;
+   list_add_tail(_priv->blobs, >head_file);
+   mutex_unlock(>mode_config.blob_lock);
+
+   return 0;
+
+out_blob:
+   drm_property_unreference_blob(blob);
+   return ret;
+}
+
+/**
+ * drm_mode_destroyblob_ioctl - destroy a user blob property
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Destroy an existing user-defined blob property.
+ *
+ * Called by the user via ioctl.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_mode_destroyblob_ioctl(struct drm_device *dev,
+  void *data, struct drm_file *file_priv)
+{
+   struct

[PATCH 3/4] drm: Return error value from blob creation

Change drm_property_create_blob to return an ERR_PTR-encoded error on
failure, so we can pass the failure reason down.

Signed-off-by: Daniel Stone 
Cc: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_crtc.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f7b075b..df4a3fb 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4213,6 +4213,10 @@ done:
  * @param dev DRM device to create property for
  * @param length Length to allocate for blob data
  * @param data If specified, copies data into blob
+ *
+ * Returns:
+ * New blob property with a single reference on success, or an ERR_PTR
+ * value on failure.
  */
 struct drm_property_blob *
 drm_property_create_blob(struct drm_device *dev, size_t length,
@@ -4222,11 +4226,11 @@ drm_property_create_blob(struct drm_device *dev, size_t 
length,
int ret;

if (!length)
-   return NULL;
+   return ERR_PTR(-EINVAL);

blob = kzalloc(sizeof(struct drm_property_blob)+length, GFP_KERNEL);
if (!blob)
-   return NULL;
+   return ERR_PTR(-ENOMEM);

blob->length = length;
blob->dev = dev;
@@ -4240,7 +4244,7 @@ drm_property_create_blob(struct drm_device *dev, size_t 
length,
if (ret) {
kfree(blob);
mutex_unlock(>mode_config.blob_lock);
-   return NULL;
+   return ERR_PTR(-EINVAL);
}

kref_init(>refcount);
@@ -4430,8 +4434,8 @@ static int drm_property_replace_global_blob(struct 
drm_device *dev,

if (length && data) {
new_blob = drm_property_create_blob(dev, length, data);
-   if (!new_blob)
-   return -EINVAL;
+   if (IS_ERR(new_blob))
+   return PTR_ERR(new_blob);
}

/* This does not need to be synchronised with blob_lock, as the
-- 
2.4.0

[PATCH 2/4] drm: Allow creating blob properties without copy

Make the data parameter to drm_property_create_blob optional; if
omitted, the copy will be skipped and the data will be empty.

Signed-off-by: Daniel Stone 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_crtc.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6f3cafb..f7b075b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4204,6 +4204,16 @@ done:
return ret;
 }

+/**
+ * drm_property_create_blob - Create new blob property
+ *
+ * Creates a new blob property for a specified DRM device, optionally
+ * copying data.
+ *
+ * @param dev DRM device to create property for
+ * @param length Length to allocate for blob data
+ * @param data If specified, copies data into blob
+ */
 struct drm_property_blob *
 drm_property_create_blob(struct drm_device *dev, size_t length,
 const void *data)
@@ -4211,7 +4221,7 @@ drm_property_create_blob(struct drm_device *dev, size_t 
length,
struct drm_property_blob *blob;
int ret;

-   if (!length || !data)
+   if (!length)
return NULL;

blob = kzalloc(sizeof(struct drm_property_blob)+length, GFP_KERNEL);
@@ -4221,7 +4231,8 @@ drm_property_create_blob(struct drm_device *dev, size_t 
length,
blob->length = length;
blob->dev = dev;

-   memcpy(blob->data, data, length);
+   if (data)
+   memcpy(blob->data, data, length);

mutex_lock(>mode_config.blob_lock);

-- 
2.4.0

[PATCH 1/4] drm: Remove extraneous parameter from kerneldoc

672cb1d6ae mistakenly added an extra parameter to the kerneldoc for
drm_property_unreference_blob which wasn't actually present.

Signed-off-by: Daniel Stone 
---
 drivers/gpu/drm/drm_crtc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4f922aa..6f3cafb 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4267,7 +4267,6 @@ static void drm_property_free_blob(struct kref *kref)
  *
  * Drop a reference on a blob property. May free the object.
  *
- * @param dev  Device the blob was created on
  * @param blob Pointer to blob property
  */
 void drm_property_unreference_blob(struct drm_property_blob *blob)
-- 
2.4.0

[PATCH v2] User-created blob properties

Hi,
With most of the supporting series already merged into drm-misc,
this is a resend after Maarten and Daniel's review of the core creation
ioctl.

Notably, size/type validation is now gone, as well as the double
allocation. Errors from blob creation are also propagated down through
ERR_PTR.

Cheers,
Daniel

[GIT PULL] TDA998x I2C driver development updates

David,

Please incorporate the latest TDA998x I2C driver development updates,
which can be found at:

  git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-tda998x-devel

with SHA1 8c7a075da9f7980cc95ffcd7e6621d4a87f20f40.

Just one commit to convert TDA998x to use the HDMI AVI infoframe helper.

This will update the following files:

 drivers/gpu/drm/i2c/tda998x_drv.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

through these changes:

Russell King (1):
  drm/i2c: tda998x: use drm_hdmi_avi_infoframe_from_display_mode()

Many thanks.

[GIT PULL] Armada DRM development updates development updates

David,

Please incorporate the latest Armada DRM development updates development
updates, which can be found at:

  git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-armada-devel

with SHA1 38bf3aee3ec7b5b264b701da14114a618cddd1a1.

A couple of cleanups from Rickard Strandqvist to remove some unused
functions.

This will update the following files:

 drivers/gpu/drm/armada/armada_drm.h|  2 --
 drivers/gpu/drm/armada/armada_drv.c| 10 --
 drivers/gpu/drm/armada/armada_output.c | 16 
 drivers/gpu/drm/armada/armada_output.h |  6 --
 4 files changed, 34 deletions(-)

through these changes:

Rickard Strandqvist (2):
  drm/armada: armada_output: Remove some unused functions
  drm/armada: armada_drv: Remove unused function

Many thanks.

drm/exynos: Add atomic modesetting support

And here's the drm.debug=0xff output leading to the oops:
> [  109.575582] [drm:drm_stub_open] 
> [  109.575609] [drm:drm_open_helper] pid = 2430, minor = 0
> [  109.575630] [drm:ipp_subdrv_open] done priv[0xed9b7e10]
> [  109.575647] [drm:drm_setup] 
> [  109.575699] [drm:drm_ioctl] pid=2430, dev=0xe200, auth=1, DRM_IOCTL_VERSION
> [  109.575719] [drm:drm_ioctl] pid=2430, dev=0xe200, auth=1, DRM_IOCTL_VERSION
> [  109.575764] [drm:drm_release] open_count = 1
> [  109.575786] [drm:drm_release] pid = 2430, device = 0xe200, open_count = 1
> [  109.575810] [drm:drm_lastclose] 
> [  109.575856] [drm:drm_atomic_state_alloc] Allocate atomic state edbdb100
> [  109.575876] [drm:drm_atomic_get_crtc_state] Added [CRTC:21] ed10d600 state 
> to edbdb100
> [  109.575893] [drm:drm_atomic_get_plane_state] Added [PLANE:17] edbdb900 
> state to edbdb100
> [  109.575906] [drm:drm_atomic_set_crtc_for_plane] Link plane state edbdb900 
> to [NOCRTC]
> [  109.575918] [drm:drm_atomic_set_fb_for_plane] Set [NOFB] for plane state 
> edbdb900
> [  109.575933] [drm:drm_atomic_add_affected_connectors] Adding all current 
> connectors for [CRTC:21] to edbdb100
> [  109.575947] [drm:drm_atomic_check_only] checking edbdb100
> [  109.575965] [drm:drm_atomic_commit] commiting edbdb100
> [  109.575996] Unable to handle kernel NULL pointer dereference at virtual 
> address 00a4

I've tried to do this in userspace by running modetest through gdb, but
I can't seem to break when the segfault occurs (modetest is already dead
when gdb attempts to break).

I hope this makes it easier to isolate the issue.

With best wishes,
Tobias

drm/exynos: Add atomic modesetting support

Tobias Jakobi wrote:
> Hello Inki,
> 
> 
> Inki Dae wrote:
>> Hi,
>>
>> 2015-05-09 6:51 GMT+09:00 Tobias Jakobi :
>>> Hello,
>>>
>>> I've tested this on my Hardkernel Odroid-X2 (connected via HDMI to a
>>> 1080p panel).
>>>
>>> Run the usual modetest tests (just primary plane, primary plane with
>>> vsync, primary plane with overlay, primary plane with overlay and video
>>> overlay, overlay partially outside of crtc area, etc.) and haven't
>>> noticed any issues so far.
>>
>> As I mentioned several times, it works well in case that only one crtc
>> driver is enabled. Could you check it again after you enable two or
>> more crtc drivers such as FIMD and HDMI or FIMD, HDMI and VIDI
>> together? For this, dts file for X2 should contain their device nodes
>> and also should be configurated though menuconfig.
> I've enabled VIDI and FIMD and confirmed that they should up properly in
> modetest before applying the series.
This should read "...show up properly..."



> 
> Booting with the atomic series works fine, but I get a segfault when
> calling modetest. I've attached the kernel log below.
> 
> 
> 
>>> Kernel log is 'clean', so the series works fine for me.
>>>
>>> You can add my
>>> Tested-by: Tobias Jakobi 
>>
>> So you didn't test it correctly yet.
> I tested the common usage scenario. In fact I can't really test with
> FIMD anyway, since I don't have any panel that I can attach to the LCD
> expansion port. Regardless of whether the kernel oopses or anything with
> atomic, I can never make sure that the FIMD visuals are actually correct.
> 
> 
> With best wishes,
> Tobias
> 
>> Thanks,
>> Inki Dae
>>
> 
> 
> 
> Kernel log (after triggering segfault with modetest):
>> liquid at chidori ~/sourcecode/video/drm/tests/modetest $ dmesg
>> [0.00] Booting Linux on physical CPU 0xa00
>> [0.00] Initializing cgroup subsys cpuset
>> [0.00] Initializing cgroup subsys cpuacct
>> [0.00] Linux version 4.1.0-rc2-debug+ (liquid at chidori) (gcc 
>> version 4.8.3 (Gentoo 4.8.3 p1.1, pie-0.5.9) ) #4 SMP PREEMPT Sat May 9 
>> 05:11:08 CEST 2015
>> [0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), 
>> cr=10c5387d
>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
>> instruction cache
>> [0.00] Machine model: Hardkernel ODROID-X2 board based on Exynos4412
>> [0.00] earlycon: no match for ttySAC1,115200n8
>> [0.00] bootconsole [earlycon0] enabled
>> [0.00] Reserved memory: created CMA memory pool at 0x7700, size 
>> 16 MiB
>> [0.00] Reserved memory: initialized node region at 7700, 
>> compatible id shared-dma-pool
>> [0.00] Reserved memory: created CMA memory pool at 0x7800, size 
>> 16 MiB
>> [0.00] Reserved memory: initialized node region at 7800, 
>> compatible id shared-dma-pool
>> [0.00] cma: Reserved 128 MiB at 0xb7c0
>> [0.00] Memory policy: Data cache writealloc
>> [0.00] Samsung CPU ID: 0xe4412220
>> [0.00] On node 0 totalpages: 524032
>> [0.00] free_area_init_node: node 0, pgdat c0712980, node_mem_map 
>> ee7f5000
>> [0.00]   Normal zone: 1520 pages used for memmap
>> [0.00]   Normal zone: 0 pages reserved
>> [0.00]   Normal zone: 194560 pages, LIFO batch:31
>> [0.00]   HighMem zone: 329472 pages, LIFO batch:31
>> [0.00] Running under secure firmware.
>> [0.00] PERCPU: Embedded 12 pages/cpu @ee786000 s17600 r8192 d23360 
>> u49152
>> [0.00] pcpu-alloc: s17600 r8192 d23360 u49152 alloc=12*4096
>> [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
>> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
>> pages: 522512
>> [0.00] Kernel command line: video=HDMI-A-1:1280x720M at 60 
>> console=ttySAC1,115200n8 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait ro 
>> earlyprintk
>> [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
>> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
>> bytes)
>> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
>> [0.00] Memory: 1907080K/2096128K available (5067K kernel code, 230K 
>> rwdata, 1696K rodata, 228K init, 255K bss, 25208K reserved, 163840K 
>> cma-reserved, 1154048K highmem)
>> [0.00] Virtual kernel memory layout:
>> vector  : 0x - 0x1000   (   4 kB)
>> fixmap  : 0xffc0 - 0xfff0   (3072 kB)
>> vmalloc : 0xf000 - 0xff00   ( 240 MB)
>> lowmem  : 0xc000 - 0xef80   ( 760 MB)
>> pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>> modules : 0xbf00 - 0xbfe0   (  14 MB)
>>   .text : 0xc0008000 - 0xc06a2fb4   (6764 kB)
>>   .init : 0xc06a3000 - 0xc06dc000   ( 228 kB)
>>   .data : 0xc06dc000 - 0xc0715a18   ( 231 kB)
>>.bss : 0xc0718000 - 0xc0757d28   ( 256 kB)
>> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
>> [

drm/exynos: Add atomic modesetting support

Hello Inki,


Inki Dae wrote:
> Hi,
> 
> 2015-05-09 6:51 GMT+09:00 Tobias Jakobi :
>> Hello,
>>
>> I've tested this on my Hardkernel Odroid-X2 (connected via HDMI to a
>> 1080p panel).
>>
>> Run the usual modetest tests (just primary plane, primary plane with
>> vsync, primary plane with overlay, primary plane with overlay and video
>> overlay, overlay partially outside of crtc area, etc.) and haven't
>> noticed any issues so far.
> 
> As I mentioned several times, it works well in case that only one crtc
> driver is enabled. Could you check it again after you enable two or
> more crtc drivers such as FIMD and HDMI or FIMD, HDMI and VIDI
> together? For this, dts file for X2 should contain their device nodes
> and also should be configurated though menuconfig.
I've enabled VIDI and FIMD and confirmed that they should up properly in
modetest before applying the series.

Booting with the atomic series works fine, but I get a segfault when
calling modetest. I've attached the kernel log below.



>> Kernel log is 'clean', so the series works fine for me.
>>
>> You can add my
>> Tested-by: Tobias Jakobi 
> 
> So you didn't test it correctly yet.
I tested the common usage scenario. In fact I can't really test with
FIMD anyway, since I don't have any panel that I can attach to the LCD
expansion port. Regardless of whether the kernel oopses or anything with
atomic, I can never make sure that the FIMD visuals are actually correct.


With best wishes,
Tobias

> Thanks,
> Inki Dae
> 



Kernel log (after triggering segfault with modetest):
> liquid at chidori ~/sourcecode/video/drm/tests/modetest $ dmesg
> [0.00] Booting Linux on physical CPU 0xa00
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 4.1.0-rc2-debug+ (liquid at chidori) (gcc 
> version 4.8.3 (Gentoo 4.8.3 p1.1, pie-0.5.9) ) #4 SMP PREEMPT Sat May 9 
> 05:11:08 CEST 2015
> [0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] Machine model: Hardkernel ODROID-X2 board based on Exynos4412
> [0.00] earlycon: no match for ttySAC1,115200n8
> [0.00] bootconsole [earlycon0] enabled
> [0.00] Reserved memory: created CMA memory pool at 0x7700, size 
> 16 MiB
> [0.00] Reserved memory: initialized node region at 7700, 
> compatible id shared-dma-pool
> [0.00] Reserved memory: created CMA memory pool at 0x7800, size 
> 16 MiB
> [0.00] Reserved memory: initialized node region at 7800, 
> compatible id shared-dma-pool
> [0.00] cma: Reserved 128 MiB at 0xb7c0
> [0.00] Memory policy: Data cache writealloc
> [0.00] Samsung CPU ID: 0xe4412220
> [0.00] On node 0 totalpages: 524032
> [0.00] free_area_init_node: node 0, pgdat c0712980, node_mem_map 
> ee7f5000
> [0.00]   Normal zone: 1520 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 194560 pages, LIFO batch:31
> [0.00]   HighMem zone: 329472 pages, LIFO batch:31
> [0.00] Running under secure firmware.
> [0.00] PERCPU: Embedded 12 pages/cpu @ee786000 s17600 r8192 d23360 
> u49152
> [0.00] pcpu-alloc: s17600 r8192 d23360 u49152 alloc=12*4096
> [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 522512
> [0.00] Kernel command line: video=HDMI-A-1:1280x720M at 60 
> console=ttySAC1,115200n8 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait ro 
> earlyprintk
> [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
> bytes)
> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> [0.00] Memory: 1907080K/2096128K available (5067K kernel code, 230K 
> rwdata, 1696K rodata, 228K init, 255K bss, 25208K reserved, 163840K 
> cma-reserved, 1154048K highmem)
> [0.00] Virtual kernel memory layout:
> vector  : 0x - 0x1000   (   4 kB)
> fixmap  : 0xffc0 - 0xfff0   (3072 kB)
> vmalloc : 0xf000 - 0xff00   ( 240 MB)
> lowmem  : 0xc000 - 0xef80   ( 760 MB)
> pkmap   : 0xbfe0 - 0xc000   (   2 MB)
> modules : 0xbf00 - 0xbfe0   (  14 MB)
>   .text : 0xc0008000 - 0xc06a2fb4   (6764 kB)
>   .init : 0xc06a3000 - 0xc06dc000   ( 228 kB)
>   .data : 0xc06dc000 - 0xc0715a18   ( 231 kB)
>.bss : 0xc0718000 - 0xc0757d28   ( 256 kB)
> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [0.00] Preemptible hierarchical RCU implementation.
> [0.00] NR_IRQS:16 nr_irqs:16 16
> [0.00] L2C: platform modifies aux control register: 0x0207 -> 
> 0x3e470001
> [0.00] L2C:

[PATCH 13/13] drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver

Parse the ELD (EDID like data) stored from the HDMI driver to restrict
the sample rates and channels which are available to ALSA.  This causes
the ALSA device to reflect the capabilities of the overall audio path,
not just what is supported at the HDMI source interface level.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/Kconfig | 1 +
 drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c | 6 ++
 drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.h | 1 +
 drivers/gpu/drm/bridge/dw_hdmi.c   | 3 +++
 4 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 56ed35fe0734..204861bfb867 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -7,6 +7,7 @@ config DRM_DW_HDMI_AHB_AUDIO
tristate "Synopsis Designware AHB Audio interface"
depends on DRM_DW_HDMI && SND
select SND_PCM
+   select SND_PCM_ELD
select SND_PCM_IEC958
help
  Support the AHB Audio interface which is part of the Synopsis
diff --git a/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c 
b/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c
index e98c291268f4..2bb68bda3cb0 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c
@@ -12,11 +12,13 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "dw_hdmi-ahb-audio.h"
@@ -284,6 +286,10 @@ static int dw_hdmi_open(struct snd_pcm_substream 
*substream)

runtime->hw = dw_hdmi_hw;

+   ret = snd_pcm_hw_constraint_eld(runtime, dw->data.eld);
+   if (ret < 0)
+   return ret;
+
ret = snd_pcm_limit_hw_rates(runtime);
if (ret < 0)
return ret;
diff --git a/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.h 
b/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.h
index 1e840118d90a..91f631beecc7 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.h
+++ b/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.h
@@ -8,6 +8,7 @@ struct dw_hdmi_audio_data {
void __iomem *base;
int irq;
struct dw_hdmi *hdmi;
+   u8 *eld;
 };

 #endif
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 1cb427935ed2..dc0aed18019d 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1446,6 +1446,8 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)

drm_mode_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
+   /* Store the ELD */
+   drm_edid_to_eld(connector, edid);
kfree(edid);
} else {
dev_dbg(hdmi->dev, "failed to get edid\n");
@@ -1725,6 +1727,7 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
audio.base = hdmi->regs;
audio.irq = irq;
audio.hdmi = hdmi;
+   audio.eld = hdmi->connector.eld;

pdevinfo.name = "dw-hdmi-ahb-audio";
pdevinfo.data = 
-- 
1.8.3.1

[PATCH 12/13] drm: bridge/dw_hdmi-ahb-audio: add audio driver

Add ALSA based HDMI AHB audio driver for dw_hdmi.  The only buffer
format supported by the hardware is its own special IEC958 based format,
which is not compatible with any ALSA format.  To avoid doing too much
data manipulation within the driver, we support only ALSAs IEC958 LE and
24-bit PCM formats for 2 to 6 channels, which we convert to its hardware
format.

A more desirable solution would be to have this conversion in userspace,
but ALSA does not appear to allow such transformations outside of
libasound itself.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/Kconfig |  10 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c | 560 +
 drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.h |  13 +
 drivers/gpu/drm/bridge/dw_hdmi.c   |  24 ++
 drivers/gpu/drm/bridge/dw_hdmi.h   |   3 +
 6 files changed, 611 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c
 create mode 100644 drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index acef3223772c..56ed35fe0734 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -3,6 +3,16 @@ config DRM_DW_HDMI
depends on DRM
select DRM_KMS_HELPER

+config DRM_DW_HDMI_AHB_AUDIO
+   tristate "Synopsis Designware AHB Audio interface"
+   depends on DRM_DW_HDMI && SND
+   select SND_PCM
+   select SND_PCM_IEC958
+   help
+ Support the AHB Audio interface which is part of the Synopsis
+ Designware HDMI block.  This is used in conjunction with
+ the i.MX6 HDMI driver.
+
 config DRM_PTN3460
tristate "PTN3460 DP/LVDS bridge"
depends on DRM
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 8dfebd984370..eb80dbbb8365 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,3 +3,4 @@ ccflags-y := -Iinclude/drm
 obj-$(CONFIG_DRM_PS8622) += ps8622.o
 obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
+obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw_hdmi-ahb-audio.o
diff --git a/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c 
b/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c
new file mode 100644
index ..e98c291268f4
--- /dev/null
+++ b/drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c
@@ -0,0 +1,560 @@
+/*
+ * DesignWare HDMI audio driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Written and tested against the Designware HDMI Tx found in iMX6.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dw_hdmi-ahb-audio.h"
+
+#define DRIVER_NAME "dw-hdmi-ahb-audio"
+
+/* Provide some bits rather than bit offsets */
+enum {
+   HDMI_AHB_DMA_CONF0_SW_FIFO_RST = BIT(7),
+   HDMI_AHB_DMA_CONF0_EN_HLOCK = BIT(3),
+   HDMI_AHB_DMA_START_START = BIT(0),
+   HDMI_AHB_DMA_STOP_STOP = BIT(0),
+   HDMI_IH_MUTE_AHBDMAAUD_STAT0_ERROR = BIT(5),
+   HDMI_IH_MUTE_AHBDMAAUD_STAT0_LOST = BIT(4),
+   HDMI_IH_MUTE_AHBDMAAUD_STAT0_RETRY = BIT(3),
+   HDMI_IH_MUTE_AHBDMAAUD_STAT0_DONE = BIT(2),
+   HDMI_IH_MUTE_AHBDMAAUD_STAT0_BUFFFULL = BIT(1),
+   HDMI_IH_MUTE_AHBDMAAUD_STAT0_BUFFEMPTY = BIT(0),
+   HDMI_IH_MUTE_AHBDMAAUD_STAT0_ALL =
+   HDMI_IH_MUTE_AHBDMAAUD_STAT0_ERROR |
+   HDMI_IH_MUTE_AHBDMAAUD_STAT0_LOST |
+   HDMI_IH_MUTE_AHBDMAAUD_STAT0_RETRY |
+   HDMI_IH_MUTE_AHBDMAAUD_STAT0_DONE |
+   HDMI_IH_MUTE_AHBDMAAUD_STAT0_BUFFFULL |
+   HDMI_IH_MUTE_AHBDMAAUD_STAT0_BUFFEMPTY,
+   HDMI_IH_AHBDMAAUD_STAT0_ERROR = BIT(5),
+   HDMI_IH_AHBDMAAUD_STAT0_LOST = BIT(4),
+   HDMI_IH_AHBDMAAUD_STAT0_RETRY = BIT(3),
+   HDMI_IH_AHBDMAAUD_STAT0_DONE = BIT(2),
+   HDMI_IH_AHBDMAAUD_STAT0_BUFFFULL = BIT(1),
+   HDMI_IH_AHBDMAAUD_STAT0_BUFFEMPTY = BIT(0),
+   HDMI_IH_AHBDMAAUD_STAT0_ALL =
+   HDMI_IH_AHBDMAAUD_STAT0_ERROR |
+   HDMI_IH_AHBDMAAUD_STAT0_LOST |
+   HDMI_IH_AHBDMAAUD_STAT0_RETRY |
+   HDMI_IH_AHBDMAAUD_STAT0_DONE |
+   HDMI_IH_AHBDMAAUD_STAT0_BUFFFULL |
+   HDMI_IH_AHBDMAAUD_STAT0_BUFFEMPTY,
+   HDMI_AHB_DMA_CONF0_INCR16 = 2 << 1,
+   HDMI_AHB_DMA_CONF0_INCR8 = 1 << 1,
+   HDMI_AHB_DMA_CONF0_INCR4 = 0,
+   HDMI_AHB_DMA_CONF0_BURST_MODE = BIT(0),
+   HDMI_AHB_DMA_MASK_DONE = BIT(7),
+   HDMI_REVISION_ID = 0x0001,
+   HDMI_IH_AHBDMAAUD_STAT0 = 0x0109,
+   HDMI_IH_MUTE_AHBDMAAUD_STAT0 = 0x0189,
+   HDMI_AHB_DMA_CONF0 = 0x3600,
+   HDMI_AHB_DMA_START = 0x3601,
+   HDMI_AHB_DMA_STOP = 0x3602,
+

[PATCH 11/13] sound/core: add IEC958 channel status helper

Add a helper to create the IEC958 channel status from an ALSA
snd_pcm_runtime structure, taking account of the sample rate and
sample size.

Signed-off-by: Russell King 
---
 include/sound/pcm_iec958.h |  9 +
 sound/core/Kconfig |  3 ++
 sound/core/Makefile|  1 +
 sound/core/pcm_iec958.c| 95 ++
 4 files changed, 108 insertions(+)
 create mode 100644 include/sound/pcm_iec958.h
 create mode 100644 sound/core/pcm_iec958.c

diff --git a/include/sound/pcm_iec958.h b/include/sound/pcm_iec958.h
new file mode 100644
index ..0eed397aca8e
--- /dev/null
+++ b/include/sound/pcm_iec958.h
@@ -0,0 +1,9 @@
+#ifndef __SOUND_PCM_IEC958_H
+#define __SOUND_PCM_IEC958_H
+
+#include 
+
+int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
+   size_t len);
+
+#endif
diff --git a/sound/core/Kconfig b/sound/core/Kconfig
index b534c8a6046b..1507469425ec 100644
--- a/sound/core/Kconfig
+++ b/sound/core/Kconfig
@@ -9,6 +9,9 @@ config SND_PCM
 config SND_PCM_ELD
bool

+config SND_PCM_IEC958
+   bool
+
 config SND_DMAENGINE_PCM
tristate

diff --git a/sound/core/Makefile b/sound/core/Makefile
index 591b49157b4d..2b925fcc95ea 100644
--- a/sound/core/Makefile
+++ b/sound/core/Makefile
@@ -14,6 +14,7 @@ snd-pcm-y := pcm.o pcm_native.o pcm_lib.o pcm_timer.o 
pcm_misc.o \
pcm_memory.o memalloc.o
 snd-pcm-$(CONFIG_SND_DMA_SGBUF) += sgbuf.o
 snd-pcm-$(CONFIG_SND_PCM_ELD) += pcm_drm_eld.o
+snd-pcm-$(CONFIG_SND_PCM_IEC958) += pcm_iec958.o

 # for trace-points
 CFLAGS_pcm_lib.o := -I$(src)
diff --git a/sound/core/pcm_iec958.c b/sound/core/pcm_iec958.c
new file mode 100644
index ..36b2d7aca1bd
--- /dev/null
+++ b/sound/core/pcm_iec958.c
@@ -0,0 +1,95 @@
+/*
+ *  PCM DRM helpers
+ *
+ *   This program is free software; you can redistribute it and/or modify
+ *   it under the terms of the GNU General Public License version 2 as
+ *   published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * snd_pcm_create_iec958_consumer - create consumer format IEC958 channel 
status
+ * @runtime: pcm runtime structure with ->rate filled in
+ * @cs: channel status buffer, at least four bytes
+ * @len: length of channel status buffer
+ *
+ * Create the consumer format channel status data in @cs of maximum size
+ * @len corresponding to the parameters of the PCM runtime @runtime.
+ *
+ * Drivers may wish to tweak the contents of the buffer after creation.
+ *
+ * Returns: length of buffer, or negative error code if something failed.
+ */
+int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
+   size_t len)
+{
+   unsigned int fs, ws;
+
+   if (len < 4)
+   return -EINVAL;
+
+   switch (runtime->rate) {
+   case 32000:
+   fs = IEC958_AES3_CON_FS_32000;
+   break;
+   case 44100:
+   fs = IEC958_AES3_CON_FS_44100;
+   break;
+   case 48000:
+   fs = IEC958_AES3_CON_FS_48000;
+   break;
+   case 88200:
+   fs = IEC958_AES3_CON_FS_88200;
+   break;
+   case 96000:
+   fs = IEC958_AES3_CON_FS_96000;
+   break;
+   case 176400:
+   fs = IEC958_AES3_CON_FS_176400;
+   break;
+   case 192000:
+   fs = IEC958_AES3_CON_FS_192000;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   if (len > 4) {
+   switch (snd_pcm_format_width(runtime->format)) {
+   case 16:
+   ws = IEC958_AES4_CON_WORDLEN_20_16;
+   break;
+   case 18:
+   ws = IEC958_AES4_CON_WORDLEN_22_18;
+   break;
+   case 20:
+   ws = IEC958_AES4_CON_WORDLEN_20_16 |
+IEC958_AES4_CON_MAX_WORDLEN_24;
+   break;
+   case 24:
+   ws = IEC958_AES4_CON_WORDLEN_24_20 |
+IEC958_AES4_CON_MAX_WORDLEN_24;
+   break;
+
+   default:
+   return -EINVAL;
+   }
+   }
+
+   memset(cs, 0, len);
+
+   cs[0] = IEC958_AES0_CON_NOT_COPYRIGHT | IEC958_AES0_CON_EMPHASIS_NONE;
+   cs[1] = IEC958_AES1_CON_GENERAL;
+   cs[2] = IEC958_AES2_CON_SOURCE_UNSPEC | IEC958_AES2_CON_CHANNEL_UNSPEC;
+   cs[3] = IEC958_AES3_CON_CLOCK_1000PPM | fs;
+
+   if (len > 4)
+   cs[4] = ws;
+
+   return len;
+}
+EXPORT_SYMBOL(snd_pcm_create_iec958_consumer);
-- 
1.8.3.1

[PATCH 10/13] sound/core: add DRM ELD helper

Add a helper for the EDID like data structure, which is typically passed
from a HDMI adapter to its associated audio driver.  This informs the
audio driver of the capabilities of the attached HDMI sink.

Signed-off-by: Russell King 
---
 include/sound/pcm_drm_eld.h |  6 +++
 sound/core/Kconfig  |  3 ++
 sound/core/Makefile |  1 +
 sound/core/pcm_drm_eld.c| 99 +
 4 files changed, 109 insertions(+)
 create mode 100644 include/sound/pcm_drm_eld.h
 create mode 100644 sound/core/pcm_drm_eld.c

diff --git a/include/sound/pcm_drm_eld.h b/include/sound/pcm_drm_eld.h
new file mode 100644
index ..93357b25d2e2
--- /dev/null
+++ b/include/sound/pcm_drm_eld.h
@@ -0,0 +1,6 @@
+#ifndef __SOUND_PCM_DRM_ELD_H
+#define __SOUND_PCM_DRM_ELD_H
+
+int snd_pcm_hw_constraint_eld(struct snd_pcm_runtime *runtime, void *eld);
+
+#endif
diff --git a/sound/core/Kconfig b/sound/core/Kconfig
index 313f22e9d929..b534c8a6046b 100644
--- a/sound/core/Kconfig
+++ b/sound/core/Kconfig
@@ -6,6 +6,9 @@ config SND_PCM
tristate
select SND_TIMER

+config SND_PCM_ELD
+   bool
+
 config SND_DMAENGINE_PCM
tristate

diff --git a/sound/core/Makefile b/sound/core/Makefile
index 4daf2f58261c..591b49157b4d 100644
--- a/sound/core/Makefile
+++ b/sound/core/Makefile
@@ -13,6 +13,7 @@ snd-$(CONFIG_SND_JACK)  += jack.o
 snd-pcm-y := pcm.o pcm_native.o pcm_lib.o pcm_timer.o pcm_misc.o \
pcm_memory.o memalloc.o
 snd-pcm-$(CONFIG_SND_DMA_SGBUF) += sgbuf.o
+snd-pcm-$(CONFIG_SND_PCM_ELD) += pcm_drm_eld.o

 # for trace-points
 CFLAGS_pcm_lib.o := -I$(src)
diff --git a/sound/core/pcm_drm_eld.c b/sound/core/pcm_drm_eld.c
new file mode 100644
index ..e70379fb63d0
--- /dev/null
+++ b/sound/core/pcm_drm_eld.c
@@ -0,0 +1,99 @@
+/*
+ *  PCM DRM helpers
+ *
+ *   This program is free software; you can redistribute it and/or modify
+ *   it under the terms of the GNU General Public License version 2 as
+ *   published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+
+static const unsigned int eld_rates[] = {
+   32000,
+   44100,
+   48000,
+   88200,
+   96000,
+   176400,
+   192000,
+};
+
+static unsigned int sad_max_channels(const u8 *sad)
+{
+   return 1 + (sad[0] & 7);
+}
+
+static int eld_limit_rates(struct snd_pcm_hw_params *params,
+  struct snd_pcm_hw_rule *rule)
+{
+   struct snd_interval *r = hw_param_interval(params, rule->var);
+   struct snd_interval *c;
+   unsigned int rate_mask = 7, i;
+   const u8 *sad, *eld = rule->private;
+
+   sad = drm_eld_sad(eld);
+   if (sad) {
+   c = hw_param_interval(params, SNDRV_PCM_HW_PARAM_CHANNELS);
+
+   for (i = drm_eld_sad_count(eld); i > 0; i--, sad += 3) {
+   unsigned max_channels = sad_max_channels(sad);
+
+   /*
+* Exclude SADs which do not include the
+* requested number of channels.
+*/
+   if (c->min <= max_channels)
+   rate_mask |= sad[1];
+   }
+   }
+
+   return snd_interval_list(r, ARRAY_SIZE(eld_rates), eld_rates,
+rate_mask);
+}
+
+static int eld_limit_channels(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+   struct snd_interval *c = hw_param_interval(params, rule->var);
+   struct snd_interval *r;
+   struct snd_interval t = { .min = 1, .max = 2, .integer = 1, };
+   unsigned int i;
+   const u8 *sad, *eld = rule->private;
+
+   sad = drm_eld_sad(eld);
+   if (sad) {
+   unsigned int rate_mask = 0;
+
+   /* Convert the rate interval to a mask */
+   r = hw_param_interval(params, SNDRV_PCM_HW_PARAM_RATE);
+   for (i = 0; i < ARRAY_SIZE(eld_rates); i++)
+   if (r->min <= eld_rates[i] && r->max >= eld_rates[i])
+   rate_mask |= BIT(i);
+
+   for (i = drm_eld_sad_count(eld); i > 0; i--, sad += 3)
+   if (rate_mask & sad[1])
+   t.max = max(t.max, sad_max_channels(sad));
+   }
+
+   return snd_interval_refine(c, );
+}
+
+int snd_pcm_hw_constraint_eld(struct snd_pcm_runtime *runtime, void *eld)
+{
+   int ret;
+
+   ret = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
+ eld_limit_rates, eld,
+ SNDRV_PCM_HW_PARAM_CHANNELS, -1);
+   if (ret < 0)
+   return ret;
+
+   ret = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
+ eld_limit_channels, eld,
+ SNDRV_PCM_HW_PARAM_RATE, -1);
+
+

[PATCH 09/13] drm/edid: add function to help find SADs

Add a function to find the start of the SADs in the ELD.  This
complements the helper to retrieve the SAD count.

Signed-off-by: Russell King 
---
 include/drm/drm_edid.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 799050198323..53c53c459b15 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -348,6 +348,25 @@ static inline int drm_eld_mnl(const uint8_t *eld)
 }

 /**
+ * drm_eld_sad - Get ELD SAD structures.
+ * @eld: pointer to an eld memory structure with sad_count set
+ */
+static inline const uint8_t *drm_eld_sad(const uint8_t *eld)
+{
+   unsigned int ver, mnl;
+
+   ver = (eld[DRM_ELD_VER] & DRM_ELD_VER_MASK) >> DRM_ELD_VER_SHIFT;
+   if (ver != 2 && ver != 31)
+   return NULL;
+
+   mnl = drm_eld_mnl(eld);
+   if (mnl > 16)
+   return NULL;
+
+   return eld + DRM_ELD_CEA_SAD(mnl, 0);
+}
+
+/**
  * drm_eld_sad_count - Get ELD SAD count.
  * @eld: pointer to an eld memory structure with sad_count set
  */
-- 
1.8.3.1

[PATCH 08/13] drm: bridge/dw_hdmi: introduce interfaces to enable and disable audio

iMX6 devices suffer from an errata (ERR005174) where the audio FIFO can
be emptied while it is partially full, resulting in misalignment of the
audio samples.

To prevent this, the errata workaround recommends writing N as zero
until the audio FIFO has been loaded by DMA.  Writing N=0 prevents the
HDMI bridge from reading from the audio FIFO, effectively disabling
audio.

This means we need to provide the audio driver with a pair of functions
to enable/disable audio.  These are dw_hdmi_audio_enable() and
dw_hdmi_audio_disable().

A spinlock is introduced to ensure that setting the CTS/N values can't
race, ensuring that the audio driver calling the enable/disable
functions (which are called in an atomic context) can't race with a
modeset.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 34 +-
 include/drm/bridge/dw_hdmi.h |  2 ++
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 0369fab5c695..adda3a988f36 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -124,8 +125,12 @@ struct dw_hdmi {
struct i2c_adapter *ddc;
void __iomem *regs;

+   spinlock_t audio_lock;
struct mutex audio_mutex;
unsigned int sample_rate;
+   unsigned int audio_cts;
+   unsigned int audio_n;
+   bool audio_enable;
int ratio;

void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
@@ -347,7 +352,11 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
dev_dbg(hdmi->dev, "%s: samplerate=%ukHz ratio=%d pixelclk=%luMHz N=%d 
cts=%d\n",
__func__, sample_rate, ratio, pixel_clk, n, cts);

-   hdmi_set_cts_n(hdmi, cts, n);
+   spin_lock_irq(>audio_lock);
+   hdmi->audio_n = n;
+   hdmi->audio_cts = cts;
+   hdmi_set_cts_n(hdmi, cts, hdmi->audio_enable ? n : 0);
+   spin_unlock_irq(>audio_lock);
 }

 static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
@@ -376,6 +385,28 @@ void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, 
unsigned int rate)
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_set_sample_rate);

+void dw_hdmi_audio_enable(struct dw_hdmi *hdmi)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>audio_lock, flags);
+   hdmi->audio_enable = true;
+   hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
+   spin_unlock_irqrestore(>audio_lock, flags);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_audio_enable);
+
+void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>audio_lock, flags);
+   hdmi->audio_enable = false;
+   hdmi_set_cts_n(hdmi, hdmi->audio_cts, 0);
+   spin_unlock_irqrestore(>audio_lock, flags);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
+
 /*
  * this submodule is responsible for the video data synchronization.
  * for example, for RGB 4:4:4 input, the data map is defined as
@@ -1578,6 +1609,7 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
hdmi->encoder = encoder;

mutex_init(>audio_mutex);
+   spin_lock_init(>audio_lock);

of_property_read_u32(np, "reg-io-width", );

diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 763af51e1d60..bae79f3c4d28 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -63,5 +63,7 @@ int dw_hdmi_bind(struct device *dev, struct device *master,
 const struct dw_hdmi_plat_data *plat_data);

 void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);
+void dw_hdmi_audio_enable(struct dw_hdmi *hdmi);
+void dw_hdmi_audio_disable(struct dw_hdmi *hdmi);

 #endif /* __IMX_HDMI_H__ */
-- 
1.8.3.1

[PATCH 07/13] drm: bridge/dw_hdmi: introduce interface to setting sample rate

Introduce dw_hdmi_set_sample_rate(), which allows us to configure the
audio sample rate, setting the CTS/N values appropriately.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 10 ++
 include/drm/bridge/dw_hdmi.h |  5 +
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 75728ba552d0..0369fab5c695 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -366,6 +366,16 @@ static void hdmi_clk_regenerator_update_pixel_clock(struct 
dw_hdmi *hdmi)
mutex_unlock(>audio_mutex);
 }

+void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate)
+{
+   mutex_lock(>audio_mutex);
+   hdmi->sample_rate = rate;
+   hdmi_set_clk_regenerator(hdmi, hdmi->hdmi_data.video_mode.mpixelclock,
+hdmi->sample_rate, hdmi->ratio);
+   mutex_unlock(>audio_mutex);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_set_sample_rate);
+
 /*
  * this submodule is responsible for the video data synchronization.
  * for example, for RGB 4:4:4 input, the data map is defined as
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index de13bfc35634..763af51e1d60 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -12,6 +12,8 @@

 #include 

+struct dw_hdmi;
+
 enum {
DW_HDMI_RES_8,
DW_HDMI_RES_10,
@@ -59,4 +61,7 @@ int dw_hdmi_bind(struct device *dev, struct device *master,
 void *data, struct drm_encoder *encoder,
 struct resource *iores, int irq,
 const struct dw_hdmi_plat_data *plat_data);
+
+void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);
+
 #endif /* __IMX_HDMI_H__ */
-- 
1.8.3.1

[PATCH 06/13] drm: bridge/dw_hdmi: remove mhsyncpolarity/mvsyncpolarity/minterlaced

Remove the struct hdmi_vmode mhsyncpolarity/mvsyncpolarity/minterlaced
members, which are only used within a single function.  We can directly
reference the appropriate mode->flags instead.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index a8bd3fbf4300..75728ba552d0 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -82,9 +82,6 @@ static const u16 csc_coeff_rgb_in_eitu709[3][4] = {

 struct hdmi_vmode {
bool mdvi;
-   bool mhsyncpolarity;
-   bool mvsyncpolarity;
-   bool minterlaced;
bool mdataenablepolarity;

unsigned int mpixelclock;
@@ -1024,9 +1021,6 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
struct hdmi_vmode *vmode = >hdmi_data.video_mode;
int hblank, vblank, h_de_hs, v_de_vs, hsync_len, vsync_len;

-   vmode->mhsyncpolarity = !!(mode->flags & DRM_MODE_FLAG_PHSYNC);
-   vmode->mvsyncpolarity = !!(mode->flags & DRM_MODE_FLAG_PVSYNC);
-   vmode->minterlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
vmode->mpixelclock = mode->clock * 1000;

dev_dbg(hdmi->dev, "final pixclk = %d\n", vmode->mpixelclock);
@@ -1036,13 +1030,13 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
HDMI_FC_INVIDCONF_HDCP_KEEPOUT_ACTIVE :
HDMI_FC_INVIDCONF_HDCP_KEEPOUT_INACTIVE);

-   inv_val |= (vmode->mvsyncpolarity ?
+   inv_val |= mode->flags & DRM_MODE_FLAG_PVSYNC ?
HDMI_FC_INVIDCONF_VSYNC_IN_POLARITY_ACTIVE_HIGH :
-   HDMI_FC_INVIDCONF_VSYNC_IN_POLARITY_ACTIVE_LOW);
+   HDMI_FC_INVIDCONF_VSYNC_IN_POLARITY_ACTIVE_LOW;

-   inv_val |= (vmode->mhsyncpolarity ?
+   inv_val |= mode->flags & DRM_MODE_FLAG_PHSYNC ?
HDMI_FC_INVIDCONF_HSYNC_IN_POLARITY_ACTIVE_HIGH :
-   HDMI_FC_INVIDCONF_HSYNC_IN_POLARITY_ACTIVE_LOW);
+   HDMI_FC_INVIDCONF_HSYNC_IN_POLARITY_ACTIVE_LOW;

inv_val |= (vmode->mdataenablepolarity ?
HDMI_FC_INVIDCONF_DE_IN_POLARITY_ACTIVE_HIGH :
@@ -1051,13 +1045,13 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
if (hdmi->vic == 39)
inv_val |= HDMI_FC_INVIDCONF_R_V_BLANK_IN_OSC_ACTIVE_HIGH;
else
-   inv_val |= (vmode->minterlaced ?
+   inv_val |= mode->flags & DRM_MODE_FLAG_INTERLACE ?
HDMI_FC_INVIDCONF_R_V_BLANK_IN_OSC_ACTIVE_HIGH :
-   HDMI_FC_INVIDCONF_R_V_BLANK_IN_OSC_ACTIVE_LOW);
+   HDMI_FC_INVIDCONF_R_V_BLANK_IN_OSC_ACTIVE_LOW;

-   inv_val |= (vmode->minterlaced ?
+   inv_val |= mode->flags & DRM_MODE_FLAG_INTERLACE ?
HDMI_FC_INVIDCONF_IN_I_P_INTERLACED :
-   HDMI_FC_INVIDCONF_IN_I_P_PROGRESSIVE);
+   HDMI_FC_INVIDCONF_IN_I_P_PROGRESSIVE;

inv_val |= (vmode->mdvi ?
HDMI_FC_INVIDCONF_DVI_MODEZ_DVI_MODE :
-- 
1.8.3.1

[PATCH 05/13] drm: bridge/dw_hdmi: simplify hdmi_config_AVI() a little

When a YCBCR format is selected, we can merely copy the colorimetry
information directly as we use the same definitions for both the
unpacked AVI info frame and the hdmi_data_info structure.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 0f3ccfa3ccfc..a8bd3fbf4300 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -943,10 +943,7 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
frame.extended_colorimetry =
HDMI_EXTENDED_COLORIMETRY_XV_YCC_709;
} else if (hdmi->hdmi_data.enc_out_format != RGB) {
-   if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601)
-   frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
-   else /*hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_709*/
-   frame.colorimetry = HDMI_COLORIMETRY_ITU_709;
+   frame.colorimetry = hdmi->hdmi_data.colorimetry;
frame.extended_colorimetry = 
HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
} else { /* Carries no data */
frame.colorimetry = HDMI_COLORIMETRY_NONE;
-- 
1.8.3.1

[PATCH 04/13] drm: bridge/dw_hdmi: use drm_hdmi_avi_infoframe_from_display_mode()

Use drm_hdmi_avi_infoframe_from_display_mode() to compose the AVI
frame.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 126 +--
 1 file changed, 67 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 75099b80ca7e..0f3ccfa3ccfc 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -918,74 +918,79 @@ static void hdmi_tx_hdcp_config(struct dw_hdmi *hdmi)
  HDMI_A_HDCPCFG1_ENCRYPTIONDISABLE_MASK, HDMI_A_HDCPCFG1);
 }

-static void hdmi_config_AVI(struct dw_hdmi *hdmi)
+static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode 
*mode)
 {
-   u8 val, pix_fmt, under_scan;
-   u8 act_ratio, coded_ratio, colorimetry, ext_colorimetry;
-   bool aspect_16_9;
+   struct hdmi_avi_infoframe frame;
+   u8 val;

-   aspect_16_9 = false; /* FIXME */
+   /* Initialise info frame from DRM mode */
+   drm_hdmi_avi_infoframe_from_display_mode(, mode);

-   /* AVI Data Byte 1 */
if (hdmi->hdmi_data.enc_out_format == YCBCR444)
-   pix_fmt = HDMI_FC_AVICONF0_PIX_FMT_YCBCR444;
+   frame.colorspace = HDMI_COLORSPACE_YUV444;
else if (hdmi->hdmi_data.enc_out_format == YCBCR422_8BITS)
-   pix_fmt = HDMI_FC_AVICONF0_PIX_FMT_YCBCR422;
+   frame.colorspace = HDMI_COLORSPACE_YUV422;
else
-   pix_fmt = HDMI_FC_AVICONF0_PIX_FMT_RGB;
-
-   under_scan =  HDMI_FC_AVICONF0_SCAN_INFO_NODATA;
-
-   /*
-* Active format identification data is present in the AVI InfoFrame.
-* Under scan info, no bar data
-*/
-   val = pix_fmt | under_scan |
-   HDMI_FC_AVICONF0_ACTIVE_FMT_INFO_PRESENT |
-   HDMI_FC_AVICONF0_BAR_DATA_NO_DATA;
-
-   hdmi_writeb(hdmi, val, HDMI_FC_AVICONF0);
-
-   /* AVI Data Byte 2 -Set the Aspect Ratio */
-   if (aspect_16_9) {
-   act_ratio = HDMI_FC_AVICONF1_ACTIVE_ASPECT_RATIO_16_9;
-   coded_ratio = HDMI_FC_AVICONF1_CODED_ASPECT_RATIO_16_9;
-   } else {
-   act_ratio = HDMI_FC_AVICONF1_ACTIVE_ASPECT_RATIO_4_3;
-   coded_ratio = HDMI_FC_AVICONF1_CODED_ASPECT_RATIO_4_3;
-   }
+   frame.colorspace = HDMI_COLORSPACE_RGB;

/* Set up colorimetry */
if (hdmi->hdmi_data.enc_out_format == XVYCC444) {
-   colorimetry = HDMI_FC_AVICONF1_COLORIMETRY_EXTENDED_INFO;
+   frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601)
-   ext_colorimetry =
-   HDMI_FC_AVICONF2_EXT_COLORIMETRY_XVYCC601;
+   frame.extended_colorimetry =
+   HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
else /*hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_709*/
-   ext_colorimetry =
-   HDMI_FC_AVICONF2_EXT_COLORIMETRY_XVYCC709;
+   frame.extended_colorimetry =
+   HDMI_EXTENDED_COLORIMETRY_XV_YCC_709;
} else if (hdmi->hdmi_data.enc_out_format != RGB) {
if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601)
-   colorimetry = HDMI_FC_AVICONF1_COLORIMETRY_SMPTE;
+   frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
else /*hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_709*/
-   colorimetry = HDMI_FC_AVICONF1_COLORIMETRY_ITUR;
-   ext_colorimetry = HDMI_FC_AVICONF2_EXT_COLORIMETRY_XVYCC601;
+   frame.colorimetry = HDMI_COLORIMETRY_ITU_709;
+   frame.extended_colorimetry = 
HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
} else { /* Carries no data */
-   colorimetry = HDMI_FC_AVICONF1_COLORIMETRY_NO_DATA;
-   ext_colorimetry = HDMI_FC_AVICONF2_EXT_COLORIMETRY_XVYCC601;
+   frame.colorimetry = HDMI_COLORIMETRY_NONE;
+   frame.extended_colorimetry = 
HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
}

-   val = colorimetry | coded_ratio | act_ratio;
+   frame.scan_mode = HDMI_SCAN_MODE_NONE;
+
+   /*
+* The Designware IP uses a different byte format from standard
+* AVI info frames, though generally the bits are in the correct
+* bytes.
+*/
+
+   /*
+* AVI data byte 1 differences: Colorspace in bits 4,5 rather than 5,6,
+* active aspect present in bit 6 rather than 4.
+*/
+   val = (frame.colorspace & 3) << 4 | (frame.scan_mode & 0x3);
+   if (frame.active_aspect & 15)
+   val |= HDMI_FC_AVICONF0_ACTIVE_FMT_INFO_PRESENT;
+   if (frame.top_bar || frame.bottom_bar)
+   val |=

[PATCH 03/13] drm: bridge/dw_hdmi: clean up hdmi_set_clk_regenerator()

Clean up hdmi_set_clk_regenerator() by allowing it to take the audio
sample rate and ratio directly, rather than hiding it inside the
function.  Raise the unsupported pixel clock/sample rate message from
debug to error level as this results in audio not working correctly.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 32 +++-
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 23ea8c5c85b6..75099b80ca7e 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -335,39 +335,37 @@ static unsigned int hdmi_compute_cts(unsigned int freq, 
unsigned long pixel_clk,
 }

 static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
-unsigned long pixel_clk)
+   unsigned long pixel_clk, unsigned int sample_rate, unsigned int ratio)
 {
-   unsigned int clk_n, clk_cts;
+   unsigned int n, cts;

-   clk_n = hdmi_compute_n(hdmi->sample_rate, pixel_clk,
-  hdmi->ratio);
-   clk_cts = hdmi_compute_cts(hdmi->sample_rate, pixel_clk,
-  hdmi->ratio);
-
-   if (!clk_cts) {
-   dev_dbg(hdmi->dev, "%s: pixel clock not supported: %lu\n",
-   __func__, pixel_clk);
-   return;
+   n = hdmi_compute_n(sample_rate, pixel_clk, ratio);
+   cts = hdmi_compute_cts(sample_rate, pixel_clk, ratio);
+   if (!cts) {
+   dev_err(hdmi->dev,
+   "%s: pixel clock/sample rate not supported: %luMHz / 
%ukHz\n",
+   __func__, pixel_clk, sample_rate);
}

-   dev_dbg(hdmi->dev, "%s: samplerate=%d  ratio=%d  pixelclk=%lu  N=%d 
cts=%d\n",
-   __func__, hdmi->sample_rate, hdmi->ratio,
-   pixel_clk, clk_n, clk_cts);
+   dev_dbg(hdmi->dev, "%s: samplerate=%ukHz ratio=%d pixelclk=%luMHz N=%d 
cts=%d\n",
+   __func__, sample_rate, ratio, pixel_clk, n, cts);

-   hdmi_set_cts_n(hdmi, clk_cts, clk_n);
+   hdmi_set_cts_n(hdmi, cts, n);
 }

 static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
 {
mutex_lock(>audio_mutex);
-   hdmi_set_clk_regenerator(hdmi, 7425);
+   hdmi_set_clk_regenerator(hdmi, 7425, hdmi->sample_rate,
+hdmi->ratio);
mutex_unlock(>audio_mutex);
 }

 static void hdmi_clk_regenerator_update_pixel_clock(struct dw_hdmi *hdmi)
 {
mutex_lock(>audio_mutex);
-   hdmi_set_clk_regenerator(hdmi, hdmi->hdmi_data.video_mode.mpixelclock);
+   hdmi_set_clk_regenerator(hdmi, hdmi->hdmi_data.video_mode.mpixelclock,
+hdmi->sample_rate, hdmi->ratio);
mutex_unlock(>audio_mutex);
 }

-- 
1.8.3.1

[PATCH 02/13] drm: bridge/dw_hdmi: clean up phy configuration

The phy configuration is dependent on the SoC, and we look up values for
some of the registers in SoC specific data.  However, we had partially
programmed the phy before we had successfully looked up the clock rate.
Also, we were only checking that we had a valid configuration for the
currctrl register.

Move all these lookups to the start of this function instead, so we can
check that all lookups were successful before beginning to program the
phy.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 68 +---
 1 file changed, 35 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 3494391e4199..23ea8c5c85b6 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -753,12 +753,12 @@ static void dw_hdmi_phy_sel_interface_control(struct 
dw_hdmi *hdmi, u8 enable)
 static int hdmi_phy_configure(struct dw_hdmi *hdmi, unsigned char prep,
  unsigned char res, int cscon)
 {
-   unsigned res_idx, i;
+   unsigned res_idx;
u8 val, msec;
-   const struct dw_hdmi_plat_data *plat_data = hdmi->plat_data;
-   const struct dw_hdmi_mpll_config *mpll_config = plat_data->mpll_cfg;
-   const struct dw_hdmi_curr_ctrl *curr_ctrl = plat_data->cur_ctr;
-   const struct dw_hdmi_phy_config *phy_config = plat_data->phy_config;
+   const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
+   const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
+   const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
+   const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;

if (prep)
return -EINVAL;
@@ -778,6 +778,30 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
return -EINVAL;
}

+   /* PLL/MPLL Cfg - always match on final entry */
+   for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
+   if (hdmi->hdmi_data.video_mode.mpixelclock <=
+   mpll_config->mpixelclock)
+   break;
+
+   for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
+   if (hdmi->hdmi_data.video_mode.mpixelclock <=
+   curr_ctrl->mpixelclock)
+   break;
+
+   for (; phy_config->mpixelclock != ~0UL; phy_config++)
+   if (hdmi->hdmi_data.video_mode.mpixelclock <=
+   phy_config->mpixelclock)
+   break;
+
+   if (mpll_config->mpixelclock == ~0UL ||
+   curr_ctrl->mpixelclock == ~0UL ||
+   phy_config->mpixelclock == ~0UL) {
+   dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
+   hdmi->hdmi_data.video_mode.mpixelclock);
+   return -EINVAL;
+   }
+
/* Enable csc path */
if (cscon)
val = HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH;
@@ -803,40 +827,18 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
HDMI_PHY_I2CM_SLAVE_ADDR);
hdmi_phy_test_clear(hdmi, 0);

-   /* PLL/MPLL Cfg - always match on final entry */
-   for (i = 0; mpll_config[i].mpixelclock != (~0UL); i++)
-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   mpll_config[i].mpixelclock)
-   break;
-
-   hdmi_phy_i2c_write(hdmi, mpll_config[i].res[res_idx].cpce, 0x06);
-   hdmi_phy_i2c_write(hdmi, mpll_config[i].res[res_idx].gmp, 0x15);
-
-   for (i = 0; curr_ctrl[i].mpixelclock != (~0UL); i++)
-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   curr_ctrl[i].mpixelclock)
-   break;
-
-   if (curr_ctrl[i].mpixelclock == (~0UL)) {
-   dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
-   hdmi->hdmi_data.video_mode.mpixelclock);
-   return -EINVAL;
-   }
+   hdmi_phy_i2c_write(hdmi, mpll_config->res[res_idx].cpce, 0x06);
+   hdmi_phy_i2c_write(hdmi, mpll_config->res[res_idx].gmp, 0x15);

/* CURRCTRL */
-   hdmi_phy_i2c_write(hdmi, curr_ctrl[i].curr[res_idx], 0x10);
+   hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[res_idx], 0x10);

hdmi_phy_i2c_write(hdmi, 0x, 0x13);  /* PLLPHBYCTRL */
hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);

-   for (i = 0; phy_config[i].mpixelclock != (~0UL); i++)
-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   phy_config[i].mpixelclock)
-   break;
-
-   hdmi_phy_i2c_write(hdmi, phy_config[i].term, 0x19);  /* TXTERM */
-   hdmi_phy_i2c_write(hdmi, phy_config[i].sym_ctr, 0x09); /* CKSYMTXCTRL */
-   hdmi_phy_i2c_write(hdmi, phy_config[i].vlev_ctr, 0x0E); /* VLEVCTRL */
+   hdmi_phy_i2c_write(hdmi, phy_config->term, 0x19);  /* TXTERM */
+

[PATCH 01/13] drm: imx/dw_hdmi: move phy comments

The phy comments in dw_hdmi.c applied to the iMX6 version.  Move these
comments to the iMX6 dw_hdmi-imx data along side the data.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/dw_hdmi.c  | 3 ---
 drivers/gpu/drm/imx/dw_hdmi-imx.c | 5 +
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 49cafb61d290..3494391e4199 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -834,11 +834,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
phy_config[i].mpixelclock)
break;

-   /* RESISTANCE TERM 133Ohm Cfg */
hdmi_phy_i2c_write(hdmi, phy_config[i].term, 0x19);  /* TXTERM */
-   /* PREEMP Cgf 0.00 */
hdmi_phy_i2c_write(hdmi, phy_config[i].sym_ctr, 0x09); /* CKSYMTXCTRL */
-   /* TX/CK LVL 10 */
hdmi_phy_i2c_write(hdmi, phy_config[i].vlev_ctr, 0x0E); /* VLEVCTRL */

/* REMOVE CLK TERM */
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index a3ecf1069b76..644edf65dbe0 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -75,6 +75,11 @@ static const struct dw_hdmi_curr_ctrl imx_cur_ctr[] = {
},
 };

+/*
+ * Resistance term 133Ohm Cfg
+ * PREEMP config 0.00
+ * TX/CK level 10
+ */
 static const struct dw_hdmi_phy_config imx_phy_config[] = {
/*pixelclk   symbol   term   vlev */
{ 14850, 0x800d, 0x0005, 0x01ad},
-- 
1.8.3.1

[PATCH v3 0/13] dw_hdmi cleanups, audio preparation, helpers and ahb audio support

I'm sending this series again for comments, and to allow people to
update their code bases (for those who are using my AHB audio driver
on iMX6).

There have been very few changes from the previous posting, the
exception being the ELD helper in patch 10, which should be correctly
sorted now.

I would like to:
* queue the first six patches for David, so I'm asking for acks for these
* obtain agreement with the Rockchip guys on patches 7 and 8
* queue patches 9 to 11 inclusive as well (as these are cross-subsystem,
  I think we need to discuss how they are to be handled - there is other
  work in the pipelines from others depending on these changes.)  So acks
  for these would be nice too.

Here's the summary of the patches, same as last time:

The first four patches are a few cleanups to the dw_hdmi driver.

The next two patches introduce new interfaces to the dw_hdmi driver
to support AHB audio, including the errata found on iMX6 which
requires N to be programmed to zero when the audio FIFO is not full.
I'm expecting some discussion with these last two as we try to work
out how to deal with the two variants of audio support for this part
(AHB audio vs I2S audio).

The following three add various helpers to the DRM and ALSA subsystems
for audio support which is non-specific to the AHB audio driver.  For
DRM, this is a helper macro to obtain the pointer into the short audio
descriptors.  For ALSA, it's a set of helpers to restrict an audio PCM
device's capabilities according to the ELD, and to generate the IEC958
channel status data.  If these helpers are acceptable, we can convert
a number of drivers to them.

The ELD helper isn't quite finished, but should be sufficient for
initial testing.

The last two patches add support for the dw_hdmi audio.  This is an
ALSA driver rather than an ASoC driver as it's a pretty simple affair.
I couldn't find a suitable location in the sound/ subtree to place it,
so I've placed it next to the bridge - yes, we probably need to find
it a better home in the sound/ subtree, but it currently makes
use of dw_hdmi.h in the directory it lives.

 drivers/gpu/drm/bridge/Kconfig |  11 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c | 566 +
 drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.h |  14 +
 drivers/gpu/drm/bridge/dw_hdmi.c   | 321 +---
 drivers/gpu/drm/bridge/dw_hdmi.h   |   3 +
 drivers/gpu/drm/imx/dw_hdmi-imx.c  |   5 +
 include/drm/bridge/dw_hdmi.h   |   7 +
 include/drm/drm_edid.h |  19 +
 include/sound/pcm_drm_eld.h|   6 +
 include/sound/pcm_iec958.h |   9 +
 sound/core/Kconfig |   6 +
 sound/core/Makefile|   2 +
 sound/core/pcm_drm_eld.c   |  99 +
 sound/core/pcm_iec958.c|  95 +
 15 files changed, 1036 insertions(+), 128 deletions(-)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[Bug 90266] Unigine Heaven 4.0 logging vm faults since radeon/llvm: Run LLVM's instruction combining pass

https://bugs.freedesktop.org/show_bug.cgi?id=90266

--- Comment #8 from Arek RuÅniak  ---
thx Tom, heaven works as before

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150509/9cc91e4f/attachment-0001.html>

[Bug 90284] GPU lockup with DOTA2

https://bugs.freedesktop.org/show_bug.cgi?id=90284

--- Comment #6 from pablow.1422 at gmail.com ---
Same here. 

Graphics card: AMD Radeon HD7750
Kernel: 3.19.0-16-generic #16-Ubuntu SMP
DE: KDE

Mesa 10.6.0-devel (git-28090b3 2015-05-05 vivid-oibaf-ppa)

Any info needed, I'm happy to provide it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150509/47572f19/attachment.html>

[Bug 97931] GPU lockup with Radeon HD 4670

2015-05-09 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=97931

--- Comment #7 from joe.r.floss.user at gmail.com ---
Hello,

I had the lockup again this morning. I attached 3 files corresponding to this
lockup: dmesg output, Xorg.log and data gathered by reportbug for the
xserver-xorg package (which includes versions of related packages).

I could work in a virtual console after the lockup once I stopped kdm, however
restarting it was useless because it immediately started with garbled display.

Thanks

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 97931] GPU lockup with Radeon HD 4670

2015-05-09 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=97931

--- Comment #6 from joe.r.floss.user at gmail.com ---
Created attachment 176291
  --> https://bugzilla.kernel.org/attachment.cgi?id=176291=edit
Info related to the xserver-xorg package

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 97931] GPU lockup with Radeon HD 4670

2015-05-09 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=97931

--- Comment #5 from joe.r.floss.user at gmail.com ---
Created attachment 176281
  --> https://bugzilla.kernel.org/attachment.cgi?id=176281=edit
Xorg.log

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 97931] GPU lockup with Radeon HD 4670

2015-05-09 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=97931

--- Comment #4 from joe.r.floss.user at gmail.com ---
Created attachment 176271
  --> https://bugzilla.kernel.org/attachment.cgi?id=176271=edit
dmesg output

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[xf86-video-nouveau] dri2: Enable BufferAge support

2015-05-09 Thread Mario Kleiner



On 01/19/2015 12:00 PM, Chris Wilson wrote:
> For enable BufferAge support, we just have to be not using the
> DRI2Buffer->flags field for any purpose (i.e. it is always expected to
> be 0, as it is now) and to be sure to swap the flags field whenever we
> exchange buffers. As nouveau does not exactly support TripleBuffer, we
> don't have to worry about setting the copying the flags field when
> injecting the third buffer.
>
> Signed-off-by: Chris Wilson 
> Cc: Maarten Lankhorst 
> Cc: Mario Kleiner 
> ---
>   src/nouveau_dri2.c | 7 +++
>   1 file changed, 7 insertions(+)
>
> diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
> index e3445b2..428ef92 100644
> --- a/src/nouveau_dri2.c
> +++ b/src/nouveau_dri2.c
> @@ -711,6 +711,7 @@ nouveau_dri2_finish_swap(DrawablePtr draw, unsigned int 
> frame,
>   }
>
>   SWAP(s->dst->name, s->src->name);
> + SWAP(s->dst->flags, s->src->flags);
>   SWAP(nouveau_pixmap(dst_pix)->bo, nouveau_pixmap(src_pix)->bo);
>
>   DamageRegionProcessPending(draw);
> @@ -1003,6 +1004,12 @@ nouveau_dri2_init(ScreenPtr pScreen)
>   dri2.DestroyBuffer2 = nouveau_dri2_destroy_buffer2;
>   dri2.CopyRegion2 = nouveau_dri2_copy_region2;
>   #endif
> +
> +#if DRI2INFOREC_VERSION >= 10
> + dri2.version = 10;
> + dri2.bufferAge = 1;
> +#endif
> +
>   return DRI2ScreenInit(pScreen, );
>   }
>
>

Seems ok to me.

Reviewed-by: Mario Kleiner 

-mario

[PATCH v4 09/12] drm/exynos: remove exported functions from exynos_drm_plane

Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Now that no one is using the functions exported by exynos_drm_plane due
> to the atomic conversion we can make remove some of the them or make them
> static.
> 
> v2: remove unused exynos_drm_crtc
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 90 
> +--
>  drivers/gpu/drm/exynos/exynos_drm_plane.h | 11 
>  2 files changed, 37 insertions(+), 64 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index 7d42e09..8bad40e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -62,35 +62,12 @@ static int exynos_plane_get_size(int start, unsigned 
> length, unsigned last)
>   return size;
>  }
>  
> -int exynos_check_plane(struct drm_plane *plane, struct drm_framebuffer *fb)
> -{
> - struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> - int nr;
> - int i;
> -
> - nr = exynos_drm_fb_get_buf_cnt(fb);
> - for (i = 0; i < nr; i++) {
> - struct exynos_drm_gem_buf *buffer = exynos_drm_fb_buffer(fb, i);
> -
> - if (!buffer) {
> - DRM_DEBUG_KMS("buffer is null\n");
> - return -EFAULT;
> - }
> -
> - exynos_plane->dma_addr[i] = buffer->dma_addr;
> -
> - DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n",
> - i, (unsigned long)exynos_plane->dma_addr[i]);
> - }
> -
> - return 0;
> -}
> -
> -void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc *crtc,
> -   struct drm_framebuffer *fb, int crtc_x, int crtc_y,
> -   unsigned int crtc_w, unsigned int crtc_h,
> -   uint32_t src_x, uint32_t src_y,
> -   uint32_t src_w, uint32_t src_h)
> +static void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc 
> *crtc,
> +   struct drm_framebuffer *fb,
> +   int crtc_x, int crtc_y,
> +   unsigned int crtc_w, unsigned int crtc_h,
> +   uint32_t src_x, uint32_t src_y,
> +   uint32_t src_w, uint32_t src_h)
>  {
>   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
>   unsigned int actual_w;
> @@ -145,24 +122,6 @@ void exynos_plane_mode_set(struct drm_plane *plane, 
> struct drm_crtc *crtc,
>   plane->crtc = crtc;
>  }
>  
> -void
> -exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
> -  struct drm_framebuffer *fb, int crtc_x, int crtc_y,
> -  unsigned int crtc_w, unsigned int crtc_h,
> -  uint32_t src_x, uint32_t src_y,
> -  uint32_t src_w, uint32_t src_h)
> -{
> - struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> - struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> -
> - exynos_plane_mode_set(plane, crtc, fb, crtc_x, crtc_y,
> -   crtc_w, crtc_h, src_x >> 16, src_y >> 16,
> -   src_w >> 16, src_h >> 16);
> -
> - if (exynos_crtc->ops->win_commit)
> - exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
> -}
> -
>  static struct drm_plane_funcs exynos_plane_funcs = {
>   .update_plane   = drm_atomic_helper_update_plane,
>   .disable_plane  = drm_atomic_helper_disable_plane,
> @@ -175,19 +134,44 @@ static struct drm_plane_funcs exynos_plane_funcs = {
>  static int exynos_plane_atomic_check(struct drm_plane *plane,
>struct drm_plane_state *state)
>  {
> - return exynos_check_plane(plane, state->fb);
> + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> + int nr;
> + int i;
> +
> + nr = exynos_drm_fb_get_buf_cnt(state->fb);
> + for (i = 0; i < nr; i++) {
> + struct exynos_drm_gem_buf *buffer =
> + exynos_drm_fb_buffer(state->fb, i);
> +
> + if (!buffer) {
> + DRM_DEBUG_KMS("buffer is null\n");
> + return -EFAULT;
> + }
> +
> + exynos_plane->dma_addr[i] = buffer->dma_addr;
This clashes with this commit:
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm/for-next=40dcb441cdaaef405a2e540d496cefefdbc89ab5



> +
> + DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n",
> + i, (unsigned long)exynos_plane->dma_addr[i]);
> + }
> +
> + return 0;
>  }
>  
>  static void exynos_plane_atomic_update(struct drm_plane *plane,
>  struct drm_plane_state *old_state)
>  {
>   struct drm_plane_state *state = plane->state;
> + struct exynos_drm_crtc *exynos_crtc =

[Bug 90378] GPU lockups in Left 4 Dead 2

https://bugs.freedesktop.org/show_bug.cgi?id=90378

Daniel Scharrer  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=89228

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150509/120051aa/attachment.html>

[Bug 89228] Regression with left for dead 2

https://bugs.freedesktop.org/show_bug.cgi?id=89228

Daniel Scharrer  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=90378

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150509/835279d9/attachment.html>

[Bug 90378] GPU lockups in Left 4 Dead 2

https://bugs.freedesktop.org/show_bug.cgi?id=90378

Daniel Scharrer  changed:

   What|Removed |Added

 CC||daniel at constexpr.org

--- Comment #1 from Daniel Scharrer  ---
The game stdout with R600_DEBUG=ps,vs,gs was too large to attach, so here it is
instead:

 http://constexpr.org/tmp/l4d.log (5 MiB)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150509/06b1a6ed/attachment.html>

[Bug 90378] GPU lockups in Left 4 Dead 2

https://bugs.freedesktop.org/show_bug.cgi?id=90378

Bug ID: 90378
Summary: GPU lockups in Left 4 Dead 2
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel at lists.freedesktop.org
Reporter: daniel at constexpr.org
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 115653
--> https://bugs.freedesktop.org/attachment.cgi?id=115653=edit
dmesg output

While playing L4D2 today I got a lot of GPU lockups.

While the lockups seem to happen randomly, they are fairly easy to reproduce in
the third chapter (The Mall) of the Dead Center campaign. I recorded an
apitrace while encountering 3 lockups and there seem to be at least a couple of
lockups each time I retrace it:

http://constexpr.org/tmp/L4D2-radeonsi.trace.xz (507 MiB)

At least driver was able to successfully reset the GPU each time.

There also seem to be some infrequent rendering glitches.

Probably related to bug 89228, and possibly bug 90217, bug 90284 and/or bug
89954 (all reports of lockups with Source engine games).

GPU; Radeon HD 7950 (TAHITI)
Mesa 10.6.0-devel (git-3bdbc1e)
LLVM r236436
Linux 4.0.1-gentoo

The above logs and apitrace were recorded with unsafe-fp-math enbled (see bug
89069 comment 34) but the lockups also happen without it. I also noticed some
VM fault messages in dmesg while running L4D2 without unsafe-fp-math.

--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150509/325d5c5a/attachment.html>

Tiny fixes - resent

2015-05-09 Thread Mario Kleiner

On 05/04/2015 11:15 AM, Daniel Vetter wrote:
> On Mon, May 04, 2015 at 06:29:43AM +0200, Mario Kleiner wrote:
>> Hi, a resend of updated versions of the earlier patches:
>>
>> Patch 1 should really get into Linux 4.1 to avoid tegra breaking
>> user-space clients.
>>
>> Patch 2 reviewed-by Michel, updated to take his feedback into account.
>>
>> Patch 3 is modified to not conflict with Daniel Vetter's patch
>> "drm/vblank: Fixup and document timestamp update/read barriers"
>>
>> Patch 4 will be needed for drm/qxl to compile with Daniel's fixup
>> patch applied.
>
> Merged patch 2-4 to topic/drm-misc on top of my memory barrier patch. I'll
> leave 1 to Thierry for tegra-fixes. And there doesn't seem to be a patch 5
> somehow, was that intentional? The patches are numbered n/5.
> -Daniel
>

Thanks. There isn't a patch 5, that was just some hack of mine that 
accidentally slipped into the numbering.

-mario

drm/exynos: Add atomic modesetting support

Hello,

I've tested this on my Hardkernel Odroid-X2 (connected via HDMI to a
1080p panel).

Run the usual modetest tests (just primary plane, primary plane with
vsync, primary plane with overlay, primary plane with overlay and video
overlay, overlay partially outside of crtc area, etc.) and haven't
noticed any issues so far.

Kernel log is 'clean', so the series works fine for me.

You can add my
Tested-by: Tobias Jakobi 

With best wishes,
Tobias


Gustavo Padovan wrote:
> Hi,
> 
> Here goes the full support for atomic modesetting on exynos. I've
> split the patches in the various phases of atomic support.
> 
> v2: fixes comments by Joonyoung
> - remove unused var in patch 09
> - use ->disable instead of outdated ->dpms in hdmi code
> - remove WARN_ON from crtc enable/disable
> 
> v3: fixes comment by Joonyoung
> - move the removal of drm_helper_disable_unused_functions() to
> separated patch
> 
> v4: add patches that remove unnecessary calls to disable_plane()
> 
>   Gustavo
> 
> ---
> Gustavo Padovan (12):
>   drm/exynos: atomic phase 1: use drm_plane_helper_update()
>   drm/exynos: atomic phase 1: use drm_plane_helper_disable()
>   drm/exynos: atomic phase 1: add .mode_set_nofb() callback
>   drm/exynos: atomic phase 2: wire up state reset(), duplicate() and 
> destroy()
>   drm/exynos: atomic phase 2: keep track of framebuffer pointer
>   drm/exynos: atomic phase 3: atomic updates of planes
>   drm/exynos: atomic phase 3: use atomic .set_config helper
>   drm/exynos: atomic phase 3: convert page flips
>   drm/exynos: remove exported functions from exynos_drm_plane
>   drm/exynos: don't disable unused functions at init
>   drm/exynos: atomic dpms support
>   drm/exynos: remove unnecessary calls to disable_plane()
> 
>  drivers/gpu/drm/bridge/ps8622.c |   6 +-
>  drivers/gpu/drm/bridge/ptn3460.c|   6 +-
>  drivers/gpu/drm/exynos/exynos_dp_core.c |   6 +-
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c| 215 
> +--
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c |   6 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   2 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.h |   4 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |   6 +-
>  drivers/gpu/drm/exynos/exynos_drm_encoder.c |  35 +
>  drivers/gpu/drm/exynos/exynos_drm_fb.c  |  12 +-
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c   |   3 -
>  drivers/gpu/drm/exynos/exynos_drm_plane.c   | 115 +
>  drivers/gpu/drm/exynos/exynos_drm_plane.h   |  11 --
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c|   6 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c|  10 +-
>  15 files changed, 178 insertions(+), 265 deletions(-)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[Bug 88561] [radeonsi][regression, bisected] Depth test/buffer issues in Portal

https://bugs.freedesktop.org/show_bug.cgi?id=88561

--- Comment #9 from Daniel Scharrer  ---
Created attachment 115651
  --> https://bugs.freedesktop.org/attachment.cgi?id=115651=edit
Junk rendered in The Talos Principle

This still happens in various Source engine games (and perhaps elsewhere), just
not as frequently.

The The Talos Principle trace from bug 87278 comment 29 has some garbage being
rendered (screenshot attached) that looks similar to what I get in Source
engine games, but it is much easier to reproduce:

 http://constexpr.org/tmp/Talos-radeonsi.3.trace.xz (147 MiB)

No idea of that is the same bug or even if the current Source engine issue is
related to the original Portal bug I bisected in this bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 89069] Lack of grass in The Talos Principle on radeonsi (native\wine\nine)

https://bugs.freedesktop.org/show_bug.cgi?id=89069

--- Comment #35 from Daniel Scharrer  ---
Confirmed that both GPU faults and garbage being rendered happens independently
of unsafe-fp-math. New trace in bug 87278 comment 29.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 87278] Packet0 not allowed and GPU fault detected errors with Serious Engine games