-next trees

-next trees

[Dave Airlie]

Hey all,

Back from a week off, I've hoovered up everything and backmerged -rc8 on top.

If I've missed anything please let me know, I haven't seen next trees
for exynos or nouveau, as possibly a few others, but those are the
main two I noticed.

Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -next trees

[Alex Deucher]

On Tue, Sep 27, 2016 at 11:31 PM, Dave Airlie <airlied@gmail.com> wrote:
> Hey all,
>
> Back from a week off, I've hoovered up everything and backmerged -rc8 on top.
>
> If I've missed anything please let me know, I haven't seen next trees
> for exynos or nouveau, as possibly a few others, but those are the
> main two I noticed.

Just one last set of bug fixes I sent out a few minutes ago.

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -next trees

[Daniel Vetter]

On Wed, Sep 28, 2016 at 05:07:04PM -0400, Alex Deucher wrote:
> On Tue, Sep 27, 2016 at 11:31 PM, Dave Airlie <airlied@gmail.com> wrote:
> > Hey all,
> >
> > Back from a week off, I've hoovered up everything and backmerged -rc8 on top.
> >
> > If I've missed anything please let me know, I haven't seen next trees
> > for exynos or nouveau, as possibly a few others, but those are the
> > main two I noticed.
> 
> Just one last set of bug fixes I sent out a few minutes ago.

I realized that I've forgotten the generic pipe crc work from Tomeu. One
more -misc pull for that I guess.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -next trees

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 646 bytes --]

On Wed, Sep 28, 2016 at 01:31:36PM +1000, Dave Airlie wrote:
> Hey all,
> 
> Back from a week off, I've hoovered up everything and backmerged -rc8 on top.
> 
> If I've missed anything please let me know, I haven't seen next trees
> for exynos or nouveau, as possibly a few others, but those are the
> main two I noticed.

Bad timing with my vacation this time. I just sent out a single fix pull
request for Tegra that I had wanted to send out before the vacation but
forgot.

I also sent out a drm/panel pull request earlier. Nothing major there,
just updates and one new driver, all cooked in linux-next for two weeks.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -next trees

[Daniel Vetter]

On Wed, Sep 26, 2012 at 04:04:43PM -0500, Ian Pilcher wrote:
> On 09/26/2012 12:00 PM, Adam Jackson wrote:
> >On Tue, 2012-09-25 at 13:47 -0500, Ian Pilcher wrote:
> >>
> >>1.  The display (LG L246WP) is confused by *any* InfoFrames.
> >
> >If this is still the case after applying:
> >
> >commit adf00b26d18e1b3570451296e03bcb20e4798cdd
> >Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >Date:   Tue Sep 25 13:23:34 2012 -0300
> >
> >     drm/i915: make sure we write all the DIP data bytes
> >
> >Then I suspect I'm compelled to agree that we need a quirk to forcibly
> >disable InfoFrames entirely.  I don't like to be difficult about this,
> >but the HDMI spec is quite clear that sinks _must_ accept InfoFrames
> >defined in either the CEA or HDMI specs, so if we're seeing that class
> >of failure I tend to strongly suspect our drivers first.
> 
> I just tested with that patch applied, and the problem still exists, so
> consider yourself compelled.
> 
> Unless you object, I will go ahead and create a patch series that does
> only:
> 
> - user-defined EDID quirks
> - DISABLE_INFOFRAMES quirk
> - DISABLE_INFOFRAMES quirk for LG L246WP
> 
> (I will specifically *not* address the audio issue in this series.)
> 
> >>3.  drm_detect_monitor_audio is returning true for the LG L246WP, which
> >>      definitely doesn't have any audio capabilities.  This may be a bug
> >>      in the display's EDID, or it may be a parsing error.
> >
> >The display is definitely a filthy liar then:
> >
> >   Audio data block
> >     Linear PCM, max channels 1
> >     Supported sample rates (kHz): 48 44.1 32
> >     Supported sample sizes (bits): 24 20 16
> >
> >Hooray for hardware.  Not sure what the logic should be for whether to
> >send HDMI audio or not, I'll re-read the appropriate scrolls.
> 
> Well, if hardware didn't suck we wouldn't need quirks.
> 
> If you'd like, I can generate a second patch series that adds some or
> all of:
> 
> - NO_AUDIO quirk
> - drm_monitor_has_hdmi_audio() function

I've volunteered Antti from our team to implement this (and to patch up
drm/i915), so this should happen already and with the above no infoframes
quirks we shouldn't need any additional quirks.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: -next trees

[Ian Pilcher]

On 09/26/2012 12:00 PM, Adam Jackson wrote:
> On Tue, 2012-09-25 at 13:47 -0500, Ian Pilcher wrote:
>>
>> 1.  The display (LG L246WP) is confused by *any* InfoFrames.
>
> If this is still the case after applying:
>
> commit adf00b26d18e1b3570451296e03bcb20e4798cdd
> Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Date:   Tue Sep 25 13:23:34 2012 -0300
>
>      drm/i915: make sure we write all the DIP data bytes
>
> Then I suspect I'm compelled to agree that we need a quirk to forcibly
> disable InfoFrames entirely.  I don't like to be difficult about this,
> but the HDMI spec is quite clear that sinks _must_ accept InfoFrames
> defined in either the CEA or HDMI specs, so if we're seeing that class
> of failure I tend to strongly suspect our drivers first.

