[Bug 93649] [radeonsi] Graphics lockup while playing tf2

[bugzilla-dae...@freedesktop.org]

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

--- Comment #59 from pandiculationfinch at gmail.com ---
sigh turns something else must have caused the shutdowns, the game is back to
just freezing the system today. =/

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

[Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Sharma, Shashank]

Regards

Shashank


On 11/2/2016 10:27 PM, Ville Syrjälä wrote:
> On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote:
>> CEA-861-F specs defines new 4k video modes to be used with
>> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
>> way till VIC=107.
>>
>> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
>> to be able to parse 4k modes using the existing techniques, we have
>> to complete the modedb (VIC=65 onwards).
>>
>> This patch adds:
>> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
>> - Newly added 4k modes (from VIC=93 to VIC=107).
>>
>> Signed-off-by: Shashank Sharma 
>> Signed-off-by: Sonika Jindal 
>> Reviewed-by: Jose Abreu 
>> Reviewed-by: Alex Deucher 
>>
>> Cc: Jose Abreu 
>> Cc: Alex Deucher 
>>
>> V2: Addressed review comments from Jose:
>>  - fix the timings for VIC 83, 90 and 91
>>  - fix formatting for VIC 93-107
>> ---
>>   drivers/gpu/drm/drm_edid.c | 215 
>> +
>>   1 file changed, 215 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 9506933..d18602c 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -994,6 +994,221 @@ struct minimode {
> 
>> +/* 77 - 1920x1080 at 100Hz */
>> +{ DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 297000, 1920, 2448,
>> +   2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> + .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> My script gave me:
> { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 297000, 1920, 2448,
>2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, 
> },
>
> Manual reading of the spec agrees with my script.
>
> 
>> +/* 104 - 3840x2160p at 25Hz 64:27 */
>> +{ DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, 3840, 4016,
>> +4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
>> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +.vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27},
> My script gave me:
> { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, 3840, 4896,
>4984, 5280, 0, 2160, 2168, 2178, 2250, 0,
>DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, 
> },
>
> Manual reading of the spec agrees with my script.
>
> Outside those two I don't see any errors in your table when compared to my
> script's output. I do see some differences in the already existing modes 
> though.
> I'll look those over and send a patch if necessary.
>
Got it, Thanks.
Will cross check, correct and re-send.

Shashank

[Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Sharma, Shashank]

Regards

Shashank


On 11/2/2016 10:04 PM, Ville Syrjälä wrote:
> On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote:
>> CEA-861-F specs defines new 4k video modes to be used with
>> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
>> way till VIC=107.
>>
>> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
>> to be able to parse 4k modes using the existing techniques, we have
>> to complete the modedb (VIC=65 onwards).
>>
>> This patch adds:
>> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
>> - Newly added 4k modes (from VIC=93 to VIC=107).
>>
>> Signed-off-by: Shashank Sharma 
>> Signed-off-by: Sonika Jindal 
>> Reviewed-by: Jose Abreu 
>> Reviewed-by: Alex Deucher 
>>
>> Cc: Jose Abreu 
>> Cc: Alex Deucher 
>>
>> V2: Addressed review comments from Jose:
>>  - fix the timings for VIC 83, 90 and 91
>>  - fix formatting for VIC 93-107
>> ---
>>   drivers/gpu/drm/drm_edid.c | 215 
>> +
>>   1 file changed, 215 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 9506933..d18602c 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -994,6 +994,221 @@ struct minimode {
>> 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
>> +/* 65 - 1280x720 at 24Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
>> +   3080, 3300, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 66 - 1280x720 at 25Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
>> +   3740, 3960, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 67 - 1280x720 at 30Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
>> +   3080, 3300, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 68 - 1280x720 at 50Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
>> +   1760, 1980, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 69 - 1280x720 at 60Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
>> +   1430, 1650, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 70 - 1280x720 at 100Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
>> +   1760, 1980, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 71 - 1280x720 at 120Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
>> +   1430, 1650, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 72 - 1920x1080 at 24Hz */
>> +{ DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
>> +   2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 73 - 1920x1080 at 25Hz */
>> +{ DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
>> +   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 74 - 1920x1080 at 30Hz */
>> +{ DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
>> +   2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 75 - 1920x1080 at 50Hz */
>> +{ DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
>> +   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 76 - 1920x1080 at 60Hz */
>> +{ DRM_MODE("1920x1080", 

[PATCH] drm/bridge: dw-hdmi: Set sink_is_hdmi and sink_has_audio in mode_set

[Russell King - ARM Linux]

On Wed, Nov 02, 2016 at 09:47:50PM +, James Le Cuirot wrote:
> On Mon, 31 Oct 2016 16:37:36 +
> Russell King - ARM Linux  wrote:
> > We also need to apply this to the ELD as well - and several other
> > drivers are similarly buggy, and are going to need similar fixes
> > (thanks for pointing this problem out!)
> 
> Are you sure that is necessary? If you take a look at
> drm_load_edid_firmware, you'll see that it already calls
> drm_edid_to_eld when the drm_kms_helper.edid_firmware parameter is
> given.

Hmm, thanks for pointing that out - you are correct that we only need
to call drm_edid_to_eld() in get_modes().

I've also been digging more into the CEA861B spec, and it seems that
keying the infoframes off the result of drm_detect_hdmi_monitor() is
not entirely correct - CEA861B allows version 2 AVI infoframes to be
sent if the EDID version is 3, and audio (along with audio infoframes)
where audio is reported as supported.

I've been fixing this in TDA998x primarily at the moment, because that
works.  I've been avoiding iMX6 stuff (where dw-hdmi is used) while
iMX stabilises after the merge window - the autobuilers have been
reporting boot failures on those platforms, although it looks like rc3
has solved them all now.

> I briefly tested while giving drm_kms_helper.edid_firmware and it
> works, though I did have to assign edid via edid_blob->data like I did
> in my own patch. edid_blob_ptr is not an edid struct.

Yes, found that with applying a similar approach to TDA998x, I'll fix
this dw-hdmi patch up for that once I've finished with TDA998x.
Nevertheless, your report is good news.

> >  drivers/gpu/drm/bridge/dw-hdmi.c | 30 +-
> >  1 file changed, 25 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> > b/drivers/gpu/drm/bridge/dw-hdmi.c
> > index 77ab47341658..878568af2d41 100644
> > --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> > @@ -1413,6 +1413,30 @@ static void dw_hdmi_bridge_enable(struct drm_bridge 
> > *bridge)
> > mutex_unlock(>mutex);
> >  }
> >  
> > +static int dw_hdmi_connector_fill_modes(struct drm_connector *connector,
> > +   uint32_t maxX, uint32_t maxY)
> > +{
> > +   struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
> > +connector);
> > +   struct edid *edid;
> > +   int ret;
> > +
> > +   ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY);
> > +
> > +   edid = connector->edid_blob_ptr;
> > +   if (edid) {
> > +   hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> > +   hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
> > +   /* Store the ELD */
> > +   drm_edid_to_eld(connector, edid);
> > +   } else {
> > +   hdmi->sink_is_hdmi = false;
> > +   hdmi->sink_has_audio = false;
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> >  static enum drm_connector_status
> >  dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
> >  {
> > @@ -1444,12 +1468,8 @@ static int dw_hdmi_connector_get_modes(struct 
> > drm_connector *connector)
> > dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
> > edid->width_cm, edid->height_cm);
> >  
> > -   hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> > -   hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
> > 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");
> > @@ -1496,7 +1516,7 @@ static void dw_hdmi_connector_force(struct 
> > drm_connector *connector)
> >  
> >  static const struct drm_connector_funcs dw_hdmi_connector_funcs = {
> > .dpms = drm_atomic_helper_connector_dpms,
> > -   .fill_modes = drm_helper_probe_single_connector_modes,
> > +   .fill_modes = dw_hdmi_connector_fill_modes,
> > .detect = dw_hdmi_connector_detect,
> > .destroy = dw_hdmi_connector_destroy,
> > .force = dw_hdmi_connector_force,
> > 
> > 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Sharma, Shashank]

Regards

Shashank


On 11/2/2016 9:50 PM, Ville Syrjälä wrote:
> On Wed, Nov 02, 2016 at 09:39:48PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 11/2/2016 9:32 PM, Ville Syrjälä wrote:
>>> On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote:
 Regards

 Shashank


 On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
> On 02.11.2016 10:46, Shashank Sharma wrote:
>> CEA-861-F specs defines new 4k video modes to be used with
>> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
>> way till VIC=107.
>>
>> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
>> to be able to parse 4k modes using the existing techniques, we have
>> to complete the modedb (VIC=65 onwards).
>>
>> This patch adds:
>> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
>> - Newly added 4k modes (from VIC=93 to VIC=107).
> As I understand it modifies edid_cea_modes array. This array
> is used by couple of functions, particularly by drm_match_cea_mode,
> which is used by drm_hdmi_avi_infoframe_from_display_mode.
> I.e. since this patch AVI infoframes generated using drm core code will
> be different - they can contain VIC codes unknown to TV.
> I am not sure if it is harmful, but for sure this patch has visible
> impact on drivers behavior.
>
> Maybe it would be good to allow drivers to keep full compatibility with
> HDMI 1.4?
 Hello Andrzej,
 Thanks for the comment.
 If you watch the code flow carefully, this is driven by EDID. So any
 VIC, which is translated/transformed using this array, would be coming
 from the EDID itself.
>>> No. The user is free to specify any mode they wish. It doesn't have to
>>> come from the EDID. Not sure specifying a modern VIC for an older
>>> display is a good idea or not. If not, we could always check the cea_rev
>>> assuming it changed whenever the list if VICs was expanded.
>> I agree, that user can specify a mode, out of EDID too.
>> I am anyways planning to add a patch, where before loading HDMI 2.0 VICs
>> in AVI IF, we are checking the EDID rev.
>> That should solve our problem.
>>
>> So if edid_rev < 2.0
>>   do_not_load VICs from 93 - 107, but keep it 0.
> Why edid_rev and not cea_rev?
We can do that also, but in the current structure, we are already 
caching EDID rev, its just about re-using it.
AFAIK, we don't have CEA extension cached anywhere.

Shashank
>> Shashank
 So I dont think there would be a problem if the mode is defined in the
 EDID section itself, coz we are expecting the TV to know what its
 mentioning in EDID.

 This is how a typical flow would look:
 - hot-plug
 - driver reads modes specified in EDID basic.
 - driver parses various CEA extension blocks.
- For both of the above mentioned steps, driver will probe the
 functions like do_cea_modes which uses edid_cea_modes[] array.
 - driver will add the probed modes in EDID, into connector
 - driver will pass the connector to userspace
 - userspace will pick one of the probed modes for modeset.
 - during modeset, we will set VIC part for a CEA mode, in the AVI
 infoframe section.

 So in other words, the only source of a VIC (cea_mode) is from TV's own
 EDID.
 This means we should never run into an unknown VIC. There can be a 0 VIC
 (for non CEA modes), but not unknown one.

 Regards
 Shashank
> Regards
> Andrzej
>
>
>> Signed-off-by: Shashank Sharma 
>> Signed-off-by: Sonika Jindal 
>> Reviewed-by: Jose Abreu 
>> Reviewed-by: Alex Deucher 
>>
>> Cc: Jose Abreu 
>> Cc: Alex Deucher 
>>
>> V2: Addressed review comments from Jose:
>>  - fix the timings for VIC 83, 90 and 91
>>  - fix formatting for VIC 93-107
>> ---
>> drivers/gpu/drm/drm_edid.c | 215 
>> +
>> 1 file changed, 215 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 9506933..d18602c 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -994,6 +994,221 @@ struct minimode {
>> 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>   .vrefresh = 100, .picture_aspect_ratio = 
>> HDMI_PICTURE_ASPECT_16_9, },
>> +/* 65 - 1280x720 at 24Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
>> +   3080, 3300, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 24, .picture_aspect_ratio = 
>> HDMI_PICTURE_ASPECT_64_27, },
>> +/* 66 - 1280x720 at 25Hz */
>> +{ DRM_MODE("1280x720", 

[PATCH] drm/bridge: dw-hdmi: Set sink_is_hdmi and sink_has_audio in mode_set

[James Le Cuirot]

On Mon, 31 Oct 2016 16:37:36 +
Russell King - ARM Linux  wrote:

> On Sun, Oct 30, 2016 at 01:56:25PM +, James Le Cuirot wrote:
> > These were previously set in dw_hdmi_connector_get_modes but this
> > isn't called when the EDID is overridden. This can be seen in
> > drm_helper_probe_single_connector_modes. Using the
> > drm_kms_helper.edid_firmware parameter therefore always resulted in
> > silence, even when providing the very same EDID that had previously
> > been read from /sys.
> > 
> > I saw that other drivers set similar properties in mode_set rather
> > than get_modes. radeon_audio_hdmi_mode_set is one such example. It
> > calls radeon_connector_edid to retrieve the EDID so I drew
> > inspiration from this for the fix.
> 
> I'm not sure I particularly like this approach - the issue seems to
> be that drm_helper_probe_single_connector_modes() can avoid calling
> ->get_modes(), at which point our ideas about the EDID-based  
> capabilities become stale.
> 
> I think it would be better to provide our own ->fill_modes
> implementation which calls drm_helper_probe_single_connector_modes(),
> and then parses the resulting EDID, rather than re-parsing it each
> time we set a mode.

I also thought it was a little odd to do it via mode_set but figured it
was like that for a reason. I can't really comment on which approach is
better so some input from others would be appreciated.

> We also need to apply this to the ELD as well - and several other
> drivers are similarly buggy, and are going to need similar fixes
> (thanks for pointing this problem out!)

Are you sure that is necessary? If you take a look at
drm_load_edid_firmware, you'll see that it already calls
drm_edid_to_eld when the drm_kms_helper.edid_firmware parameter is
given.

> > Notes:
> > I do have some questions.
> >
> > I'm also wondering whether I should initially set both
> > properties to false in case the EDID is missing but the driver
> > didn't do this previously. Perhaps it should have?  
> 
> The driver's private data is initially zero-ed, so that should be
> unnecessary.

Right, but what if you hotplug from a display that has a readable EDID
to one that doesn't? You did this in your patch anyway.

> So maybe something like this instead - can you test please?

I briefly tested while giving drm_kms_helper.edid_firmware and it
works, though I did have to assign edid via edid_blob->data like I did
in my own patch. edid_blob_ptr is not an edid struct.

>  drivers/gpu/drm/bridge/dw-hdmi.c | 30 +-
>  1 file changed, 25 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 77ab47341658..878568af2d41 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1413,6 +1413,30 @@ static void dw_hdmi_bridge_enable(struct drm_bridge 
> *bridge)
>   mutex_unlock(>mutex);
>  }
>  
> +static int dw_hdmi_connector_fill_modes(struct drm_connector *connector,
> + uint32_t maxX, uint32_t maxY)
> +{
> + struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
> +  connector);
> + struct edid *edid;
> + int ret;
> +
> + ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY);
> +
> + edid = connector->edid_blob_ptr;
> + if (edid) {
> + hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> + hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
> + /* Store the ELD */
> + drm_edid_to_eld(connector, edid);
> + } else {
> + hdmi->sink_is_hdmi = false;
> + hdmi->sink_has_audio = false;
> + }
> +
> + return ret;
> +}
> +
>  static enum drm_connector_status
>  dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
>  {
> @@ -1444,12 +1468,8 @@ static int dw_hdmi_connector_get_modes(struct 
> drm_connector *connector)
>   dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
>   edid->width_cm, edid->height_cm);
>  
> - hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> - hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
>   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");
> @@ -1496,7 +1516,7 @@ static void dw_hdmi_connector_force(struct 
> drm_connector *connector)
>  
>  static const struct drm_connector_funcs dw_hdmi_connector_funcs = {
>   .dpms = drm_atomic_helper_connector_dpms,
> - .fill_modes = drm_helper_probe_single_connector_modes,
> + .fill_modes = dw_hdmi_connector_fill_modes,
>   .detect = dw_hdmi_connector_detect,
>   

[Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Sharma, Shashank]

Regards

Shashank


On 11/2/2016 9:32 PM, Ville Syrjälä wrote:
> On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
>>> On 02.11.2016 10:46, Shashank Sharma wrote:
 CEA-861-F specs defines new 4k video modes to be used with
 HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
 way till VIC=107.

 Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
 to be able to parse 4k modes using the existing techniques, we have
 to complete the modedb (VIC=65 onwards).

 This patch adds:
 - Timings for existing CEA video modes (from VIC=65 till VIC=92)
 - Newly added 4k modes (from VIC=93 to VIC=107).
>>> As I understand it modifies edid_cea_modes array. This array
>>> is used by couple of functions, particularly by drm_match_cea_mode,
>>> which is used by drm_hdmi_avi_infoframe_from_display_mode.
>>> I.e. since this patch AVI infoframes generated using drm core code will
>>> be different - they can contain VIC codes unknown to TV.
>>> I am not sure if it is harmful, but for sure this patch has visible
>>> impact on drivers behavior.
>>>
>>> Maybe it would be good to allow drivers to keep full compatibility with
>>> HDMI 1.4?
>> Hello Andrzej,
>> Thanks for the comment.
>> If you watch the code flow carefully, this is driven by EDID. So any
>> VIC, which is translated/transformed using this array, would be coming
>> from the EDID itself.
> No. The user is free to specify any mode they wish. It doesn't have to
> come from the EDID. Not sure specifying a modern VIC for an older
> display is a good idea or not. If not, we could always check the cea_rev
> assuming it changed whenever the list if VICs was expanded.
I agree, that user can specify a mode, out of EDID too.
I am anyways planning to add a patch, where before loading HDMI 2.0 VICs 
in AVI IF, we are checking the EDID rev.
That should solve our problem.

So if edid_rev < 2.0
 do_not_load VICs from 93 - 107, but keep it 0.

Shashank
>> So I dont think there would be a problem if the mode is defined in the
>> EDID section itself, coz we are expecting the TV to know what its
>> mentioning in EDID.
>>
>> This is how a typical flow would look:
>> - hot-plug
>> - driver reads modes specified in EDID basic.
>> - driver parses various CEA extension blocks.
>>   - For both of the above mentioned steps, driver will probe the
>> functions like do_cea_modes which uses edid_cea_modes[] array.
>> - driver will add the probed modes in EDID, into connector
>> - driver will pass the connector to userspace
>> - userspace will pick one of the probed modes for modeset.
>> - during modeset, we will set VIC part for a CEA mode, in the AVI
>> infoframe section.
>>
>> So in other words, the only source of a VIC (cea_mode) is from TV's own
>> EDID.
>> This means we should never run into an unknown VIC. There can be a 0 VIC
>> (for non CEA modes), but not unknown one.
>>
>> Regards
>> Shashank
>>> Regards
>>> Andrzej
>>>
>>>
 Signed-off-by: Shashank Sharma 
 Signed-off-by: Sonika Jindal 
 Reviewed-by: Jose Abreu 
 Reviewed-by: Alex Deucher 

 Cc: Jose Abreu 
 Cc: Alex Deucher 

 V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107
 ---
drivers/gpu/drm/drm_edid.c | 215 
 +
1 file changed, 215 insertions(+)

 diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
 index 9506933..d18602c 100644
 --- a/drivers/gpu/drm/drm_edid.c
 +++ b/drivers/gpu/drm/drm_edid.c
 @@ -994,6 +994,221 @@ struct minimode {
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = 
 HDMI_PICTURE_ASPECT_16_9, },
 +  /* 65 - 1280x720 at 24Hz */
 +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
 + 3080, 3300, 0, 720, 725, 730, 750, 0,
 + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 +.vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
 +  /* 66 - 1280x720 at 25Hz */
 +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
 + 3740, 3960, 0, 720, 725, 730, 750, 0,
 + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 +.vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
 +  /* 67 - 1280x720 at 30Hz */
 +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
 + 3080, 3300, 0, 720, 725, 730, 750, 0,
 + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 +.vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
 +  /* 68 - 1280x720 at 50Hz */
 +  { DRM_MODE("1280x720", 

[PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Sharma, Shashank]

Regards

Shashank


On 11/2/2016 8:44 PM, Andrzej Hajda wrote:
> On 02.11.2016 15:44, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
>>> On 02.11.2016 10:46, Shashank Sharma wrote:
 CEA-861-F specs defines new 4k video modes to be used with
 HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
 way till VIC=107.

 Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
 to be able to parse 4k modes using the existing techniques, we have
 to complete the modedb (VIC=65 onwards).

 This patch adds:
 - Timings for existing CEA video modes (from VIC=65 till VIC=92)
 - Newly added 4k modes (from VIC=93 to VIC=107).
>>> As I understand it modifies edid_cea_modes array. This array
>>> is used by couple of functions, particularly by drm_match_cea_mode,
>>> which is used by drm_hdmi_avi_infoframe_from_display_mode.
>>> I.e. since this patch AVI infoframes generated using drm core code will
>>> be different - they can contain VIC codes unknown to TV.
>>> I am not sure if it is harmful, but for sure this patch has visible
>>> impact on drivers behavior.
>>>
>>> Maybe it would be good to allow drivers to keep full compatibility with
>>> HDMI 1.4?
>> Hello Andrzej,
>> Thanks for the comment.
>> If you watch the code flow carefully, this is driven by EDID. So any
>> VIC, which is translated/transformed using this array, would be coming
>> from the EDID itself.
>> So I dont think there would be a problem if the mode is defined in the
>> EDID section itself, coz we are expecting the TV to know what its
>> mentioning in EDID.
>>
>> This is how a typical flow would look:
>> - hot-plug
>> - driver reads modes specified in EDID basic.
>> - driver parses various CEA extension blocks.
>>   - For both of the above mentioned steps, driver will probe the
>> functions like do_cea_modes which uses edid_cea_modes[] array.
>> - driver will add the probed modes in EDID, into connector
>> - driver will pass the connector to userspace
>> - userspace will pick one of the probed modes for modeset.
>> - during modeset, we will set VIC part for a CEA mode, in the AVI
>> infoframe section.
>>
>> So in other words, the only source of a VIC (cea_mode) is from TV's own
>> EDID.
>> This means we should never run into an unknown VIC. There can be a 0 VIC
>> (for non CEA modes), but not unknown one.
> For example 3840x2160 at 30Hz has no VIC in HDMI 1.4 but it can
> be present in HDMI vendor specific block with HDMI_VIC 1, on the
> other side it has VIC 95 in HDMI 2.0. So before your patch
> AVI infoframe.video_code is set to 0, after your patch is set to 95.
I agree, this particular case is true only for 4k at 30 mode can be present 
in vendor specific blocks.
But as per HDMI compliance test cases, if all the timings match to the 
mode specified, the VIC should
be 95.
I was going through the HDMI 1.4 spec, and CEA-861-D/E specs with these 
corner cases, and we saw that its ok
to specify the right VIC, as per the CEA specs.

Do you also think this is the right thing to do ?
I have another patch coming up, where we can check the EDID version 
before setting VIC in AVI IF.

- Shashank
>
> Regards
> Andrzej
>
>
>> Regards
>> Shashank
>>> Regards
>>> Andrzej
>>>
>>>
 Signed-off-by: Shashank Sharma 
 Signed-off-by: Sonika Jindal 
 Reviewed-by: Jose Abreu 
 Reviewed-by: Alex Deucher 

 Cc: Jose Abreu 
 Cc: Alex Deucher 

 V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107
 ---
drivers/gpu/drm/drm_edid.c | 215 
 +
1 file changed, 215 insertions(+)

 diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
 index 9506933..d18602c 100644
 --- a/drivers/gpu/drm/drm_edid.c
 +++ b/drivers/gpu/drm/drm_edid.c
 @@ -994,6 +994,221 @@ struct minimode {
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = 
 HDMI_PICTURE_ASPECT_16_9, },
 +  /* 65 - 1280x720 at 24Hz */
 +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
 + 3080, 3300, 0, 720, 725, 730, 750, 0,
 + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 +.vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
 +  /* 66 - 1280x720 at 25Hz */
 +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
 + 3740, 3960, 0, 720, 725, 730, 750, 0,
 + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 +.vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
 +  /* 67 - 1280x720 at 30Hz */
 +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
 + 3080, 3300, 0, 

[Bug 10499] S3 savage4: glxgears hangs pc

[bugzilla-dae...@freedesktop.org]

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

Peter Hutterer  changed:

   What|Removed |Added

 CC||peter.hutterer at who-t.net
Product|X.org integration tests |DRI
 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG
  Component|general |General
  Alias|a, to.my|
   Assignee|peter.hutterer at who-t.net|dri-devel at 
lists.freedesktop
   ||.org

--- Comment #10 from Peter Hutterer  ---
Not sure why this was moved to XIT, so moving back and closing as per comment
#9 and 9 years of silence after that.

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

[RESEND][PATCH 2/2 v4] drm/bridge: adv7511: Enable the audio data and clock pads on adv7533

[John Stultz]

From: Srinivas Kandagatla 

This patch enables the Audio Data and Clock pads to the adv7533 bridge.
Without this patch audio can not be played.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
Cc: Wolfram Sang 
Cc: Srinivas Kandagatla 
Cc: "Ville Syrjälä" 
Cc: Boris Brezillon 
Cc: Andy Green 
Cc: Dave Long 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Mark Brown 
Cc: Lars-Peter Clausen 
Cc: Jose Abreu 
Cc: Kuninori Morimoto 
Cc: dri-devel at lists.freedesktop.org
Reviewed-by: Archit Taneja 
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/bridge/adv7511/adv7533.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c 
b/drivers/gpu/drm/bridge/adv7511/adv7533.c
index d7f7b7c..8b21037 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
@@ -29,6 +29,7 @@ static const struct reg_sequence 
adv7533_cec_fixed_registers[] = {
{ 0x17, 0xd0 },
{ 0x24, 0x20 },
{ 0x57, 0x11 },
+   { 0x05, 0xc8 },
 };

 static const struct regmap_config adv7533_cec_regmap_config = {
-- 
2.7.4

[RESEND][PATCH 1/2 v4] drm/bridge: adv7511: Add Audio support.

[John Stultz]

This patch adds support to Audio for both adv7511 and adv7533
bridge chips.

This patch was originally from [1] by Lars-Peter Clausen 
and was adapted by Archit Taneja  and
Srinivas Kandagatla .

Then I heavily reworked it to use the hdmi-codec driver. And also
folded in some audio packet initialization done by Andy Green
. So credit to them, but blame to me.

[1] 
https://github.com/analogdevicesinc/linux/blob/xcomm_zynq/drivers/gpu/drm/i2c/adv7511_audio.c

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
Cc: Wolfram Sang 
Cc: Srinivas Kandagatla 
Cc: "Ville Syrjälä" 
Cc: Boris Brezillon 
Cc: Andy Green 
Cc: Dave Long 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Mark Brown 
Cc: Lars-Peter Clausen 
Cc: Jose Abreu 
Cc: Kuninori Morimoto 
Cc: dri-devel at lists.freedesktop.org
Reviewed-by: Archit Taneja 
Acked-by: Lars-Peter Clausen 
Signed-off-by: John Stultz 
---
v4:
* Kconfig tweaks suggested by Lars-Peter Clausen
v3:
* Allowed audio support to be configured in or out, as suggested by Laurent
* Minor cleanups suggested by Laurent
* Folded in Andy's audio packet initialization patch, as suggested by Archit
---
 drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
 drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
 drivers/gpu/drm/bridge/adv7511/adv7511.h   |  16 ++
 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 213 +
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |   4 +
 5 files changed, 242 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c

diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig 
b/drivers/gpu/drm/bridge/adv7511/Kconfig
index d2b0499..2fed567 100644
--- a/drivers/gpu/drm/bridge/adv7511/Kconfig
+++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
@@ -6,6 +6,14 @@ config DRM_I2C_ADV7511
help
  Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.

+config DRM_I2C_ADV7511_AUDIO
+   bool "ADV7511 HDMI Audio driver"
+   depends on DRM_I2C_ADV7511 && SND_SOC
+   select SND_SOC_HDMI_CODEC
+   help
+ Support the ADV7511 HDMI Audio interface. This is used in
+ conjunction with the AV7511  HDMI driver.
+
 config DRM_I2C_ADV7533
bool "ADV7533 encoder"
depends on DRM_I2C_ADV7511
diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile 
b/drivers/gpu/drm/bridge/adv7511/Makefile
index 9019327..5ba6755 100644
--- a/drivers/gpu/drm/bridge/adv7511/Makefile
+++ b/drivers/gpu/drm/bridge/adv7511/Makefile
@@ -1,3 +1,4 @@
 adv7511-y := adv7511_drv.o
+adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
 adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 161c923..992d76c 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -309,6 +309,8 @@ struct adv7511 {
struct drm_display_mode curr_mode;

unsigned int f_tmds;
+   unsigned int f_audio;
+   unsigned int audio_source;

unsigned int current_edid_segment;
uint8_t edid_buf[256];
@@ -334,6 +336,7 @@ struct adv7511 {
bool use_timing_gen;

enum adv7511_type type;
+   struct platform_device *audio_pdev;
 };

 #ifdef CONFIG_DRM_I2C_ADV7533
@@ -389,4 +392,17 @@ static inline int adv7533_parse_dt(struct device_node *np, 
struct adv7511 *adv)
 }
 #endif

+#ifdef CONFIG_DRM_I2C_ADV7511_AUDIO
+int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511);
+void adv7511_audio_exit(struct adv7511 *adv7511);
+#else /*CONFIG_DRM_I2C_ADV7511_AUDIO */
+static inline int adv7511_audio_init(struct device *dev, struct adv7511 
*adv7511)
+{
+   return 0;
+}
+static inline void adv7511_audio_exit(struct adv7511 *adv7511)
+{
+}
+#endif /* CONFIG_DRM_I2C_ADV7511_AUDIO */
+
 #endif /* __DRM_I2C_ADV7511_H__ */
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
new file mode 100644
index 000..5ce29a5
--- /dev/null
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
@@ -0,0 +1,213 @@
+/*
+ * Analog Devices ADV7511 HDMI transmitter driver
+ *
+ * Copyright 2012 Analog Devices Inc.
+ * Copyright (c) 2016, Linaro Limited
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "adv7511.h"
+
+static void adv7511_calc_cts_n(unsigned int f_tmds, unsigned int fs,
+  unsigned int *cts, unsigned int *n)
+{
+   switch (fs) {
+   case 32000:
+   *n = 4096;
+   break;
+   case 44100:
+   *n = 6272;
+   break;
+   case 48000:
+   *n = 6144;
+   break;
+   }
+
+   *cts = ((f_tmds * *n) / (128 * fs)) * 1000;
+}
+
+static int adv7511_update_cts_n(struct adv7511 *adv7511)
+{
+   unsigned int cts = 0;
+   unsigned int n = 0;
+
+   

[RESEND][PATCH 0/2 v4] Audio support for adv7511 hdmi bridge

[John Stultz]

Just wanted to resend the adv7511 hdmi bridge audio support for
review and consideration for merging.

I've taken the core audio work done by Lars-Peter Clausen, and
adapted by Srinivas Kandagatla and Archit Taneja, and tried to
rework it to use the hdmi-codec sound driver.

This patchset, along with the i2s driver and dts changes allows
HDMI audio to work on the HiKey board. 

As suggested, I do intend to rework the dts changes (not submitted
here) to use the of graph simple-card, instead of the simple-card
method I currently use, but I don't believe that that change would
effect these patches.

I'd really appreciate any thoughts or feedback.

thanks
-john

New in v4:
* Kconfig tweaks suggested by Lars-Peter Clausen

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
Cc: Wolfram Sang 
Cc: Srinivas Kandagatla 
Cc: "Ville Syrjälä" 
Cc: Boris Brezillon 
Cc: Andy Green 
Cc: Dave Long 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Mark Brown 
Cc: Lars-Peter Clausen 
Cc: Jose Abreu 
Cc: Kuninori Morimoto 
Cc: dri-devel at lists.freedesktop.org

John Stultz (1):
  drm/bridge: adv7511: Add Audio support.

Srinivas Kandagatla (1):
  drm/bridge: adv7511: Enable the audio data and clock pads on adv7533

 drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
 drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
 drivers/gpu/drm/bridge/adv7511/adv7511.h   |  16 ++
 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 213 +
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |   4 +
 drivers/gpu/drm/bridge/adv7511/adv7533.c   |   1 +
 6 files changed, 243 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c

-- 
2.7.4

[Bug 93649] [radeonsi] Graphics lockup while playing tf2

[bugzilla-dae...@freedesktop.org]

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

pandiculationfinch at gmail.com changed:

   What|Removed |Added

 CC||pandiculationfinch at gmail.co
   ||m

--- Comment #58 from pandiculationfinch at gmail.com ---
Created attachment 127704
  --> https://bugs.freedesktop.org/attachment.cgi?id=127704=edit
package update history that lead to a change in behaviour

Last night the freezes I've been having changed their behaviour. They use to
just cause the system to completely freeze up. Now my system does a immediate
shutdown.

this is interesting because I had just updated linux and mesa-git so I
potentially have a commit range in mesa/llvm which has code related to the
problem. I'm going to rollback my kernel/headers tonight and reboot to rule
that out. And if that doesn't cause the hang to re-appear I'll roll back mesa
tomorrow. and then I'll rollback llvm.

In the meantime I've attached the package update history for the last few days
in case that helps any of the developers.

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

[PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Sharma, Shashank]

Regards

Shashank


On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
> On 02.11.2016 10:46, Shashank Sharma wrote:
>> CEA-861-F specs defines new 4k video modes to be used with
>> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
>> way till VIC=107.
>>
>> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
>> to be able to parse 4k modes using the existing techniques, we have
>> to complete the modedb (VIC=65 onwards).
>>
>> This patch adds:
>> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
>> - Newly added 4k modes (from VIC=93 to VIC=107).
> As I understand it modifies edid_cea_modes array. This array
> is used by couple of functions, particularly by drm_match_cea_mode,
> which is used by drm_hdmi_avi_infoframe_from_display_mode.
> I.e. since this patch AVI infoframes generated using drm core code will
> be different - they can contain VIC codes unknown to TV.
> I am not sure if it is harmful, but for sure this patch has visible
> impact on drivers behavior.
>
> Maybe it would be good to allow drivers to keep full compatibility with
> HDMI 1.4?
Hello Andrzej,
Thanks for the comment.
If you watch the code flow carefully, this is driven by EDID. So any 
VIC, which is translated/transformed using this array, would be coming 
from the EDID itself.
So I dont think there would be a problem if the mode is defined in the 
EDID section itself, coz we are expecting the TV to know what its 
mentioning in EDID.

This is how a typical flow would look:
- hot-plug
- driver reads modes specified in EDID basic.
- driver parses various CEA extension blocks.
 - For both of the above mentioned steps, driver will probe the 
functions like do_cea_modes which uses edid_cea_modes[] array.
- driver will add the probed modes in EDID, into connector
- driver will pass the connector to userspace
- userspace will pick one of the probed modes for modeset.
- during modeset, we will set VIC part for a CEA mode, in the AVI 
infoframe section.

So in other words, the only source of a VIC (cea_mode) is from TV's own 
EDID.
This means we should never run into an unknown VIC. There can be a 0 VIC 
(for non CEA modes), but not unknown one.

Regards
Shashank
> Regards
> Andrzej
>
>
>> Signed-off-by: Shashank Sharma 
>> Signed-off-by: Sonika Jindal 
>> Reviewed-by: Jose Abreu 
>> Reviewed-by: Alex Deucher 
>>
>> Cc: Jose Abreu 
>> Cc: Alex Deucher 
>>
>> V2: Addressed review comments from Jose:
>>  - fix the timings for VIC 83, 90 and 91
>>  - fix formatting for VIC 93-107
>> ---
>>   drivers/gpu/drm/drm_edid.c | 215 
>> +
>>   1 file changed, 215 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 9506933..d18602c 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -994,6 +994,221 @@ struct minimode {
>> 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
>> +/* 65 - 1280x720 at 24Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
>> +   3080, 3300, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 66 - 1280x720 at 25Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
>> +   3740, 3960, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 67 - 1280x720 at 30Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
>> +   3080, 3300, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 68 - 1280x720 at 50Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
>> +   1760, 1980, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 69 - 1280x720 at 60Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
>> +   1430, 1650, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 70 - 1280x720 at 100Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
>> +   1760, 1980, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>> +  .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 71 - 1280x720 at 120Hz */
>> + 

[PATCH] drm/sun4i: Add a few formats

[Maxime Ripard]

On Sat, Oct 29, 2016 at 06:25:46PM +0800, Chen-Yu Tsai wrote:
> On Thu, Oct 27, 2016 at 10:35 PM, Maxime Ripard
>  wrote:
> > Hi,
> >
> > On Tue, Oct 25, 2016 at 08:42:26AM +0800, Chen-Yu Tsai wrote:
> >> On Mon, Oct 24, 2016 at 10:40 PM, Maxime Ripard
> >>  wrote:
> >> > Hi,
> >> >
> >> > On Fri, Oct 21, 2016 at 11:15:32AM +0800, Chen-Yu Tsai wrote:
> >> >> On Tue, Oct 18, 2016 at 4:46 PM, Maxime Ripard
> >> >>  wrote:
> >> >> > The planes can do more than what was previously exposed. Add support 
> >> >> > for
> >> >> > them.
> >> >> >
> >> >> > Signed-off-by: Maxime Ripard 
> >> >> > ---
> >> >> >  drivers/gpu/drm/sun4i/sun4i_backend.c | 20 
> >> >> >  drivers/gpu/drm/sun4i/sun4i_layer.c   |  6 ++
> >> >> >  2 files changed, 26 insertions(+)
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
> >> >> > b/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> >> > index afb7ddf660ef..b184a476a480 100644
> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> >> > @@ -96,6 +96,22 @@ static int 
> >> >> > sun4i_backend_drm_format_to_layer(struct drm_plane *plane,
> >> >> > *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB;
> >> >> > break;
> >> >> >
> >> >> > +   case DRM_FORMAT_ARGB:
> >> >> > +   *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB;
> >> >> > +   break;
> >> >> > +
> >> >> > +   case DRM_FORMAT_ARGB1555:
> >> >> > +   *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB1555;
> >> >> > +   break;
> >> >> > +
> >> >> > +   case DRM_FORMAT_RGBA5551:
> >> >> > +   *mode = SUN4I_BACKEND_LAY_FBFMT_RGBA5551;
> >> >> > +   break;
> >> >> > +
> >> >> > +   case DRM_FORMAT_RGBA:
> >> >> > +   *mode = SUN4I_BACKEND_LAY_FBFMT_RGBA;
> >> >>
> >> >> The A20 manual only lists ARGB, not RGBA. There might be
> >> >> some discrepancy here. We can deal with them
> >> >
> >> > Hmm, yes, that's weird. But I guess this would be part of porting it
> >> > to the A20.
> >> >
> >> >> Also there are some more formats missing from the list, could you
> >> >> add them as well?
> >> >
> >> > Which one do you refer to?
> >>
> >> RGB556 and RGB655.
> >
> > These formats are not supported by Linux yet though.
> 
> I see. Sorry for the noise.
> 
> Acked-by: Chen-Yu Tsai 

Applied with a more verbose commit log.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161102/5e496141/attachment.sig>

[Bug 90666] Stacktrace / Warning during switch (ctrl+alt+f1) to console on zbook 14 (Radeon/intel)

[bugzilla-dae...@freedesktop.org]

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

Tomasz Fortuna  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Tomasz Fortuna  ---
I'm currently fighting on 4.7.8 with pretty much other bugs. In general
everything works, almost stable except for MST - but that's a case for a
different bug.

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

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-dae...@freedesktop.org]

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

--- Comment #42 from Evan Black  ---
Can't really contribute much in terms of any of the tracing stuff; just
dropping my specs here as I have similar issues.

Core i5 4690k
R9 285
8 GB Memory

I've tried it both on my SSD and HDD, and the issue was exactly the same:
freezing in the early stages of the match or when new players join the game,
obviously linked to loading their model / textures.

Please keep the search up; I'd love to play this game just as smooth as it runs
on Windows.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161102/ea87cf16/attachment-0001.html>

[Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Ville Syrjälä]

On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote:
> CEA-861-F specs defines new 4k video modes to be used with
> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> way till VIC=107.
> 
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse 4k modes using the existing techniques, we have
> to complete the modedb (VIC=65 onwards).
> 
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Sonika Jindal 
> Reviewed-by: Jose Abreu 
> Reviewed-by: Alex Deucher 
> 
> Cc: Jose Abreu 
> Cc: Alex Deucher 
> 
> V2: Addressed review comments from Jose:
>   - fix the timings for VIC 83, 90 and 91
>   - fix formatting for VIC 93-107
> ---
>  drivers/gpu/drm/drm_edid.c | 215 
> +
>  1 file changed, 215 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9506933..d18602c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -994,6 +994,221 @@ struct minimode {

> + /* 77 - 1920x1080 at 100Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 297000, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +  .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },

My script gave me:
   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 297000, 1920, 2448,
  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },

Manual reading of the spec agrees with my script.


> + /* 104 - 3840x2160p at 25Hz 64:27 */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, 3840, 4016,
> + 4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27},

My script gave me:
   { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, 3840, 4896,
  4984, 5280, 0, 2160, 2168, 2178, 2250, 0,
  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },

Manual reading of the spec agrees with my script.

Outside those two I don't see any errors in your table when compared to my
script's output. I do see some differences in the already existing modes though.
I'll look those over and send a patch if necessary.

-- 
Ville Syrjälä
Intel OTC

[Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Ville Syrjälä]

On Wed, Nov 02, 2016 at 09:57:12PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/2/2016 9:50 PM, Ville Syrjälä wrote:
> > On Wed, Nov 02, 2016 at 09:39:48PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 11/2/2016 9:32 PM, Ville Syrjälä wrote:
> >>> On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote:
>  Regards
> 
>  Shashank
> 
> 
>  On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
> > On 02.11.2016 10:46, Shashank Sharma wrote:
> >> CEA-861-F specs defines new 4k video modes to be used with
> >> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> >> way till VIC=107.
> >>
> >> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> >> to be able to parse 4k modes using the existing techniques, we have
> >> to complete the modedb (VIC=65 onwards).
> >>
> >> This patch adds:
> >> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> >> - Newly added 4k modes (from VIC=93 to VIC=107).
> > As I understand it modifies edid_cea_modes array. This array
> > is used by couple of functions, particularly by drm_match_cea_mode,
> > which is used by drm_hdmi_avi_infoframe_from_display_mode.
> > I.e. since this patch AVI infoframes generated using drm core code will
> > be different - they can contain VIC codes unknown to TV.
> > I am not sure if it is harmful, but for sure this patch has visible
> > impact on drivers behavior.
> >
> > Maybe it would be good to allow drivers to keep full compatibility with
> > HDMI 1.4?
>  Hello Andrzej,
>  Thanks for the comment.
>  If you watch the code flow carefully, this is driven by EDID. So any
>  VIC, which is translated/transformed using this array, would be coming
>  from the EDID itself.
> >>> No. The user is free to specify any mode they wish. It doesn't have to
> >>> come from the EDID. Not sure specifying a modern VIC for an older
> >>> display is a good idea or not. If not, we could always check the cea_rev
> >>> assuming it changed whenever the list if VICs was expanded.
> >> I agree, that user can specify a mode, out of EDID too.
> >> I am anyways planning to add a patch, where before loading HDMI 2.0 VICs
> >> in AVI IF, we are checking the EDID rev.
> >> That should solve our problem.
> >>
> >> So if edid_rev < 2.0
> >>   do_not_load VICs from 93 - 107, but keep it 0.
> > Why edid_rev and not cea_rev?
> We can do that also, but in the current structure, we are already 
> caching EDID rev, its just about re-using it.
> AFAIK, we don't have CEA extension cached anywhere.

Yes we do.

> 
> Shashank
> >> Shashank
>  So I dont think there would be a problem if the mode is defined in the
>  EDID section itself, coz we are expecting the TV to know what its
>  mentioning in EDID.
> 
>  This is how a typical flow would look:
>  - hot-plug
>  - driver reads modes specified in EDID basic.
>  - driver parses various CEA extension blocks.
> - For both of the above mentioned steps, driver will probe the
>  functions like do_cea_modes which uses edid_cea_modes[] array.
>  - driver will add the probed modes in EDID, into connector
>  - driver will pass the connector to userspace
>  - userspace will pick one of the probed modes for modeset.
>  - during modeset, we will set VIC part for a CEA mode, in the AVI
>  infoframe section.
> 
>  So in other words, the only source of a VIC (cea_mode) is from TV's own
>  EDID.
>  This means we should never run into an unknown VIC. There can be a 0 VIC
>  (for non CEA modes), but not unknown one.
> 
>  Regards
>  Shashank
> > Regards
> > Andrzej
> >
> >
> >> Signed-off-by: Shashank Sharma 
> >> Signed-off-by: Sonika Jindal 
> >> Reviewed-by: Jose Abreu 
> >> Reviewed-by: Alex Deucher 
> >>
> >> Cc: Jose Abreu 
> >> Cc: Alex Deucher 
> >>
> >> V2: Addressed review comments from Jose:
> >>- fix the timings for VIC 83, 90 and 91
> >>- fix formatting for VIC 93-107
> >> ---
> >> drivers/gpu/drm/drm_edid.c | 215 
> >> +
> >> 1 file changed, 215 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 9506933..d18602c 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -994,6 +994,221 @@ struct minimode {
> >>   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> >>   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> .vrefresh = 100, .picture_aspect_ratio = 
> >> HDMI_PICTURE_ASPECT_16_9, },
> >> +  /* 65 - 1280x720 at 24Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> 

[Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Ville Syrjälä]

On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote:
> CEA-861-F specs defines new 4k video modes to be used with
> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> way till VIC=107.
> 
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse 4k modes using the existing techniques, we have
> to complete the modedb (VIC=65 onwards).
> 
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Sonika Jindal 
> Reviewed-by: Jose Abreu 
> Reviewed-by: Alex Deucher 
> 
> Cc: Jose Abreu 
> Cc: Alex Deucher 
> 
> V2: Addressed review comments from Jose:
>   - fix the timings for VIC 83, 90 and 91
>   - fix formatting for VIC 93-107
> ---
>  drivers/gpu/drm/drm_edid.c | 215 
> +
>  1 file changed, 215 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9506933..d18602c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -994,6 +994,221 @@ struct minimode {
>  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720 at 24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720 at 25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720 at 30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 68 - 1280x720 at 50Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 69 - 1280x720 at 60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 70 - 1280x720 at 100Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 71 - 1280x720 at 120Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 72 - 1920x1080 at 24Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 73 - 1920x1080 at 25Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 74 - 1920x1080 at 30Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
> +2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 75 - 1920x1080 at 50Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 76 - 1920x1080 at 60Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2008,
> +2052, 2200, 0, 1080, 1084, 1089, 1125, 0,

[PATCH 3/3] drm/tilcdc: Add drm bridge support for attaching drm bridge drivers

[Jyri Sarha]

Adds drm bride support for attaching drm bridge drivers to tilcdc. The
decision whether a video port leads to an external encoder or bridge
is made simply based on remote device's compatible string. The code
has been tested with BeagleBone-Black with and without BeagleBone
DVI-D Cape Rev A3 using ti-tfp410 driver.

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/display/tilcdc/tilcdc.txt  |   7 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|   7 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   2 +
 drivers/gpu/drm/tilcdc/tilcdc_external.c   | 140 ++---
 drivers/gpu/drm/tilcdc/tilcdc_external.h   |   1 +
 5 files changed, 135 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt 
b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
index 6fddb4f..ae7a942 100644
--- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
@@ -34,9 +34,10 @@ Optional properties:

 Optional nodes:

- - port/ports: to describe a connection to an external encoder. The
-   binding follows Documentation/devicetree/bindings/graph.txt and
-   suppors a single port with a single endpoint.
+ - port/ports: to describe a connection to an external encoder or
+   bridge. The binding follows
+   Documentation/devicetree/bindings/graph.txt and suppors a single
+   port with a single endpoint.

  - See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and
Documentation/devicetree/bindings/display/tilcdc/tfp410.txt for connecting
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index dcc9621..ec22576 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -384,9 +384,14 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
device *dev)
ret = tilcdc_add_external_encoders(ddev);
if (ret < 0)
goto init_failed;
+   } else {
+   ret = tilcdc_attach_remote_device(ddev);
+   if (ret)
+   goto init_failed;
}

-   if ((priv->num_encoders == 0) || (priv->num_connectors == 0)) {
+   if (!priv->remote_encoder &&
+   ((priv->num_encoders == 0) || (priv->num_connectors == 0))) {
dev_err(dev, "no encoders/connectors found\n");
ret = -ENXIO;
goto init_failed;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index d31fe5d..283ff28 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -90,6 +90,8 @@ struct tilcdc_drm_private {
struct drm_connector *connectors[8];
const struct drm_connector_helper_funcs *connector_funcs[8];

+   struct drm_encoder *remote_encoder;
+
bool is_registered;
bool is_componentized;
 };
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c 
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 06a4c58..bcb1324 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -28,6 +28,18 @@
.raster_order   = 0,
 };

+static const struct tilcdc_panel_info panel_info_default = {
+   .ac_bias= 255,
+   .ac_bias_intrpt = 0,
+   .dma_burst_sz   = 16,
+   .bpp= 16,
+   .fdd= 0x80,
+   .tft_alt_mode   = 0,
+   .sync_edge  = 0,
+   .sync_ctrl  = 1,
+   .raster_order   = 0,
+};
+
 static int tilcdc_external_mode_valid(struct drm_connector *connector,
  struct drm_display_mode *mode)
 {
@@ -130,6 +142,101 @@ void tilcdc_remove_external_encoders(struct drm_device 
*dev)
 priv->connector_funcs[i]);
 }

+static struct drm_encoder_funcs tilcdc_remote_encoder_funcs = {
+   .destroy= drm_encoder_cleanup,
+};
+
+static
+int tilcdc_attach_bridge(struct drm_device *ddev, struct drm_bridge *bridge)
+{
+   struct tilcdc_drm_private *priv = ddev->dev_private;
+   int ret;
+
+   priv->remote_encoder->possible_crtcs = BIT(0);
+   priv->remote_encoder->bridge = bridge;
+   bridge->encoder = priv->remote_encoder;
+
+   ret = drm_bridge_attach(ddev, bridge);
+   if (ret) {
+   dev_err(ddev->dev, "drm_bridge_attach() failed %d\n", ret);
+   return ret;
+   }
+
+   tilcdc_crtc_set_panel_info(priv->crtc, _info_default);
+
+   return 0;
+}
+
+static int tilcdc_node_has_port(struct device_node *dev_node)
+{
+   struct device_node *node;
+
+   node = of_get_child_by_name(dev_node, "ports");
+   if (!node)
+   node = 

[PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver

[Jyri Sarha]

Add very basic ti-ftp410 HDMI transmitter driver. The only feature
separating this from a completely dummy bridge is the DDC i2c
support. However, other HW specific features may be added later when
needed. For instance there is a set of registers behind i2c if it is
connected. The implementations is tested against my new tilcdc bridge
support and works with BeagleBone DVI-D Cape Rev A3. A DT binding
document is also added.

Signed-off-by: Jyri Sarha 
---
 .../bindings/display/bridge/ti,tfp410.txt  |  30 
 drivers/gpu/drm/bridge/Kconfig |   7 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/ti-tfp410.c | 199 +
 4 files changed, 237 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
 create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt 
b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
new file mode 100644
index 000..dc93713
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
@@ -0,0 +1,30 @@
+TFP410 HDMI/DVI bridge bindings
+
+Required properties:
+   - compatible: "ti,tfp410"
+
+Optional properties:
+   - ddc-i2c: phandle of an I2C controller used for DDC EDID probing
+
+Optional subnodes:
+   - video input: this subnode can contain a video input port node
+ to connect the bridge to a display controller output (See this
+ documentation [1]).
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   hdmi-bridge {
+   compatible = "ti,tfp410";
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   bridge_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index bd6acc8..a424e03 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -81,6 +81,13 @@ config DRM_TOSHIBA_TC358767
---help---
  Toshiba TC358767 eDP bridge chip driver.

+config DRM_TI_TFP410
+   tristate "TI TFP410 DVI/HDMI bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   ---help---
+ Texas Instruments TFP410 DVI/HDMI Transmitter driver
+
 source "drivers/gpu/drm/bridge/analogix/Kconfig"

 source "drivers/gpu/drm/bridge/adv7511/Kconfig"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 97ed1a5..8b065d9 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
+obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
b/drivers/gpu/drm/bridge/ti-tfp410.c
new file mode 100644
index 000..b0753d2
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -0,0 +1,199 @@
+/*
+ * Copyright (C) 2016 Texas Instruments
+ * Author: Jyri Sarha 
+ *
+ * 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 
+#include 
+
+struct tfp410 {
+   struct drm_bridge   bridge;
+   struct drm_connectorconnector;
+
+   struct i2c_adapter  *ddc;
+
+   struct device *dev;
+};
+
+static inline struct tfp410 *
+drm_bridge_to_tfp410(struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct tfp410, bridge);
+}
+
+static inline struct tfp410 *
+drm_connector_to_tfp410(struct drm_connector *connector)
+{
+   return container_of(connector, struct tfp410, connector);
+}
+
+static int tfp410_get_modes(struct drm_connector *connector)
+{
+   struct tfp410 *hdmi = drm_connector_to_tfp410(connector);
+   struct edid *edid;
+   int ret;
+
+   if (!hdmi->ddc)
+   goto fallback;
+
+   edid = drm_get_edid(connector, hdmi->ddc);
+   if (!edid) {
+   DRM_INFO("EDID read failed. Fallback to standard modes\n");
+   goto fallback;
+   }
+
+   drm_mode_connector_update_edid_property(connector, edid);
+
+   return drm_add_edid_modes(connector, edid);
+fallback:
+   /* No EDID, fallback on the XGA standard modes */
+   ret = drm_add_modes_noedid(connector, 1920, 1200);
+
+   /* And prefer a mode pretty much anything can handle */
+   drm_set_preferred_mode(connector, 1024, 768);
+
+   return ret;
+}

[PATCH 1/3] drm/tilcdc: Recover from sync lost error flood by resetting the LCDC

[Jyri Sarha]

Recover from sync lost error flood by resetting the LCDC instead of
turning off the SYNC_LOST error IRQ. When LCDC starves on limited
memory bandwidth it may sometimes result an error situation when the
picture may have shifted couple of pixels to right and SYNC_LOST
interrupt is generated on every frame. LCDC main reset recovers from
this situation and causes a brief blanking on the screen.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 0d09acc..c787349 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -55,6 +55,7 @@ struct tilcdc_crtc {

int sync_lost_count;
bool frame_intact;
+   struct work_struct recover_work;
 };
 #define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)

@@ -252,6 +253,25 @@ static bool tilcdc_crtc_is_on(struct drm_crtc *crtc)
return crtc->state && crtc->state->enable && crtc->state->active;
 }

+static void tilcdc_crtc_recover_work(struct work_struct *work)
+{
+   struct tilcdc_crtc *tilcdc_crtc =
+   container_of(work, struct tilcdc_crtc, recover_work);
+   struct drm_crtc *crtc = _crtc->base;
+
+   dev_info(crtc->dev->dev, "%s: Reset CRTC", __func__);
+
+   drm_modeset_lock_crtc(crtc, NULL);
+
+   if (!tilcdc_crtc_is_on(crtc))
+   goto out;
+
+   tilcdc_crtc_disable(crtc);
+   tilcdc_crtc_enable(crtc);
+out:
+   drm_modeset_unlock_crtc(crtc);
+}
+
 static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
 {
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
@@ -838,9 +858,12 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
tilcdc_crtc->frame_intact = false;
if (tilcdc_crtc->sync_lost_count++ >
SYNC_LOST_COUNT_LIMIT) {
-   dev_err(dev->dev, "%s(0x%08x): Sync lost flood 
detected, disabling the interrupt", __func__, stat);
+   dev_err(dev->dev, "%s(0x%08x): Sync lost flood 
detected, recovering", __func__, stat);
+   queue_work(system_wq,
+  _crtc->recover_work);
tilcdc_write(dev, LCDC_INT_ENABLE_CLR_REG,
 LCDC_SYNC_LOST);
+   tilcdc_crtc->sync_lost_count = 0;
}
}

@@ -880,6 +903,7 @@ struct drm_crtc *tilcdc_crtc_create(struct drm_device *dev)
"unref", unref_worker);

spin_lock_init(_crtc->irq_lock);
+   INIT_WORK(_crtc->recover_work, tilcdc_crtc_recover_work);

ret = drm_crtc_init_with_planes(dev, crtc,
_crtc->primary,
-- 
1.9.1

[PATCH 0/3] drm/tilcdc: Add bridge support and sync-lost flood recovery

[Jyri Sarha]

The first patch is an independent on and I've been testing it for
quite a while now.

The tfp410 bridge driver and the tilcdc bridge support are tested with
BeagleBone DVI-D Cape Rev A3. The tfp410 bridge driver is missing a
lot of features, because the DVI-D cape does not have too many wires
connected. They missing features can be added later when they are
needed.

Jyri Sarha (3):
  drm/tilcdc: Recover from sync lost error flood by resetting the LCDC
  drm/bridge: Add ti-ftp410 HDMI transmitter driver
  drm/tilcdc: Add drm bridge support for attaching drm bridge drivers

 .../bindings/display/bridge/ti,tfp410.txt  |  30 
 .../devicetree/bindings/display/tilcdc/tilcdc.txt  |   7 +-
 drivers/gpu/drm/bridge/Kconfig |   7 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/ti-tfp410.c | 199 +
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  26 ++-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|   7 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   2 +
 drivers/gpu/drm/tilcdc/tilcdc_external.c   | 140 +--
 drivers/gpu/drm/tilcdc/tilcdc_external.h   |   1 +
 10 files changed, 397 insertions(+), 23 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
 create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c

-- 
1.9.1

[Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Ville Syrjälä]

On Wed, Nov 02, 2016 at 09:39:48PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/2/2016 9:32 PM, Ville Syrjälä wrote:
> > On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
> >>> On 02.11.2016 10:46, Shashank Sharma wrote:
>  CEA-861-F specs defines new 4k video modes to be used with
>  HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
>  way till VIC=107.
> 
>  Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
>  to be able to parse 4k modes using the existing techniques, we have
>  to complete the modedb (VIC=65 onwards).
> 
>  This patch adds:
>  - Timings for existing CEA video modes (from VIC=65 till VIC=92)
>  - Newly added 4k modes (from VIC=93 to VIC=107).
> >>> As I understand it modifies edid_cea_modes array. This array
> >>> is used by couple of functions, particularly by drm_match_cea_mode,
> >>> which is used by drm_hdmi_avi_infoframe_from_display_mode.
> >>> I.e. since this patch AVI infoframes generated using drm core code will
> >>> be different - they can contain VIC codes unknown to TV.
> >>> I am not sure if it is harmful, but for sure this patch has visible
> >>> impact on drivers behavior.
> >>>
> >>> Maybe it would be good to allow drivers to keep full compatibility with
> >>> HDMI 1.4?
> >> Hello Andrzej,
> >> Thanks for the comment.
> >> If you watch the code flow carefully, this is driven by EDID. So any
> >> VIC, which is translated/transformed using this array, would be coming
> >> from the EDID itself.
> > No. The user is free to specify any mode they wish. It doesn't have to
> > come from the EDID. Not sure specifying a modern VIC for an older
> > display is a good idea or not. If not, we could always check the cea_rev
> > assuming it changed whenever the list if VICs was expanded.
> I agree, that user can specify a mode, out of EDID too.
> I am anyways planning to add a patch, where before loading HDMI 2.0 VICs 
> in AVI IF, we are checking the EDID rev.
> That should solve our problem.
> 
> So if edid_rev < 2.0
>  do_not_load VICs from 93 - 107, but keep it 0.

Why edid_rev and not cea_rev?

> 
> Shashank
> >> So I dont think there would be a problem if the mode is defined in the
> >> EDID section itself, coz we are expecting the TV to know what its
> >> mentioning in EDID.
> >>
> >> This is how a typical flow would look:
> >> - hot-plug
> >> - driver reads modes specified in EDID basic.
> >> - driver parses various CEA extension blocks.
> >>   - For both of the above mentioned steps, driver will probe the
> >> functions like do_cea_modes which uses edid_cea_modes[] array.
> >> - driver will add the probed modes in EDID, into connector
> >> - driver will pass the connector to userspace
> >> - userspace will pick one of the probed modes for modeset.
> >> - during modeset, we will set VIC part for a CEA mode, in the AVI
> >> infoframe section.
> >>
> >> So in other words, the only source of a VIC (cea_mode) is from TV's own
> >> EDID.
> >> This means we should never run into an unknown VIC. There can be a 0 VIC
> >> (for non CEA modes), but not unknown one.
> >>
> >> Regards
> >> Shashank
> >>> Regards
> >>> Andrzej
> >>>
> >>>
>  Signed-off-by: Shashank Sharma 
>  Signed-off-by: Sonika Jindal 
>  Reviewed-by: Jose Abreu 
>  Reviewed-by: Alex Deucher 
> 
>  Cc: Jose Abreu 
>  Cc: Alex Deucher 
> 
>  V2: Addressed review comments from Jose:
>   - fix the timings for VIC 83, 90 and 91
>   - fix formatting for VIC 93-107
>  ---
> drivers/gpu/drm/drm_edid.c | 215 
>  +
> 1 file changed, 215 insertions(+)
> 
>  diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>  index 9506933..d18602c 100644
>  --- a/drivers/gpu/drm/drm_edid.c
>  +++ b/drivers/gpu/drm/drm_edid.c
>  @@ -994,6 +994,221 @@ struct minimode {
>  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>    .vrefresh = 100, .picture_aspect_ratio = 
>  HDMI_PICTURE_ASPECT_16_9, },
>  +/* 65 - 1280x720 at 24Hz */
>  +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
>  +   3080, 3300, 0, 720, 725, 730, 750, 0,
>  +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>  +  .vrefresh = 24, .picture_aspect_ratio = 
>  HDMI_PICTURE_ASPECT_64_27, },
>  +/* 66 - 1280x720 at 25Hz */
>  +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
>  +   3740, 3960, 0, 720, 725, 730, 750, 0,
>  +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>  +  .vrefresh = 25, .picture_aspect_ratio = 
>  

[Spice-devel] [drm/qxl 5/6] qxl: Don't notify userspace when monitors config is unchanged

[Christophe Fergeau]

On Wed, Nov 02, 2016 at 05:31:28PM +0100, Christophe Fergeau wrote:
> > 
> > > + if (client_head->flags != 0) {
> > > + client_head->flags = 0;
> > > + changed = true;
> > > + }
> > 
> > why testing flags change if is always 0 ?
> 
> Yeah, same for surface_id above actually. Just mechanically changed
> everything ;)

At first I changed the commit to exclude flags and surface_id from these
checks, but on second though, I'd keep them the same way as the rest,
this way if these can get changed to a different value outside of
copy_rom, this code will still work as intended.

Christophe
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161102/2b5b804f/attachment.sig>

[Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Ville Syrjälä]

On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
> > On 02.11.2016 10:46, Shashank Sharma wrote:
> >> CEA-861-F specs defines new 4k video modes to be used with
> >> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> >> way till VIC=107.
> >>
> >> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> >> to be able to parse 4k modes using the existing techniques, we have
> >> to complete the modedb (VIC=65 onwards).
> >>
> >> This patch adds:
> >> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> >> - Newly added 4k modes (from VIC=93 to VIC=107).
> > As I understand it modifies edid_cea_modes array. This array
> > is used by couple of functions, particularly by drm_match_cea_mode,
> > which is used by drm_hdmi_avi_infoframe_from_display_mode.
> > I.e. since this patch AVI infoframes generated using drm core code will
> > be different - they can contain VIC codes unknown to TV.
> > I am not sure if it is harmful, but for sure this patch has visible
> > impact on drivers behavior.
> >
> > Maybe it would be good to allow drivers to keep full compatibility with
> > HDMI 1.4?
> Hello Andrzej,
> Thanks for the comment.
> If you watch the code flow carefully, this is driven by EDID. So any 
> VIC, which is translated/transformed using this array, would be coming 
> from the EDID itself.

No. The user is free to specify any mode they wish. It doesn't have to
come from the EDID. Not sure specifying a modern VIC for an older
display is a good idea or not. If not, we could always check the cea_rev
assuming it changed whenever the list if VICs was expanded.

> So I dont think there would be a problem if the mode is defined in the 
> EDID section itself, coz we are expecting the TV to know what its 
> mentioning in EDID.
> 
> This is how a typical flow would look:
> - hot-plug
> - driver reads modes specified in EDID basic.
> - driver parses various CEA extension blocks.
>  - For both of the above mentioned steps, driver will probe the 
> functions like do_cea_modes which uses edid_cea_modes[] array.
> - driver will add the probed modes in EDID, into connector
> - driver will pass the connector to userspace
> - userspace will pick one of the probed modes for modeset.
> - during modeset, we will set VIC part for a CEA mode, in the AVI 
> infoframe section.
> 
> So in other words, the only source of a VIC (cea_mode) is from TV's own 
> EDID.
> This means we should never run into an unknown VIC. There can be a 0 VIC 
> (for non CEA modes), but not unknown one.
> 
> Regards
> Shashank
> > Regards
> > Andrzej
> >
> >
> >> Signed-off-by: Shashank Sharma 
> >> Signed-off-by: Sonika Jindal 
> >> Reviewed-by: Jose Abreu 
> >> Reviewed-by: Alex Deucher 
> >>
> >> Cc: Jose Abreu 
> >> Cc: Alex Deucher 
> >>
> >> V2: Addressed review comments from Jose:
> >>- fix the timings for VIC 83, 90 and 91
> >>- fix formatting for VIC 93-107
> >> ---
> >>   drivers/gpu/drm/drm_edid.c | 215 
> >> +
> >>   1 file changed, 215 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 9506933..d18602c 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -994,6 +994,221 @@ struct minimode {
> >>   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> >>   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> >> +  /* 65 - 1280x720 at 24Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> >> + 3080, 3300, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 66 - 1280x720 at 25Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> >> + 3740, 3960, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 67 - 1280x720 at 30Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> >> + 3080, 3300, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 68 - 1280x720 at 50Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> >> + 1760, 1980, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 69 - 1280x720 at 60Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> >> + 1430, 1650, 0, 720, 725, 730, 750, 0,
> 

[drm/qxl v2 7/7] qxl: Allow resolution which are not multiple of 8

[Christophe Fergeau]

The use of drm_cvt_mode() in qxl_add_monitors_config_modes() means that
the resolutions we are going to present to user-space are going to be
rounded down to a multiple of 8. In the QXL arbitrary resolution case,
this is not useful.
This commit forces the actual width/height that was requested by the
client in the drm_display_mode structure rather than keeping the
rounded version.

Signed-off-by: Christophe Fergeau 
---
 drivers/gpu/drm/qxl/qxl_display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 2f1d738..2241954 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -200,6 +200,9 @@ static int qxl_add_monitors_config_modes(struct 
drm_connector *connector,
mode = drm_cvt_mode(dev, head->width, head->height, 60, false, false,
false);
mode->type |= DRM_MODE_TYPE_PREFERRED;
+   mode->hdisplay = head->width;
+   mode->vdisplay = head->height;
+   drm_mode_set_name(mode);
*pwidth = head->width;
*pheight = head->height;
drm_mode_probed_add(connector, mode);
-- 
2.9.3

[drm/qxl v2 6/7] qxl: Don't notify userspace when monitors config is unchanged

[Christophe Fergeau]

When the QXL driver receives a QXL_INTERRUPT_CLIENT_MONITORS_CONFIG interrupt,
we currently always notify userspace that there was some hotplug event.

However, gnome-shell/mutter is reacting to this event by attempting a
resolution change, which it does by issueing drmModeRmFB, drmModeAddFB,
and then drmModeSetCrtc. This has the side-effect of causing
qxl_crtc_mode_set() to tell the QXL virtual hardware that a primary
surface was destroyed and created. After going through QEMU and then the
remote SPICE client, a new identical monitors config message will be
sent, resulting in a QXL_INTERRUPT_CLIENT_MONITORS_CONFIG interrupt to
be emitted, and the same scenario occurring again.

As destroying/creating the primary surface causes a visible screen
flicker, this makes the guest hard to use (
https://bugzilla.redhat.com/show_bug.cgi?id=1266484 ).

This commit checks if the screen configuration we received is the same
one as the current one, and does not notify userspace about it if that's
the case.

Signed-off-by: Christophe Fergeau 
---
Changes since v1:
  - made qxl_display_copy_rom_client_monitors_config return an enum
MonitorsConfigCopyStatus
  - remove 'bool changed' from +qxl_display_copy_rom_client_monitors_config and 
directly
set the return value instead

 drivers/gpu/drm/qxl/qxl_display.c | 65 ---
 1 file changed, 54 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 8cf5177..2f1d738 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -57,11 +57,19 @@ static void qxl_alloc_client_monitors_config(struct 
qxl_device *qdev, unsigned c
qdev->client_monitors_config->count = count;
 }

-static int qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
+enum MonitorsConfigCopyStatus {
+   MONITORS_CONFIG_MODIFIED,
+   MONITORS_CONFIG_UNCHANGED,
+   MONITORS_CONFIG_BAD_CRC,
+};
+
+static enum MonitorsConfigCopyStatus
+qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
 {
int i;
int num_monitors;
uint32_t crc;
+   enum MonitorsConfigCopyStatus status = MONITORS_CONFIG_UNCHANGED;

num_monitors = qdev->rom->client_monitors_config.count;
crc = crc32(0, (const uint8_t *)>rom->client_monitors_config,
@@ -70,7 +78,7 @@ static int qxl_display_copy_rom_client_monitors_config(struct 
qxl_device *qdev)
qxl_io_log(qdev, "crc mismatch: have %X (%zd) != %X\n", crc,
   sizeof(qdev->rom->client_monitors_config),
   qdev->rom->client_monitors_config_crc);
-   return 1;
+   return MONITORS_CONFIG_BAD_CRC;
}
if (num_monitors > qdev->monitors_config->max_allowed) {
DRM_DEBUG_KMS("client monitors list will be truncated: %d < 
%d\n",
@@ -79,6 +87,10 @@ static int 
qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
} else {
num_monitors = qdev->rom->client_monitors_config.count;
}
+   if (qdev->client_monitors_config
+ && (num_monitors != qdev->client_monitors_config->count)) {
+   status = MONITORS_CONFIG_MODIFIED;
+   }
qxl_alloc_client_monitors_config(qdev, num_monitors);
/* we copy max from the client but it isn't used */
qdev->client_monitors_config->max_allowed =
@@ -88,17 +100,39 @@ static int 
qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
>rom->client_monitors_config.heads[i];
struct qxl_head *client_head =
>client_monitors_config->heads[i];
-   client_head->x = c_rect->left;
-   client_head->y = c_rect->top;
-   client_head->width = c_rect->right - c_rect->left;
-   client_head->height = c_rect->bottom - c_rect->top;
-   client_head->surface_id = 0;
-   client_head->id = i;
-   client_head->flags = 0;
+   if (client_head->x != c_rect->left) {
+   client_head->x = c_rect->left;
+   status = MONITORS_CONFIG_MODIFIED;
+   }
+   if (client_head->y != c_rect->top) {
+   client_head->y = c_rect->top;
+   status = MONITORS_CONFIG_MODIFIED;
+   }
+   if (client_head->width != c_rect->right - c_rect->left) {
+   client_head->width = c_rect->right - c_rect->left;
+   status = MONITORS_CONFIG_MODIFIED;
+   }
+   if (client_head->height != c_rect->bottom - c_rect->top) {
+   client_head->height = c_rect->bottom - c_rect->top;
+   status = MONITORS_CONFIG_MODIFIED;
+   }
+   if (client_head->surface_id != 0) {
+   

[drm/qxl v2 5/7] qxl: Remove qxl_bo_init() return value

[Christophe Fergeau]

It's always returning 0, and it's always ignored.

Signed-off-by: Christophe Fergeau 
---
Changes since v1: new patch

 drivers/gpu/drm/qxl/qxl_drv.h | 2 +-
 drivers/gpu/drm/qxl/qxl_gem.c | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 5a4720a..feac7e6 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -398,7 +398,7 @@ int qxl_create_monitors_object(struct qxl_device *qdev);
 int qxl_destroy_monitors_object(struct qxl_device *qdev);

 /* qxl_gem.c */
-int qxl_gem_init(struct qxl_device *qdev);
+void qxl_gem_init(struct qxl_device *qdev);
 void qxl_gem_fini(struct qxl_device *qdev);
 int qxl_gem_object_create(struct qxl_device *qdev, int size,
  int alignment, int initial_domain,
diff --git a/drivers/gpu/drm/qxl/qxl_gem.c b/drivers/gpu/drm/qxl/qxl_gem.c
index d9746e9..3f185c4 100644
--- a/drivers/gpu/drm/qxl/qxl_gem.c
+++ b/drivers/gpu/drm/qxl/qxl_gem.c
@@ -111,10 +111,9 @@ void qxl_gem_object_close(struct drm_gem_object *obj,
 {
 }

-int qxl_gem_init(struct qxl_device *qdev)
+void qxl_gem_init(struct qxl_device *qdev)
 {
INIT_LIST_HEAD(>gem.objects);
-   return 0;
 }

 void qxl_gem_fini(struct qxl_device *qdev)
-- 
2.9.3

[drm/qxl v2 4/7] qxl: Call qxl_gem_{init,fini}

[Christophe Fergeau]

qdev->gem.objects was initialized directly in qxl_device_init() rather
than going through qxl_gem_init(), and qxl_gem_fini() was never called.

Signed-off-by: Christophe Fergeau 
---
 drivers/gpu/drm/qxl/qxl_kms.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index e642242..af685f1 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -131,7 +131,7 @@ static int qxl_device_init(struct qxl_device *qdev,
mutex_init(>update_area_mutex);
mutex_init(>release_mutex);
mutex_init(>surf_evict_mutex);
-   INIT_LIST_HEAD(>gem.objects);
+   qxl_gem_init(qdev);

qdev->rom_base = pci_resource_start(pdev, 2);
qdev->rom_size = pci_resource_len(pdev, 2);
@@ -273,6 +273,7 @@ static void qxl_device_fini(struct qxl_device *qdev)
qxl_ring_free(qdev->command_ring);
qxl_ring_free(qdev->cursor_ring);
qxl_ring_free(qdev->release_ring);
+   qxl_gem_fini(qdev);
qxl_bo_fini(qdev);
io_mapping_free(qdev->surface_mapping);
io_mapping_free(qdev->vram_mapping);
-- 
2.9.3

[drm/qxl v2 3/7] qxl: Add missing '\n' to qxl_io_log() call

[Christophe Fergeau]

The message has to be terminated by a newline as it's not going to get
added automatically.

Signed-off-by: Christophe Fergeau 
Acked-by: Frediano Ziglio 
---
 drivers/gpu/drm/qxl/qxl_fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index 28c1423..969c7c1 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -198,7 +198,7 @@ static int qxlfb_framebuffer_dirty(struct drm_framebuffer 
*fb,
/*
 * we are using a shadow draw buffer, at qdev->surface0_shadow
 */
-   qxl_io_log(qdev, "dirty x[%d, %d], y[%d, %d]", clips->x1, clips->x2,
+   qxl_io_log(qdev, "dirty x[%d, %d], y[%d, %d]\n", clips->x1, clips->x2,
   clips->y1, clips->y2);
image->dx = clips->x1;
image->dy = clips->y1;
-- 
2.9.3

[drm/qxl v2 2/7] qxl: Remove unused prototype

[Christophe Fergeau]

qxl_crtc_set_from_monitors_config() is defined in qxl_drv.h but never
implemented.

Signed-off-by: Christophe Fergeau 
Acked-by: Frediano Ziglio 
---
 drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index a3c1131..5a4720a 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -397,9 +397,6 @@ void qxl_display_read_client_monitors_config(struct 
qxl_device *qdev);
 int qxl_create_monitors_object(struct qxl_device *qdev);
 int qxl_destroy_monitors_object(struct qxl_device *qdev);

-/* used by qxl_debugfs only */
-void qxl_crtc_set_from_monitors_config(struct qxl_device *qdev);
-
 /* qxl_gem.c */
 int qxl_gem_init(struct qxl_device *qdev);
 void qxl_gem_fini(struct qxl_device *qdev);
-- 
2.9.3

[drm/qxl v2 1/7] qxl: Mark some internal functions as static

[Christophe Fergeau]

They are not used outside of their respective source file

Signed-off-by: Christophe Fergeau 
Acked-by: Frediano Ziglio 
---
 drivers/gpu/drm/qxl/qxl_cmd.c | 2 +-
 drivers/gpu/drm/qxl/qxl_display.c | 4 ++--
 drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
index 04270f5..74fc936 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -578,7 +578,7 @@ int qxl_hw_surface_dealloc(struct qxl_device *qdev,
return 0;
 }

-int qxl_update_surface(struct qxl_device *qdev, struct qxl_bo *surf)
+static int qxl_update_surface(struct qxl_device *qdev, struct qxl_bo *surf)
 {
struct qxl_rect rect;
int ret;
diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 3aef127..8cf5177 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -36,7 +36,7 @@ static bool qxl_head_enabled(struct qxl_head *head)
return head->width && head->height;
 }

-void qxl_alloc_client_monitors_config(struct qxl_device *qdev, unsigned count)
+static void qxl_alloc_client_monitors_config(struct qxl_device *qdev, unsigned 
count)
 {
if (qdev->client_monitors_config &&
count > qdev->client_monitors_config->count) {
@@ -559,7 +559,7 @@ static bool qxl_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
 }

-void
+static void
 qxl_send_monitors_config(struct qxl_device *qdev)
 {
int i;
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 8e633ca..a3c1131 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -394,13 +394,11 @@ qxl_framebuffer_init(struct drm_device *dev,
 struct drm_gem_object *obj,
 const struct drm_framebuffer_funcs *funcs);
 void qxl_display_read_client_monitors_config(struct qxl_device *qdev);
-void qxl_send_monitors_config(struct qxl_device *qdev);
 int qxl_create_monitors_object(struct qxl_device *qdev);
 int qxl_destroy_monitors_object(struct qxl_device *qdev);

 /* used by qxl_debugfs only */
 void qxl_crtc_set_from_monitors_config(struct qxl_device *qdev);
-void qxl_alloc_client_monitors_config(struct qxl_device *qdev, unsigned count);

 /* qxl_gem.c */
 int qxl_gem_init(struct qxl_device *qdev);
@@ -573,6 +571,5 @@ int qxl_bo_check_id(struct qxl_device *qdev, struct qxl_bo 
*bo);
 struct qxl_drv_surface *
 qxl_surface_lookup(struct drm_device *dev, int surface_id);
 void qxl_surface_evict(struct qxl_device *qdev, struct qxl_bo *surf, bool 
freeing);
-int qxl_update_surface(struct qxl_device *qdev, struct qxl_bo *surf);

 #endif
-- 
2.9.3

[drm/qxl v2 0/7] qxl: Various cleanups/fixes

[Christophe Fergeau]

Hey,

Here is the v2 of my patch series. It improves a bit patch 6/7 readability
following Frediano's review, and patch 5/7 is new and was suggested during
review. The other patches are unchanged.

Christophe

[PATCHv3 4/4] drm/tilcdc: Fix race from forced shutdown of crtc in unload

[Jyri Sarha]

Fix race from forced shutdown of crtc in unload by adding internal
locking and a boolean telling if device is going to be shutdown.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 29 +++--
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.h  |  3 ++-
 3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 6277363..0d09acc 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -33,7 +33,9 @@ struct tilcdc_crtc {
struct drm_plane primary;
const struct tilcdc_panel_info *info;
struct drm_pending_vblank_event *event;
+   struct mutex enable_lock;
bool enabled;
+   bool shutdown;
wait_queue_head_t frame_done_wq;
bool frame_done;
spinlock_t irq_lock;
@@ -158,9 +160,11 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);

WARN_ON(!drm_modeset_is_locked(>mutex));
-
-   if (tilcdc_crtc->enabled)
+   mutex_lock(_crtc->enable_lock);
+   if (tilcdc_crtc->enabled || tilcdc_crtc->shutdown) {
+   mutex_unlock(_crtc->enable_lock);
return;
+   }

pm_runtime_get_sync(dev->dev);

@@ -175,17 +179,22 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
drm_crtc_vblank_on(crtc);

tilcdc_crtc->enabled = true;
+   mutex_unlock(_crtc->enable_lock);
 }

-void tilcdc_crtc_off(struct drm_crtc *crtc)
+static void tilcdc_crtc_off(struct drm_crtc *crtc, bool shutdown)
 {
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct tilcdc_drm_private *priv = dev->dev_private;

-   if (!tilcdc_crtc->enabled)
+   mutex_lock(_crtc->enable_lock);
+   if (shutdown)
+   tilcdc_crtc->shutdown = true;
+   if (!tilcdc_crtc->enabled) {
+   mutex_unlock(_crtc->enable_lock);
return;
-
+   }
tilcdc_crtc->frame_done = false;
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);

@@ -224,12 +233,18 @@ void tilcdc_crtc_off(struct drm_crtc *crtc)
tilcdc_crtc->last_vblank = ktime_set(0, 0);

tilcdc_crtc->enabled = false;
+   mutex_unlock(_crtc->enable_lock);
 }

 static void tilcdc_crtc_disable(struct drm_crtc *crtc)
 {
WARN_ON(!drm_modeset_is_locked(>mutex));
-   tilcdc_crtc_off(crtc);
+   tilcdc_crtc_off(crtc, false);
+}
+
+void tilcdc_crtc_shutdown(struct drm_crtc *crtc)
+{
+   tilcdc_crtc_off(crtc, true);
 }

 static bool tilcdc_crtc_is_on(struct drm_crtc *crtc)
@@ -857,6 +872,8 @@ struct drm_crtc *tilcdc_crtc_create(struct drm_device *dev)
if (ret < 0)
goto fail;

+   mutex_init(_crtc->enable_lock);
+
init_waitqueue_head(_crtc->frame_done_wq);

drm_flip_work_init(_crtc->unref_work,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 14896b6..dcc9621 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -197,7 +197,7 @@ static void tilcdc_fini(struct drm_device *dev)
struct tilcdc_drm_private *priv = dev->dev_private;

if (priv->crtc)
-   tilcdc_crtc_off(priv->crtc);
+   tilcdc_crtc_shutdown(priv->crtc);

if (priv->is_registered)
drm_dev_unregister(dev);
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 7db23f2..d31fe5d 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 

 /* Defaulting to pixel clock defined on AM335x */
 #define TILCDC_DEFAULT_MAX_PIXELCLOCK  126000
@@ -173,7 +174,7 @@ void tilcdc_crtc_set_simulate_vesa_sync(struct drm_crtc 
*crtc,
bool simulate_vesa_sync);
 int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct drm_display_mode 
*mode);
 int tilcdc_crtc_max_width(struct drm_crtc *crtc);
-void tilcdc_crtc_off(struct drm_crtc *crtc);
+void tilcdc_crtc_shutdown(struct drm_crtc *crtc);
 int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_pending_vblank_event *event);
-- 
1.9.1

[PATCHv3 3/4] drm/tilcdc: Use unload to handle initialization failures

[Jyri Sarha]

Use unload to handle initialization failures instead of complex goto
label mess. To do this the initialization sequence needed slight
reordering and some unload functions needed to become conditional.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |  10 ++--
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 101 ---
 drivers/gpu/drm/tilcdc/tilcdc_drv.h  |   3 +-
 3 files changed, 43 insertions(+), 71 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index ea79e09..6277363 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -177,14 +177,12 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
tilcdc_crtc->enabled = true;
 }

-void tilcdc_crtc_disable(struct drm_crtc *crtc)
+void tilcdc_crtc_off(struct drm_crtc *crtc)
 {
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct tilcdc_drm_private *priv = dev->dev_private;

-   WARN_ON(!drm_modeset_is_locked(>mutex));
-
if (!tilcdc_crtc->enabled)
return;

@@ -228,6 +226,12 @@ void tilcdc_crtc_disable(struct drm_crtc *crtc)
tilcdc_crtc->enabled = false;
 }

+static void tilcdc_crtc_disable(struct drm_crtc *crtc)
+{
+   WARN_ON(!drm_modeset_is_locked(>mutex));
+   tilcdc_crtc_off(crtc);
+}
+
 static bool tilcdc_crtc_is_on(struct drm_crtc *crtc)
 {
return crtc->state && crtc->state->enable && crtc->state->active;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 11f3262..14896b6 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -158,8 +158,6 @@ static int modeset_init(struct drm_device *dev)
struct tilcdc_drm_private *priv = dev->dev_private;
struct tilcdc_module *mod;

-   drm_mode_config_init(dev);
-
priv->crtc = tilcdc_crtc_create(dev);

list_for_each_entry(mod, _list, list) {
@@ -198,22 +196,25 @@ static void tilcdc_fini(struct drm_device *dev)
 {
struct tilcdc_drm_private *priv = dev->dev_private;

-   drm_modeset_lock_crtc(priv->crtc, NULL);
-   tilcdc_crtc_disable(priv->crtc);
-   drm_modeset_unlock_crtc(priv->crtc);
+   if (priv->crtc)
+   tilcdc_crtc_off(priv->crtc);

-   drm_dev_unregister(dev);
+   if (priv->is_registered)
+   drm_dev_unregister(dev);

drm_kms_helper_poll_fini(dev);
-   drm_fbdev_cma_fini(priv->fbdev);
+
+   if (priv->fbdev)
+   drm_fbdev_cma_fini(priv->fbdev);
+
drm_irq_uninstall(dev);
drm_mode_config_cleanup(dev);
-
tilcdc_remove_external_encoders(dev);

 #ifdef CONFIG_CPU_FREQ
-   cpufreq_unregister_notifier(>freq_transition,
-   CPUFREQ_TRANSITION_NOTIFIER);
+   if (priv->freq_transition.notifier_call)
+   cpufreq_unregister_notifier(>freq_transition,
+   CPUFREQ_TRANSITION_NOTIFIER);
 #endif

if (priv->clk)
@@ -222,8 +223,10 @@ static void tilcdc_fini(struct drm_device *dev)
if (priv->mmio)
iounmap(priv->mmio);

-   flush_workqueue(priv->wq);
-   destroy_workqueue(priv->wq);
+   if (priv->wq) {
+   flush_workqueue(priv->wq);
+   destroy_workqueue(priv->wq);
+   }

dev->dev_private = NULL;

@@ -254,6 +257,8 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
device *dev)

ddev->platformdev = pdev;
ddev->dev_private = priv;
+   platform_set_drvdata(pdev, ddev);
+   drm_mode_config_init(ddev);

priv->is_componentized =
tilcdc_get_external_components(dev, NULL) > 0;
@@ -261,28 +266,28 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
device *dev)
priv->wq = alloc_ordered_workqueue("tilcdc", 0);
if (!priv->wq) {
ret = -ENOMEM;
-   goto fail_unset_priv;
+   goto init_failed;
}

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "failed to get memory resource\n");
ret = -EINVAL;
-   goto fail_free_wq;
+   goto init_failed;
}

priv->mmio = ioremap_nocache(res->start, resource_size(res));
if (!priv->mmio) {
dev_err(dev, "failed to ioremap\n");
ret = -ENOMEM;
-   goto fail_free_wq;
+   goto init_failed;
}

priv->clk = clk_get(dev, "fck");
if (IS_ERR(priv->clk)) {
dev_err(dev, "failed to get functional clock\n");
ret = -ENODEV;
-   goto fail_iounmap;
+   goto init_failed;
}

 #ifdef CONFIG_CPU_FREQ
@@ -291,7 +296,8 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
device *dev)
 

[PATCHv3 2/4] drm/tilcdc: Stop using struct drm_driver load() callback

[Jyri Sarha]

Stop using struct drm_driver load() and unload() callbacks. The
callbacks should not be used anymore. Instead of using load the
drm_device is allocated with drm_dev_alloc() and registered with
drm_dev_register() only after the driver is completely initialized.
The deinitialization is done directly either in component unbind
callback or in platform driver demove callback.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 124 
 1 file changed, 70 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 5cf534c..11f3262 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -194,18 +194,22 @@ static int cpufreq_transition(struct notifier_block *nb,
  * DRM operations:
  */

-static int tilcdc_unload(struct drm_device *dev)
+static void tilcdc_fini(struct drm_device *dev)
 {
struct tilcdc_drm_private *priv = dev->dev_private;

-   tilcdc_remove_external_encoders(dev);
+   drm_modeset_lock_crtc(priv->crtc, NULL);
+   tilcdc_crtc_disable(priv->crtc);
+   drm_modeset_unlock_crtc(priv->crtc);
+
+   drm_dev_unregister(dev);

-   drm_fbdev_cma_fini(priv->fbdev);
drm_kms_helper_poll_fini(dev);
+   drm_fbdev_cma_fini(priv->fbdev);
+   drm_irq_uninstall(dev);
drm_mode_config_cleanup(dev);
-   drm_vblank_cleanup(dev);

-   drm_irq_uninstall(dev);
+   tilcdc_remove_external_encoders(dev);

 #ifdef CONFIG_CPU_FREQ
cpufreq_unregister_notifier(>freq_transition,
@@ -225,28 +229,34 @@ static int tilcdc_unload(struct drm_device *dev)

pm_runtime_disable(dev->dev);

-   return 0;
+   drm_dev_unref(dev);
 }

-static int tilcdc_load(struct drm_device *dev, unsigned long flags)
+static int tilcdc_init(struct drm_driver *ddrv, struct device *dev)
 {
-   struct platform_device *pdev = dev->platformdev;
-   struct device_node *node = pdev->dev.of_node;
+   struct drm_device *ddev;
+   struct platform_device *pdev = to_platform_device(dev);
+   struct device_node *node = dev->of_node;
struct tilcdc_drm_private *priv;
struct resource *res;
u32 bpp = 0;
int ret;

-   priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
+   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
-   dev_err(dev->dev, "failed to allocate private data\n");
+   dev_err(dev, "failed to allocate private data\n");
return -ENOMEM;
}

-   dev->dev_private = priv;
+   ddev = drm_dev_alloc(ddrv, dev);
+   if (IS_ERR(ddev))
+   return PTR_ERR(ddev);
+
+   ddev->platformdev = pdev;
+   ddev->dev_private = priv;

priv->is_componentized =
-   tilcdc_get_external_components(dev->dev, NULL) > 0;
+   tilcdc_get_external_components(dev, NULL) > 0;

priv->wq = alloc_ordered_workqueue("tilcdc", 0);
if (!priv->wq) {
@@ -256,21 +266,21 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
-   dev_err(dev->dev, "failed to get memory resource\n");
+   dev_err(dev, "failed to get memory resource\n");
ret = -EINVAL;
goto fail_free_wq;
}

priv->mmio = ioremap_nocache(res->start, resource_size(res));
if (!priv->mmio) {
-   dev_err(dev->dev, "failed to ioremap\n");
+   dev_err(dev, "failed to ioremap\n");
ret = -ENOMEM;
goto fail_free_wq;
}

-   priv->clk = clk_get(dev->dev, "fck");
+   priv->clk = clk_get(dev, "fck");
if (IS_ERR(priv->clk)) {
-   dev_err(dev->dev, "failed to get functional clock\n");
+   dev_err(dev, "failed to get functional clock\n");
ret = -ENODEV;
goto fail_iounmap;
}
@@ -280,7 +290,7 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
ret = cpufreq_register_notifier(>freq_transition,
CPUFREQ_TRANSITION_NOTIFIER);
if (ret) {
-   dev_err(dev->dev, "failed to register cpufreq notifier\n");
+   dev_err(dev, "failed to register cpufreq notifier\n");
goto fail_put_clk;
}
 #endif
@@ -301,11 +311,11 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)

DBG("Maximum Pixel Clock Value %dKHz", priv->max_pixelclock);

-   pm_runtime_enable(dev->dev);
+   pm_runtime_enable(dev);

/* Determine LCD IP Version */
-   pm_runtime_get_sync(dev->dev);
-   switch (tilcdc_read(dev, LCDC_PID_REG)) {
+   pm_runtime_get_sync(dev);
+   switch (tilcdc_read(ddev, LCDC_PID_REG)) {
case 0x4c100102:
priv->rev = 1;
   

[PATCHv3 1/4] drm/tilcdc: Remove obsolete drm_connector_register() calls

[Jyri Sarha]

Remove obsolete drm_connector_register() calls from tilcdc_panel.c and
tilcdc_tfp410.c. All connectors are registered when drm_dev_register()
is called.

Signed-off-by: Jyri Sarha 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 2 --
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 2 --
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 2134bb20..ad7a0e8 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -240,8 +240,6 @@ static struct drm_connector *panel_connector_create(struct 
drm_device *dev,
if (ret)
goto fail;

-   drm_connector_register(connector);
-
return connector;

 fail:
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index c32c1ef..eea82b4 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -251,8 +251,6 @@ static struct drm_connector *tfp410_connector_create(struct 
drm_device *dev,
if (ret)
goto fail;

-   drm_connector_register(connector);
-
return connector;

 fail:
-- 
1.9.1

[PATCHv3 0/4] drm/tilcdc: Cleanup tilcdc init sequence

[Jyri Sarha]

Since v2 version of this series:
- Rebased on top of latest drm-next
- Add "drm/tilcdc: Fix race from forced shutdown of crtc in unload"

Since first version of this series:
- Dropped "drm/i2c: tda998x: Remove obsolete drm_connector_register() call"
  - an earlier instance of the same patch already exists
- Got rid of unload callback and deprecated drm_put_dev() calls

This series depends on tda998x dropping the drm_connector_register().
Please keep me in loop so that I know when it gets merged so that I
know when it is safe send a pull request for these.

A patch[1] that crashed all drm drivers using load() hook was briefly
part of linux-next, so became aware that tilcdc should stop using
that too.

The two first patches should be merged before the third can be
merged. So the merge order should be agreed with tda998x before going
forward.

The last patch is just a cleanup, but depends on earlier ones.

Best regards,
Jyri

[1] https://patchwork.kernel.org/patch/9322771/

Jyri Sarha (4):
  drm/tilcdc: Remove obsolete drm_connector_register() calls
  drm/tilcdc: Stop using struct drm_driver load() callback
  drm/tilcdc: Use unload to handle initialization failures
  drm/tilcdc: Fix race from forced shutdown of crtc in unload

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  35 +--
 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 185 +++--
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   4 +-
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  |   2 -
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |   2 -
 5 files changed, 115 insertions(+), 113 deletions(-)

-- 
1.9.1

[Spice-devel] [drm/qxl 5/6] qxl: Don't notify userspace when monitors config is unchanged

[Christophe Fergeau]

Hey,

On Mon, Oct 31, 2016 at 08:00:09AM -0400, Frediano Ziglio wrote:
> > diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> > b/drivers/gpu/drm/qxl/qxl_display.c
> > index 156b7de..edb90f6 100644
> > --- a/drivers/gpu/drm/qxl/qxl_display.c
> > +++ b/drivers/gpu/drm/qxl/qxl_display.c
> > @@ -57,11 +57,18 @@ static void qxl_alloc_client_monitors_config(struct
> > qxl_device *qdev, unsigned c
> > qdev->client_monitors_config->count = count;
> >  }
> >  
> > +enum MonitorsConfigCopyStatus {
> > +   MONITORS_CONFIG_COPIED,
> > +   MONITORS_CONFIG_UNCHANGED,
> > +   MONITORS_CONFIG_BAD_CRC,
> > +};
> > +
> 
> I don't remember exactly kernel style, a 
> 
> typedef enum {
>   MONITORS_CONFIG_COPIED,
>   MONITORS_CONFIG_UNCHANGED,
>   MONITORS_CONFIG_BAD_CRC,
> } MonitorsConfigCopyStatus;
> 
> could make following code shorter.

A git grep enum in qxl/ returns a dozen results, none of these using
typedef, I guess I just followed that style.

> 
> >  static int qxl_display_copy_rom_client_monitors_config(struct qxl_device
> >  *qdev)
> 
> why not returning MonitorsConfigCopyStatus ?

No idea ;) I'll change the patch.

> 
> >  {
> > int i;
> > int num_monitors;
> > uint32_t crc;
> > +   bool changed = false;
> >  
> 
> using a "MonitorsConfigCopyStatus res = MONITORS_CONFIG_UNCHANGED" here
> could make return statement shorter.
> 
> > num_monitors = qdev->rom->client_monitors_config.count;
> > crc = crc32(0, (const uint8_t *)>rom->client_monitors_config,
> > @@ -88,17 +99,42 @@ static int
> > qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
> > >rom->client_monitors_config.heads[i];
> > struct qxl_head *client_head =
> > >client_monitors_config->heads[i];
> > -   client_head->x = c_rect->left;
> > -   client_head->y = c_rect->top;
> > -   client_head->width = c_rect->right - c_rect->left;
> > -   client_head->height = c_rect->bottom - c_rect->top;
> > -   client_head->surface_id = 0;
> > -   client_head->id = i;
> > -   client_head->flags = 0;
> > +   if (client_head->x != c_rect->left) {
> > +   client_head->x = c_rect->left;
> > +   changed = true;
> > +   }
> > +   if (client_head->y != c_rect->top) {
> > +   client_head->y = c_rect->top;
> > +   changed = true;
> > +   }
> > +   if (client_head->width != c_rect->right - c_rect->left) {
> > +   client_head->width = c_rect->right - c_rect->left;
> > +   changed = true;
> > +   }
> > +   if (client_head->height != c_rect->bottom - c_rect->top) {
> > +   client_head->height = c_rect->bottom - c_rect->top;
> > +   changed = true;
> > +   }
> > +   if (client_head->surface_id != 0) {
> > +   client_head->surface_id = 0;
> > +   changed = true;
> > +   }
> > +   if (client_head->id != i) {
> > +   client_head->id = i;
> > +   changed = true;
> > +   }
> 
> quite similar code... I would write a macro but I'm a too macro fun :)
> Would be something like this
> 
>   if (client_head->id != i)
>   res = MONITORS_CONFIG_COPIED;
>   client_head->id = i;
> 
> make sense?

I'm not a big macro fan, especially if they have side effects, so I
preferred to keep things explicit, even though I am annoyed by the
repetitive code too /o\


> 
> > +   if (client_head->flags != 0) {
> > +   client_head->flags = 0;
> > +   changed = true;
> > +   }
> 
> why testing flags change if is always 0 ?

Yeah, same for surface_id above actually. Just mechanically changed
everything ;)

> 
> Usually I would write something like
> 
>   for (;;) {
>   status = qxl_display_copy_rom_client_monitors_config(qdev);
>   if (status != MONITORS_CONFIG_BAD_CRC)
>   break;
>   qxl_io_log(qdev, "failed crc check for client_monitors_config,"
>" retrying\n");
>   }
> 
> or
> 
>   while ((status = qxl_display_copy_rom_client_monitors_config(qdev))
>   ==  MONITORS_CONFIG_BAD_CRC) {
>   qxl_io_log(qdev, "failed crc check for client_monitors_config,"
>" retrying\n");
>   }
> 
> (just style and probably indentation is even wrong)

Same as above, I don't like either, first one obscures the loop exit
condition, and second one makes the assignment/test harder to read.

Christophe
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161102/0ebe12cf/attachment.sig>

[Bug 176311] Fiji DisplayPort amdgpu_crtc_page_flip *ERROR* failed to get vblank before flip

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #6 from Vedran Miletić  ---
Still happens with xorg-x11-drv-ati-7.7.1-1.20160928git3fc839ff

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

[Bug 10499] S3 savage4: glxgears hangs pc

[bugzilla-dae...@freedesktop.org]

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

tommy ujai  changed:

   What|Removed |Added

   Severity|blocker |normal
Product|DRI |X.org integration tests
  Alias||to.my, a
  Component|General |general
   Assignee|dri-devel at lists.freedesktop |peter.hutterer at who-t.net
   |.org|

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

[Spice-devel] [drm/qxl 4/6] qxl: Call qxl_gem_{init,fini}

[Christophe Fergeau]

On Mon, Oct 31, 2016 at 07:42:35AM -0400, Frediano Ziglio wrote:
> > 
> > qdev->gem.objects was initialized directly in qxl_device_init() rather
> > than going through qxl_gem_init(), and qxl_gem_fini() was never called.
> > 
> 
> Considering "qxl_gem_fini() was never called" did we have a leak?

Maybe, as this forces the freeing of some pending bo's if they are still in
use. This would only happen when unloading/reloading the module
repeatedly, which I don't expect to happen on production systems.

> 
> > Signed-off-by: Christophe Fergeau 
> > ---
> >  drivers/gpu/drm/qxl/qxl_kms.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
> > index e642242..af685f1 100644
> > --- a/drivers/gpu/drm/qxl/qxl_kms.c
> > +++ b/drivers/gpu/drm/qxl/qxl_kms.c
> > @@ -131,7 +131,7 @@ static int qxl_device_init(struct qxl_device *qdev,
> > mutex_init(>update_area_mutex);
> > mutex_init(>release_mutex);
> > mutex_init(>surf_evict_mutex);
> > -   INIT_LIST_HEAD(>gem.objects);
> > +   qxl_gem_init(qdev);
> >  
> 
> Here qxl_gem_init returns a value that is always ignored, perhaps
> would be better to return void from qxl_gem_init if it cannot
> fails.

Good suggestion, I'll add that to a separate patch.

Christophe
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161102/06aaea44/attachment.sig>

[Bug 176301] Fiji DisplayPort drm_crtc_helper_set_config *ERROR* failed to set mode on

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #3 from Vedran Miletić  ---
Created attachment 243541
  --> https://bugzilla.kernel.org/attachment.cgi?id=243541=edit
dmesg

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

[Bug 176301] Fiji DisplayPort drm_crtc_helper_set_config *ERROR* failed to set mode on

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #2 from Vedran Miletić  ---
Created attachment 243531
  --> https://bugzilla.kernel.org/attachment.cgi?id=243531=edit
xorg log

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

[Bug 98505] [Topaz] Regression introduces in 4.8-rc3

[bugzilla-dae...@freedesktop.org]

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

--- Comment #13 from Alex Deucher  ---
(In reply to Alex Deucher from comment #12)
> methods and PR# should not be exposed.

PR3

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

[Bug 98505] [Topaz] Regression introduces in 4.8-rc3

[bugzilla-dae...@freedesktop.org]

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

--- Comment #12 from Alex Deucher  ---
(In reply to Peter Wu from comment #11)
> (In reply to Alex Deucher from comment #10)
> > (In reply to Peter Wu from comment #7)
> > > Created attachment 127678 [details] [review] [review] [review]
> > > amdgpu patch that checks whether the new interface can be used for PM
> > > 
> > > PCIe port PM is not enabled because this BIOS is pre-2015: 12/04/2014
> > > The BIOS seems to be able to report support for lots of things (can you 
> > > post
> > > a fuller dmesg that include the supported functions?):
> > 
> > Can we bump the bios white list to 2014?  Windows enabled Hybrid graphics on
> > windows 8.x as well as 10, and a number of preliminary win10 systems have
> > 2014 bios versions. I'd prefer that to doing all of these hacks in the 
> > drivers.
> 
> Lowering the minumum from 2015 to 2014 should work for nouveau:
> https://lists.freedesktop.org/archives/nouveau/2016-July/025619.html
> 

For further clarify on your research, the current hybrid graphics spec requires
no connectors on the dGPU and hence no audio devices.  For devices with
connectors on the dGPU, they should use the older vendor specific methods and
PR# should not be exposed.

> You can try to ask Mika, see v4.7-rc2-3-g9d26d3a. Maybe the presence of a
> power resource (_PR3 or flags.power_resources) can be used as a hint whether
> to enable port PM.

Yes, the presence of _PR3 would be a great way to determine when to enable it.

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

[Bug 176311] Fiji DisplayPort amdgpu_crtc_page_flip *ERROR* failed to get vblank before flip

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #5 from Vedran Miletić  ---
Testing. Looks good and haven't had it happen thus far, will report in a few
days. Bug 176301 is still occuring.

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

[Bug 98505] [Topaz] Regression introduces in 4.8-rc3

[bugzilla-dae...@freedesktop.org]

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

--- Comment #11 from Peter Wu  ---
(In reply to Alex Deucher from comment #10)
> (In reply to Peter Wu from comment #7)
> > Created attachment 127678 [details] [review] [review]
> > amdgpu patch that checks whether the new interface can be used for PM
> > 
> > PCIe port PM is not enabled because this BIOS is pre-2015: 12/04/2014
> > The BIOS seems to be able to report support for lots of things (can you post
> > a fuller dmesg that include the supported functions?):
> 
> Can we bump the bios white list to 2014?  Windows enabled Hybrid graphics on
> windows 8.x as well as 10, and a number of preliminary win10 systems have
> 2014 bios versions. I'd prefer that to doing all of these hacks in the 
> drivers.

Lowering the minumum from 2015 to 2014 should work for nouveau:
https://lists.freedesktop.org/archives/nouveau/2016-July/025619.html

You can try to ask Mika, see v4.7-rc2-3-g9d26d3a. Maybe the presence of a power
resource (_PR3 or flags.power_resources) can be used as a hint whether to
enable port PM.

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

[Bug 98505] [Topaz] Regression introduces in 4.8-rc3

[bugzilla-dae...@freedesktop.org]

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

--- Comment #10 from Alex Deucher  ---
(In reply to Peter Wu from comment #7)
> Created attachment 127678 [details] [review]
> amdgpu patch that checks whether the new interface can be used for PM
> 
> PCIe port PM is not enabled because this BIOS is pre-2015: 12/04/2014
> The BIOS seems to be able to report support for lots of things (can you post
> a fuller dmesg that include the supported functions?):

Can we bump the bios white list to 2014?  Windows enabled Hybrid graphics on
windows 8.x as well as 10, and a number of preliminary win10 systems have 2014
bios versions.  I'd prefer that to doing all of these hacks in the drivers.

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

[PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Andrzej Hajda]

On 02.11.2016 15:44, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
>> On 02.11.2016 10:46, Shashank Sharma wrote:
>>> CEA-861-F specs defines new 4k video modes to be used with
>>> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
>>> way till VIC=107.
>>>
>>> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
>>> to be able to parse 4k modes using the existing techniques, we have
>>> to complete the modedb (VIC=65 onwards).
>>>
>>> This patch adds:
>>> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
>>> - Newly added 4k modes (from VIC=93 to VIC=107).
>> As I understand it modifies edid_cea_modes array. This array
>> is used by couple of functions, particularly by drm_match_cea_mode,
>> which is used by drm_hdmi_avi_infoframe_from_display_mode.
>> I.e. since this patch AVI infoframes generated using drm core code will
>> be different - they can contain VIC codes unknown to TV.
>> I am not sure if it is harmful, but for sure this patch has visible
>> impact on drivers behavior.
>>
>> Maybe it would be good to allow drivers to keep full compatibility with
>> HDMI 1.4?
> Hello Andrzej,
> Thanks for the comment.
> If you watch the code flow carefully, this is driven by EDID. So any 
> VIC, which is translated/transformed using this array, would be coming 
> from the EDID itself.
> So I dont think there would be a problem if the mode is defined in the 
> EDID section itself, coz we are expecting the TV to know what its 
> mentioning in EDID.
>
> This is how a typical flow would look:
> - hot-plug
> - driver reads modes specified in EDID basic.
> - driver parses various CEA extension blocks.
>  - For both of the above mentioned steps, driver will probe the 
> functions like do_cea_modes which uses edid_cea_modes[] array.
> - driver will add the probed modes in EDID, into connector
> - driver will pass the connector to userspace
> - userspace will pick one of the probed modes for modeset.
> - during modeset, we will set VIC part for a CEA mode, in the AVI 
> infoframe section.
>
> So in other words, the only source of a VIC (cea_mode) is from TV's own 
> EDID.
> This means we should never run into an unknown VIC. There can be a 0 VIC 
> (for non CEA modes), but not unknown one.

For example 3840x2160 at 30Hz has no VIC in HDMI 1.4 but it can
be present in HDMI vendor specific block with HDMI_VIC 1, on the
other side it has VIC 95 in HDMI 2.0. So before your patch
AVI infoframe.video_code is set to 0, after your patch is set to 95.

Regards
Andrzej


>
> Regards
> Shashank
>> Regards
>> Andrzej
>>
>>
>>> Signed-off-by: Shashank Sharma 
>>> Signed-off-by: Sonika Jindal 
>>> Reviewed-by: Jose Abreu 
>>> Reviewed-by: Alex Deucher 
>>>
>>> Cc: Jose Abreu 
>>> Cc: Alex Deucher 
>>>
>>> V2: Addressed review comments from Jose:
>>> - fix the timings for VIC 83, 90 and 91
>>> - fix formatting for VIC 93-107
>>> ---
>>>   drivers/gpu/drm/drm_edid.c | 215 
>>> +
>>>   1 file changed, 215 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> index 9506933..d18602c 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -994,6 +994,221 @@ struct minimode {
>>>2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>>>DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>>  .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
>>> +   /* 65 - 1280x720 at 24Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
>>> +  3080, 3300, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>> + .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 66 - 1280x720 at 25Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
>>> +  3740, 3960, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>> + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 67 - 1280x720 at 30Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
>>> +  3080, 3300, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>> + .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 68 - 1280x720 at 50Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
>>> +  1760, 1980, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>> + .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 69 - 1280x720 at 60Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
>>> +  1430, 1650, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>> + 

[PATCH v2] virtio-gpu: fix vblank events

[Gustavo Padovan]

ping

2016-10-18 Gustavo Padovan :

> From: Gerd Hoffmann 
> 
> virtio-gpu sends vblank events in virtio_gpu_crtc_atomic_flush, and
> because of that it must be called for disabled planes too.  Ask
> drm_atomic_helper_commit_planes to do that.
> 
> v2: update to use new drm_atomic_helper_commit_planes() API.
> 
> Signed-off-by: Gerd Hoffmann 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/virtio/virtgpu_display.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index 6848651..64facc8 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -340,8 +340,7 @@ static void vgdev_atomic_commit_tail(struct 
> drm_atomic_state *state)
>  
>   drm_atomic_helper_commit_modeset_disables(dev, state);
>   drm_atomic_helper_commit_modeset_enables(dev, state);
> - drm_atomic_helper_commit_planes(dev, state,
> - DRM_PLANE_COMMIT_ACTIVE_ONLY);
> + drm_atomic_helper_commit_planes(dev, state, 0);
>  
>   drm_atomic_helper_commit_hw_done(state);
>  
> -- 
> 2.5.5
> 

[Bug 97993] amdgpu_query_gpu_info () segfaults when user does not have permission to open /dev/dri/card*

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from Vedran Miletić  ---
(In reply to Alex Deucher from comment #2)
> Created attachment 127593 [details] [review]
> possible fix
> 
> The patch should fix the acute problem, but may not fix the actual root
> cause which is likely in the OCL driver.

Thanks. I don't have time to test it now, but it looks good.

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

[PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Andrzej Hajda]

On 02.11.2016 10:46, Shashank Sharma wrote:
> CEA-861-F specs defines new 4k video modes to be used with
> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> way till VIC=107.
>
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse 4k modes using the existing techniques, we have
> to complete the modedb (VIC=65 onwards).
>
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).

As I understand it modifies edid_cea_modes array. This array
is used by couple of functions, particularly by drm_match_cea_mode,
which is used by drm_hdmi_avi_infoframe_from_display_mode.
I.e. since this patch AVI infoframes generated using drm core code will
be different - they can contain VIC codes unknown to TV.
I am not sure if it is harmful, but for sure this patch has visible
impact on drivers behavior.

Maybe it would be good to allow drivers to keep full compatibility with
HDMI 1.4?

Regards
Andrzej


>
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Sonika Jindal 
> Reviewed-by: Jose Abreu 
> Reviewed-by: Alex Deucher 
>
> Cc: Jose Abreu 
> Cc: Alex Deucher 
>
> V2: Addressed review comments from Jose:
>   - fix the timings for VIC 83, 90 and 91
>   - fix formatting for VIC 93-107
> ---
>  drivers/gpu/drm/drm_edid.c | 215 
> +
>  1 file changed, 215 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9506933..d18602c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -994,6 +994,221 @@ struct minimode {
>  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720 at 24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720 at 25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720 at 30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 68 - 1280x720 at 50Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 69 - 1280x720 at 60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 70 - 1280x720 at 100Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 71 - 1280x720 at 120Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 72 - 1920x1080 at 24Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 73 - 1920x1080 at 25Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 74 - 1920x1080 at 30Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
> +2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },

[PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Shashank Sharma]

CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse 4k modes using the existing techniques, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

Signed-off-by: Shashank Sharma 
Signed-off-by: Sonika Jindal 
Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 

Cc: Jose Abreu 
Cc: Alex Deucher 

V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107
---
 drivers/gpu/drm/drm_edid.c | 215 +
 1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9506933..d18602c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -994,6 +994,221 @@ struct minimode {
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720 at 24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720 at 25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720 at 30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720 at 50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720 at 60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720 at 100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720 at 120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080 at 24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080 at 25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080 at 30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080 at 50Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 76 - 1920x1080 at 60Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = 

[PATCH] drm/nouveau/tegra: Fix error handling

[Alexandre Courbot]

On Mon, Oct 31, 2016 at 3:35 PM, Christophe JAILLET
 wrote:
> 'iommu_domain_alloc()' returns NULL in case of error, not an error pointer.
> So test it accordingly.
>
> Signed-off-by: Christophe JAILLET 

Reviewed-by: Alexandre Courbot 

Indeed. Thanks for the fix!

[PATCH v2] drm: Complete CEA modedb(VIC 1-107)

[Deucher, Alexander]

> -Original Message-
> From: Shashank Sharma [mailto:shashank.sharma at intel.com]
> Sent: Wednesday, November 02, 2016 5:46 AM
> To: dri-devel at lists.freedesktop.org; intel-gfx at lists.freedesktop.org
> Cc: airlied at redhat.com; daniel.vetter at intel.com;
> Jose.Abreu at synopsys.com; Shashank Sharma; Deucher, Alexander
> Subject: [PATCH v2] drm: Complete CEA modedb(VIC 1-107)
> 
> CEA-861-F specs defines new 4k video modes to be used with
> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> way till VIC=107.
> 
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse 4k modes using the existing techniques, we have
> to complete the modedb (VIC=65 onwards).
> 
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).

I don't have the spec in front of me to double check the timings, but assuming 
the previous typos were addressed, the patch is:
Reviewed-by: Alex Deucher 

> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Sonika Jindal 
> Reviewed-by: Jose Abreu 
> Reviewed-by: Alex Deucher 
> 
> Cc: Jose Abreu 
> Cc: Alex Deucher 
> 
> V2: Addressed review comments from Jose:
>   - fix the timings for VIC 83, 90 and 91
>   - fix formatting for VIC 93-107
> ---
>  drivers/gpu/drm/drm_edid.c | 215
> +
>  1 file changed, 215 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9506933..d18602c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -994,6 +994,221 @@ struct minimode {
>  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720 at 24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280,
> 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720 at 25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720 at 30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 68 - 1280x720 at 50Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 50, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 69 - 1280x720 at 60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 60, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 70 - 1280x720 at 100Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280,
> 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 100, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 71 - 1280x720 at 120Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280,
> 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 120, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 72 - 1920x1080 at 24Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920,
> 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 73 - 1920x1080 at 25Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920,
> 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 74 - 1920x1080 at 30Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920,
> 2008,
> +2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   

[PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info

[Peter Wu]

On Wed, Nov 02, 2016 at 11:47:03AM +, Emil Velikov wrote:
> On 2 November 2016 at 11:14, Peter Wu  wrote:
> > On Tue, Nov 01, 2016 at 06:13:34PM +, Emil Velikov wrote:
> >>  sysfs file wakes up the device. The latter of which may
> >> be slow and isn't required to begin with.
> >>
> >> Reading through config is/was required since the revision is not
> >> available by other means, although with a kernel patch in the way we can
> >> 'cheat' temporarily.
> >>
> >> That should be fine, since no open-source project has ever used the
> >> value.
> >>
> >> Cc: Michel Dänzer 
> >> Cc: Mauro Santos 
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
> >> Signed-off-by: Emil Velikov 
> >
> > See below for one observation. Other than that, strace confirms that
> > the new sysfs files are being accessed.
> >
> > Reviewed-and-tested-by: Peter Wu 
> >
> > This was tested with Linux 4.8.4 (unpatched) and libdrm 2.4.71 (+this
> > patch) with i915 + nouveau. Tested with running glxgears and glxinfo.
> > Note that glxinfo still accesses 'config' due to libpciaccess.
> >
> > + drm_intel_get_aperture_sizes
> >   + drm_intel_probe_agp_aperture_size
> > + pci_system_init()
> >   + pci_system_linux_sysfs_create
> > + populate_entries
> >   + pci_device_linux_sysfs_read() <-- offending function
> > + pci_device_find_by_slot(0, 0, 2, 0)
> >
> > That populate_entries function can probably use a fix similar to this
> > one.
> >
> Indeed it would, although we ought to check if that won't cause any
> (extra) regressions.
> 
> Skimming through my distro (Arch) the following depend on libpciaccess:
> 
> intel-gpu-tools

Does not use the "revision" field.

> libdrm

Does not use the "revision" field of libpciaccess.

While amdgpu has the "pci_rev" line below, it is copied from the
response of an ioctl, not pciaccess, so it is safe:

drm_private int amdgpu_query_gpu_info_init(amdgpu_device_handle dev)
{
int r, i;

r = amdgpu_query_info(dev, AMDGPU_INFO_DEV_INFO, sizeof(dev->dev_info),
  >dev_info);
// ...
dev->info.pci_rev_id = dev->dev_info.pci_rev;

> libvirt
> radeontool
> spice-vdagent
> vbetool

These four do not use the "revision" field and are safe.

> xorg-server
> 
> Of which the first two are safe, while the last one isn't + it even
> exports the revision to DDX via xf86str.h's GDevRec::chipRev

xorg-server internally does not use the revision field, but it exports
them as you have observed:

GDevRec::chipRev
(copied from libpciaccess, struct pci_device::revision)
XF86ConfDevicePtr::dev_chiprev (copied from GDevRec::chipRev)

Not knowing what the users are, I tried to have a look at the git logs
for "chipRev", but the change introducing it is not that helpful:

commit ded6147bfb5d75ff1e67c858040a628b61bc17d1
Author: Kaleb Keithley 
Date:   Fri Nov 14 15:54:54 2003 +

R6.6 is the Xorg base-line
...
 609 files changed, 262690 insertions(+)

To play safe, you could fallback to "config" in sysfs when "revision" is
not found, that would allow older kernels to work with no regressions in
the information while reducing the runtime wakeups for newer kernels.

> Which gives us even more places to check through. Can you lend a hand ?
> 
> Thanks
> Emil

I am also on Arch, what other places are you thinking about? DDXes or
other users of libpciaccess?

Kind regards,
Peter

[PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge

[Alexey Brodkin]

Hi Daniel, David,

On Mon, 2016-10-24 at 18:33 +, Alexey Brodkin wrote:
> Hi Daniel,
> 
> > 
> > -Original Message-
> > From: linux-snps-arc [mailto:linux-snps-arc-bounces at lists.infradead.org] 
> > On Behalf Of Alexey Brodkin
> > Sent: 19 октября 2016 г. 12:33
> > To: dri-devel at lists.freedesktop.org; architt at codeaurora.org; 
> > Eugeniy.Paltsev at synopsys.com
> > Cc: linux-snps-arc at lists.infradead.org; linux-kernel at vger.kernel.org
> > Subject: Re: [PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge
> > 
> > Hi Archit, all,
> > 
> > On Wed, 2016-10-19 at 14:43 +0530, Archit Taneja wrote:
> > > 
> > > 
> > > On 10/19/2016 01:16 PM, Eugeniy Paltsev wrote:
> > > > 
> > > > 
> > > > ARC PGU driver starts crashing on initialization after
> > > > 'commit e12c2f645557 ("drm/i2c: adv7511: Convert to drm_bridge")'
> > > > This happenes because in "arcpgu_drm_hdmi_init" function we get pointer
> > > > of "drm_i2c_encoder_driver" structure, which doesn't exist after
> > > > adv7511 hdmi encoder interface changed from slave encoder to drm bridge.
> > > > So, when we call "encoder_init" function from this structure driver
> > > > crashes.
> > 
> > [snip]
> > 
> > > 
> > > Looks good now.
> > > 
> > > Reviewed-by: Archit Taneja 
> > 
> > And IMHO it would be really good to get this one back-ported to 4.8
> > because it really fixes kernel crash if ARC PGU driver is used.
> > 
> > It might be a bit of a problem because patch itself a little-bit larger
> > than formal requirement for stable backports but let's see if it gets 
> > accepted.
> 
> Could you please pick this one up?
> I may alternatively send a pull-request to David but not sure if 1 patch 
> worth it.
> 
> Also if that's not really too late it would be good to get this one in 4.9 
> since the patch
> In question fixes a real driver crash on its instantiation.
> Actually driver crash happens since 4.8 but I failed to notice it earlier and 
> given amount
> of changes I think there's barely a chance for it it to be accepted in stable 
> branches...
> which in its turn makes at least 4.9 very desirable.

Any chance this one gets accepted anytime soon?

Regards,
Alexey

[PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info

[Peter Wu]

On Tue, Nov 01, 2016 at 06:13:34PM +, Emil Velikov wrote:
>  sysfs file wakes up the device. The latter of which may
> be slow and isn't required to begin with.
> 
> Reading through config is/was required since the revision is not
> available by other means, although with a kernel patch in the way we can
> 'cheat' temporarily.
> 
> That should be fine, since no open-source project has ever used the
> value.
> 
> Cc: Michel Dänzer 
> Cc: Mauro Santos 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
> Signed-off-by: Emil Velikov 

See below for one observation. Other than that, strace confirms that
the new sysfs files are being accessed.

Reviewed-and-tested-by: Peter Wu 

This was tested with Linux 4.8.4 (unpatched) and libdrm 2.4.71 (+this
patch) with i915 + nouveau. Tested with running glxgears and glxinfo.
Note that glxinfo still accesses 'config' due to libpciaccess.

+ drm_intel_get_aperture_sizes
  + drm_intel_probe_agp_aperture_size
+ pci_system_init()
  + pci_system_linux_sysfs_create
+ populate_entries
  + pci_device_linux_sysfs_read() <-- offending function
+ pci_device_find_by_slot(0, 0, 2, 0)

That populate_entries function can probably use a fix similar to this
one.

> ---
> Mauro can you apply this against libdrm and rebuild it. You do _not_
> need to rebuild mesa afterwords.
> 
> Thanks
> ---
>  xf86drm.c | 50 +++---
>  1 file changed, 35 insertions(+), 15 deletions(-)
> 
> diff --git a/xf86drm.c b/xf86drm.c
> index 52add5e..5a5100c 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -2950,25 +2950,45 @@ static int drmParsePciDeviceInfo(const char *d_name,
>   drmPciDeviceInfoPtr device)
>  {
>  #ifdef __linux__
> +#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
> +static const char *attrs[] = {
> +  "revision", /* XXX: make sure it's always first, see note below */
> +  "vendor",
> +  "device",
> +  "subsystem_vendor",
> +  "subsystem_device",
> +};
>  char path[PATH_MAX + 1];

The size for snprintf already includes the nul-terminator, so strictly
speaking the +1 is not needed. It does not hurt either though.

> -unsigned char config[64];
> -int fd, ret;
> +unsigned int data[ARRAY_SIZE(attrs)];
> +FILE *fp;
> +int ret;
>  
> -snprintf(path, PATH_MAX, "/sys/class/drm/%s/device/config", d_name);
> -fd = open(path, O_RDONLY);
> -if (fd < 0)
> -return -errno;
> +for (unsigned i = 0; i < ARRAY_SIZE(attrs); i++) {
> +snprintf(path, PATH_MAX, "/sys/class/drm/%s/device/%s",
> + d_name, attrs[i]);
> +fp = fopen(path, "r");
> +if (!fp) {
> +/* Note: First we check the revision, since older kernels
> + * may not have it. Default to zero in such cases. */
> +if (i == 0) {
> +data[i] = 0;
> +continue;
> +}
> +return -errno;
> +}
>  
> -ret = read(fd, config, sizeof(config));
> -close(fd);
> -if (ret < 0)
> -return -errno;
> +ret = fscanf(fp, "%x", [i]);
> +fclose(fp);
> +if (ret != 1)
> +return -errno;
> +
> +}
>  
> -device->vendor_id = config[0] | (config[1] << 8);
> -device->device_id = config[2] | (config[3] << 8);
> -device->revision_id = config[8];
> -device->subvendor_id = config[44] | (config[45] << 8);
> -device->subdevice_id = config[46] | (config[47] << 8);
> +device->revision_id = data[0] & 0xff;
> +device->vendor_id = data[1] & 0x;
> +device->device_id = data[2] & 0x;
> +device->subvendor_id = data[3] & 0x;
> +device->subdevice_id = data[4] & 0x;
>  
>  return 0;
>  #else
> -- 
> 2.10.0

[PATCH v8 03/12] drm/i915: rename OACONTROL GEN7_OACONTROL

[sourab gupta]

On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> OACONTROL changes quite a bit for gen8, with some bits split out into a
> per-context OACTXCONTROL register. Rename now before adding more gen7 OA
> registers
> 
> Signed-off-by: Robert Bragg 
> Reviewed-by: Matthew Auld 
Reviewed-by: Sourab Gupta 

[PATCH v8 10/12] drm/i915: add oa_event_min_timer_exponent sysctl

[sourab gupta]

On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> The minimal sampling period is now configurable via a
> dev.i915.oa_min_timer_exponent sysctl parameter.
> 
> Following the precedent set by perf, the default is the minimum that
> won't (on its own) exceed the default kernel.perf_event_max_sample_rate
> default of 10 samples/s.
> 
> Signed-off-by: Robert Bragg 
> Reviewed-by: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/i915_perf.c | 42 
> 
>  1 file changed, 30 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 4e42073..e3c6f51 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -82,6 +82,22 @@ static u32 i915_perf_stream_paranoid = true;
>  #define INVALID_CTX_ID 0x
>  
> 
> +/* for sysctl proc_dointvec_minmax of i915_oa_min_timer_exponent */
> +static int oa_exponent_max = OA_EXPONENT_MAX;
> +
> +/* Theoretically we can program the OA unit to sample every 160ns but don't
> + * allow that by default unless root...
> + *
> + * The period is derived from the exponent as:
> + *
> + *   period = 80ns * 2^(exponent + 1)
> + *
> + * Referring to perf's kernel.perf_event_max_sample_rate for a precedent
> + * (10 by default); with an OA exponent of 6 we get a period of 10.240
> + * microseconds - just under 10Hz
> + */
> +static u32 i915_oa_min_timer_exponent = 6;

For HSW, the timestamp period is 80ns, so the exponent of 6 translates
to sampling rate of ~10Hz. But the timestamp period may change for
other platforms, leading to different values of oa_min_timer_exponent
corresponding to sampling rate of ~10Hz. Do we plan to have this
value platform specific subsequently, or the guidance value of ~10Hz
min sampling rate needn't be strictly followed?

> +
>  /* XXX: beware if future OA HW adds new report formats that the current
>   * code assumes all reports have a power-of-two size and ~(size - 1) can
>   * be used as a mask to align the OA tail pointer.
> @@ -1353,21 +1369,14 @@ static int read_properties_unlocked(struct 
> drm_i915_private *dev_priv,
>   return -EINVAL;
>   }
>  
> - /* NB: The exponent represents a period as follows:
> -  *
> -  *   80ns * 2^(period_exponent + 1)
> -  *
> -  * Theoretically we can program the OA unit to sample
> + /* Theoretically we can program the OA unit to sample
>* every 160ns but don't allow that by default unless
>* root.
> -  *
> -  * Referring to perf's
> -  * kernel.perf_event_max_sample_rate for a precedent
> -  * (10 by default); with an OA exponent of 6 we get
> -  * a period of 10.240 microseconds -just under 10Hz
>*/
> - if (value < 6 && !capable(CAP_SYS_ADMIN)) {
> - DRM_ERROR("Minimum OA sampling exponent is 6 
> without root privileges\n");
> + if (value < i915_oa_min_timer_exponent &&
> + !capable(CAP_SYS_ADMIN)) {
> + DRM_ERROR("Minimum OA sampling exponent (sysctl 
> dev.i915.oa_min_timer_exponent) is %u without root privileges\n",
> +   i915_oa_min_timer_exponent);
>   return -EACCES;
>   }
>  
> @@ -1475,6 +1484,15 @@ static struct ctl_table oa_table[] = {
>.extra1 = ,
>.extra2 = ,
>},
> + {
> +  .procname = "oa_min_timer_exponent",
> +  .data = _oa_min_timer_exponent,
> +  .maxlen = sizeof(i915_oa_min_timer_exponent),
> +  .mode = 0644,
> +  .proc_handler = proc_dointvec_minmax,
> +  .extra1 = ,
> +  .extra2 = _exponent_max,
> +  },
>   {}
>  };
>  

[PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info

[Emil Velikov]

On 2 November 2016 at 11:14, Peter Wu  wrote:
> On Tue, Nov 01, 2016 at 06:13:34PM +, Emil Velikov wrote:
>>  sysfs file wakes up the device. The latter of which may
>> be slow and isn't required to begin with.
>>
>> Reading through config is/was required since the revision is not
>> available by other means, although with a kernel patch in the way we can
>> 'cheat' temporarily.
>>
>> That should be fine, since no open-source project has ever used the
>> value.
>>
>> Cc: Michel Dänzer 
>> Cc: Mauro Santos 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
>> Signed-off-by: Emil Velikov 
>
> See below for one observation. Other than that, strace confirms that
> the new sysfs files are being accessed.
>
> Reviewed-and-tested-by: Peter Wu 
>
> This was tested with Linux 4.8.4 (unpatched) and libdrm 2.4.71 (+this
> patch) with i915 + nouveau. Tested with running glxgears and glxinfo.
> Note that glxinfo still accesses 'config' due to libpciaccess.
>
> + drm_intel_get_aperture_sizes
>   + drm_intel_probe_agp_aperture_size
> + pci_system_init()
>   + pci_system_linux_sysfs_create
> + populate_entries
>   + pci_device_linux_sysfs_read() <-- offending function
> + pci_device_find_by_slot(0, 0, 2, 0)
>
> That populate_entries function can probably use a fix similar to this
> one.
>
Indeed it would, although we ought to check if that won't cause any
(extra) regressions.

Skimming through my distro (Arch) the following depend on libpciaccess:

intel-gpu-tools
libdrm
libvirt
radeontool
spice-vdagent
vbetool
xorg-server

Of which the first two are safe, while the last one isn't + it even
exports the revision to DDX via xf86str.h's GDevRec::chipRev
Which gives us even more places to check through. Can you lend a hand ?

Thanks
Emil

[Intel-gfx] [RFC PATCH] drm: define drm_compat_ioctl NULL on CONFIG_COMPAT=n and reduce #ifdefs

[Sean Paul]

On Wed, Nov 2, 2016 at 2:03 AM, Patrik Jakobsson
 wrote:
> On Tue, Nov 1, 2016 at 4:40 PM, Jani Nikula  wrote:
>> If we define drm_compat_ioctl NULL on CONFIG_COMPAT=n, we don't have to
>> check for the config everywhere.
>>
>> Signed-off-by: Jani Nikula 
>
> Looks good and I like the idea.
>
> Reviewed-by: Patrik Jakobsson 
>


Applied to drm-misc, thanks

Sean

>> ---
>>
>> Just an idea on top of Patrik's patch.
>> ---
>>  drivers/gpu/drm/arc/arcpgu_drv.c|  2 --
>>  drivers/gpu/drm/arm/hdlcd_drv.c |  2 --
>>  drivers/gpu/drm/arm/malidp_drv.c|  2 --
>>  drivers/gpu/drm/ast/ast_drv.c   |  2 --
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c|  2 --
>>  drivers/gpu/drm/bochs/bochs_drv.c   |  2 --
>>  drivers/gpu/drm/cirrus/cirrus_drv.c |  2 --
>>  drivers/gpu/drm/drm_fops.c  | 13 ++---
>>  drivers/gpu/drm/etnaviv/etnaviv_drv.c   |  2 --
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c |  2 --
>>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   |  2 --
>>  drivers/gpu/drm/gma500/psb_drv.c|  2 --
>>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  2 --
>>  drivers/gpu/drm/i810/i810_dma.c |  2 --
>>  drivers/gpu/drm/i810/i810_drv.c |  2 --
>>  drivers/gpu/drm/i915/i915_drv.c |  2 --
>>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  2 --
>>  drivers/gpu/drm/mgag200/mgag200_drv.c   |  2 --
>>  drivers/gpu/drm/msm/msm_drv.c   |  2 --
>>  drivers/gpu/drm/rcar-du/rcar_du_drv.c   |  2 --
>>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  2 --
>>  drivers/gpu/drm/savage/savage_drv.c |  2 --
>>  drivers/gpu/drm/shmobile/shmob_drm_drv.c|  2 --
>>  drivers/gpu/drm/sis/sis_drv.c   |  2 --
>>  drivers/gpu/drm/sti/sti_drv.c   |  2 --
>>  drivers/gpu/drm/sun4i/sun4i_drv.c   |  2 --
>>  drivers/gpu/drm/tdfx/tdfx_drv.c |  2 --
>>  drivers/gpu/drm/tegra/drm.c |  2 --
>>  drivers/gpu/drm/tilcdc/tilcdc_drv.c |  2 --
>>  drivers/gpu/drm/udl/udl_drv.c   |  2 --
>>  drivers/gpu/drm/vc4/vc4_drv.c   |  2 --
>>  drivers/gpu/drm/via/via_drv.c   |  2 --
>>  drivers/gpu/drm/virtio/virtgpu_drv.c|  2 --
>>  include/drm/drmP.h  |  5 +
>>  35 files changed, 13 insertions(+), 71 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c 
>> b/drivers/gpu/drm/arc/arcpgu_drv.c
>> index 28e6471257d0..0b6eaa49a1db 100644
>> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
>> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
>> @@ -65,9 +65,7 @@ static const struct file_operations arcpgu_drm_ops = {
>> .open = drm_open,
>> .release = drm_release,
>> .unlocked_ioctl = drm_ioctl,
>> -#ifdef CONFIG_COMPAT
>> .compat_ioctl = drm_compat_ioctl,
>> -#endif
>> .poll = drm_poll,
>> .read = drm_read,
>> .llseek = no_llseek,
>> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c 
>> b/drivers/gpu/drm/arm/hdlcd_drv.c
>> index 6477d1a65266..59747ecaad54 100644
>> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
>> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
>> @@ -268,9 +268,7 @@ static const struct file_operations fops = {
>> .open   = drm_open,
>> .release= drm_release,
>> .unlocked_ioctl = drm_ioctl,
>> -#ifdef CONFIG_COMPAT
>> .compat_ioctl   = drm_compat_ioctl,
>> -#endif
>> .poll   = drm_poll,
>> .read   = drm_read,
>> .llseek = noop_llseek,
>> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
>> b/drivers/gpu/drm/arm/malidp_drv.c
>> index 9f4739452a25..d53b625b14fe 100644
>> --- a/drivers/gpu/drm/arm/malidp_drv.c
>> +++ b/drivers/gpu/drm/arm/malidp_drv.c
>> @@ -197,9 +197,7 @@ static const struct file_operations fops = {
>> .open = drm_open,
>> .release = drm_release,
>> .unlocked_ioctl = drm_ioctl,
>> -#ifdef CONFIG_COMPAT
>> .compat_ioctl = drm_compat_ioctl,
>> -#endif
>> .poll = drm_poll,
>> .read = drm_read,
>> .llseek = noop_llseek,
>> diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
>> index f54afd2113a9..fd7c9eec92e4 100644
>> --- a/drivers/gpu/drm/ast/ast_drv.c
>> +++ b/drivers/gpu/drm/ast/ast_drv.c
>> @@ -188,9 +188,7 @@ static const struct file_operations ast_fops = {
>> .unlocked_ioctl = drm_ioctl,
>> .mmap = ast_mmap,
>> .poll = drm_poll,
>> -#ifdef CONFIG_COMPAT
>> .compat_ioctl = drm_compat_ioctl,
>> -#endif
>> .read = drm_read,
>>  };
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> index 9f6222895212..cbd0070265c9 100644
>> --- 

[PATCH] drm/gma500: Add compat ioctl

[Sean Paul]

On Tue, Nov 1, 2016 at 10:43 AM, Patrik Jakobsson
 wrote:
> Hook up drm_compat_ioctl to support 32-bit userspace on 64-bit kernels.
> It turns out that N2600 and N2800 comes with 64-bit enabled. We
> previously assumed there where no such systems out there.
>


Applied to drm-misc, thanks

Sean

> Cc: stable at vger.kernel.org
> Signed-off-by: Patrik Jakobsson 
> ---
>  drivers/gpu/drm/gma500/psb_drv.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/gma500/psb_drv.c 
> b/drivers/gpu/drm/gma500/psb_drv.c
> index 50eb944f..8f3ca52 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.c
> +++ b/drivers/gpu/drm/gma500/psb_drv.c
> @@ -473,6 +473,9 @@ static const struct file_operations psb_gem_fops = {
> .open = drm_open,
> .release = drm_release,
> .unlocked_ioctl = psb_unlocked_ioctl,
> +#ifdef CONFIG_COMPAT
> +   .compat_ioctl = drm_compat_ioctl,
> +#endif
> .mmap = drm_gem_mmap,
> .poll = drm_poll,
> .read = drm_read,
> --
> 2.10.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] omapdrm changes for v4.10

[Tomi Valkeinen]

dss/omapdss.h  |  98 +++--
 drivers/gpu/drm/omapdrm/dss/output.c   |   5 +-
 drivers/gpu/drm/omapdrm/dss/rfbi.c |  49 +++--
 drivers/gpu/drm/omapdrm/dss/sdi.c  |  33 ++-
 drivers/gpu/drm/omapdrm/dss/venc.c |  97 -
 drivers/gpu/drm/omapdrm/omap_connector.c   |  87 +---
 drivers/gpu/drm/omapdrm/omap_crtc.c|  30 +--
 drivers/gpu/drm/omapdrm/omap_drv.h |   7 +-
 drivers/gpu/drm/omapdrm/omap_encoder.c |  10 +-
 drivers/gpu/drm/omapdrm/omap_gem.c |   6 +-
 drivers/gpu/drm/omapdrm/omap_plane.c   |  28 ++-
 drivers/video/of_display_timing.c  |   9 +
 include/video/display_timing.h |   4 +
 39 files changed, 807 insertions(+), 1016 deletions(-)

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161102/6debaf04/attachment.sig>

[Bug 98541] [bisected] gpu hang

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from Nicolai Hähnle  ---
Can you provide an apitrace that reproduces the hang?

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

[PATCH] drm: move check for min/max width/height for atomic drivers

[Rob Clark]

drm-hwc + android tries to create an fb for the wallpaper layer, which
is larger than the screen resolution, and potentially larger than
mode_config->max_{width,height}.  But the plane src_w/src_h is within
the max limits, so it is something the hardware can otherwise do.

For atomic drivers, defer the check to drm_atomic_plane_check().

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_atomic.c | 17 +
 drivers/gpu/drm/drm_crtc.c   | 26 +-
 2 files changed, 34 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 34edd4f..fb0f07ce 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -846,7 +846,9 @@ plane_switching_crtc(struct drm_atomic_state *state,
 static int drm_atomic_plane_check(struct drm_plane *plane,
struct drm_plane_state *state)
 {
+   struct drm_mode_config *config = >dev->mode_config;
unsigned int fb_width, fb_height;
+   unsigned int min_width, max_width, min_height, max_height;
int ret;

/* either *both* CRTC and FB must be set, or neither */
@@ -909,6 +911,21 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
return -ENOSPC;
}

+   min_width = config->min_width << 16;
+   max_width = config->max_width << 16;
+   min_height = config->min_height << 16;
+   max_height = config->max_height << 16;
+
+   /* Make sure source dimensions are within bounds. */
+   if (min_width > state->src_w || state->src_w > max_width ||
+   min_height > state->src_h || state->src_h > max_height) {
+   DRM_DEBUG_ATOMIC("Invalid source size "
+"%u.%06ux%u.%06u\n",
+state->src_w >> 16, ((state->src_w & 0x) * 
15625) >> 10,
+state->src_h >> 16, ((state->src_h & 0x) * 
15625) >> 10);
+   return -ERANGE;
+   }
+
if (plane_switching_crtc(state->state, plane, state)) {
DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
 plane->base.id, plane->name);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b4b973f..7294bde 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3369,15 +3369,23 @@ internal_framebuffer_create(struct drm_device *dev,
return ERR_PTR(-EINVAL);
}

-   if ((config->min_width > r->width) || (r->width > config->max_width)) {
-   DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d && <= 
%d\n",
- r->width, config->min_width, config->max_width);
-   return ERR_PTR(-EINVAL);
-   }
-   if ((config->min_height > r->height) || (r->height > 
config->max_height)) {
-   DRM_DEBUG_KMS("bad framebuffer height %d, should be >= %d && <= 
%d\n",
- r->height, config->min_height, config->max_height);
-   return ERR_PTR(-EINVAL);
+   /* for atomic drivers, we check the src dimensions in
+* drm_atomic_plane_check().. allow creation of a fb
+* that is larger than what can be scanned out, as
+* long as userspace doesn't try to scanout a portion
+* of the fb that is too large.
+*/
+   if (!file_priv->atomic) {
+   if ((config->min_width > r->width) || (r->width > 
config->max_width)) {
+   DRM_DEBUG_KMS("bad framebuffer width %d, should be >= 
%d && <= %d\n",
+ r->width, config->min_width, 
config->max_width);
+   return ERR_PTR(-EINVAL);
+   }
+   if ((config->min_height > r->height) || (r->height > 
config->max_height)) {
+   DRM_DEBUG_KMS("bad framebuffer height %d, should be >= 
%d && <= %d\n",
+ r->height, config->min_height, 
config->max_height);
+   return ERR_PTR(-EINVAL);
+   }
}

if (r->flags & DRM_MODE_FB_MODIFIERS &&
-- 
2.7.4

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

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

Jan Ziak <0xe2.0x9a.0x9b at gmail.com> changed:

   What|Removed |Added

   Severity|major   |critical

--- Comment #126 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
Resolution of this bug is critical for CONFIG_DRM_AMDGPU_CIK to move from
experimental to non-experimental state.

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

[linux-sunxi] Re: [PATCH v3 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply

[Chen-Yu Tsai]

On Mon, Oct 31, 2016 at 2:28 PM, Rob Herring  wrote:
> On Sat, Oct 29, 2016 at 07:06:10PM +0800, Chen-Yu Tsai wrote:
>> Some dumb VGA DACs are active components which require external power.
>> Add support for specifying a regulator as its power supply.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  .../bindings/display/bridge/dumb-vga-dac.txt   |  2 ++
>
> For the binding,
>
> Acked-by: Rob Herring 
>
> One code comment below...
>
>>  drivers/gpu/drm/bridge/dumb-vga-dac.c  | 35 
>> ++
>>  2 files changed, 37 insertions(+)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt 
>> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> index 003bc246a270..164cbb15f04c 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> @@ -16,6 +16,8 @@ graph bindings specified in 
>> Documentation/devicetree/bindings/graph.txt.
>>  - Video port 0 for RGB input
>>  - Video port 1 for VGA output
>>
>> +Optional properties:
>> +- vdd-supply: Power supply for DAC
>>
>>  Example
>>  ---
>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> index afec232185a7..59781e031220 100644
>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> @@ -12,6 +12,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -23,6 +24,7 @@ struct dumb_vga {
>>   struct drm_connectorconnector;
>>
>>   struct i2c_adapter  *ddc;
>> + struct regulator*vdd;
>>  };
>>
>>  static inline struct dumb_vga *
>> @@ -124,8 +126,33 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>>   return 0;
>>  }
>>
>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>> +{
>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> + int ret;
>> +
>> + if (!IS_ERR(vga->vdd)) {
>
> if (IS_ERR())
> return;
>
> ...will save some intentation.

I thought about that, though if someone were to add more stuff to
this, such as an enable GPIO, they might have to rework it. A standalone
block of code would be easier to work with. I'm OK either way though.

ChenYu

>
>> + ret = regulator_enable(vga->vdd);
>> +
>> + if (ret) {
>> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
>> + return;
>> + }
>> + }
>> +}
>> +
>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>> +{
>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> +
>> + if (!IS_ERR(vga->vdd))
>> + regulator_disable(vga->vdd);
>> +}
>> +
>>  static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>>   .attach = dumb_vga_attach,
>> + .enable = dumb_vga_enable,
>> + .disable= dumb_vga_disable,
>>  };
>>
>>  static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>> @@ -169,6 +196,14 @@ static int dumb_vga_probe(struct platform_device *pdev)
>>   return -ENOMEM;
>>   platform_set_drvdata(pdev, vga);
>>
>> + vga->vdd = devm_regulator_get_optional(>dev, "vdd");
>> + if (IS_ERR(vga->vdd)) {
>> + ret = PTR_ERR(vga->vdd);
>> + if (ret == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>> + dev_dbg(>dev, "No vdd regulator found: %d\n", ret);
>> + }
>> +
>>   vga->ddc = dumb_vga_retrieve_ddc(>dev);
>>   if (IS_ERR(vga->ddc)) {
>>   if (PTR_ERR(vga->ddc) == -ENODEV) {
>> --
>> 2.9.3
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Intel-gfx] [PATCH 01/19] drm/atomic: Add new iterators over all state

[Maarten Lankhorst]

Op 01-11-16 om 14:41 schreef Ville Syrjälä:
> On Tue, Nov 01, 2016 at 02:34:00PM +0100, Maarten Lankhorst wrote:
>> Op 01-11-16 om 14:09 schreef Ville Syrjälä:
>>> On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote:
 Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
 replace the old for_each_xxx_in_state ones. This is useful for >1 flip
 depth and getting rid of all xxx->state dereferences.

 Signed-off-by: Maarten Lankhorst 
 ---
  drivers/gpu/drm/drm_atomic.c |  6 +++
  drivers/gpu/drm/drm_atomic_helper.c  | 52 +--
  drivers/gpu/drm/i915/intel_display.c | 11 ++---
  include/drm/drm_atomic.h | 81 
 ++--
  include/drm/drm_atomic_helper.h  |  3 ++
  5 files changed, 142 insertions(+), 11 deletions(-)

 diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
 index 5dd70540219c..120775fcfb70 100644
 --- a/drivers/gpu/drm/drm_atomic.c
 +++ b/drivers/gpu/drm/drm_atomic.c
 @@ -278,6 +278,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state 
 *state,
return ERR_PTR(-ENOMEM);
  
state->crtcs[index].state = crtc_state;
 +  state->crtcs[index].old_state = crtc->state;
 +  state->crtcs[index].new_state = crtc_state;
state->crtcs[index].ptr = crtc;
crtc_state->state = state;
  
 @@ -640,6 +642,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state 
 *state,
  
state->planes[index].state = plane_state;
state->planes[index].ptr = plane;
 +  state->planes[index].old_state = plane->state;
 +  state->planes[index].new_state = plane_state;
plane_state->state = state;
  
DRM_DEBUG_ATOMIC("Added [PLANE:%d:%s] %p state to %p\n",
 @@ -931,6 +935,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
 *state,
  
drm_connector_reference(connector);
state->connectors[index].state = connector_state;
 +  state->connectors[index].old_state = connector->state;
 +  state->connectors[index].new_state = connector_state;
state->connectors[index].ptr = connector;
connector_state->state = state;
  
 diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
 b/drivers/gpu/drm/drm_atomic_helper.c
 index 07b432f43b98..fcb6e5b55217 100644
 --- a/drivers/gpu/drm/drm_atomic_helper.c
 +++ b/drivers/gpu/drm/drm_atomic_helper.c
 @@ -2495,7 +2495,7 @@ EXPORT_SYMBOL(drm_atomic_helper_disable_all);
   *
   * See also:
   * drm_atomic_helper_duplicate_state(), drm_atomic_helper_disable_all(),
 - * drm_atomic_helper_resume()
 + * drm_atomic_helper_resume(), drm_atomic_helper_commit_duplicated_state()
   */
  struct drm_atomic_state *drm_atomic_helper_suspend(struct drm_device *dev)
  {
 @@ -2536,6 +2536,52 @@ unlock:
  EXPORT_SYMBOL(drm_atomic_helper_suspend);
  
  /**
 + * drm_atomic_helper_commit_duplicated_state - commit duplicated state
 + * @state: duplicated atomic state to commit
 + * @ctx: pointer to acquire_ctx to use for commit.
 + * @nonblock: commit the state non-blocking.
 + *
 + * The state returned by drm_atomic_helper_duplicate_state() and
 + * drm_atomic_helper_suspend() is partially invalid, and needs to
 + * be fixed up before commit.
>>> So the old_state pointers are potentially invalid because whatever->state
>>> may have changed since we duplicated the state?
>> Yes when you use drm_atomic_helper_duplicate_state, and commit a different 
>> state before committing the duplicated state.
>> This only happens during suspend/resume and gpu reset.
> Should we maybe have something like drm_atomic_refresh_old_state(state)?
> Would allow the caller then to check something in the old vs. new state
> before committing?

iirc that was the first approach I took, but then you shouldn't do anything 
with a duplicated state after
creating a except commit it, so creating a commit_duplicated_state should be 
enough.

Can you think of any case where you do the following?

Duplicate state
commit different state
Look at duplicated state, tinker with it, commit it.

~Maarten

[Bug 98541] [bisected] gpu hang

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Alexandr Zelinsky  ---
Created attachment 127683
  --> https://bugs.freedesktop.org/attachment.cgi?id=127683=edit
Xorg.0.log

r7 360
llvm git 188a521a18bf77747e2fa21a8a541e7882b0aea0
kernel 4.7.0 and 4.8.2 driver amdgpu
dual screen configuration

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

[Bug 178281] wine-staging apps freezes the machine with RX460

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #16 from fin4478 at hotmail.com ---
Recent drm-next-4.10-wip and Mesa changes have made wine-staging gaming more
stable. TR 2013,  Legend and Underworld works now at my monitor native
1920x1200 resolution. To play TR 2013 without desktop hanging, I needed to
disable Post Processing, Anti-Aliasing, SSAO and set Texture Filter to
Bilinear. Other settings can be ultra and high.

I thank driver developers for fast fixes.

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

[Bug 98541] [bisected] gpu hang

[bugzilla-dae...@freedesktop.org]

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||nhaehnle at gmail.com

--- Comment #1 from Michel Dänzer  ---
Nicolai, any ideas? That's

commit 1b6fb88ab2031a98ddf03a81f644b22a8f7e9428
Author: Nicolai Hähnle 
Date:   Wed Sep 28 21:27:16 2016 +0200

gallium/radeon: unify the creation of basic blocks

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

[Bug 98541] [bisected] gpu hang

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 98541
   Summary: [bisected] gpu hang
   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: mexahotabop at w1l.ru
QA Contact: dri-devel at lists.freedesktop.org

bisected in 1b6fb88ab2031a98ddf03a81f644b22a8f7e9428
no errors in logs 

hangs very random fasted way to reproduce that what i find its fast switch
between ships in star conflict

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

[PATCH v3] drm: bridge: add DesignWare HDMI I2S audio support

[Russell King - ARM Linux]

On Wed, Nov 02, 2016 at 01:18:35AM +, Kuninori Morimoto wrote:
> + platform = platform_device_register_full();
> + if (IS_ERR_OR_NULL(platform))
> + return PTR_ERR(platform);

This is wrong.  If platform is NULL, PTR_ERR() will return zero, which
will be interpreted as success.  Please, avoid using IS_ERR_OR_NULL(),
it leads to exactly this kind of cockup - and it's unnecessary here
because platform_device_register_full() does not return NULL.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[RFC PATCH] drm: define drm_compat_ioctl NULL on CONFIG_COMPAT=n and reduce #ifdefs

[Patrik Jakobsson]

On Tue, Nov 1, 2016 at 4:40 PM, Jani Nikula  wrote:
> If we define drm_compat_ioctl NULL on CONFIG_COMPAT=n, we don't have to
> check for the config everywhere.
>
> Signed-off-by: Jani Nikula 

Looks good and I like the idea.

Reviewed-by: Patrik Jakobsson 

> ---
>
> Just an idea on top of Patrik's patch.
> ---
>  drivers/gpu/drm/arc/arcpgu_drv.c|  2 --
>  drivers/gpu/drm/arm/hdlcd_drv.c |  2 --
>  drivers/gpu/drm/arm/malidp_drv.c|  2 --
>  drivers/gpu/drm/ast/ast_drv.c   |  2 --
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c|  2 --
>  drivers/gpu/drm/bochs/bochs_drv.c   |  2 --
>  drivers/gpu/drm/cirrus/cirrus_drv.c |  2 --
>  drivers/gpu/drm/drm_fops.c  | 13 ++---
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c   |  2 --
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |  2 --
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   |  2 --
>  drivers/gpu/drm/gma500/psb_drv.c|  2 --
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  2 --
>  drivers/gpu/drm/i810/i810_dma.c |  2 --
>  drivers/gpu/drm/i810/i810_drv.c |  2 --
>  drivers/gpu/drm/i915/i915_drv.c |  2 --
>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  2 --
>  drivers/gpu/drm/mgag200/mgag200_drv.c   |  2 --
>  drivers/gpu/drm/msm/msm_drv.c   |  2 --
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c   |  2 --
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  2 --
>  drivers/gpu/drm/savage/savage_drv.c |  2 --
>  drivers/gpu/drm/shmobile/shmob_drm_drv.c|  2 --
>  drivers/gpu/drm/sis/sis_drv.c   |  2 --
>  drivers/gpu/drm/sti/sti_drv.c   |  2 --
>  drivers/gpu/drm/sun4i/sun4i_drv.c   |  2 --
>  drivers/gpu/drm/tdfx/tdfx_drv.c |  2 --
>  drivers/gpu/drm/tegra/drm.c |  2 --
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c |  2 --
>  drivers/gpu/drm/udl/udl_drv.c   |  2 --
>  drivers/gpu/drm/vc4/vc4_drv.c   |  2 --
>  drivers/gpu/drm/via/via_drv.c   |  2 --
>  drivers/gpu/drm/virtio/virtgpu_drv.c|  2 --
>  include/drm/drmP.h  |  5 +
>  35 files changed, 13 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c 
> b/drivers/gpu/drm/arc/arcpgu_drv.c
> index 28e6471257d0..0b6eaa49a1db 100644
> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
> @@ -65,9 +65,7 @@ static const struct file_operations arcpgu_drm_ops = {
> .open = drm_open,
> .release = drm_release,
> .unlocked_ioctl = drm_ioctl,
> -#ifdef CONFIG_COMPAT
> .compat_ioctl = drm_compat_ioctl,
> -#endif
> .poll = drm_poll,
> .read = drm_read,
> .llseek = no_llseek,
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 6477d1a65266..59747ecaad54 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -268,9 +268,7 @@ static const struct file_operations fops = {
> .open   = drm_open,
> .release= drm_release,
> .unlocked_ioctl = drm_ioctl,
> -#ifdef CONFIG_COMPAT
> .compat_ioctl   = drm_compat_ioctl,
> -#endif
> .poll   = drm_poll,
> .read   = drm_read,
> .llseek = noop_llseek,
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 9f4739452a25..d53b625b14fe 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -197,9 +197,7 @@ static const struct file_operations fops = {
> .open = drm_open,
> .release = drm_release,
> .unlocked_ioctl = drm_ioctl,
> -#ifdef CONFIG_COMPAT
> .compat_ioctl = drm_compat_ioctl,
> -#endif
> .poll = drm_poll,
> .read = drm_read,
> .llseek = noop_llseek,
> diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
> index f54afd2113a9..fd7c9eec92e4 100644
> --- a/drivers/gpu/drm/ast/ast_drv.c
> +++ b/drivers/gpu/drm/ast/ast_drv.c
> @@ -188,9 +188,7 @@ static const struct file_operations ast_fops = {
> .unlocked_ioctl = drm_ioctl,
> .mmap = ast_mmap,
> .poll = drm_poll,
> -#ifdef CONFIG_COMPAT
> .compat_ioctl = drm_compat_ioctl,
> -#endif
> .read = drm_read,
>  };
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 9f6222895212..cbd0070265c9 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -749,9 +749,7 @@ static const struct file_operations fops = {
> .open   = drm_open,
> .release

[Bug 98293] Crash on Intel HSW when using multiple OpenGL contexts and X11 Display connections.

[bugzilla-dae...@freedesktop.org]

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

Matt Turner  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Matt Turner  ---


*** This bug has been marked as a duplicate of bug 91082 ***

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

[Bug 98505] [Topaz] Regression introduces in 4.8-rc3

[bugzilla-dae...@freedesktop.org]

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

--- Comment #9 from Nayan Deshmukh  ---
I will also try to the master branch of kernel to see if bug 98357 is gone

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

[Bug 98505] [Topaz] Regression introduces in 4.8-rc3

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from Nayan Deshmukh  ---
Comment on attachment 127678
  --> https://bugs.freedesktop.org/attachment.cgi?id=127678
amdgpu patch that checks whether the new interface can be used for PM

Review of attachment 127678:
-

::: drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
@@ +206,5 @@
>   atpx->is_hybrid = false;
>   if (valid_bits & ATPX_MS_HYBRID_GFX_SUPPORTED) {
>   printk("ATPX Hybrid Graphics\n");
> + /* Disable legacy PM methods only when pcie port PM is usable. 
> */
> + atpx->functions.power_cntl = 
> !amdgpu_atpx_priv->bridge_pm_usable;

With this replaced by 
atpx->functions.power_cntl = !amdgpu_atpx_priv.bridge_pm_usable;

The patch fixes the issue. :)

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

[PATCH 0/4 v2] Audio support for adv7511 hdmi bridge

[Kuninori Morimoto]

Hi John

> > Above patch is using normal simple-card style for HDMI sound, but as Laurent
> > said we want to use same DT style for HDMI video and sound (= OF graph 
> > style).
> > Fortunately, I posted patch-set for OF graph support on sound card 
> > yesterday.
> > Can you check this ?
> > http://www.spinics.net/lists/devicetree/msg146131.html
> > The points are
> >  - sound can use OF graph style DT
> >  - sound-card DT is no longer needed
> >  - it needs type = "sound" property
> >
> > patch-set [0/23] is this
> > http://www.spinics.net/lists/devicetree/msg146113.html
> 
> Thanks for the pointers! If I understand this correctly, the OF graph
> simple-card method would replace my current simple-card dts usage for
> hikey?   Other then just having another out-of-tree patchset to track,
> I don't have any objection to trying to use the OF graph simple-card
> method in the hikey dts (though I suspect I'll have to pester you for
> help when I give it a shot).

I posted v2 patchset OF graph simple-card which doesn't have "type" property.
Anyway, if you use OF graph simple-card, your "CPU" side driver need to
call asoc_simple_card_try_to_probe_graph_card() to probing it.

And this is not 100% mandatory, but your CPU and/or Codec driver
want to adjust OF graph style for parsing. The position is like this

simple-card :: dai-link <-> OF graph simple-card :: port/endpoint

[PATCH v3] drm: bridge: add DesignWare HDMI I2S audio support

[Kuninori Morimoto]

From: Kuninori Morimoto 

Current dw-hdmi is supporting sound via AHB bus, but it has
I2S audio feature too. This patch adds I2S audio support to dw-hdmi.
This HDMI I2S is supported by using ALSA SoC common HDMI encoder
driver.

Tested-by: Jose Abreu 
Signed-off-by: Kuninori Morimoto 
---
v2 -> v3

 - add .remove and call platform_device_unregister()
 - add missing Tested-by: Jose Abreu on log

 drivers/gpu/drm/bridge/Kconfig |   8 ++
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/dw-hdmi-audio.h |   7 ++
 drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c | 142 +
 drivers/gpu/drm/bridge/dw-hdmi.c   |  22 -
 drivers/gpu/drm/bridge/dw-hdmi.h   |  21 +
 6 files changed, 199 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 10e12e7..3129f8d 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -39,6 +39,14 @@ config DRM_DW_HDMI_AHB_AUDIO
  Designware HDMI block.  This is used in conjunction with
  the i.MX6 HDMI driver.

+config DRM_DW_HDMI_I2S_AUDIO
+   tristate "Synopsis Designware I2S Audio interface"
+   depends on DRM_DW_HDMI
+   select SND_SOC_HDMI_CODEC
+   help
+ Support the I2S Audio interface which is part of the Synopsis
+ Designware HDMI block.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index cdf3a3c..9a54f2a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
+obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
diff --git a/drivers/gpu/drm/bridge/dw-hdmi-audio.h 
b/drivers/gpu/drm/bridge/dw-hdmi-audio.h
index 91f631b..fd1f745 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi-audio.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi-audio.h
@@ -11,4 +11,11 @@ struct dw_hdmi_audio_data {
u8 *eld;
 };

+struct dw_hdmi_i2s_audio_data {
+   struct dw_hdmi *hdmi;
+
+   void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
+   u8 (*read)(struct dw_hdmi *hdmi, int offset);
+};
+
 #endif
diff --git a/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c 
b/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c
new file mode 100644
index 000..44880d8
--- /dev/null
+++ b/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c
@@ -0,0 +1,142 @@
+/*
+ * dw-hdmi-i2s-audio.c
+ *
+ * Copyright (c) 2016 Kuninori Morimoto 
+ *
+ * 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 "dw-hdmi.h"
+#include "dw-hdmi-audio.h"
+
+#define DRIVER_NAME "dw-hdmi-i2s-audio"
+
+static inline void hdmi_write(struct dw_hdmi_i2s_audio_data *audio,
+ u8 val, int offset)
+{
+   struct dw_hdmi *hdmi = audio->hdmi;
+
+   audio->write(hdmi, val, offset);
+}
+
+static inline u8 hdmi_read(struct dw_hdmi_i2s_audio_data *audio, int offset)
+{
+   struct dw_hdmi *hdmi = audio->hdmi;
+
+   return audio->read(hdmi, offset);
+}
+
+static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
+struct hdmi_codec_daifmt *fmt,
+struct hdmi_codec_params *hparms)
+{
+   struct dw_hdmi_i2s_audio_data *audio = data;
+   struct dw_hdmi *hdmi = audio->hdmi;
+   u8 conf0 = 0;
+   u8 conf1 = 0;
+   u8 inputclkfs = 0;
+
+   /* it cares I2S only */
+   if ((fmt->fmt != HDMI_I2S) ||
+   (fmt->bit_clk_master | fmt->frame_clk_master)) {
+   dev_err(dev, "unsupported format/settings\n");
+   return -EINVAL;
+   }
+
+   inputclkfs  = HDMI_AUD_INPUTCLKFS_64FS;
+   conf0   = HDMI_AUD_CONF0_I2S_ALL_ENABLE;
+
+   switch (hparms->sample_width) {
+   case 16:
+   conf1 = HDMI_AUD_CONF1_WIDTH_16;
+   break;
+   case 24:
+   case 32:
+   conf1 = HDMI_AUD_CONF1_WIDTH_24;
+   break;
+   }
+
+   dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
+
+   hdmi_write(audio, inputclkfs, HDMI_AUD_INPUTCLKFS);
+   hdmi_write(audio, conf0, HDMI_AUD_CONF0);
+   hdmi_write(audio, conf1, HDMI_AUD_CONF1);
+
+   dw_hdmi_audio_enable(hdmi);
+
+   return 0;
+}
+
+static void dw_hdmi_i2s_audio_shutdown(struct device 

[PATCH] drm/exynos: gsc: fix spelling mistakes

[Javier Martinez Canillas]

Hello Colin,

On 11/01/2016 11:23 PM, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fixes to spelling mistakes "precalser" to "prescaler"
> in dev_err messages
> 
> Signed-off-by: Colin Ian King 
> ---

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

[Bug 98505] [Topaz] Regression introduces in 4.8-rc3

[bugzilla-dae...@freedesktop.org]

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

--- Comment #7 from Peter Wu  ---
Created attachment 127678
  --> https://bugs.freedesktop.org/attachment.cgi?id=127678=edit
amdgpu patch that checks whether the new interface can be used for PM

PCIe port PM is not enabled because this BIOS is pre-2015: 12/04/2014
The BIOS seems to be able to report support for lots of things (can you post a
fuller dmesg that include the supported functions?):

Scope (\_SB.PCI0.GFX0) {
Method (ATPX, 2, Serialized) {
// ...
If (Arg0 == One) {
Name (TMP2, Buffer (0x0100) { 0x00 })
CreateWordField (TMP2, Zero, F1SS)
CreateDWordField (TMP2, 0x02, F1VM)
CreateDWordField (TMP2, 0x06, F1FG)
F1SS = 0x0A
F1VM = 0x7FC0
If ((\_SB.PCI0.RP05.PXSX.SGMD & 0x0F) == 0x02) {
// ...
If (\_SB.PCI0.RP05.PXSX.PXDY == One) {
F1FG |= 0x80 /* ATPX_DYNAMIC_PX_SUPPORTED */
F1VM |= 0x80
}
//
If (\_SB.PCI0.RP05.PXSX.FDPD == One) {
F1FG |= 0x0400 /* ATPX_DYNAMIC_DGPU_POWER_OFF_SUPPORTED
*/
F1VM |= 0x0400
If (OSYS >= 0x07DC) {
F1FG |= 0x0800 /* ATPX_DGPU_REQ_POWER_FOR_DISPLAYS
*/
F1VM |= 0x0800
}
}
// ...
If (OSYS >= 0x07DD) {
F1FG |= 0x4000 /* ATPX_MS_HYBRID_GFX_SUPPORTED */ 
F1VM |= 0x4000
}

amdgpu (and radeon) needs to check whether PCIe port PM is really supported.
Possible patch is attached (there should probably be a pci_d3cold_disable call
somewhere, see commit 279cf3f23870f7eb8ca071115e06d3d5ca0a2b9e for nouveau).

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