I just tested with that patch applied, and the problem still exists, so
consider yourself compelled.

Unless you object, I will go ahead and create a patch series that does
only:

- user-defined EDID quirks
- DISABLE_INFOFRAMES quirk
- DISABLE_INFOFRAMES quirk for LG L246WP

(I will specifically *not* address the audio issue in this series.)

>> 3.  drm_detect_monitor_audio is returning true for the LG L246WP, which
>>       definitely doesn't have any audio capabilities.  This may be a bug
>>       in the display's EDID, or it may be a parsing error.
>
> The display is definitely a filthy liar then:
>
>    Audio data block
>      Linear PCM, max channels 1
>      Supported sample rates (kHz): 48 44.1 32
>      Supported sample sizes (bits): 24 20 16
>
> Hooray for hardware.  Not sure what the logic should be for whether to
> send HDMI audio or not, I'll re-read the appropriate scrolls.

Well, if hardware didn't suck we wouldn't need quirks.

If you'd like, I can generate a second patch series that adds some or
all of:

- NO_AUDIO quirk
- drm_monitor_has_hdmi_audio() function
- NO_AUDIO quirk for LG L246WP (kind of redundant if no InfoFrames are
   being sent anyway, but still technically accurate)

Let me know if you'd like any or all of those.

Thanks!

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
========================================================================

Re: -next trees

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 1401 bytes --]

On Tue, 2012-09-25 at 13:47 -0500, Ian Pilcher wrote:

> In the meantime, I would like to move the ball forward on this issue.
> As I see it, there 3 issues that have become conflated:
> 
> 1.  The display (LG L246WP) is confused by *any* InfoFrames.

If this is still the case after applying:

commit adf00b26d18e1b3570451296e03bcb20e4798cdd
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Tue Sep 25 13:23:34 2012 -0300

    drm/i915: make sure we write all the DIP data bytes

Then I suspect I'm compelled to agree that we need a quirk to forcibly
disable InfoFrames entirely.  I don't like to be difficult about this,
but the HDMI spec is quite clear that sinks _must_ accept InfoFrames
defined in either the CEA or HDMI specs, so if we're seeing that class
of failure I tend to strongly suspect our drivers first.

> 3.  drm_detect_monitor_audio is returning true for the LG L246WP, which
>      definitely doesn't have any audio capabilities.  This may be a bug
>      in the display's EDID, or it may be a parsing error.

The display is definitely a filthy liar then:

  Audio data block
    Linear PCM, max channels 1
    Supported sample rates (kHz): 48 44.1 32
    Supported sample sizes (bits): 24 20 16

Hooray for hardware.  Not sure what the logic should be for whether to
send HDMI audio or not, I'll re-read the appropriate scrolls.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -next trees

[Ian Pilcher]

[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]

On 09/24/2012 09:34 AM, Adam Jackson wrote:
> I'm sorry, I thought I was clearer.  Daniel posted a patch to fix the
> Intel driver for this:
>
> http://lists.freedesktop.org/archives/intel-gfx/2012-August/020046.html
>
> Which I didn't entirely ack, but which is essentially right.  That's
> what we should do; and having done so, if I understand things correctly,
> there's no need for any quirks here at all.
>
> Is there something I'm missing?


Yes.  The DISABLE_INFOFRAMES quirk will still be required by this
display.

(The reason that the Intel driver got dragged into this is because it is
sending audio InfoFrames to the display, even when
drm_detect_hdmi_monitor returns false.)

> I haven't actually seen the EDID block for this display, I don't
> believe, so I'm not sure whether the "non-existent" part of this is even
> accurate, or whether we're just parsing things incorrectly.  There's a
> reason I keep a standalone parser around.

EDID attached.

In the meantime, I would like to move the ball forward on this issue.
As I see it, there 3 issues that have become conflated:

1.  The display (LG L246WP) is confused by *any* InfoFrames.

2.  The Intel driver is sending audio InfoFrames when
     drm_detect_hdmi_monitor returns false and drm_detect_monitor_audio
     returns true.

3.  drm_detect_monitor_audio is returning true for the LG L246WP, which
     definitely doesn't have any audio capabilities.  This may be a bug
     in the display's EDID, or it may be a parsing error.

Would you be amenable to a patch series that addresses *only* issue
number 1?

Thanks!

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
========================================================================

[-- Attachment #2: edid.bin --]
[-- Type: application/octet-stream, Size: 256 bytes --]

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -next trees

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 1271 bytes --]

On Sat, 2012-09-22 at 23:34 -0500, Ian Pilcher wrote:
> On 09/12/2012 08:44 PM, Dave Airlie wrote:
> > Ajax, I think Ian still has an open request on how to proceed with the
> > infoframes quirk nightmare.
> 
> Indeed.

I'm sorry, I thought I was clearer.  Daniel posted a patch to fix the
Intel driver for this:

http://lists.freedesktop.org/archives/intel-gfx/2012-August/020046.html

Which I didn't entirely ack, but which is essentially right.  That's
what we should do; and having done so, if I understand things correctly,
there's no need for any quirks here at all.

Is there something I'm missing?

But also:

> > * Leave both flags, because both are accurate.  The display is confused
> >   by any InfoFrames (audio or AVI), and it is reporting non-existent
> >   audio capabilities.  The fact that the combination of the two flags
> >   makes the display work with Intel GPUs is a happy/sad/neutral
> >   accident, and the driver's behavior is still considered broken.

I haven't actually seen the EDID block for this display, I don't
believe, so I'm not sure whether the "non-existent" part of this is even
accurate, or whether we're just parsing things incorrectly.  There's a
reason I keep a standalone parser around.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -next trees

[Ian Pilcher]

On 09/12/2012 08:44 PM, Dave Airlie wrote:
> Ajax, I think Ian still has an open request on how to proceed with the
> infoframes quirk nightmare.

Indeed.

On 08/30/2012 12:23 AM, Ian Pilcher wrote:
> In terms of moving forward with the rest of the EDID quirk stuff, are
> you OK with either of these options:
>
> * Remove EDID_QUIRK_NO_AUDIO from the flags for the LG L246WP.  It won't
>   work "out of the box" with the Intel driver until that driver is
>   fixed to not send audio InfoFrames to non-HDMI displays (but anyone
>   who has the combination will be able to add their own quirk to make
>   it work).
>
> * Leave both flags, because both are accurate.  The display is confused
>   by any InfoFrames (audio or AVI), and it is reporting non-existent
>   audio capabilities.  The fact that the combination of the two flags
>   makes the display work with Intel GPUs is a happy/sad/neutral
>   accident, and the driver's behavior is still considered broken.
>
>   (Essentially, this would mean just editing the comments to reflect the
>   above reasoning.)

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
========================================================================

Re: -next trees

[Paul Menzel]

[-- Attachment #1.1: Type: text/plain, Size: 752 bytes --]

Am Donnerstag, den 13.09.2012, 11:44 +1000 schrieb Dave Airlie:
> Just a reminder to the subtree maintainers that I should be starting
> to see signs of -next trees lining up soon,
> 
> I've merged a bunch of patches from the list, but I'm sure I've forgotten some,
> I've got the 3 quirks from Paul that I'm iffy about due to the lack of
> testing against VGA ports that ajax requested, but I could be turned.

I am really sorry, but it looks like more testing is needed, so please
revert them. :/

Testing on a T60 shows that it works out of the box. So it is either
915GM or cable problem. [1]

I will answer to the single patches later on.

[…]


Thanks,

Paul


[1] https://bugs.freedesktop.org/show_bug.cgi?id=53544#c5

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -next trees

[Rob Clark]

On Wed, Sep 12, 2012 at 8:44 PM, Dave Airlie <airlied@gmail.com> wrote:
> Just a reminder to the subtree maintainers that I should be starting
> to see signs of -next trees lining up soon,
>
> I've merged a bunch of patches from the list, but I'm sure I've forgotten some,
> I've got the 3 quirks from Paul that I'm iffy about due to the lack of
> testing against VGA ports that ajax requested, but I could be turned.

What about:

  drm: support for rotated scanout
  drm: refcnt drm_framebuffer
  drm: change ioctl permissions

BR,
-R

> Ajax, I think Ian still has an open request on how to proceed with the
> infoframes quirk nightmare.
>
> Alex, Christian, Jerome: would be good to resolve that fence issue for
> -fixes asap.
>
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -next trees

[Alex Deucher]

On Wed, Sep 12, 2012 at 9:44 PM, Dave Airlie <airlied@gmail.com> wrote:
> Just a reminder to the subtree maintainers that I should be starting
> to see signs of -next trees lining up soon,
>
> I've merged a bunch of patches from the list, but I'm sure I've forgotten some,
> I've got the 3 quirks from Paul that I'm iffy about due to the lack of
> testing against VGA ports that ajax requested, but I could be turned.
>
> Ajax, I think Ian still has an open request on how to proceed with the
> infoframes quirk nightmare.
>
> Alex, Christian, Jerome: would be good to resolve that fence issue for
> -fixes asap.

-fixes request sent.  I've also got a wip -next tree here:
http://cgit.freedesktop.org/~agd5f/linux/?h=drm-next-3.7-wip
If anyone has any additional outstanding radeon patches they want in
3.7, let me know.  Christian, you might want to double check the last
set of VM patches, I had to make a minor adjustment to the last one
due to skipping 7/8.

Alex


>
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-next trees

[Dave Airlie]

Just a reminder to the subtree maintainers that I should be starting
to see signs of -next trees lining up soon,

I've merged a bunch of patches from the list, but I'm sure I've forgotten some,
I've got the 3 quirks from Paul that I'm iffy about due to the lack of
testing against VGA ports that ajax requested, but I could be turned.

Ajax, I think Ian still has an open request on how to proceed with the
infoframes quirk nightmare.

Alex, Christian, Jerome: would be good to resolve that fence issue for
-fixes asap.

Dave.