[Intel-gfx] [PATCH 11/9] drm/i915: Opt out of vblank disable timer on >gen2

[Ville Syrjälä]

On Thu, Nov 19, 2015 at 10:53:30PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 19, 2015 at 06:35:04PM -0200, Paulo Zanoni wrote:
> > 2015-11-19 18:06 GMT-02:00 Ville Syrjälä  > linux.intel.com>:
> > > On Thu, Nov 19, 2015 at 05:44:51PM -0200, Paulo Zanoni wrote:
> > >> 2014-05-26 11:26 GMT-03:00  :
> > >> > From: Ville Syrjälä 
> > >> >
> > >> > Now that the vblank races are plugged, we can opt out of using
> > >> > the vblank disable timer and just let vblank interrupts get
> > >> > disabled immediately when the last reference is dropped.
> > >> >
> > >> > Gen2 is the exception since it has no hardware frame counter.
> > >>
> > >> Hi
> > >>
> > >> Remember last week's FBC vblank optimization patch that had an
> > >> erroneous drm_crtc_vblank_get() instead of drm_crtc_vblank_count()?
> > >> After I fixed the bug in the patch I realized that it was the
> > >> unbalanced vblank_get() call that moved PC state residency up.
> > >>
> > >> I did some experiments, and on my specific BDW machine, after running
> > >> "powertop --auto-tune", I get about 15-25% PC7 residency without FBC.
> > >> If I revert this patch, the number jumps to 40-45%. With FBC, the PC7
> > >> residency goes from 60-70% to 85-90% when I revert this patch. I'm
> > >> running just an idle Cinnamon with an open terminal.
> > >>
> > >> So, since the commit message lacks more details, what are the
> > >> downsides of reverting this patch? What are the advantages of opting
> > >> out of the vblank timer? I see my desktop does tons and tons of vblank
> > >> get/put calls per second, so the disable timer makes a lot of sense.
> > >
> > > "Idle" desktop :(
> > 
> > My first realization of this little problem was when I was
> > implementing runtime PM :)
> > 
> > 
> > >
> > > Really the immediate disable should save power. Where are these tons of
> > > vblank get/puts coming from actually?
> > 
> > I'll take a finer look tomorrow, but I assume it's probably some
> > application redrawing. I see it does calm down sometimes, but that's
> > not enough to get better PC7 residency.
> > 
> > 
> > > I would assume you'd get a handful
> > > per frame at most, and that when you're actually doing something. On an
> > > idle system I would expect nothing at all happens during most frames.
> > >
> > > Not sure, but I guess it's possible the extra register accesses in the
> > > get/puts actually cause the display to exit low power states all the time,
> > > or something.
> > 
> > I tried replacing the register macros with the _FW version and that didn't 
> > help.
> 
> Well, that would just get rid of the unclaimed reg checks. Nothing more
> I think.
> 
> > 
> > 
> > >
> > > There's also this note in Bspec (for HSW at least):
> > 
> > I think this not is present on most (all?) gens.
> 
> Doesn't really prove anything.
> 
> > >  "Workaround : Do not enable and unmask this interrupt if the associated
> > >   pipe is disabled.  Do not leave this interrupt enabled and unmasked
> > >   after the associated pipe is disabled."
> > > which we took to mean that having the interrupt masked but enabled is
> > > fine.
> > 
> > I'm aware of this, but I think the problem is that the resources
> > drained by the constant enable+disable+enable+disable outweigh the
> > resources saved by turning off vblanks.
> 
> Well the CPU is awake anyway doing the get/put, so not sure why a a few
> extra register accesses there would have such a huge impact.
> 
> > Not sure if there's an extra
> > reason why BSpec asks us to immediately disable vblanks though...
> > 
> > So, to summarize, the main (only?) reason is the BSpec comment?
> 
> The point is not to wake up due to interrupts when we don't need them.
> 
> > 
> > 
> > > But maybe we'd actually have to frob IER too to avoid wasting
> > > power somehow?
> > 
> > With the interrupt masked on IMR, I don't think IER matters.
> 
> I'm not sure anyone actually verified that.

Well, I just tried this on HSW. And on that one IER didn't make a
difference to pc7 residency (~70%) at least. This was on an actually
idle system ;)

> 
> > 
> > >
> > >> I also wish there was some easy way to check how this patch (or its
> > >> revert) affect a bunch of different workloads...
> > >>
> > >> (Also CCing Chris for insightful comments on performance)
> > >
> > > IIRC Chris had a patch to not disable the interrupt immediately when
> > > the refcount drops to 0, but instead delay the disable until the next
> > > interrupt actually happens. But I guess it didn't go in? Probably I
> > > should have reviewed it but didn't. It sounds like a decent idea to
> > > me in any case for the active use case.
> > >
> > >>
> > >> Thanks,
> > >> Paulo
> > >>
> > >> >
> > >> > Signed-off-by: Ville Syrjälä 
> > >> > ---
> > >> >  drivers/gpu/drm/i915/i915_irq.c | 8 
> > >> >  1 file changed, 8 insertions(+)
> > >> >
> > >> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > >> > b/drivers/gpu/drm/i915/i915_irq.c
> > >> > index 28bae6e..4b2e7af 100644
> > >> > 

[Intel-gfx] [PATCH 11/9] drm/i915: Opt out of vblank disable timer on >gen2

[Ville Syrjälä]

On Thu, Nov 19, 2015 at 06:35:04PM -0200, Paulo Zanoni wrote:
> 2015-11-19 18:06 GMT-02:00 Ville Syrjälä :
> > On Thu, Nov 19, 2015 at 05:44:51PM -0200, Paulo Zanoni wrote:
> >> 2014-05-26 11:26 GMT-03:00  :
> >> > From: Ville Syrjälä 
> >> >
> >> > Now that the vblank races are plugged, we can opt out of using
> >> > the vblank disable timer and just let vblank interrupts get
> >> > disabled immediately when the last reference is dropped.
> >> >
> >> > Gen2 is the exception since it has no hardware frame counter.
> >>
> >> Hi
> >>
> >> Remember last week's FBC vblank optimization patch that had an
> >> erroneous drm_crtc_vblank_get() instead of drm_crtc_vblank_count()?
> >> After I fixed the bug in the patch I realized that it was the
> >> unbalanced vblank_get() call that moved PC state residency up.
> >>
> >> I did some experiments, and on my specific BDW machine, after running
> >> "powertop --auto-tune", I get about 15-25% PC7 residency without FBC.
> >> If I revert this patch, the number jumps to 40-45%. With FBC, the PC7
> >> residency goes from 60-70% to 85-90% when I revert this patch. I'm
> >> running just an idle Cinnamon with an open terminal.
> >>
> >> So, since the commit message lacks more details, what are the
> >> downsides of reverting this patch? What are the advantages of opting
> >> out of the vblank timer? I see my desktop does tons and tons of vblank
> >> get/put calls per second, so the disable timer makes a lot of sense.
> >
> > "Idle" desktop :(
> 
> My first realization of this little problem was when I was
> implementing runtime PM :)
> 
> 
> >
> > Really the immediate disable should save power. Where are these tons of
> > vblank get/puts coming from actually?
> 
> I'll take a finer look tomorrow, but I assume it's probably some
> application redrawing. I see it does calm down sometimes, but that's
> not enough to get better PC7 residency.
> 
> 
> > I would assume you'd get a handful
> > per frame at most, and that when you're actually doing something. On an
> > idle system I would expect nothing at all happens during most frames.
> >
> > Not sure, but I guess it's possible the extra register accesses in the
> > get/puts actually cause the display to exit low power states all the time,
> > or something.
> 
> I tried replacing the register macros with the _FW version and that didn't 
> help.

Well, that would just get rid of the unclaimed reg checks. Nothing more
I think.

> 
> 
> >
> > There's also this note in Bspec (for HSW at least):
> 
> I think this not is present on most (all?) gens.

Doesn't really prove anything.

> >  "Workaround : Do not enable and unmask this interrupt if the associated
> >   pipe is disabled.  Do not leave this interrupt enabled and unmasked
> >   after the associated pipe is disabled."
> > which we took to mean that having the interrupt masked but enabled is
> > fine.
> 
> I'm aware of this, but I think the problem is that the resources
> drained by the constant enable+disable+enable+disable outweigh the
> resources saved by turning off vblanks.

Well the CPU is awake anyway doing the get/put, so not sure why a a few
extra register accesses there would have such a huge impact.

> Not sure if there's an extra
> reason why BSpec asks us to immediately disable vblanks though...
> 
> So, to summarize, the main (only?) reason is the BSpec comment?

The point is not to wake up due to interrupts when we don't need them.

> 
> 
> > But maybe we'd actually have to frob IER too to avoid wasting
> > power somehow?
> 
> With the interrupt masked on IMR, I don't think IER matters.

I'm not sure anyone actually verified that.

> 
> >
> >> I also wish there was some easy way to check how this patch (or its
> >> revert) affect a bunch of different workloads...
> >>
> >> (Also CCing Chris for insightful comments on performance)
> >
> > IIRC Chris had a patch to not disable the interrupt immediately when
> > the refcount drops to 0, but instead delay the disable until the next
> > interrupt actually happens. But I guess it didn't go in? Probably I
> > should have reviewed it but didn't. It sounds like a decent idea to
> > me in any case for the active use case.
> >
> >>
> >> Thanks,
> >> Paulo
> >>
> >> >
> >> > Signed-off-by: Ville Syrjälä 
> >> > ---
> >> >  drivers/gpu/drm/i915/i915_irq.c | 8 
> >> >  1 file changed, 8 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >> > b/drivers/gpu/drm/i915/i915_irq.c
> >> > index 28bae6e..4b2e7af 100644
> >> > --- a/drivers/gpu/drm/i915/i915_irq.c
> >> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> > @@ -4364,6 +4364,14 @@ void intel_irq_init(struct drm_device *dev)
> >> > dev->max_vblank_count = 0xff; /* only 24 bits of 
> >> > frame count */
> >> > }
> >> >
> >> > +   /*
> >> > +* Opt out of the vblank disable timer on everything except gen2.
> >> > +* Gen2 doesn't have a hardware frame counter and so depends on
> >> > +* vblank 

Funky new vblank counter regressions in Linux 4.4-rc1

[Alex Deucher]

On Thu, Nov 19, 2015 at 12:46 PM, Mario Kleiner
 wrote:
> Hi Alex and Michel and Ville,
>
> it's "fix vblank stuff" time again ;-)

Adding Harry from our display team.  He might be able to fill in the
blanks of on some of this better than I can.  It might also be worth
checking to see how our DAL (our new display code which is being
developed directly by our display team) code handles this.  It could
be that we are just missing register settings:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=DAL-wip
Additionally we've published full registers headers for the display block:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/include/asic_reg/dce
The DCE8 stuff should generally apply back to DCE4.  If you have
questions about registers older asics not covered in the hw docs, let
me know.  Note the new headers are dword aligned rather than byte
aligned.

>
> Ville's changes to the DRM's drm_handle_vblank() / drm_update_vblank_count()
> code in Linux 4.4 not only made that code more elegant, but also removed the
> robustness against the vblank irq quirks in AMD hw and similar hardware. So
> now i get tons of off-by-one errors and
>
> "[   432.345] (WW) RADEON(1): radeon_dri2_flip_event_handler: Pageflip
> completion event has impossible msc 24803 < target_msc 24804" XOrg messages
> from that kernel.
>
> One of the reasons for trouble is that AMD hw quirk where the hw fires an
> extra vblank irq shortly after vblank irq's get enabled, not synchronized to
> vblank, but typically in the middle of active scanout, so we get a redundant
> call to drm_handle_vblank in the middle of scanout.
>
> To fix that i have a minor patch to make drm_update_vblank_count() again
> robust against such redundant calls, which i will send out later to the
> mailing list. Diff attached for reference.
>
> The second quirk of AMD hw is that the vblank interrupt fires a few
> scanlines before start of vblank, so drm_handle_vblank ->
> drm_update_vblank_count() -> dev->driver->get_vblank_counter() gets called
> before the start of the vblank for which the new vblank count should be
> queried.
>
> The third problem is that the DRM vblank handling always had the assumption
> that hardware vblank counters would essentially increment at leading edge of
> vblank - basically in sync with the firing of the vblank irq, so that a hw
> counter readout from within the vblank irq handler would always deliver the
> new incremented value. If this assumption is violated then the counting by
> use of the hw counter gets unreliable, because depending on random small
> delays in irq handling the code may end up sampling the hw counter pre- or
> post-increment, leading to inconsistent updating and funky bugs. It just so
> happens that AMD hardware doesn't increment the hw counter at leading edge
> of vblank, so stuff falls apart.
>
> So to fix those two problems i'm tinkering with cooking the hw vblank
> counter value returned by radeon_get_vblank_counter_kms() to make it appear
> as if the counter incremented at leading edge of vblank in sync with vblank
> irq.
>
> It almost sort of works on the rs600 code path, but i need a bit of info
> from you:
>
> 1. There's this register from the old specs for m76.pdf, which is not part
> of the current register defines for radeon-kms:
>
> "D1CRTC_STATUS_VF_COUNT - RW - 32 bits - [GpuF0MMReg:0x60A8]"
>
> It contains the lower 16 bits of framecounter and the 13 bits of vertical
> scanout position. It seems to give the same readings as the 24 bit
> R_0060A4_D1CRTC_STATUS_FRAME_COUNT we use for the hw counter. This would
> come handy.
>
> Does Evergreen and later have a same/similar register and where is it?

Yes.  CRTC_STATUS_VF_COUNT

CRTC:CRTC_STATUS_VF_COUNT  ·  [R/W]  ·  32 bits  ·  Access: 8/16/32  ·
 [INST0] GpuF0MMReg:0x6e9c, [INST1] GpuF0MMReg:0x7a9c, [INST2]
GpuF0MMReg:0x1069c, [INST3] GpuF0MMReg:0x1129c, [INST4]
GpuF0MMReg:0x11e9c, [INST5] GpuF0MMReg:0x12a9c
DESCRIPTION: Current composite vertical and frame count for CRTC
Field Name   BitsDefault   Description
CRTC_VF_COUNT
(Access: R)28:00x0Reports current vertical and frame count

>
> 2. The hw framecounter seems to increment when the vertical scanout position
> wraps back from (VTOTAL - 1) to 0, at least on the one DCE-3 gpu i tested so
> far. Is this so on all asics? And is the hw counter increment happening
> exactly at the moment that vertical scanout position jumps back to zero, ie.
> both events are driven by the same signal? Or is the framecounter increment
> just happening somewhere inside either scanline VTOTAL-1 or scanline 0?

Unless Harry knows, we can ask the hw team, but I doubt they would
have changed it.  I think it's tied to the start line which is
controlled by this register:
CRTC:CRTC_START_LINE_CONTROL  ·  [R/W]  ·  32 bits  ·  Access: 8/16/32
 ·  [INST0] GpuF0MMReg:0x6ecc, [INST1] GpuF0MMReg:0x7acc, [INST2]
GpuF0MMReg:0x106cc, [INST3] GpuF0MMReg:0x112cc, [INST4]

[Intel-gfx] [PATCH 11/9] drm/i915: Opt out of vblank disable timer on >gen2

[Ville Syrjälä]

On Thu, Nov 19, 2015 at 05:44:51PM -0200, Paulo Zanoni wrote:
> 2014-05-26 11:26 GMT-03:00  :
> > From: Ville Syrjälä 
> >
> > Now that the vblank races are plugged, we can opt out of using
> > the vblank disable timer and just let vblank interrupts get
> > disabled immediately when the last reference is dropped.
> >
> > Gen2 is the exception since it has no hardware frame counter.
> 
> Hi
> 
> Remember last week's FBC vblank optimization patch that had an
> erroneous drm_crtc_vblank_get() instead of drm_crtc_vblank_count()?
> After I fixed the bug in the patch I realized that it was the
> unbalanced vblank_get() call that moved PC state residency up.
> 
> I did some experiments, and on my specific BDW machine, after running
> "powertop --auto-tune", I get about 15-25% PC7 residency without FBC.
> If I revert this patch, the number jumps to 40-45%. With FBC, the PC7
> residency goes from 60-70% to 85-90% when I revert this patch. I'm
> running just an idle Cinnamon with an open terminal.
> 
> So, since the commit message lacks more details, what are the
> downsides of reverting this patch? What are the advantages of opting
> out of the vblank timer? I see my desktop does tons and tons of vblank
> get/put calls per second, so the disable timer makes a lot of sense.

"Idle" desktop :(

Really the immediate disable should save power. Where are these tons of
vblank get/puts coming from actually? I would assume you'd get a handful
per frame at most, and that when you're actually doing something. On an
idle system I would expect nothing at all happens during most frames.

Not sure, but I guess it's possible the extra register accesses in the
get/puts actually cause the display to exit low power states all the time,
or something.

There's also this note in Bspec (for HSW at least):
 "Workaround : Do not enable and unmask this interrupt if the associated
  pipe is disabled.  Do not leave this interrupt enabled and unmasked
  after the associated pipe is disabled."
which we took to mean that having the interrupt masked but enabled is
fine. But maybe we'd actually have to frob IER too to avoid wasting
power somehow?

> I also wish there was some easy way to check how this patch (or its
> revert) affect a bunch of different workloads...
> 
> (Also CCing Chris for insightful comments on performance)

IIRC Chris had a patch to not disable the interrupt immediately when
the refcount drops to 0, but instead delay the disable until the next
interrupt actually happens. But I guess it didn't go in? Probably I
should have reviewed it but didn't. It sounds like a decent idea to
me in any case for the active use case.

> 
> Thanks,
> Paulo
> 
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 28bae6e..4b2e7af 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -4364,6 +4364,14 @@ void intel_irq_init(struct drm_device *dev)
> > dev->max_vblank_count = 0xff; /* only 24 bits of frame 
> > count */
> > }
> >
> > +   /*
> > +* Opt out of the vblank disable timer on everything except gen2.
> > +* Gen2 doesn't have a hardware frame counter and so depends on
> > +* vblank interrupts to produce sane vblank seuquence numbers.
> > +*/
> > +   if (!IS_GEN2(dev))
> > +   dev->vblank_disable_immediate = true;
> > +
> > if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> > dev->driver->get_vblank_timestamp = 
> > i915_get_vblank_timestamp;
> > dev->driver->get_scanout_position = 
> > i915_get_crtc_scanoutpos;
> > --
> > 1.8.5.5
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
> 
> -- 
> Paulo Zanoni

-- 
Ville Syrjälä
Intel OTC

Funky new vblank counter regressions in Linux 4.4-rc1

[Ville Syrjälä]

On Thu, Nov 19, 2015 at 08:12:24PM +0100, Mario Kleiner wrote:
> On 11/19/2015 07:20 PM, Ville Syrjälä wrote:
> > On Thu, Nov 19, 2015 at 06:46:28PM +0100, Mario Kleiner wrote:
> >> Hi Alex and Michel and Ville,
> >>
> >> it's "fix vblank stuff" time again ;-)
> >>
> >> Ville's changes to the DRM's drm_handle_vblank() /
> >> drm_update_vblank_count() code in Linux 4.4 not only made that code more
> >> elegant, but also removed the robustness against the vblank irq quirks
> >> in AMD hw and similar hardware. So now i get tons of off-by-one errors and
> >>
> >> "[   432.345] (WW) RADEON(1): radeon_dri2_flip_event_handler: Pageflip
> >> completion event has impossible msc 24803 < target_msc 24804" XOrg
> >> messages from that kernel.
> >
> > Argh. Sorry about that.
> >
> 
> On the plus side, your "vblank timestamp deltas as fake vblank counters" 
> code seems to work nicely on nouveau-kms, as far as testing with three 
> Nvidia's went so far :). And both Intel gpu's (HD Ironlake, and 
> Ivybridge) i tested checked out nicely.
> 
> And at least the recent nv50+ NVidia Tesla also have 16 bit vblank 
> counters which we could implement in nouveau, maybe with the same 
> trickery to allow long trouble-free vblank off periods, hopefully that 
> would also apply to the Tegra-4 and later Kepler based parts. Tegra-3 
> will probably also work. I think i read in the Tegra-3 PRM that the sync 
> points they use to implement vblank counters do increment at leading 
> edge of vblank.
> 
> The only problem we may have is that some of the embedded gpus may not 
> have compliant vblank counters and they probably also lack vblank 
> timestamping, so it might be a good idea to rather not use vblank 
> counters at all in those drivers - patch their kms drivers to 
> max_vblank_count = 0;
> 
> >>
> >> One of the reasons for trouble is that AMD hw quirk where the hw fires
> >> an extra vblank irq shortly after vblank irq's get enabled, not
> >> synchronized to vblank, but typically in the middle of active scanout,
> >> so we get a redundant call to drm_handle_vblank in the middle of scanout.
> >
> > I think that should be fine as such. The code should ignore redudntant
> > vbl irqs. Well, assuming you have a reliable hw counter or you use the
> > timestamp guesstimate mechanism and your scanout position is reported
> > accurately. But I guess you have a bit of problem with both.
> >
> 
> The problem is i'll need to treat calls to radeon kms 
> driver->get_vblank_counter differently, depending if the function gets 
> called from vblank irq, or from regular code, so that hw quirk that 
> causes spontaneous misfiring of the vblank irq in the middle of scanout 
> would confuse my hw vblank counter cooking method to produce a fake hw 
> vblank counter increment. That's why i moved the filtering for redundant 
> irqs based on vblank timestamps in drm_vblank_update() around to always 
> apply. Makes us robust against that type of hw quirk in general and 
> makes life for the vblank counter cooking so much easier.
> 
> It's a beautiful collaboration of different hw bugs to make things 
> interesting :)
> 
> >>
> >> To fix that i have a minor patch to make drm_update_vblank_count() again
> >> robust against such redundant calls, which i will send out later to the
> >> mailing list. Diff attached for reference.
> >>
> >> The second quirk of AMD hw is that the vblank interrupt fires a few
> >> scanlines before start of vblank, so drm_handle_vblank ->
> >> drm_update_vblank_count() -> dev->driver->get_vblank_counter() gets
> >> called before the start of the vblank for which the new vblank count
> >> should be queried.
> >
> > Does it fire too soon, or is the scanout position register value(s)
> > just offset by a few lines perhaps?
> >
> > We have that with i915 and I simply fix up the value when reading it
> > out. Fortunately for us the offset is constant (or at least seems to
> > be) for a given platform/connector combo.
> >
> 
> I think they fire too soon, from all i've seen so far on a few cards.

That's unfortunate. Firing a bit too late would be perfectly fine for
most things. And that's actually what happens on older intel hw. Firing
too soon opens up some more races, as in you may have to wait a bit
more after getting woken up to make sure you've crossed into the
freame you were waiting for.

Also not sure how to deal with that sort of thing in a reasonable way in
.get_vblank_timestamp(). DRM_CALLED_FROM_VBLIRQ gets passed there, so it
could fudge things a bit when the early irq arrives, but then if someone
calls drm_update_vblank_count() after the irq was handled but before
start of vblank you'll end up with a -1 diff.

Maybe something like:
.get_scanout_positon()
{
read frame counter and scaline position

if ((flags & DRM_CALLED_FROM_VBLIRQ || frame == last_fudge_frame) &&
 scanline_slightly_below_start_of_vblank)) {
last_fudge_frame = frame;
scanline = 

[Intel-gfx] [PATCH 11/9] drm/i915: Opt out of vblank disable timer on >gen2

[Chris Wilson]

On Thu, Nov 19, 2015 at 10:06:01PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 19, 2015 at 05:44:51PM -0200, Paulo Zanoni wrote:
> > 2014-05-26 11:26 GMT-03:00  :
> > > From: Ville Syrjälä 
> > >
> > > Now that the vblank races are plugged, we can opt out of using
> > > the vblank disable timer and just let vblank interrupts get
> > > disabled immediately when the last reference is dropped.
> > >
> > > Gen2 is the exception since it has no hardware frame counter.
> > 
> > Hi
> > 
> > Remember last week's FBC vblank optimization patch that had an
> > erroneous drm_crtc_vblank_get() instead of drm_crtc_vblank_count()?
> > After I fixed the bug in the patch I realized that it was the
> > unbalanced vblank_get() call that moved PC state residency up.
> > 
> > I did some experiments, and on my specific BDW machine, after running
> > "powertop --auto-tune", I get about 15-25% PC7 residency without FBC.
> > If I revert this patch, the number jumps to 40-45%. With FBC, the PC7
> > residency goes from 60-70% to 85-90% when I revert this patch. I'm
> > running just an idle Cinnamon with an open terminal.
> > 
> > So, since the commit message lacks more details, what are the
> > downsides of reverting this patch? What are the advantages of opting
> > out of the vblank timer? I see my desktop does tons and tons of vblank
> > get/put calls per second, so the disable timer makes a lot of sense.
> 
> "Idle" desktop :(
> 
> Really the immediate disable should save power. Where are these tons of
> vblank get/puts coming from actually? I would assume you'd get a handful
> per frame at most, and that when you're actually doing something. On an
> idle system I would expect nothing at all happens during most frames.

Yes, with the immediate disable we end up with a few get/put per frame
of rendering, as userspace queries and queues the next flip/swap. With
more clients, there are more opportunities for queries prior to queuing
the swap. It really shouldn't be more than a handful per frame if all
the clients are vrefresh limited. (The oddity was the vblank_mode=0
rendering where we still maintained the handful of get/put per frame...)

> > I also wish there was some easy way to check how this patch (or its
> > revert) affect a bunch of different workloads...

Maybe add the PC residencies to the power meter in intel-gpu-overlay,
alongside the RC residencies?

> > (Also CCing Chris for insightful comments on performance)
> 
> IIRC Chris had a patch to not disable the interrupt immediately when
> the refcount drops to 0, but instead delay the disable until the next
> interrupt actually happens. But I guess it didn't go in? Probably I
> should have reviewed it but didn't. It sounds like a decent idea to
> me in any case for the active use case.

The discussion went off into the barriers around the vblank counter, and
I forgot to bring it up again. I think even Mario was happy enough about
it.

Paulo, you may want to try

http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly=ef97f4680d316cc8f9656dded1e1e41544c7225e

or you can change the KEEPALIVES value in src/sna/sna_dri2.c for a
similar effect.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] nvidia/noveau: Fix color mask

[Michael Büsch]

The expression (~0 >> x) will always yield all-ones, because the right
shift is an arithmetic right shift that will always shift ones in.
Accordingly ~(~0 >> x) will always be zero.
Hence 'mask' will always be zero in this case.

Fix this by forcing a logical right shift instead of an arithmetic
right shift by using an unsigned int constant.

Signed-off-by: Michael Buesch 

---

This patch is untested, because I do not have the hardware.

Resend: Patch was originally sent on Wed, 17 Jun 2015.


Index: linux/drivers/gpu/drm/nouveau/nv50_fbcon.c
===
--- linux.orig/drivers/gpu/drm/nouveau/nv50_fbcon.c
+++ linux/drivers/gpu/drm/nouveau/nv50_fbcon.c
@@ -96,7 +96,7 @@ nv50_fbcon_imageblit(struct fb_info *inf
struct nouveau_drm *drm = nouveau_drm(nfbdev->dev);
struct nouveau_channel *chan = drm->channel;
uint32_t width, dwords, *data = (uint32_t *)image->data;
-   uint32_t mask = ~(~0 >> (32 - info->var.bits_per_pixel));
+   uint32_t mask = ~(~0U >> (32 - info->var.bits_per_pixel));
uint32_t *palette = info->pseudo_palette;
int ret;

Index: linux/drivers/gpu/drm/nouveau/nvc0_fbcon.c
===
--- linux.orig/drivers/gpu/drm/nouveau/nvc0_fbcon.c
+++ linux/drivers/gpu/drm/nouveau/nvc0_fbcon.c
@@ -96,7 +96,7 @@ nvc0_fbcon_imageblit(struct fb_info *inf
struct nouveau_drm *drm = nouveau_drm(nfbdev->dev);
struct nouveau_channel *chan = drm->channel;
uint32_t width, dwords, *data = (uint32_t *)image->data;
-   uint32_t mask = ~(~0 >> (32 - info->var.bits_per_pixel));
+   uint32_t mask = ~(~0U >> (32 - info->var.bits_per_pixel));
uint32_t *palette = info->pseudo_palette;
int ret;

Index: linux/drivers/video/fbdev/nvidia/nv_accel.c
===
--- linux.orig/drivers/video/fbdev/nvidia/nv_accel.c
+++ linux/drivers/video/fbdev/nvidia/nv_accel.c
@@ -351,7 +351,7 @@ static void nvidiafb_mono_color_expand(s
   const struct fb_image *image)
 {
struct nvidia_par *par = info->par;
-   u32 fg, bg, mask = ~(~0 >> (32 - info->var.bits_per_pixel));
+   u32 fg, bg, mask = ~(~0U >> (32 - info->var.bits_per_pixel));
u32 dsize, width, *data = (u32 *) image->data, tmp;
int j, k = 0;

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151119/d075878e/attachment-0001.sig>

[PATCH] drm/sysfs: Send out uevent when connector->force changes

[Chris Wilson]

On Thu, Nov 19, 2015 at 05:46:50PM +0100, Daniel Vetter wrote:
> To avoid even more code duplication punt this all to the probe worker,
> which needs some slight adjustment to also generate a uevent when the
> status has changed to due connector->force.
> 
> v2: Instead of running the output_poll_work (which is kinda the wrong
> thing and a layering violation since it's an internal of the probe
> helpers), or calling ->detect (which is again a layering violation
> since it's used only by probe helpers) just call the official
> ->fill_modes function, like a GET_CONNECTOR ioctl call.
> 
> v3: Restore the accidentally removed forced-probe for echo "detect" >
> force.
> 

> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 9ac4ffa6cce3..df66d9447cb0 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -167,47 +167,35 @@ static ssize_t status_store(struct device *device,
>  {
>   struct drm_connector *connector = to_drm_connector(device);
>   struct drm_device *dev = connector->dev;
> - enum drm_connector_status old_status;
> + enum drm_connector_force old_force;
>   int ret;
>  
>   ret = mutex_lock_interruptible(>mode_config.mutex);
>   if (ret)
>   return ret;
>  
> - old_status = connector->status;
> + old_force = connector->force;
>  
> - if (sysfs_streq(buf, "detect")) {
> + if (sysfs_streq(buf, "detect"))
>   connector->force = 0;
> - connector->status = connector->funcs->detect(connector, true);
> - } else if (sysfs_streq(buf, "on")) {
> + else if (sysfs_streq(buf, "on"))
>   connector->force = DRM_FORCE_ON;
> - } else if (sysfs_streq(buf, "on-digital")) {
> + else if (sysfs_streq(buf, "on-digital"))
>   connector->force = DRM_FORCE_ON_DIGITAL;
> - } else if (sysfs_streq(buf, "off")) {
> + else if (sysfs_streq(buf, "off"))
>   connector->force = DRM_FORCE_OFF;
> - } else
> + else
>   ret = -EINVAL;
>  
> - if (ret == 0 && connector->force) {
> - if (connector->force == DRM_FORCE_ON ||
> - connector->force == DRM_FORCE_ON_DIGITAL)
> - connector->status = connector_status_connected;
> - else
> - connector->status = connector_status_disconnected;
> - if (connector->funcs->force)
> - connector->funcs->force(connector);
> - }
> -
> - if (old_status != connector->status) {
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
> %d\n",
> + if (old_force != connector->force || !connector->force) {
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] force updated from %d to %d or 
> reprobing\n",
> connector->base.id,
> connector->name,
> -   old_status, connector->status);
> +   old_force, connector->force);
>  
> - dev->mode_config.delayed_event = true;
> - if (dev->mode_config.poll_enabled)
> - 
> schedule_delayed_work(>mode_config.output_poll_work,
> -   0);
> + connector->funcs->fill_modes(connector,
> +  dev->mode_config.max_width,
> +  dev->mode_config.max_height);

This now does fill_modes() before we call detect(). We rely on the
ordering of detect() before doing fill_modes() as in many cases we use
the EDID gathered in detect() to generate the modes (if I am not
mistaken, I think we merged those patches to cache the EDID for a
detection cycle).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 92755] [APITRACE] Shadow of Mordor locks up R600

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

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

--- Comment #4 from Christoph Brill  ---
(In reply to Michel Dänzer from comment #3)
> Does replaying the apitrace reproduce the lockup?

Yes, it reproducibly locks the GPU.

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

[Bug 91994] Samsung U28D590D Monitor does not wake up after power saving mode

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

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

--- Comment #5 from Adam Flott  ---
(In reply to Adam Flott from comment #4)
> This looks to have been fixed from 4.2->4.3 xf86-video-ati 7.5->7.6 and I
> thank you immensely. My sanity has been restored.

That is Linux kernel 4.2->4.3

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

[Bug 91994] Samsung U28D590D Monitor does not wake up after power saving mode

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

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

Adam Flott  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Adam Flott  ---
This looks to have been fixed from 4.2->4.3 xf86-video-ati 7.5->7.6 and I thank
you immensely. My sanity has been restored.

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

[Bug 88043] Star Conflict locks up AMD BARTS

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

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

EoD  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from EoD  ---
I cannot reproduce the bug anymore with current mesa git. I suspect it is a
duplicate of bug 73528

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

Funky new vblank counter regressions in Linux 4.4-rc1

[Ville Syrjälä]

On Thu, Nov 19, 2015 at 06:46:28PM +0100, Mario Kleiner wrote:
> Hi Alex and Michel and Ville,
> 
> it's "fix vblank stuff" time again ;-)
> 
> Ville's changes to the DRM's drm_handle_vblank() / 
> drm_update_vblank_count() code in Linux 4.4 not only made that code more 
> elegant, but also removed the robustness against the vblank irq quirks 
> in AMD hw and similar hardware. So now i get tons of off-by-one errors and
> 
> "[   432.345] (WW) RADEON(1): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 24803 < target_msc 24804" XOrg 
> messages from that kernel.

Argh. Sorry about that.

> 
> One of the reasons for trouble is that AMD hw quirk where the hw fires 
> an extra vblank irq shortly after vblank irq's get enabled, not 
> synchronized to vblank, but typically in the middle of active scanout, 
> so we get a redundant call to drm_handle_vblank in the middle of scanout.

I think that should be fine as such. The code should ignore redudntant
vbl irqs. Well, assuming you have a reliable hw counter or you use the
timestamp guesstimate mechanism and your scanout position is reported
accurately. But I guess you have a bit of problem with both.

> 
> To fix that i have a minor patch to make drm_update_vblank_count() again 
> robust against such redundant calls, which i will send out later to the 
> mailing list. Diff attached for reference.
> 
> The second quirk of AMD hw is that the vblank interrupt fires a few 
> scanlines before start of vblank, so drm_handle_vblank -> 
> drm_update_vblank_count() -> dev->driver->get_vblank_counter() gets 
> called before the start of the vblank for which the new vblank count 
> should be queried.

Does it fire too soon, or is the scanout position register value(s)
just offset by a few lines perhaps?

We have that with i915 and I simply fix up the value when reading it
out. Fortunately for us the offset is constant (or at least seems to
be) for a given platform/connector combo.

> 
> The third problem is that the DRM vblank handling always had the 
> assumption that hardware vblank counters would essentially increment at 
> leading edge of vblank - basically in sync with the firing of the vblank 
> irq, so that a hw counter readout from within the vblank irq handler 
> would always deliver the new incremented value. If this assumption is 
> violated then the counting by use of the hw counter gets unreliable, 
> because depending on random small delays in irq handling the code may 
> end up sampling the hw counter pre- or post-increment, leading to 
> inconsistent updating and funky bugs. It just so happens that AMD 
> hardware doesn't increment the hw counter at leading edge of vblank, so 
> stuff falls apart.
> 
> So to fix those two problems i'm tinkering with cooking the hw vblank 
> counter value returned by radeon_get_vblank_counter_kms() to make it 
> appear as if the counter incremented at leading edge of vblank in sync 
> with vblank irq.

Yeah, I do that in i915 too. Well, on some platforms where the
counter increments at the leading edge of active.

> 
> It almost sort of works on the rs600 code path, but i need a bit of info 
> from you:
> 
> 1. There's this register from the old specs for m76.pdf, which is not 
> part of the current register defines for radeon-kms:
> 
> "D1CRTC_STATUS_VF_COUNT - RW - 32 bits - [GpuF0MMReg:0x60A8]"
> 
> It contains the lower 16 bits of framecounter and the 13 bits of 
> vertical scanout position. It seems to give the same readings as the 24 
> bit R_0060A4_D1CRTC_STATUS_FRAME_COUNT we use for the hw counter. This 
> would come handy.
> 
> Does Evergreen and later have a same/similar register and where is it?
> 
> 2. The hw framecounter seems to increment when the vertical scanout 
> position wraps back from (VTOTAL - 1) to 0, at least on the one DCE-3 
> gpu i tested so far. Is this so on all asics? And is the hw counter 
> increment happening exactly at the moment that vertical scanout position 
> jumps back to zero, ie. both events are driven by the same signal? Or is 
> the framecounter increment just happening somewhere inside either 
> scanline VTOTAL-1 or scanline 0?
> 
> 
> If we can fix this and get it into rc2 or rc3 then we could avoid a bad 
> regression and with a bit of luck at the same time improve by being able 
> to set dev->vblank_disable_immediate = true then and allow vblank irqs 
> to get turned off more aggressively for a bit of extra power saving.
> 
> thanks,
> -mario

> -- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -172,9 +172,11 @@ static void drm_update_vblank_count(struct drm_device 
> *dev, unsigned int pipe,
> unsigned long flags)
>  {
> struct drm_vblank_crtc *vblank = >vblank[pipe];
> -   u32 cur_vblank, diff;
> +   u32 cur_vblank, diff = 0;
> bool rc;
> struct timeval t_vblank;
> +   const struct timeval *t_old;
> +   u64 diff_ns;
> int count = 

[Bug 92952] Enabling Anti-Aliasing, when pp_jimenezmlaa and pp_jimenezmlaa_color are set, causes screen to corrupt

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

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

--- Comment #8 from EoD  ---
Can't you disable the postprocessing AA when MSAA is enabled? Or at least give
a huge warning/error message in such a case?

It took me a very long time to figure the problem out (neither an error, nor
any other way of telling me the correlation) and I am pretty sure there are
many more people out there encountering the bug.

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

[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering

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

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

--- Comment #43 from EoD  ---
FTR: the above workaround has been reverted in
http://cgit.freedesktop.org/mesa/mesa/commit/?id=de59a40f6898e20a61ac4ea0e5995334f6ed2932
and there are no more problems on my r600g at least.

Thanks!

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

Funky new vblank counter regressions in Linux 4.4-rc1

[Mario Kleiner]

On 11/19/2015 07:20 PM, Ville Syrjälä wrote:
> On Thu, Nov 19, 2015 at 06:46:28PM +0100, Mario Kleiner wrote:
>> Hi Alex and Michel and Ville,
>>
>> it's "fix vblank stuff" time again ;-)
>>
>> Ville's changes to the DRM's drm_handle_vblank() /
>> drm_update_vblank_count() code in Linux 4.4 not only made that code more
>> elegant, but also removed the robustness against the vblank irq quirks
>> in AMD hw and similar hardware. So now i get tons of off-by-one errors and
>>
>> "[   432.345] (WW) RADEON(1): radeon_dri2_flip_event_handler: Pageflip
>> completion event has impossible msc 24803 < target_msc 24804" XOrg
>> messages from that kernel.
>
> Argh. Sorry about that.
>

On the plus side, your "vblank timestamp deltas as fake vblank counters" 
code seems to work nicely on nouveau-kms, as far as testing with three 
Nvidia's went so far :). And both Intel gpu's (HD Ironlake, and 
Ivybridge) i tested checked out nicely.

And at least the recent nv50+ NVidia Tesla also have 16 bit vblank 
counters which we could implement in nouveau, maybe with the same 
trickery to allow long trouble-free vblank off periods, hopefully that 
would also apply to the Tegra-4 and later Kepler based parts. Tegra-3 
will probably also work. I think i read in the Tegra-3 PRM that the sync 
points they use to implement vblank counters do increment at leading 
edge of vblank.

The only problem we may have is that some of the embedded gpus may not 
have compliant vblank counters and they probably also lack vblank 
timestamping, so it might be a good idea to rather not use vblank 
counters at all in those drivers - patch their kms drivers to 
max_vblank_count = 0;

>>
>> One of the reasons for trouble is that AMD hw quirk where the hw fires
>> an extra vblank irq shortly after vblank irq's get enabled, not
>> synchronized to vblank, but typically in the middle of active scanout,
>> so we get a redundant call to drm_handle_vblank in the middle of scanout.
>
> I think that should be fine as such. The code should ignore redudntant
> vbl irqs. Well, assuming you have a reliable hw counter or you use the
> timestamp guesstimate mechanism and your scanout position is reported
> accurately. But I guess you have a bit of problem with both.
>

The problem is i'll need to treat calls to radeon kms 
driver->get_vblank_counter differently, depending if the function gets 
called from vblank irq, or from regular code, so that hw quirk that 
causes spontaneous misfiring of the vblank irq in the middle of scanout 
would confuse my hw vblank counter cooking method to produce a fake hw 
vblank counter increment. That's why i moved the filtering for redundant 
irqs based on vblank timestamps in drm_vblank_update() around to always 
apply. Makes us robust against that type of hw quirk in general and 
makes life for the vblank counter cooking so much easier.

It's a beautiful collaboration of different hw bugs to make things 
interesting :)

>>
>> To fix that i have a minor patch to make drm_update_vblank_count() again
>> robust against such redundant calls, which i will send out later to the
>> mailing list. Diff attached for reference.
>>
>> The second quirk of AMD hw is that the vblank interrupt fires a few
>> scanlines before start of vblank, so drm_handle_vblank ->
>> drm_update_vblank_count() -> dev->driver->get_vblank_counter() gets
>> called before the start of the vblank for which the new vblank count
>> should be queried.
>
> Does it fire too soon, or is the scanout position register value(s)
> just offset by a few lines perhaps?
>
> We have that with i915 and I simply fix up the value when reading it
> out. Fortunately for us the offset is constant (or at least seems to
> be) for a given platform/connector combo.
>

I think they fire too soon, from all i've seen so far on a few cards.

>>
>> The third problem is that the DRM vblank handling always had the
>> assumption that hardware vblank counters would essentially increment at
>> leading edge of vblank - basically in sync with the firing of the vblank
>> irq, so that a hw counter readout from within the vblank irq handler
>> would always deliver the new incremented value. If this assumption is
>> violated then the counting by use of the hw counter gets unreliable,
>> because depending on random small delays in irq handling the code may
>> end up sampling the hw counter pre- or post-increment, leading to
>> inconsistent updating and funky bugs. It just so happens that AMD
>> hardware doesn't increment the hw counter at leading edge of vblank, so
>> stuff falls apart.
>>
>> So to fix those two problems i'm tinkering with cooking the hw vblank
>> counter value returned by radeon_get_vblank_counter_kms() to make it
>> appear as if the counter incremented at leading edge of vblank in sync
>> with vblank irq.
>
> Yeah, I do that in i915 too. Well, on some platforms where the
> counter increments at the leading edge of active.
>

Yep. I think that's key to make the vblank instant off stuff work 

[PATCH i915 v4 2/2] i915: wait for fence in prepare_plane_fb

[Alex Goins]

In intel_prepare_plane_fb, if fb is backed by dma-buf, wait for fence.

Signed-off-by: Alex Goins 
---
 drivers/gpu/drm/i915/intel_display.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4867ff0..4fb811d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13348,6 +13348,13 @@ intel_prepare_plane_fb(struct drm_plane *plane,
if (!obj)
return 0;

+   /* For framebuffer backed by dmabuf, wait for fence */
+   if (obj->base.dma_buf) {
+   reservation_object_wait_timeout_rcu(
+   obj->base.dma_buf->resv,
+   false, true, MAX_SCHEDULE_TIMEOUT);
+   }
+
mutex_lock(>struct_mutex);

if (plane->type == DRM_PLANE_TYPE_CURSOR &&
-- 
1.9.1

[PATCH i915 v4 1/2] i915: wait for fences in mmio_flip()

[Alex Goins]

If a buffer is backed by dmabuf, wait on its reservation object's fences
before flipping.

Signed-off-by: Alex Goins 
---
 drivers/gpu/drm/i915/intel_display.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b2270d5..4867ff0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -44,6 +44,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 /* Primary plane formats for gen <= 3 */
 static const uint32_t i8xx_primary_formats[] = {
@@ -11088,6 +11090,8 @@ static bool use_mmio_flip(struct intel_engine_cs *ring,
return true;
else if (i915.enable_execlists)
return true;
+   else if (obj->base.dma_buf && obj->base.dma_buf->resv->fence_excl)
+   return true;
else
return ring != i915_gem_request_get_ring(obj->last_write_req);
 }
@@ -11170,8 +11174,18 @@ static void ilk_do_mmio_flip(struct intel_crtc 
*intel_crtc)
 static void intel_do_mmio_flip(struct intel_crtc *intel_crtc)
 {
struct drm_device *dev = intel_crtc->base.dev;
+   struct intel_framebuffer *intel_fb =
+   to_intel_framebuffer(intel_crtc->base.primary->fb);
+   struct drm_i915_gem_object *obj = intel_fb->obj;
u32 start_vbl_count;

+   /* For framebuffer backed by dmabuf, wait for fence */
+   if (obj->base.dma_buf) {
+   reservation_object_wait_timeout_rcu(
+   obj->base.dma_buf->resv,
+   false, true, MAX_SCHEDULE_TIMEOUT);
+   }
+
intel_mark_page_flip_active(intel_crtc);

intel_pipe_update_start(intel_crtc, _vbl_count);
-- 
1.9.1

[PATCH i915 v4 0/2] PRIME Synchronization

[Alex Goins]

Hello all,

For a while now, I've been working to fix tearing with PRIME. This is my
fourth version of the solution, revised according to Daniel Vetter's and
Chris Wilson's suggestions. It now uses crtc->primary->fb to get the GEM
object instead of pending_flip_obj, waits for fence BEFORE marking page
flip active, and modifies use_mmio_flip() to ensure that mmio_flip is used
for objects backed by dma_buf with an exclusive fence attached. Calls to
reservation_object_wait_timeout_rcu have been changed to only wait for
exclusive fences, as well as to be interruptible and without a timeout.

Repeat of overview below:

I have two patches, one that implements fencing for i915's legacy mmio_flip
path, and one for atomic modesetting for futureproofing. Currently the
mmio_flip path is the one ultimately used by the X patches, due to the lack
of asynchronous atomic modesetting support in i915.

With my synchronization patches to X, it is possible to export two shared
buffers per crtc instead of just one. The sink driver uses the legacy
drmModePageFlip() to flip between the buffers, as the rest of the driver
has yet to be ported to atomics. In the pageflip/vblank event handler, the
sink driver requests a present from the source using the new X ABI function
pScreen->PresentTrackedFlippingPixmap(). If the call returns successfully,
it uses drmModePageFlip() to flip to the updated buffer, otherwise it waits
until the next vblank and tries again.

When the source driver presents on a given buffer, it first attaches a
fence.  The source driver is responsible for either using software
signaling or hardware semaphore-backed fences to ensure the fence is
signaled when the present is finished. If the sink's DRM driver implements
fencing in the flipping path, it will guarantee that that flip won't occur
until the present has finished.

This means that DRM drivers that don't implement fencing in their flipping
paths won't be able to guarantee 100% tear-free PRIME with my X patches.
However, the good news is that even without fencing, tearing is rare.
Generally presenting finishes before the next vblank, so there is no need
to wait on the fence. The X patches are a drastic improvement with or
without fencing, but the fencing is nonetheless important to guarantee
tear-free under all conditions.

To give some greater context, I've uploaded my branches for DRM and the X
server to Github. I'll move forward with upstreaming the X changes if and
when these DRM patches go in.

DRM Tree:https://github.com/GoinsWithTheWind/drm-prime-sync
X Tree:  https://github.com/GoinsWithTheWind/xserver-prime-sync

(branch agoins-prime-v4)

Thanks, Alex @ NVIDIA Linux Driver Team

Alex Goins (2):
  i915: wait for fences in mmio_flip()
  i915: wait for fence in prepare_plane_fb

 drivers/gpu/drm/i915/intel_display.c | 21 +
 1 file changed, 21 insertions(+)

-- 
1.9.1

Funky new vblank counter regressions in Linux 4.4-rc1

[Mario Kleiner]

Hi Alex and Michel and Ville,

it's "fix vblank stuff" time again ;-)

Ville's changes to the DRM's drm_handle_vblank() / 
drm_update_vblank_count() code in Linux 4.4 not only made that code more 
elegant, but also removed the robustness against the vblank irq quirks 
in AMD hw and similar hardware. So now i get tons of off-by-one errors and

"[   432.345] (WW) RADEON(1): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 24803 < target_msc 24804" XOrg 
messages from that kernel.

One of the reasons for trouble is that AMD hw quirk where the hw fires 
an extra vblank irq shortly after vblank irq's get enabled, not 
synchronized to vblank, but typically in the middle of active scanout, 
so we get a redundant call to drm_handle_vblank in the middle of scanout.

To fix that i have a minor patch to make drm_update_vblank_count() again 
robust against such redundant calls, which i will send out later to the 
mailing list. Diff attached for reference.

The second quirk of AMD hw is that the vblank interrupt fires a few 
scanlines before start of vblank, so drm_handle_vblank -> 
drm_update_vblank_count() -> dev->driver->get_vblank_counter() gets 
called before the start of the vblank for which the new vblank count 
should be queried.

The third problem is that the DRM vblank handling always had the 
assumption that hardware vblank counters would essentially increment at 
leading edge of vblank - basically in sync with the firing of the vblank 
irq, so that a hw counter readout from within the vblank irq handler 
would always deliver the new incremented value. If this assumption is 
violated then the counting by use of the hw counter gets unreliable, 
because depending on random small delays in irq handling the code may 
end up sampling the hw counter pre- or post-increment, leading to 
inconsistent updating and funky bugs. It just so happens that AMD 
hardware doesn't increment the hw counter at leading edge of vblank, so 
stuff falls apart.

So to fix those two problems i'm tinkering with cooking the hw vblank 
counter value returned by radeon_get_vblank_counter_kms() to make it 
appear as if the counter incremented at leading edge of vblank in sync 
with vblank irq.

It almost sort of works on the rs600 code path, but i need a bit of info 
from you:

1. There's this register from the old specs for m76.pdf, which is not 
part of the current register defines for radeon-kms:

"D1CRTC_STATUS_VF_COUNT - RW - 32 bits - [GpuF0MMReg:0x60A8]"

It contains the lower 16 bits of framecounter and the 13 bits of 
vertical scanout position. It seems to give the same readings as the 24 
bit R_0060A4_D1CRTC_STATUS_FRAME_COUNT we use for the hw counter. This 
would come handy.

Does Evergreen and later have a same/similar register and where is it?

2. The hw framecounter seems to increment when the vertical scanout 
position wraps back from (VTOTAL - 1) to 0, at least on the one DCE-3 
gpu i tested so far. Is this so on all asics? And is the hw counter 
increment happening exactly at the moment that vertical scanout position 
jumps back to zero, ie. both events are driven by the same signal? Or is 
the framecounter increment just happening somewhere inside either 
scanline VTOTAL-1 or scanline 0?


If we can fix this and get it into rc2 or rc3 then we could avoid a bad 
regression and with a bit of luck at the same time improve by being able 
to set dev->vblank_disable_immediate = true then and allow vblank irqs 
to get turned off more aggressively for a bit of extra power saving.

thanks,
-mario
-- next part --
A non-text attachment was scrubbed...
Name: fixupForDRM.patch
Type: text/x-patch
Size: 3373 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151119/ce6d9daa/attachment.bin>

[Intel-gfx] [PATCH 11/9] drm/i915: Opt out of vblank disable timer on >gen2

[Paulo Zanoni]

2015-11-19 18:06 GMT-02:00 Ville Syrjälä :
> On Thu, Nov 19, 2015 at 05:44:51PM -0200, Paulo Zanoni wrote:
>> 2014-05-26 11:26 GMT-03:00  :
>> > From: Ville Syrjälä 
>> >
>> > Now that the vblank races are plugged, we can opt out of using
>> > the vblank disable timer and just let vblank interrupts get
>> > disabled immediately when the last reference is dropped.
>> >
>> > Gen2 is the exception since it has no hardware frame counter.
>>
>> Hi
>>
>> Remember last week's FBC vblank optimization patch that had an
>> erroneous drm_crtc_vblank_get() instead of drm_crtc_vblank_count()?
>> After I fixed the bug in the patch I realized that it was the
>> unbalanced vblank_get() call that moved PC state residency up.
>>
>> I did some experiments, and on my specific BDW machine, after running
>> "powertop --auto-tune", I get about 15-25% PC7 residency without FBC.
>> If I revert this patch, the number jumps to 40-45%. With FBC, the PC7
>> residency goes from 60-70% to 85-90% when I revert this patch. I'm
>> running just an idle Cinnamon with an open terminal.
>>
>> So, since the commit message lacks more details, what are the
>> downsides of reverting this patch? What are the advantages of opting
>> out of the vblank timer? I see my desktop does tons and tons of vblank
>> get/put calls per second, so the disable timer makes a lot of sense.
>
> "Idle" desktop :(

My first realization of this little problem was when I was
implementing runtime PM :)


>
> Really the immediate disable should save power. Where are these tons of
> vblank get/puts coming from actually?

I'll take a finer look tomorrow, but I assume it's probably some
application redrawing. I see it does calm down sometimes, but that's
not enough to get better PC7 residency.


> I would assume you'd get a handful
> per frame at most, and that when you're actually doing something. On an
> idle system I would expect nothing at all happens during most frames.
>
> Not sure, but I guess it's possible the extra register accesses in the
> get/puts actually cause the display to exit low power states all the time,
> or something.

I tried replacing the register macros with the _FW version and that didn't help.


>
> There's also this note in Bspec (for HSW at least):

I think this not is present on most (all?) gens.


>  "Workaround : Do not enable and unmask this interrupt if the associated
>   pipe is disabled.  Do not leave this interrupt enabled and unmasked
>   after the associated pipe is disabled."
> which we took to mean that having the interrupt masked but enabled is
> fine.

I'm aware of this, but I think the problem is that the resources
drained by the constant enable+disable+enable+disable outweigh the
resources saved by turning off vblanks. Not sure if there's an extra
reason why BSpec asks us to immediately disable vblanks though...

So, to summarize, the main (only?) reason is the BSpec comment?


> But maybe we'd actually have to frob IER too to avoid wasting
> power somehow?

With the interrupt masked on IMR, I don't think IER matters.

>
>> I also wish there was some easy way to check how this patch (or its
>> revert) affect a bunch of different workloads...
>>
>> (Also CCing Chris for insightful comments on performance)
>
> IIRC Chris had a patch to not disable the interrupt immediately when
> the refcount drops to 0, but instead delay the disable until the next
> interrupt actually happens. But I guess it didn't go in? Probably I
> should have reviewed it but didn't. It sounds like a decent idea to
> me in any case for the active use case.
>
>>
>> Thanks,
>> Paulo
>>
>> >
>> > Signed-off-by: Ville Syrjälä 
>> > ---
>> >  drivers/gpu/drm/i915/i915_irq.c | 8 
>> >  1 file changed, 8 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>> > b/drivers/gpu/drm/i915/i915_irq.c
>> > index 28bae6e..4b2e7af 100644
>> > --- a/drivers/gpu/drm/i915/i915_irq.c
>> > +++ b/drivers/gpu/drm/i915/i915_irq.c
>> > @@ -4364,6 +4364,14 @@ void intel_irq_init(struct drm_device *dev)
>> > dev->max_vblank_count = 0xff; /* only 24 bits of frame 
>> > count */
>> > }
>> >
>> > +   /*
>> > +* Opt out of the vblank disable timer on everything except gen2.
>> > +* Gen2 doesn't have a hardware frame counter and so depends on
>> > +* vblank interrupts to produce sane vblank seuquence numbers.
>> > +*/
>> > +   if (!IS_GEN2(dev))
>> > +   dev->vblank_disable_immediate = true;
>> > +
>> > if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>> > dev->driver->get_vblank_timestamp = 
>> > i915_get_vblank_timestamp;
>> > dev->driver->get_scanout_position = 
>> > i915_get_crtc_scanoutpos;
>> > --
>> > 1.8.5.5
>> >
>> > ___
>> > Intel-gfx mailing list
>> > Intel-gfx at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>>
>>
>> --
>> Paulo Zanoni
>
> --
> 

[PULL] topic/drm-fixes

[Jani Nikula]

Hi Dave -

Here are some drm core fixes for v4.4 that I've picked up. Atomic fixes
from Maarten, and atomic helper fixes from Ville and Daniel.

Admittedly the topmost commit didn't sit in our tree for very long, but
does come with reviews and testing from trustworthy people.

BR,
Jani.

The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:

  Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-fixes-2015-11-19

for you to fetch changes up to 5481c8fb1da2a573861095fbea078f30c664d0bd:

  drm/atomic-helper: Check encoder/crtc constraints (2015-11-19 17:11:13 +0200)


Daniel Vetter (1):
  drm/atomic-helper: Check encoder/crtc constraints

Maarten Lankhorst (5):
  drm/core: Set legacy_cursor_update in drm_atomic_helper_disable_plane.
  drm/core: Fix old_fb handling in drm_mode_atomic_ioctl.
  drm/atomic: add a drm_atomic_clean_old_fb helper.
  drm/core: Fix old_fb handling in restore_fbdev_mode_atomic.
  drm/core: Fix old_fb handling in pan_display_atomic.

Ville Syrjälä (1):
  drm: Fix primary plane size for stereo doubled modes for legacy setcrtc

 drivers/gpu/drm/drm_atomic.c| 61 +
 drivers/gpu/drm/drm_atomic_helper.c | 29 --
 drivers/gpu/drm/drm_fb_helper.c | 51 +--
 include/drm/drm_atomic.h|  3 ++
 4 files changed, 79 insertions(+), 65 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH RESEND 15/20] drm/exynos: drop struct_mutex from exynos_drm_gem_get_ioctl

[Daniel Vetter]

On Thu, Nov 19, 2015 at 04:50:11PM +, Daniel Stone wrote:
> Hi,
> 
> On 19 November 2015 at 16:46, Daniel Vetter  wrote:
> > @@ -367,7 +364,6 @@ int exynos_drm_gem_get_ioctl(struct drm_device *dev, 
> > void *data,
> > args->size = exynos_gem->size;
> >
> > drm_gem_object_unreference(obj);
> > -   mutex_unlock(>struct_mutex);
> 
> drm_gem_object_unreference_unlocked, surely ...

Yeah, and then I go and do a grep for this and spot piles more offenders.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/sysfs: Send out uevent when connector->force changes

[Daniel Vetter]

To avoid even more code duplication punt this all to the probe worker,
which needs some slight adjustment to also generate a uevent when the
status has changed to due connector->force.

v2: Instead of running the output_poll_work (which is kinda the wrong
thing and a layering violation since it's an internal of the probe
helpers), or calling ->detect (which is again a layering violation
since it's used only by probe helpers) just call the official
->fill_modes function, like a GET_CONNECTOR ioctl call.

v3: Restore the accidentally removed forced-probe for echo "detect" >
force.

Cc: Chris Wilson 
Reported-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_probe_helper.c | 46 +++---
 drivers/gpu/drm/drm_sysfs.c| 38 +++
 2 files changed, 36 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index a214a4a93b03..b7bdf12c54a5 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -147,6 +147,8 @@ static int 
drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
list_for_each_entry(mode, >modes, head)
mode->status = MODE_UNVERIFIED;

+   old_status = connector->status;
+
if (connector->force) {
if (connector->force == DRM_FORCE_ON ||
connector->force == DRM_FORCE_ON_DIGITAL)
@@ -156,33 +158,31 @@ static int 
drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
if (connector->funcs->force)
connector->funcs->force(connector);
} else {
-   old_status = connector->status;
-
connector->status = connector->funcs->detect(connector, true);
+   }
+
+   /*
+* Normally either the driver's hpd code or the poll loop should
+* pick up any changes and fire the hotplug event. But if
+* userspace sneaks in a probe, we might miss a change. Hence
+* check here, and if anything changed start the hotplug code.
+*/
+   if (old_status != connector->status) {
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
%d\n",
+ connector->base.id,
+ connector->name,
+ old_status, connector->status);

/*
-* Normally either the driver's hpd code or the poll loop should
-* pick up any changes and fire the hotplug event. But if
-* userspace sneaks in a probe, we might miss a change. Hence
-* check here, and if anything changed start the hotplug code.
+* The hotplug event code might call into the fb
+* helpers, and so expects that we do not hold any
+* locks. Fire up the poll struct instead, it will
+* disable itself again.
 */
-   if (old_status != connector->status) {
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d 
to %d\n",
- connector->base.id,
- connector->name,
- old_status, connector->status);
-
-   /*
-* The hotplug event code might call into the fb
-* helpers, and so expects that we do not hold any
-* locks. Fire up the poll struct instead, it will
-* disable itself again.
-*/
-   dev->mode_config.delayed_event = true;
-   if (dev->mode_config.poll_enabled)
-   
schedule_delayed_work(>mode_config.output_poll_work,
- 0);
-   }
+   dev->mode_config.delayed_event = true;
+   if (dev->mode_config.poll_enabled)
+   
schedule_delayed_work(>mode_config.output_poll_work,
+ 0);
}

/* Re-enable polling in case the global poll config changed. */
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 9ac4ffa6cce3..df66d9447cb0 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -167,47 +167,35 @@ static ssize_t status_store(struct device *device,
 {
struct drm_connector *connector = to_drm_connector(device);
struct drm_device *dev = connector->dev;
-   enum drm_connector_status old_status;
+   enum drm_connector_force old_force;
int ret;

ret = mutex_lock_interruptible(>mode_config.mutex);
if (ret)
return ret;

-   old_status = connector->status;
+   old_force = connector->force;

-   if (sysfs_streq(buf, "detect")) {
+   if 

[PATCH RESEND 20/20] drm/vma_manage: Drop has_offset

[Daniel Vetter]

It's racy, creating mmap offsets is a slowpath, so better to remove it
to avoid drivers doing broken things.

The only user is i915, and it's ok there because everything (well
almost) is protected by dev->struct_mutex in i915-gem.

While at it add a note in the create_mmap_offset kerneldoc that
drivers must release it again. And then I also noticed that
drm_gem_object_release entirely lacks kerneldoc.

Cc: David Herrmann 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem.c   | 17 +
 drivers/gpu/drm/i915/i915_gem.c |  3 ---
 include/drm/drm_vma_manager.h   | 15 +--
 3 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 2e10bba4468b..5c5001171dd3 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -392,6 +392,10 @@ EXPORT_SYMBOL(drm_gem_handle_create);
  * @obj: obj in question
  *
  * This routine frees fake offsets allocated by drm_gem_create_mmap_offset().
+ *
+ * Note that drm_gem_object_release() already calls this function, so drivers
+ * don't have to take care of releasing the mmap offset themselves when freeing
+ * the GEM object.
  */
 void
 drm_gem_free_mmap_offset(struct drm_gem_object *obj)
@@ -415,6 +419,9 @@ EXPORT_SYMBOL(drm_gem_free_mmap_offset);
  * This routine allocates and attaches a fake offset for @obj, in cases where
  * the virtual size differs from the physical size (ie. obj->size).  Otherwise
  * just use drm_gem_create_mmap_offset().
+ *
+ * This function is idempotent and handles an already allocated mmap offset
+ * transparently. Drivers do not need to check for this case.
  */
 int
 drm_gem_create_mmap_offset_size(struct drm_gem_object *obj, size_t size)
@@ -436,6 +443,9 @@ EXPORT_SYMBOL(drm_gem_create_mmap_offset_size);
  * structures.
  *
  * This routine allocates and attaches a fake offset for @obj.
+ *
+ * Drivers can call drm_gem_free_mmap_offset() before freeing @obj to release
+ * the fake offset again.
  */
 int drm_gem_create_mmap_offset(struct drm_gem_object *obj)
 {
@@ -754,6 +764,13 @@ drm_gem_release(struct drm_device *dev, struct drm_file 
*file_private)
idr_destroy(_private->object_idr);
 }

+/**
+ * drm_gem_object_release - release GEM buffer object resources
+ * @obj: GEM buffer object
+ *
+ * This releases any structures and resources used by @obj and is the invers of
+ * drm_gem_object_init().
+ */
 void
 drm_gem_object_release(struct drm_gem_object *obj)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 33adc8f8ab20..f10a5d57377e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1972,9 +1972,6 @@ static int i915_gem_object_create_mmap_offset(struct 
drm_i915_gem_object *obj)
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
int ret;

-   if (drm_vma_node_has_offset(>base.vma_node))
-   return 0;
-
dev_priv->mm.shrinker_no_lock_stealing = true;

ret = drm_gem_create_mmap_offset(>base);
diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
index 2f63dd5e05eb..06ea8e077ec2 100644
--- a/include/drm/drm_vma_manager.h
+++ b/include/drm/drm_vma_manager.h
@@ -176,19 +176,6 @@ static inline unsigned long drm_vma_node_size(struct 
drm_vma_offset_node *node)
 }

 /**
- * drm_vma_node_has_offset() - Check whether node is added to offset manager
- * @node: Node to be checked
- *
- * RETURNS:
- * true iff the node was previously allocated an offset and added to
- * an vma offset manager.
- */
-static inline bool drm_vma_node_has_offset(struct drm_vma_offset_node *node)
-{
-   return drm_mm_node_allocated(>vm_node);
-}
-
-/**
  * drm_vma_node_offset_addr() - Return sanitized offset for user-space mmaps
  * @node: Linked offset node
  *
@@ -220,7 +207,7 @@ static inline __u64 drm_vma_node_offset_addr(struct 
drm_vma_offset_node *node)
 static inline void drm_vma_node_unmap(struct drm_vma_offset_node *node,
  struct address_space *file_mapping)
 {
-   if (drm_vma_node_has_offset(node))
+   if (drm_mm_node_allocated(>vm_node))
unmap_mapping_range(file_mapping,
drm_vma_node_offset_addr(node),
drm_vma_node_size(node) << PAGE_SHIFT, 1);
-- 
2.5.1

[PATCH RESEND 19/20] drm/vgem: Drop dev->struct_mutex

[Daniel Vetter]

With the previous two changes it doesn't protect anything any more.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 1a609347236b..b525208375aa 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -103,12 +103,8 @@ static int vgem_gem_fault(struct vm_area_struct *vma, 
struct vm_fault *vmf)
if (page_offset > num_pages)
return VM_FAULT_SIGBUS;

-   mutex_lock(>struct_mutex);
-
ret = vm_insert_page(vma, (unsigned long)vmf->virtual_address,
 obj->pages[page_offset]);
-
-   mutex_unlock(>struct_mutex);
switch (ret) {
case 0:
return VM_FAULT_NOPAGE;
@@ -205,12 +201,9 @@ int vgem_gem_dumb_map(struct drm_file *file, struct 
drm_device *dev,
int ret = 0;
struct drm_gem_object *obj;

-   mutex_lock(>struct_mutex);
obj = drm_gem_object_lookup(dev, file, handle);
-   if (!obj) {
-   ret = -ENOENT;
-   goto unlock;
-   }
+   if (!obj)
+   return -ENOENT;

ret = drm_gem_create_mmap_offset(obj);
if (ret)
@@ -224,8 +217,7 @@ int vgem_gem_dumb_map(struct drm_file *file, struct 
drm_device *dev,

 unref:
drm_gem_object_unreference(obj);
-unlock:
-   mutex_unlock(>struct_mutex);
+
return ret;
 }

-- 
2.5.1

[PATCH RESEND 18/20] drm/vgem: Move get_pages to gem_create

[Daniel Vetter]

vgem doesn't have a shrinker or anything like that and drops backing
storage only at object_free time. There's no use in trying to be
clever and allocating backing storage delayed, it only causes trouble
by requiring locking.

Instead grab pages when we allocate the object right away.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 63026d4324ad..1a609347236b 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -154,6 +154,10 @@ static struct drm_gem_object *vgem_gem_create(struct 
drm_device *dev,
if (err)
goto out;

+   ret = vgem_gem_get_pages(to_vgem_bo(obj));
+   if (ret)
+   goto out;
+
err = drm_gem_handle_create(file, gem_object, handle);
if (err)
goto handle_out;
@@ -216,16 +220,8 @@ int vgem_gem_dumb_map(struct drm_file *file, struct 
drm_device *dev,

obj->filp->private_data = obj;

-   ret = vgem_gem_get_pages(to_vgem_bo(obj));
-   if (ret)
-   goto fail_get_pages;
-
*offset = drm_vma_node_offset_addr(>vma_node);

-   goto unref;
-
-fail_get_pages:
-   drm_gem_free_mmap_offset(obj);
 unref:
drm_gem_object_unreference(obj);
 unlock:
-- 
2.5.1

[PATCH RESEND 17/20] drm/vgem: Simplify dum_map

[Daniel Vetter]

The offset manager already checks for existing offsets internally,
while holding suitable locks. We can drop this check.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 02ae60c395b7..63026d4324ad 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -208,11 +208,9 @@ int vgem_gem_dumb_map(struct drm_file *file, struct 
drm_device *dev,
goto unlock;
}

-   if (!drm_vma_node_has_offset(>vma_node)) {
-   ret = drm_gem_create_mmap_offset(obj);
-   if (ret)
-   goto unref;
-   }
+   ret = drm_gem_create_mmap_offset(obj);
+   if (ret)
+   goto unref;

BUG_ON(!obj->filp);

-- 
2.5.1

[PATCH RESEND 16/20] drm/exynos: drop struct_mutex from fbdev setup

[Daniel Vetter]

Doesn't protect anything at all, and probably just here because a long
time ago dev->struct_mutex was required to allocate gem objects.

With this patch exynos is completely struct_mutex free!

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index f6118baa8e3e..e1f7abaa61df 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -138,8 +138,6 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
  sizes->surface_depth);

-   mutex_lock(>struct_mutex);
-
size = mode_cmd.pitches[0] * mode_cmd.height;

exynos_gem = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);
@@ -154,10 +152,8 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
   size);
}

-   if (IS_ERR(exynos_gem)) {
-   ret = PTR_ERR(exynos_gem);
-   goto out;
-   }
+   if (IS_ERR(exynos_gem))
+   return PTR_ERR(exynos_gem);

exynos_fbdev->exynos_gem = exynos_gem;

@@ -173,7 +169,6 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
if (ret < 0)
goto err_destroy_framebuffer;

-   mutex_unlock(>struct_mutex);
return ret;

 err_destroy_framebuffer:
@@ -181,13 +176,12 @@ err_destroy_framebuffer:
 err_destroy_gem:
exynos_drm_gem_destroy(exynos_gem);

-/*
- * if failed, all resources allocated above would be released by
- * drm_mode_config_cleanup() when drm_load() had been called prior
- * to any specific driver such as fimd or hdmi driver.
- */
-out:
-   mutex_unlock(>struct_mutex);
+   /*
+* if failed, all resources allocated above would be released by
+* drm_mode_config_cleanup() when drm_load() had been called prior
+* to any specific driver such as fimd or hdmi driver.
+*/
+
return ret;
 }

-- 
2.5.1

[PATCH RESEND 15/20] drm/exynos: drop struct_mutex from exynos_drm_gem_get_ioctl

[Daniel Vetter]

The only things this protects is reading ->flags and ->size, both of
which are invariant over the lifetime of an exynos gem bo. So no
locking needed at all (besides that, nothing protects the writers
anyway).

Aside: exynos_gem_obj->size is redundant with
exynos_gem_obj->base.size and probably should be removed.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index a3286a1ec2b1..dfb3bfee1b63 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -352,12 +352,9 @@ int exynos_drm_gem_get_ioctl(struct drm_device *dev, void 
*data,
struct drm_exynos_gem_info *args = data;
struct drm_gem_object *obj;

-   mutex_lock(>struct_mutex);
-
obj = drm_gem_object_lookup(dev, file_priv, args->handle);
if (!obj) {
DRM_ERROR("failed to lookup gem object.\n");
-   mutex_unlock(>struct_mutex);
return -EINVAL;
}

@@ -367,7 +364,6 @@ int exynos_drm_gem_get_ioctl(struct drm_device *dev, void 
*data,
args->size = exynos_gem->size;

drm_gem_object_unreference(obj);
-   mutex_unlock(>struct_mutex);

return 0;
 }
-- 
2.5.1

[PATCH RESEND 14/20] drm/exynos: drop struct_mutex from exynos_gem_map_sgt_with_dma

[Daniel Vetter]

The sg table isn't refcounted, there's no corresponding locking for
unmapping and drm_map_sg is ok with being called concurrently.

So drop the locking since it doesn't protect anything.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 91d87e7c2a2f..a3286a1ec2b1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -378,16 +378,12 @@ int exynos_gem_map_sgt_with_dma(struct drm_device 
*drm_dev,
 {
int nents;

-   mutex_lock(_dev->struct_mutex);
-
nents = dma_map_sg(drm_dev->dev, sgt->sgl, sgt->nents, dir);
if (!nents) {
DRM_ERROR("failed to map sgl with dma.\n");
-   mutex_unlock(_dev->struct_mutex);
return nents;
}

-   mutex_unlock(_dev->struct_mutex);
return 0;
 }

-- 
2.5.1

[PATCH RESEND 13/20] drm/exynos: Drop dev->struct_mutex from mmap offset function

[Daniel Vetter]

Simply forgotten about this when I was doing my general cleansing of
simple gem mmap offset functions. There's nothing but core functions
called here, and they all have their own protection already.

Aside: DRM_ERROR for userspace controlled input isn't great, but
that's for another patch.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 252eb301470c..91d87e7c2a2f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -448,8 +448,6 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file 
*file_priv,
struct drm_gem_object *obj;
int ret = 0;

-   mutex_lock(>struct_mutex);
-
/*
 * get offset of memory allocated for drm framebuffer.
 * - this callback would be called by user application
@@ -459,16 +457,13 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file 
*file_priv,
obj = drm_gem_object_lookup(dev, file_priv, handle);
if (!obj) {
DRM_ERROR("failed to lookup gem object.\n");
-   ret = -EINVAL;
-   goto unlock;
+   return -EINVAL;
}

*offset = drm_vma_node_offset_addr(>vma_node);
DRM_DEBUG_KMS("offset = 0x%lx\n", (unsigned long)*offset);

drm_gem_object_unreference(obj);
-unlock:
-   mutex_unlock(>struct_mutex);
return ret;
 }

-- 
2.5.1

[PATCH RESEND 12/20] drm/nouveau: Drop dev->struct_mutex from fbdev init

[Daniel Vetter]

Doesn't protect anything at all.

With this patch nouveau is completely dev->struct_mutex free!

Cc: Ben Skeggs 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/nouveau_fbcon.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 59f27e774acb..3bae706126bd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -386,8 +386,6 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
}
}

-   mutex_lock(>struct_mutex);
-
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
@@ -426,8 +424,6 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,

/* Use default scratch pixmap (info->pixmap.flags = FB_PIXMAP_SYSTEM) */

-   mutex_unlock(>struct_mutex);
-
if (chan)
nouveau_fbcon_accel_init(dev);
nouveau_fbcon_zfill(dev, fbcon);
@@ -441,7 +437,6 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
return 0;

 out_unlock:
-   mutex_unlock(>struct_mutex);
if (chan)
nouveau_bo_vma_del(nvbo, >nouveau_fb.vma);
nouveau_bo_unmap(nvbo);
-- 
2.5.1

[PATCH RESEND 11/20] drm/gma500: Add driver private mutex for the fault handler

[Daniel Vetter]

There's currently two places where the gma500 fault handler relies
upon dev->struct_mutex:
- To protect r->mappping
- To make sure vm_insert_pfn isn't called concurrently (in which case
  the 2nd thread would get an error code).

Everything else (specifically psb_gtt_pin) is already protected by
some other locks. Hence just create a new driver-private mmap_mutex
just for this function.

With this gma500 is complete dev->struct_mutex free!

Cc: Patrik Jakobsson 
Acked-by: Patrik Jakobsson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/gma500/gem.c | 4 ++--
 drivers/gpu/drm/gma500/gtt.c | 1 +
 drivers/gpu/drm/gma500/psb_drv.h | 2 ++
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index f0357f525f56..506224b3a0ad 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -182,7 +182,7 @@ int psb_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)

/* Make sure we don't parallel update on a fault, nor move or remove
   something from beneath our feet */
-   mutex_lock(>struct_mutex);
+   mutex_lock(_priv->mmap_mutex);

/* For now the mmap pins the object and it stays pinned. As things
   stand that will do us no harm */
@@ -208,7 +208,7 @@ int psb_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
ret = vm_insert_pfn(vma, (unsigned long)vmf->virtual_address, pfn);

 fail:
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(_priv->mmap_mutex);
switch (ret) {
case 0:
case -ERESTARTSYS:
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index ce015db59dc6..8f69225ce2b4 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -425,6 +425,7 @@ int psb_gtt_init(struct drm_device *dev, int resume)

if (!resume) {
mutex_init(_priv->gtt_mutex);
+   mutex_init(_priv->mmap_mutex);
psb_gtt_alloc(dev);
}

diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index e21726ecac32..3bd2c726dd61 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -465,6 +465,8 @@ struct drm_psb_private {
struct mutex gtt_mutex;
struct resource *gtt_mem;   /* Our PCI resource */

+   struct mutex mmap_mutex;
+
struct psb_mmu_driver *mmu;
struct psb_mmu_pd *pf_pd;

-- 
2.5.1

[PATCH RESEND 10/20] drm/gma500: Drop dev->struct_mutex from mmap offset function

[Daniel Vetter]

Simply forgotten about this when I was doing my general cleansing of
simple gem mmap offset functions. There's nothing but core functions
called here, and they all have their own protection already.

Cc: Patrik Jakobsson 
Acked-by: Patrik Jakobsson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/gma500/gem.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index e3bdc8b1c32c..f0357f525f56 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -62,15 +62,10 @@ int psb_gem_dumb_map_gtt(struct drm_file *file, struct 
drm_device *dev,
int ret = 0;
struct drm_gem_object *obj;

-   mutex_lock(>struct_mutex);
-
/* GEM does all our handle to object mapping */
obj = drm_gem_object_lookup(dev, file, handle);
-   if (obj == NULL) {
-   ret = -ENOENT;
-   goto unlock;
-   }
-   /* What validation is needed here ? */
+   if (obj == NULL)
+   return -ENOENT;

/* Make it mmapable */
ret = drm_gem_create_mmap_offset(obj);
@@ -78,9 +73,7 @@ int psb_gem_dumb_map_gtt(struct drm_file *file, struct 
drm_device *dev,
goto out;
*offset = drm_vma_node_offset_addr(>vma_node);
 out:
-   drm_gem_object_unreference(obj);
-unlock:
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(obj);
return ret;
 }

-- 
2.5.1

[PATCH RESEND 09/20] drm/gma500: Drop dev->struct_mutex from fbdev init/teardown code

[Daniel Vetter]

This is init/teardown code, locking is just to appease locking checks.
And since gem create/free doesn't need this any more there's really no
reason for grabbing dev->struct_mutex.

Again important to switch obj_unref to _unlocked variants.

Cc: Patrik Jakobsson 
Acked-by: Patrik Jakobsson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/gma500/framebuffer.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index dc0508dca1d4..ee95c03a8c54 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -406,8 +406,6 @@ static int psbfb_create(struct psb_fbdev *fbdev,

memset(dev_priv->vram_addr + backing->offset, 0, size);

-   mutex_lock(>struct_mutex);
-
info = drm_fb_helper_alloc_fbi(>psb_fb_helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
@@ -463,17 +461,15 @@ static int psbfb_create(struct psb_fbdev *fbdev,
dev_dbg(dev->dev, "allocated %dx%d fb\n",
psbfb->base.width, psbfb->base.height);

-   mutex_unlock(>struct_mutex);
return 0;
 out_unref:
if (backing->stolen)
psb_gtt_free_range(dev, backing);
else
-   drm_gem_object_unreference(>gem);
+   drm_gem_object_unreference_unlocked(>gem);

drm_fb_helper_release_fbi(>psb_fb_helper);
 out_err1:
-   mutex_unlock(>struct_mutex);
psb_gtt_free_range(dev, backing);
return ret;
 }
@@ -569,7 +565,7 @@ static int psb_fbdev_destroy(struct drm_device *dev, struct 
psb_fbdev *fbdev)
drm_framebuffer_cleanup(>base);

if (psbfb->gtt)
-   drm_gem_object_unreference(>gtt->gem);
+   drm_gem_object_unreference_unlocked(>gtt->gem);
return 0;
 }

@@ -784,12 +780,8 @@ void psb_modeset_cleanup(struct drm_device *dev)
 {
struct drm_psb_private *dev_priv = dev->dev_private;
if (dev_priv->modeset) {
-   mutex_lock(>struct_mutex);
-
drm_kms_helper_poll_fini(dev);
psb_fbdev_fini(dev);
drm_mode_config_cleanup(dev);
-
-   mutex_unlock(>struct_mutex);
}
 }
-- 
2.5.1

[PATCH RESEND 08/20] drm/gma500: Drop dev->struct_mutex from modeset code

[Daniel Vetter]

It's either init code or already protected by other means. Note
that psb_gtt_pin/unpin has it's own lock, and that's really the
only piece of driver private state - all the modeset state is
protected with modeset locks already.

The only important bit is to switch all gem_obj_unref calls to the
_unlocked variant.

Cc: Patrik Jakobsson 
Acked-by: Patrik Jakobsson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/gma500/gma_display.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gma_display.c 
b/drivers/gpu/drm/gma500/gma_display.c
index 001b450b27b3..ff17af4cfc64 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -349,8 +349,6 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
/* If we didn't get a handle then turn the cursor off */
if (!handle) {
temp = CURSOR_MODE_DISABLE;
-   mutex_lock(>struct_mutex);
-
if (gma_power_begin(dev, false)) {
REG_WRITE(control, temp);
REG_WRITE(base, 0);
@@ -362,11 +360,9 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
gt = container_of(gma_crtc->cursor_obj,
  struct gtt_range, gem);
psb_gtt_unpin(gt);
-   drm_gem_object_unreference(gma_crtc->cursor_obj);
+   
drm_gem_object_unreference_unlocked(gma_crtc->cursor_obj);
gma_crtc->cursor_obj = NULL;
}
-
-   mutex_unlock(>struct_mutex);
return 0;
}

@@ -376,7 +372,6 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
return -EINVAL;
}

-   mutex_lock(>struct_mutex);
obj = drm_gem_object_lookup(dev, file_priv, handle);
if (!obj) {
ret = -ENOENT;
@@ -441,17 +436,15 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
if (gma_crtc->cursor_obj) {
gt = container_of(gma_crtc->cursor_obj, struct gtt_range, gem);
psb_gtt_unpin(gt);
-   drm_gem_object_unreference(gma_crtc->cursor_obj);
+   drm_gem_object_unreference_unlocked(gma_crtc->cursor_obj);
}

gma_crtc->cursor_obj = obj;
 unlock:
-   mutex_unlock(>struct_mutex);
return ret;

 unref_cursor:
-   drm_gem_object_unreference(obj);
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(obj);
return ret;
 }

-- 
2.5.1

[PATCH RESEND 07/20] drm/gma500: Use correct unref in the gem bo create function

[Daniel Vetter]

This is called without dev->struct_mutex held, we need to use the
_unlocked variant.

Never caught in the wild since you'd need an evil userspace which
races a gem_close ioctl call with the in-progress open.

Cc: Patrik Jakobsson 
Acked-by: Patrik Jakobsson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/gma500/gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index c707fa6fca85..e3bdc8b1c32c 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -130,7 +130,7 @@ int psb_gem_create(struct drm_file *file, struct drm_device 
*dev, u64 size,
return ret;
}
/* We have the initial and handle reference but need only one now */
-   drm_gem_object_unreference(>gem);
+   drm_gem_object_unreference_unlocked(>gem);
*handlep = handle;
return 0;
 }
-- 
2.5.1

[PATCH RESEND 06/20] drm/tegra: Use drm_gem_object_unreference_unlocked

[Daniel Vetter]

This only grabs the mutex when really needed, but still has a
might-acquire lockdep check to make sure that's always possible.
With this patch tegra is officially struct_mutex free, yay!

v2: refernce_unlocked doesn't exist as kbuild spotted.

Cc: Thierry Reding 
Acked-by: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/tegra/drm.c | 4 +---
 drivers/gpu/drm/tegra/gem.c | 6 +-
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index e0f827790a5e..41f4efef777b 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -277,9 +277,7 @@ host1x_bo_lookup(struct drm_device *drm, struct drm_file 
*file, u32 handle)
if (!gem)
return NULL;

-   mutex_lock(>struct_mutex);
-   drm_gem_object_unreference(gem);
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(gem);

bo = to_tegra_bo(gem);
return >base;
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index fb712316c522..fbec29516bcb 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -30,9 +30,7 @@ static void tegra_bo_put(struct host1x_bo *bo)
struct tegra_bo *obj = host1x_to_tegra_bo(bo);
struct drm_device *drm = obj->gem.dev;

-   mutex_lock(>struct_mutex);
-   drm_gem_object_unreference(>gem);
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(>gem);
 }

 static dma_addr_t tegra_bo_pin(struct host1x_bo *bo, struct sg_table **sgt)
@@ -74,9 +72,7 @@ static struct host1x_bo *tegra_bo_get(struct host1x_bo *bo)
struct tegra_bo *obj = host1x_to_tegra_bo(bo);
struct drm_device *drm = obj->gem.dev;

-   mutex_lock(>struct_mutex);
drm_gem_object_reference(>gem);
-   mutex_unlock(>struct_mutex);

return bo;
 }
-- 
2.5.1

[PATCH RESEND 05/20] drm/tegra: don't take dev->struct_mutex in mmap offset ioctl

[Daniel Vetter]

Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).

v2: Finally get rid of the copypasta from another commit in this
commit message. And convert to _unlocked like we need to (Patrik).

Cc: Patrik Jakobsson 
Cc: Thierry Reding 
Acked-by: Thierry Reding 
Reviewed-by: Patrik Jakobsson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/tegra/gem.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 01e16e146bfe..fb712316c522 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -408,12 +408,9 @@ int tegra_bo_dumb_map_offset(struct drm_file *file, struct 
drm_device *drm,
struct drm_gem_object *gem;
struct tegra_bo *bo;

-   mutex_lock(>struct_mutex);
-
gem = drm_gem_object_lookup(drm, file, handle);
if (!gem) {
dev_err(drm->dev, "failed to lookup GEM object\n");
-   mutex_unlock(>struct_mutex);
return -EINVAL;
}

@@ -421,9 +418,7 @@ int tegra_bo_dumb_map_offset(struct drm_file *file, struct 
drm_device *drm,

*offset = drm_vma_node_offset_addr(>gem.vma_node);

-   drm_gem_object_unreference(gem);
-
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(gem);

return 0;
 }
-- 
2.5.1

[PATCH RESEND 04/20] drm/armada: Use a private mutex to protect priv->linear

[Daniel Vetter]

Reusing the Big DRM Lock just leaks, and the few things left that
dev->struct_mutex protected are very well contained - it's just the
linear drm_mm manager.

With this armada is completely struct_mutex free!

Cc: Russell King 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/armada/armada_debugfs.c |  4 ++--
 drivers/gpu/drm/armada/armada_drm.h |  3 ++-
 drivers/gpu/drm/armada/armada_drv.c |  1 +
 drivers/gpu/drm/armada/armada_gem.c | 10 +-
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_debugfs.c 
b/drivers/gpu/drm/armada/armada_debugfs.c
index 471e45627f1e..d4f7ab0a30d4 100644
--- a/drivers/gpu/drm/armada/armada_debugfs.c
+++ b/drivers/gpu/drm/armada/armada_debugfs.c
@@ -21,9 +21,9 @@ static int armada_debugfs_gem_linear_show(struct seq_file *m, 
void *data)
struct armada_private *priv = dev->dev_private;
int ret;

-   mutex_lock(>struct_mutex);
+   mutex_lock(>linear_lock);
ret = drm_mm_dump_table(m, >linear);
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(>linear_lock);

return ret;
 }
diff --git a/drivers/gpu/drm/armada/armada_drm.h 
b/drivers/gpu/drm/armada/armada_drm.h
index 4df6f2af2b21..6d2d8be38297 100644
--- a/drivers/gpu/drm/armada/armada_drm.h
+++ b/drivers/gpu/drm/armada/armada_drm.h
@@ -57,7 +57,8 @@ struct armada_private {
DECLARE_KFIFO(fb_unref, struct drm_framebuffer *, 8);
struct drm_fb_helper*fbdev;
struct armada_crtc  *dcrtc[2];
-   struct drm_mm   linear;
+   struct drm_mm   linear; /* protectec by linear_lock */
+   struct mutexlinear_lock;
struct drm_property *csc_yuv_prop;
struct drm_property *csc_rgb_prop;
struct drm_property *colorkey_prop;
diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 77ab93d60125..3bd7e1cde99e 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -102,6 +102,7 @@ static int armada_drm_load(struct drm_device *dev, unsigned 
long flags)
dev->mode_config.preferred_depth = 24;
dev->mode_config.funcs = _drm_mode_config_funcs;
drm_mm_init(>linear, mem->start, resource_size(mem));
+   mutex_init(>linear_lock);

ret = component_bind_all(dev->dev, dev);
if (ret)
diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 59fafa468347..45e12d4c1722 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -46,7 +46,7 @@ static size_t roundup_gem_size(size_t size)
return roundup(size, PAGE_SIZE);
 }

-/* dev->struct_mutex is held here */
+/* dev_priv->linear_lock is held here */
 void armada_gem_free_object(struct drm_gem_object *obj)
 {
struct armada_gem_object *dobj = drm_to_armada_gem(obj);
@@ -144,10 +144,10 @@ armada_gem_linear_back(struct drm_device *dev, struct 
armada_gem_object *obj)
if (!node)
return -ENOSPC;

-   mutex_lock(>struct_mutex);
+   mutex_lock(>linear_lock);
ret = drm_mm_insert_node(>linear, node, size, align,
 DRM_MM_SEARCH_DEFAULT);
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(>linear_lock);
if (ret) {
kfree(node);
return ret;
@@ -158,9 +158,9 @@ armada_gem_linear_back(struct drm_device *dev, struct 
armada_gem_object *obj)
/* Ensure that the memory we're returning is cleared. */
ptr = ioremap_wc(obj->linear->start, size);
if (!ptr) {
-   mutex_lock(>struct_mutex);
+   mutex_lock(>linear_lock);
drm_mm_remove_node(obj->linear);
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(>linear_lock);
kfree(obj->linear);
obj->linear = NULL;
return -ENOMEM;
-- 
2.5.1

[PATCH RESEND 03/20] drm/armada: Drop struct_mutex from cursor paths

[Daniel Vetter]

The kms state itself is already protected by the modeset locks
acquired by the drm core. The only thing left is gem bo state, and
since the cursor code expects small objects which are statically
mapped at create time and then invariant over the lifetime of the gem
bo there's nothing to protect.

See armada_gem_dumb_create -> armada_gem_linear_back which assigns
obj->addr which is the only thing used by the cursor code.

Only tricky bit is to switch to the _unlocked unreference function.

Cc: Russell King 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/armada/armada_crtc.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index cebcab560626..67fed0bbe53a 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -928,11 +928,10 @@ static int armada_drm_crtc_cursor_set(struct drm_crtc 
*crtc,
}
}

-   mutex_lock(>struct_mutex);
if (dcrtc->cursor_obj) {
dcrtc->cursor_obj->update = NULL;
dcrtc->cursor_obj->update_data = NULL;
-   drm_gem_object_unreference(>cursor_obj->obj);
+   drm_gem_object_unreference_unlocked(>cursor_obj->obj);
}
dcrtc->cursor_obj = obj;
dcrtc->cursor_w = w;
@@ -942,7 +941,6 @@ static int armada_drm_crtc_cursor_set(struct drm_crtc *crtc,
obj->update_data = dcrtc;
obj->update = cursor_update;
}
-   mutex_unlock(>struct_mutex);

return ret;
 }
@@ -957,11 +955,9 @@ static int armada_drm_crtc_cursor_move(struct drm_crtc 
*crtc, int x, int y)
if (!dcrtc->variant->has_spu_adv_reg)
return -EFAULT;

-   mutex_lock(>struct_mutex);
dcrtc->cursor_x = x;
dcrtc->cursor_y = y;
ret = armada_drm_crtc_cursor_update(dcrtc, false);
-   mutex_unlock(>struct_mutex);

return ret;
 }
-- 
2.5.1

[PATCH RESEND 02/20] drm/armada: Don't grab dev->struct_mutex for in mmap offset ioctl

[Daniel Vetter]

Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).

v2: Split out the leak fix in dump_map_offset into a separate patch as
requested by Russell. Also align labels the same way as before to
stick with local coding style.

Cc: Russell King 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/armada/armada_gem.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 323da46c7ca8..59fafa468347 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -274,12 +274,10 @@ int armada_gem_dumb_map_offset(struct drm_file *file, 
struct drm_device *dev,
struct armada_gem_object *obj;
int ret = 0;

-   mutex_lock(>struct_mutex);
obj = armada_gem_object_lookup(dev, file, handle);
if (!obj) {
DRM_ERROR("failed to lookup gem object\n");
-   ret = -EINVAL;
-   goto err_unlock;
+   return -EINVAL;
}

/* Don't allow imported objects to be mapped */
@@ -295,9 +293,7 @@ int armada_gem_dumb_map_offset(struct drm_file *file, 
struct drm_device *dev,
}

  err_unref:
-   drm_gem_object_unreference(>obj);
- err_unlock:
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(>obj);

return ret;
 }
-- 
2.5.1

[PATCH RESEND 01/20] drm/armada: Plug leak in dumb_map_offset

[Daniel Vetter]

We need to drop the gem bo reference if it's an imported one.

Cc: Russell King 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/armada/armada_gem.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 60a688ef81c7..323da46c7ca8 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -285,7 +285,7 @@ int armada_gem_dumb_map_offset(struct drm_file *file, 
struct drm_device *dev,
/* Don't allow imported objects to be mapped */
if (obj->obj.import_attach) {
ret = -EINVAL;
-   goto err_unlock;
+   goto err_unref;
}

ret = drm_gem_create_mmap_offset(>obj);
@@ -294,6 +294,7 @@ int armada_gem_dumb_map_offset(struct drm_file *file, 
struct drm_device *dev,
DRM_DEBUG_DRIVER("handle %#x offset %llx\n", handle, *offset);
}

+ err_unref:
drm_gem_object_unreference(>obj);
  err_unlock:
mutex_unlock(>struct_mutex);
-- 
2.5.1

[PATCH RESEND 00/20] dev->struct_mutex locking crusade

[Daniel Vetter]

Hi all,

Here's my resend of the dev->struct_mutex locking removal patches. I'd like to
get them all into 4.5, so please pick them either up into your tree or ack them.
I'll send a pull request for the remaining in a few weeks.

Thanks, Daniel

Daniel Vetter (20):
  drm/armada: Plug leak in dumb_map_offset
  drm/armada: Don't grab dev->struct_mutex for in mmap offset ioctl
  drm/armada: Drop struct_mutex from cursor paths
  drm/armada: Use a private mutex to protect priv->linear
  drm/tegra: don't take dev->struct_mutex in mmap offset ioctl
  drm/tegra: Use drm_gem_object_unreference_unlocked
  drm/gma500: Use correct unref in the gem bo create function
  drm/gma500: Drop dev->struct_mutex from modeset code
  drm/gma500: Drop dev->struct_mutex from fbdev init/teardown code
  drm/gma500: Drop dev->struct_mutex from mmap offset function
  drm/gma500: Add driver private mutex for the fault handler
  drm/nouveau: Drop dev->struct_mutex from fbdev init
  drm/exynos: Drop dev->struct_mutex from mmap offset function
  drm/exynos: drop struct_mutex from exynos_gem_map_sgt_with_dma
  drm/exynos: drop struct_mutex from exynos_drm_gem_get_ioctl
  drm/exynos: drop struct_mutex from fbdev setup
  drm/vgem: Simplify dum_map
  drm/vgem: Move get_pages to gem_create
  drm/vgem: Drop dev->struct_mutex
  drm/vma_manage: Drop has_offset

 drivers/gpu/drm/armada/armada_crtc.c  |  6 +-
 drivers/gpu/drm/armada/armada_debugfs.c   |  4 ++--
 drivers/gpu/drm/armada/armada_drm.h   |  3 ++-
 drivers/gpu/drm/armada/armada_drv.c   |  1 +
 drivers/gpu/drm/armada/armada_gem.c   | 21 ---
 drivers/gpu/drm/drm_gem.c | 17 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 22 
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 15 +-
 drivers/gpu/drm/gma500/framebuffer.c  | 12 ++-
 drivers/gpu/drm/gma500/gem.c  | 19 ++---
 drivers/gpu/drm/gma500/gma_display.c  | 13 +++-
 drivers/gpu/drm/gma500/gtt.c  |  1 +
 drivers/gpu/drm/gma500/psb_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_gem.c   |  3 ---
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  5 -
 drivers/gpu/drm/tegra/drm.c   |  4 +---
 drivers/gpu/drm/tegra/gem.c   | 13 ++--
 drivers/gpu/drm/vgem/vgem_drv.c   | 34 +--
 include/drm/drm_vma_manager.h | 15 +-
 19 files changed, 69 insertions(+), 141 deletions(-)

-- 
2.5.1

[Intel-gfx] [PATCH 11/9] drm/i915: Opt out of vblank disable timer on >gen2

[Paulo Zanoni]

2014-05-26 11:26 GMT-03:00  :
> From: Ville Syrjälä 
>
> Now that the vblank races are plugged, we can opt out of using
> the vblank disable timer and just let vblank interrupts get
> disabled immediately when the last reference is dropped.
>
> Gen2 is the exception since it has no hardware frame counter.

Hi

Remember last week's FBC vblank optimization patch that had an
erroneous drm_crtc_vblank_get() instead of drm_crtc_vblank_count()?
After I fixed the bug in the patch I realized that it was the
unbalanced vblank_get() call that moved PC state residency up.

I did some experiments, and on my specific BDW machine, after running
"powertop --auto-tune", I get about 15-25% PC7 residency without FBC.
If I revert this patch, the number jumps to 40-45%. With FBC, the PC7
residency goes from 60-70% to 85-90% when I revert this patch. I'm
running just an idle Cinnamon with an open terminal.

So, since the commit message lacks more details, what are the
downsides of reverting this patch? What are the advantages of opting
out of the vblank timer? I see my desktop does tons and tons of vblank
get/put calls per second, so the disable timer makes a lot of sense.

I also wish there was some easy way to check how this patch (or its
revert) affect a bunch of different workloads...

(Also CCing Chris for insightful comments on performance)

Thanks,
Paulo

>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 28bae6e..4b2e7af 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -4364,6 +4364,14 @@ void intel_irq_init(struct drm_device *dev)
> dev->max_vblank_count = 0xff; /* only 24 bits of frame 
> count */
> }
>
> +   /*
> +* Opt out of the vblank disable timer on everything except gen2.
> +* Gen2 doesn't have a hardware frame counter and so depends on
> +* vblank interrupts to produce sane vblank seuquence numbers.
> +*/
> +   if (!IS_GEN2(dev))
> +   dev->vblank_disable_immediate = true;
> +
> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> dev->driver->get_vblank_timestamp = i915_get_vblank_timestamp;
> dev->driver->get_scanout_position = i915_get_crtc_scanoutpos;
> --
> 1.8.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Paulo Zanoni

Regression on Chromebook Pixel 2015 due to i915 fastboot always-on

[Jani Nikula]

On Wed, 18 Nov 2015, David Airlie  wrote:
> I'm assuming I'll get a pull request from Jani by the end of the week,
> and I'll pass it on to you as per normal, but it might be good if he
> could accelerate that.

Done. http://mid.gmane.org/87vb8yt4a2.fsf at intel.com

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[Bug 93021] Sometimes External Monitor stays black after resuming from suspend

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

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

Bug ID: 93021
   Summary: Sometimes External Monitor stays black after resuming
from suspend
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: holthuis.jan at googlemail.com

Sometimes my external monitor (Acer X223W) stays black (powersave mode) when
resuming from suspend. I'm using a HP ProBook 6465b (Llano/Sumo, AMD A6-APU,
Radeon HD6520G). The Monitor is connected to the DVI port of my HP docking
station (P/N: VB044AV).

My Desktop Environment (GNOME 3) still thinks it's connected, so some windows
aren't visible anymore.

Workarounds:
- Press WIN+P to disable the second monitor and use the Laptop screen only
- Power off the external monitor and then switch it on again. It then starts to
work again.

Some more information:
$ dmesg | tail -n 2
[ 7977.467770] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link
status failed
[ 7977.467815] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery
failed

$ uname -a
Linux jan-laptop 4.2.5-1-ARCH #1 SMP PREEMPT Tue Oct 27 08:13:28 CET 2015
x86_64 GNU/Linux

$ glxinfo | grep OpenGL | grep string
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD SUMO (DRM 2.43.0, LLVM 3.7.0)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.5
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 11.0.5
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.0.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

$ xrandr
Screen 0: minimum 320 x 200, current 3046 x 1050, maximum 8192 x 8192
VGA-0 disconnected (normal left inverted right x axis y axis)
LVDS connected primary 1366x768+0+0 (normal left inverted right x axis y axis)
309mm x 173mm
   1366x768  60.10*+
   1280x720  59.86  
   1152x768  59.78  
   1024x768  59.92  
   800x600   59.86  
   848x480   59.66  
   720x480   59.71  
   640x480   59.38  
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
DisplayPort-2 connected 1680x1050+1366+0 (normal left inverted right x axis y
axis) 474mm x 296mm
   1680x1050 59.95*+
   1600x1200 60.00  
   1400x1050 59.95  
   1280x1024 75.02  
   1440x900  74.9859.90  
   1280x960  60.00  
   1360x768  59.80  
   1152x864  75.00  
   1024x768  75.0870.0760.00  
   832x624   74.55  
   800x600   72.1975.0060.3256.25  
   640x480   75.0072.8166.6760.00  
   720x400   70.08  

$ cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 18
model   : 1
model name  : AMD A6-3410MX APU with Radeon(tm) HD Graphics
stepping: 0
microcode   : 0x327
cpu MHz : 1000.000
cache size  : 1024 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 6
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid
aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy
abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt arat cpb hw_pstate npt
lbrv svm_lock nrip_save pausefilter vmmcall
bugs: fxsave_leak sysret_ss_attrs
bogomips: 3195.26
TLB size: 1536 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate cpb

[... and 3 more times]

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

[PATCH] drm/atomic-helper: Check encoder/crtc constraints

[Jani Nikula]

On Wed, 18 Nov 2015, Daniel Vetter  wrote:
> This was totally lost when I originally created the atomic helpers.
>
> We probably should also check possible_clones in the helpers, but
> since the legacy ones didn't do that this is for a separate patch.
>
> Reported-by: Ville Syrjälä 
> Cc: Ville Syrjälä 
> Cc: Daniel Stone 
> Signed-off-by: Daniel Vetter 

Pushed to our topic/drm-fixes branch, thanks for the patch and review.

BR,
Jani.


> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 0c6f62168776..cfdc9931b08a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -210,6 +210,14 @@ update_connector_routing(struct drm_atomic_state *state, 
> int conn_idx)
>   return -EINVAL;
>   }
>  
> + if (!drm_encoder_crtc_ok(new_encoder, connector_state->crtc)) {
> + DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] incompatible with 
> [CRTC:%d]\n",
> +  new_encoder->base.id,
> +  new_encoder->name,
> +  connector_state->crtc->base.id);
> + return -EINVAL;
> + }
> +
>   if (new_encoder == connector_state->best_encoder) {
>   DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] keeps [ENCODER:%d:%s], now 
> on [CRTC:%d]\n",
>connector->base.id,

-- 
Jani Nikula, Intel Open Source Technology Center

[Bug 92923] SGPR spilling

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

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

pat  changed:

   What|Removed |Added

 Attachment #119606|0   |1
is obsolete||

--- Comment #3 from pat  ---
Created attachment 119948
  --> https://bugs.freedesktop.org/attachment.cgi?id=119948=edit
Game log file

Steam seems to mess with stderr, I hope this game log has the info you need.

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

[PATCH] drm/sysfs: Grab lock for edid/modes_show

[Daniel Vetter]

On Fri, Oct 02, 2015 at 01:08:40PM +0100, Emil Velikov wrote:
> On 2 October 2015 at 12:01, Daniel Vetter  wrote:
> > We chase pointers/lists without taking the locks protecting them,
> > which isn't that good.
> >
> > Fix it.
> >
> > v2: Actually unlock properly, spotted by Julia.
> >
> > v3: Put the label _before_ the mutex_unlock (Emil)
> >
> > Cc: Emil Velikov 
> > Cc: Julia Lawall 
> > Signed-off-by: Daniel Vetter 
> Patch does exactly what it says on the tin.
> 
> Reviewed-by: Emil Velikov 

Applied to drm-misc, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave -

i915 fixes for 4.4, including the revert for the backlight regression
Olof reported. Otherwise fixes all around.


BR,
Jani.

The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:

  Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-11-19

for you to fetch changes up to 7383123647566a813692bb37a1389c767ed89158:

  Revert "drm/i915: skip modeset if compatible for everyone." (2015-11-19 
10:38:09 +0200)


Imre Deak (1):
  drm/i915: get runtime PM reference around GEM set_caching IOCTL

Jani Nikula (2):
  drm/i915: quirk backlight present on Macbook 4, 1
  Revert "drm/i915: skip modeset if compatible for everyone."

Maarten Lankhorst (2):
  drm/i915: Clear intel_crtc->atomic before updating it.
  drm/i915: Consider SPLL as another shared pll, v2.

Mika Kuoppala (2):
  drm/i915: Fix GT frequency rounding
  drm/i915: Fix gpu frequency change tracing

Ville Syrjälä (2):
  drm/i915: Fix crtc_y assignment in intel_find_initial_plane_obj()
  drm/i915: Don't clobber the addfb2 ioctl params

 drivers/gpu/drm/i915/i915_drv.h  |  4 ++
 drivers/gpu/drm/i915/i915_gem.c  |  8 +++-
 drivers/gpu/drm/i915/i915_params.c   |  5 +++
 drivers/gpu/drm/i915/intel_crt.c | 31 ++-
 drivers/gpu/drm/i915/intel_ddi.c | 75 +++-
 drivers/gpu/drm/i915/intel_display.c | 37 +-
 drivers/gpu/drm/i915/intel_pm.c  | 10 +++--
 7 files changed, 118 insertions(+), 52 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH RESEND 15/20] drm/exynos: drop struct_mutex from exynos_drm_gem_get_ioctl

[Daniel Stone]

Hi,

On 19 November 2015 at 16:46, Daniel Vetter  wrote:
> @@ -367,7 +364,6 @@ int exynos_drm_gem_get_ioctl(struct drm_device *dev, void 
> *data,
> args->size = exynos_gem->size;
>
> drm_gem_object_unreference(obj);
> -   mutex_unlock(>struct_mutex);

drm_gem_object_unreference_unlocked, surely ...

Cheers,
Daniel

[PATCH 05/19] clk: sunxi: add DRAM gates

[Maxime Ripard]

On Fri, Nov 13, 2015 at 04:08:53PM +0800, Chen-Yu Tsai wrote:
> On Mon, Nov 9, 2015 at 12:18 PM, Chen-Yu Tsai  wrote:
> > On Fri, Oct 30, 2015 at 10:20 PM, Maxime Ripard
> >  wrote:
> >> The Allwinner SoCs have a gate controller to gate the access to the DRAM
> >> clock to the some devices that need to access the DRAM directly (mostly
> >> display / image related IPs).
> >>
> >> Use a simple gates driver to support it.
> >>
> >> Signed-off-by: Maxime Ripard 
> >
> > Acked-by: Chen-Yu Tsai 
> >
> >> ---
> >>  drivers/clk/sunxi/clk-simple-gates.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/clk/sunxi/clk-simple-gates.c 
> >> b/drivers/clk/sunxi/clk-simple-gates.c
> >> index 0214c6548afd..5666c767fa14 100644
> >> --- a/drivers/clk/sunxi/clk-simple-gates.c
> >> +++ b/drivers/clk/sunxi/clk-simple-gates.c
> >> @@ -112,6 +112,8 @@ CLK_OF_DECLARE(sun5i_a13_apb0, 
> >> "allwinner,sun5i-a13-apb0-gates-clk",
> >>sunxi_simple_gates_init);
> >>  CLK_OF_DECLARE(sun5i_a13_apb1, "allwinner,sun5i-a13-apb1-gates-clk",
> >>sunxi_simple_gates_init);
> >> +CLK_OF_DECLARE(sun5i_a13_dram, "allwinner,sun5i-a13-dram-gates-clk",
> >> +  sunxi_simple_gates_init);
> 
> Nit: Since the compatible added is sun5i, could you mention it in the
> commit message,
> to avoid confusion when we do this for the other families?

It will be fixed in the v2.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151119/e0f85642/attachment.sig>

[PATCH 01/19] clk: sunxi: Add display clock

[Maxime Ripard]

On Thu, Nov 12, 2015 at 12:31:54PM -0800, Stephen Boyd wrote:
> On 11/06, Maxime Ripard wrote:
> > Hi Stephen,
> > 
> > Thanks for your feedback!
> > 
> > On Fri, Oct 30, 2015 at 02:29:02PM -0700, Stephen Boyd wrote:
> > > > +
> > > > +   mux = kzalloc(sizeof(*mux), GFP_KERNEL);
> > > > +   if (!mux)
> > > [..]
> > > > +   goto free_reset;
> > > > +   }
> > > > +
> > > > +   return;
> > > > +
> > > > +free_reset:
> > > > +   kfree(reset_data);
> > > > +free_clk:
> > > > +   clk_unregister(clk);
> > > 
> > > We really ought to have a clk_composite_unregister() API.
> > 
> > Can we?
> > 
> > We can always unregister the clock itself, but do we have a way to
> > retrieve the structure that has been allocated in there?
> > 
> > (note that it also applies to the generic clocks registration: muxes,
> > dividers, and so on).
> 
> Yes we have a way. We've done the same sort of design for other
> generic clocks. Do the __clk_get_hw() thing like in clk-divider.c

Ack. I'll cook up a patch for this then.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151119/2f6046ef/attachment.sig>

[PATCH 04/19] clk: sunxi: Add TCON channel1 clock

[Maxime Ripard]

On Mon, Nov 09, 2015 at 11:36:15AM +0800, Chen-Yu Tsai wrote:
> >> > +   sclk1_parents[0] = sclk2_name;
> >> > +   sclk1_parents[1] = sclk2d2_name;
> >>
> >> Is there any need to expose these 2 clocks via DT using 
> >> of_clk_add_provider?
> >
> > No, as far as I'm aware, there's no user external to this clock
> > driver.
> >
> >> Note that these complex clock trees within a clock node breaks the
> >> assigned-clock-parents mechanism, as you can no longer specify the output
> >> clock's direct parents.
> >
> > There's no point of changing the parent either. Hardware blocks are
> > always connected to the leaf clock (sclk1). We could also model it as
> > an extra 1-bit divider, which would simplify a bit the logic though.
> 
> Probably not. You still have a gate to handle. It's just moving the
> divider from 1 clock to the other. I think the current approach of
> modeling it like the hardware is better.

Not really if you model it using sclk2 being a mux + gate, and sclk1
being a divider + gate. It works great using the composite clocks.

> About reparenting, what I meant was if sclk2 is not exposed through
> of_clk_add_provider, then we can't do assigned-clocks stuff on it,
> like setting a default parent or making each channel use a different
> source pll.

And we don't really want to. Using the divider allow us to simply set
the rate of sclk1, and the mux / divider will do the rest. Since only
sclk1 is exposed to the rest of the system, we do not really care
about the rate of sclk2 anyway.

> What I'm saying is if it is not expected to work with another core
> binding, we should probably note it somewhere.

Indeed.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151119/a439163e/attachment.sig>

[PATCH] drm/atomic-helper: Check encoder/crtc constraints

[Ville Syrjälä]

On Thu, Nov 19, 2015 at 03:02:09PM +0100, Daniel Vetter wrote:
> On Thu, Nov 19, 2015 at 12:12:28PM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 18, 2015 at 06:46:48PM +0100, Daniel Vetter wrote:
> > > This was totally lost when I originally created the atomic helpers.
> > > 
> > > We probably should also check possible_clones in the helpers, but
> > > since the legacy ones didn't do that this is for a separate patch.
> > > 
> > > Reported-by: Ville Syrjälä 
> > > Cc: Ville Syrjälä 
> > > Cc: Daniel Stone 
> > > Signed-off-by: Daniel Vetter 
> > 
> > Reviewed-by: Ville Syrjälä 
> > Tested-by: Ville Syrjälä 
> > 
> > But the rest of update_connector_routing() still looks somewhat bonkers
> > to me. For one, it assumes that both the old and new crtc for the
> > connector are part of the atomic state, but 
> > drm_atomic_set_crtc_for_connector()
> > only adds the new crtc, not the old one.
> 
> Nothing bonkers about it since drm_atomic_get_connector_state ensures that
> the corresponding crtc state is part of the update. Same logic applies for
> planes.

Ah, that's where it was. OK, so it's just seems bonkers in other ways ;)

Let's say we have as a starting point:
crtc0 -> enc0 -> conn0
crtc1 -> enc1 -> conn1

Then we do an atomic_ioctl()
-> set conn0 -> NULL
-> set conn1 -> crtc0
-> set conn2 -> crtc1

And if enc1 is the best_encoder for both conn1 and conn2,
it looks to me like we would silently end up with just:
crtc1 -> enc1 -> conn2

Even though the user asked for:
crtc0 -> conn1
crtc1 -> conn2

Also the code seems to assume that a single encoder can't drive multiple
connectors at once. Is that by design or an accident?

So I'm thinking maybe we should first check for routing conflicts in the
new state and fail if any were found. After that we could go through the
old state to steal stuff, and we should disallow stealing for the atomic
ioctl totally and only allow if from setcrtc.

> -Daniel
> 
> > 
> > > ---
> > >  drivers/gpu/drm/drm_atomic_helper.c | 8 
> > >  1 file changed, 8 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 0c6f62168776..cfdc9931b08a 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -210,6 +210,14 @@ update_connector_routing(struct drm_atomic_state 
> > > *state, int conn_idx)
> > >   return -EINVAL;
> > >   }
> > >  
> > > + if (!drm_encoder_crtc_ok(new_encoder, connector_state->crtc)) {
> > > + DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] incompatible with 
> > > [CRTC:%d]\n",
> > > +  new_encoder->base.id,
> > > +  new_encoder->name,
> > > +  connector_state->crtc->base.id);
> > > + return -EINVAL;
> > > + }
> > > +
> > >   if (new_encoder == connector_state->best_encoder) {
> > >   DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] keeps [ENCODER:%d:%s], now 
> > > on [CRTC:%d]\n",
> > >connector->base.id,
> > > -- 
> > > 2.5.1
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel OTC

[Bug 93017] complete system stalls while changing displays resolutions on a hybrid (intel/radeon) system

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

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

--- Comment #1 from Alex Deucher  ---
Might be similar to bug 92258.

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

[PATCH v3 03/12] drm/rockchip: return a true clock rate to adjusted_mode

[Chris Zhong]

On 11/19/2015 03:08 PM, Mark yao wrote:
> On 2015年11月19日 11:35, Chris Zhong wrote:
>> +
>> +/*
>> + * Sometimes the clock driver can not set a accurate clock_rate 
>> for vop,
>> + * get the true rate of vop_dclk and set it back to adjusted_mode.
>> + */
>> +adjusted_mode->clock = clk_get_rate(vop->dclk) / 1000;
>>   out:
>>   ret_clk = clk_enable(vop->dclk);
>>   if (ret_clk < 0) {
> Hi Chris
>  How about use clk_round_rate to check the clock rate first?
>  I think we can check it on vop_crtc_mode_fixup.
Hi Mark
 Nice advice, I'll modify it in next version. Thanks.
>
> Thanks.
> - ï¼­ark Yao
>
>
>

[PATCH] drm/sysfs: Send out uevent when connector->force changes

[Daniel Vetter]

To avoid even more code duplication punt this all to the probe worker,
which needs some slight adjustment to also generate a uevent when the
status has changed to due connector->force.

v2: Instead of running the output_poll_work (which is kinda the wrong
thing and a layering violation since it's an internal of the probe
helpers), or calling ->detect (which is again a layering violation
since it's used only by probe helpers) just call the official
->fill_modes function, like a GET_CONNECTOR ioctl call.

v3: Restore the accidentally removed forced-probe for echo "detect" >
force.

Cc: Chris Wilson 
Reported-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_probe_helper.c | 46 +++---
 drivers/gpu/drm/drm_sysfs.c| 38 +++
 2 files changed, 36 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index a214a4a93b03..b7bdf12c54a5 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -147,6 +147,8 @@ static int 
drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
list_for_each_entry(mode, >modes, head)
mode->status = MODE_UNVERIFIED;

+   old_status = connector->status;
+
if (connector->force) {
if (connector->force == DRM_FORCE_ON ||
connector->force == DRM_FORCE_ON_DIGITAL)
@@ -156,33 +158,31 @@ static int 
drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
if (connector->funcs->force)
connector->funcs->force(connector);
} else {
-   old_status = connector->status;
-
connector->status = connector->funcs->detect(connector, true);
+   }
+
+   /*
+* Normally either the driver's hpd code or the poll loop should
+* pick up any changes and fire the hotplug event. But if
+* userspace sneaks in a probe, we might miss a change. Hence
+* check here, and if anything changed start the hotplug code.
+*/
+   if (old_status != connector->status) {
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
%d\n",
+ connector->base.id,
+ connector->name,
+ old_status, connector->status);

/*
-* Normally either the driver's hpd code or the poll loop should
-* pick up any changes and fire the hotplug event. But if
-* userspace sneaks in a probe, we might miss a change. Hence
-* check here, and if anything changed start the hotplug code.
+* The hotplug event code might call into the fb
+* helpers, and so expects that we do not hold any
+* locks. Fire up the poll struct instead, it will
+* disable itself again.
 */
-   if (old_status != connector->status) {
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d 
to %d\n",
- connector->base.id,
- connector->name,
- old_status, connector->status);
-
-   /*
-* The hotplug event code might call into the fb
-* helpers, and so expects that we do not hold any
-* locks. Fire up the poll struct instead, it will
-* disable itself again.
-*/
-   dev->mode_config.delayed_event = true;
-   if (dev->mode_config.poll_enabled)
-   
schedule_delayed_work(>mode_config.output_poll_work,
- 0);
-   }
+   dev->mode_config.delayed_event = true;
+   if (dev->mode_config.poll_enabled)
+   
schedule_delayed_work(>mode_config.output_poll_work,
+ 0);
}

/* Re-enable polling in case the global poll config changed. */
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 9ac4ffa6cce3..df66d9447cb0 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -167,47 +167,35 @@ static ssize_t status_store(struct device *device,
 {
struct drm_connector *connector = to_drm_connector(device);
struct drm_device *dev = connector->dev;
-   enum drm_connector_status old_status;
+   enum drm_connector_force old_force;
int ret;

ret = mutex_lock_interruptible(>mode_config.mutex);
if (ret)
return ret;

-   old_status = connector->status;
+   old_force = connector->force;

-   if (sysfs_streq(buf, "detect")) {
+   if 

[PATCH] drm/atomic-helper: Check encoder/crtc constraints

[Daniel Vetter]

On Thu, Nov 19, 2015 at 3:24 PM, Ville Syrjälä
 wrote:
> On Thu, Nov 19, 2015 at 03:02:09PM +0100, Daniel Vetter wrote:
>> On Thu, Nov 19, 2015 at 12:12:28PM +0200, Ville Syrjälä wrote:
>> > On Wed, Nov 18, 2015 at 06:46:48PM +0100, Daniel Vetter wrote:
>> > > This was totally lost when I originally created the atomic helpers.
>> > >
>> > > We probably should also check possible_clones in the helpers, but
>> > > since the legacy ones didn't do that this is for a separate patch.
>> > >
>> > > Reported-by: Ville Syrjälä 
>> > > Cc: Ville Syrjälä 
>> > > Cc: Daniel Stone 
>> > > Signed-off-by: Daniel Vetter 
>> >
>> > Reviewed-by: Ville Syrjälä 
>> > Tested-by: Ville Syrjälä 
>> >
>> > But the rest of update_connector_routing() still looks somewhat bonkers
>> > to me. For one, it assumes that both the old and new crtc for the
>> > connector are part of the atomic state, but 
>> > drm_atomic_set_crtc_for_connector()
>> > only adds the new crtc, not the old one.
>>
>> Nothing bonkers about it since drm_atomic_get_connector_state ensures that
>> the corresponding crtc state is part of the update. Same logic applies for
>> planes.
>
> Ah, that's where it was. OK, so it's just seems bonkers in other ways ;)
>
> Let's say we have as a starting point:
> crtc0 -> enc0 -> conn0
> crtc1 -> enc1 -> conn1
>
> Then we do an atomic_ioctl()
> -> set conn0 -> NULL
> -> set conn1 -> crtc0
> -> set conn2 -> crtc1
>
> And if enc1 is the best_encoder for both conn1 and conn2,
> it looks to me like we would silently end up with just:
> crtc1 -> enc1 -> conn2
>
> Even though the user asked for:
> crtc0 -> conn1
> crtc1 -> conn2

Yeah this is what will happen, since perfect backwards compat to old
Vjuserspace. We could fix this (probably by outright disabling encoder
stealing), but I'm not too concerned really: Practically it's
impossible to ask for this config (since you can't plug in both HDMI
and DP). Same holds for other drivers, where encoder routing is at
most used to select between dvi and crt encoders for DVI-I/D.

> Also the code seems to assume that a single encoder can't drive multiple
> connectors at once. Is that by design or an accident?

That's by design - the cloning mask it as the encoder level, so hw
cloning happens between crtc/encders.

> So I'm thinking maybe we should first check for routing conflicts in the
> new state and fail if any were found. After that we could go through the
> old state to steal stuff, and we should disallow stealing for the atomic
> ioctl totally and only allow if from setcrtc.

Otoh I guess we could do that too, just for consistency. Simples
approach would be a bool in connector_state which we leave at false in
duplicate_state. Then on the first set_crtc_for_connector we set it to
true and refuse to steal from such connectors.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: Send a hotplug uevent after performing a sysfs connection probe

[Daniel Vetter]

On Thu, Nov 19, 2015 at 01:51:37PM +, Chris Wilson wrote:
> If we probe the connector status from sysfs and find it has a new value,
> we should synthesize the associated hotplug uevent. This keeps our
> behaviour consistent and informs userspace of any override or change
> imposed by the user.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/drm_sysfs.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 615b7e667320..382b82f871bc 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -208,6 +208,8 @@ static ssize_t status_store(struct device *device,
>   if (dev->mode_config.poll_enabled)
>   
> schedule_delayed_work(>mode_config.output_poll_work,
> 0);
> +
> + drm_kms_helper_hotplug_event(dev);

I don't like leaking these all over the place. What about the (untested)
idea below?
-Daniel

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index a214a4a93b03..b7bdf12c54a5 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -147,6 +147,8 @@ static int 
drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
list_for_each_entry(mode, >modes, head)
mode->status = MODE_UNVERIFIED;

+   old_status = connector->status;
+
if (connector->force) {
if (connector->force == DRM_FORCE_ON ||
connector->force == DRM_FORCE_ON_DIGITAL)
@@ -156,33 +158,31 @@ static int 
drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
if (connector->funcs->force)
connector->funcs->force(connector);
} else {
-   old_status = connector->status;
-
connector->status = connector->funcs->detect(connector, true);
+   }
+
+   /*
+* Normally either the driver's hpd code or the poll loop should
+* pick up any changes and fire the hotplug event. But if
+* userspace sneaks in a probe, we might miss a change. Hence
+* check here, and if anything changed start the hotplug code.
+*/
+   if (old_status != connector->status) {
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
%d\n",
+ connector->base.id,
+ connector->name,
+ old_status, connector->status);

/*
-* Normally either the driver's hpd code or the poll loop should
-* pick up any changes and fire the hotplug event. But if
-* userspace sneaks in a probe, we might miss a change. Hence
-* check here, and if anything changed start the hotplug code.
+* The hotplug event code might call into the fb
+* helpers, and so expects that we do not hold any
+* locks. Fire up the poll struct instead, it will
+* disable itself again.
 */
-   if (old_status != connector->status) {
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d 
to %d\n",
- connector->base.id,
- connector->name,
- old_status, connector->status);
-
-   /*
-* The hotplug event code might call into the fb
-* helpers, and so expects that we do not hold any
-* locks. Fire up the poll struct instead, it will
-* disable itself again.
-*/
-   dev->mode_config.delayed_event = true;
-   if (dev->mode_config.poll_enabled)
-   
schedule_delayed_work(>mode_config.output_poll_work,
- 0);
-   }
+   dev->mode_config.delayed_event = true;
+   if (dev->mode_config.poll_enabled)
+   
schedule_delayed_work(>mode_config.output_poll_work,
+ 0);
}

/* Re-enable polling in case the global poll config changed. */
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 9ac4ffa6cce3..8cc69f0b64bc 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -167,39 +167,28 @@ static ssize_t status_store(struct device *device,
 {
struct drm_connector *connector = to_drm_connector(device);
struct drm_device *dev = connector->dev;
-   enum drm_connector_status old_status;
+   enum drm_connector_force old_force;
int ret;

ret = mutex_lock_interruptible(>mode_config.mutex);
if (ret)
return 

[Bug 93017] complete system stalls while changing displays resolutions on a hybrid (intel/radeon) system

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

t;x0.0  162.00  1600 1664 1856 2160  1200 1201 1204 1250
+hsync +vsync (75.0 kHz e)
Nov 18 14:00:50 hopa /usr/lib/gdm3/gdm-x-session[2354]: (II) RADEON(G0):
Modeline "1680x1050"x0.0  119.00  1680 1728 1760 1840  1050 1053 1059 1080
+hsync -vsync (64.7 kHz e)
Nov 18 14:00:50 hopa kernel: BUG: unable to handle kernel NULL pointer
dereference at 0041
Nov 18 14:00:50 hopa kernel: IP: [] ttm_bo_wait+0x6b/0x170
[ttm]
Nov 18 14:00:50 hopa kernel: PGD 35dba067 PUD 35dbb067 PMD 0 
Nov 18 14:00:50 hopa kernel: Oops:  [#1] SMP 
Nov 18 14:00:50 hopa kernel: Modules linked in: fuse ctr ccm rfcomm
ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_addrtype br_netfilter bridge stp llc
dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c loop bnep
pci_stub vboxpci(
Nov 18 14:00:50 hopa kernel:  iosf_mbi x86_pkg_temp_thermal intel_powerclamp
coretemp kvm_intel kvm irqbypass pcspkr psmouse serio_raw sg i2c_i801 lpc_ich
shpchp evdev tpm_infineon mei_me mei snd_usb_audio snd_usbmidi_lib snd_rawmidi
snd_
Nov 18 14:00:50 hopa kernel:  sd_mod rtsx_pci_sdmmc mmc_core crct10dif_pclmul
crc32_pclmul crc32c_intel jitterentropy_rng sha256_ssse3 sha256_generic hmac
drbg ansi_cprng ahci libahci aesni_intel aes_x86_64 lrw gf128mul glue_helper
ablk_h
Nov 18 14:00:50 hopa kernel: CPU: 2 PID: 4571 Comm: kworker/2:0 Tainted: G 
  W  O4.4.0-rc1+ #2
Nov 18 14:00:50 hopa kernel: Hardware name: Hewlett-Packard HP ZBook 14/198F,
BIOS L71 Ver. 01.20 07/28/2014
Nov 18 14:00:50 hopa kernel: Workqueue: events ttm_bo_delayed_workqueue [ttm]
Nov 18 14:00:50 hopa kernel: task: 8804384d7100 ti: 880035e14000
task.ti: 880035e14000
Nov 18 14:00:50 hopa kernel: RIP: 0010:[] 
[] ttm_bo_wait+0x6b/0x170 [ttm]
Nov 18 14:00:50 hopa kernel: RSP: 0018:880035e17d70  EFLAGS: 00010246
Nov 18 14:00:50 hopa kernel: RAX:  RBX:  RCX:
0001
Nov 18 14:00:50 hopa kernel: RDX: 0ea6 RSI:  RDI:
8800a1626068
Nov 18 14:00:50 hopa kernel: RBP: 0001 R08: 8800a5c5cc78 R09:

Nov 18 14:00:50 hopa kernel: R10:  R11: 8804300f1dc0 R12:

Nov 18 14:00:50 hopa kernel: R13: 0001 R14: 8804382d76f8 R15:
88031b9b6400
Nov 18 14:00:50 hopa kernel: FS:  ()
GS:88044ea8() knlGS:
Nov 18 14:00:50 hopa kernel: CS:  0010 DS:  ES:  CR0: 80050033
Nov 18 14:00:50 hopa kernel: CR2: 0041 CR3: 00043018d000 CR4:
001406e0
Nov 18 14:00:50 hopa kernel: Stack:
Nov 18 14:00:50 hopa kernel:  0ea6 8800a1626068
88044ea959c0 8800a1626068
Nov 18 14:00:50 hopa kernel:  0001 0001
880437fcef40 
Nov 18 14:00:50 hopa kernel:  0001 a089b327
 0001
Nov 18 14:00:50 hopa kernel: Call Trace:
Nov 18 14:00:50 hopa kernel:  [] ?
ttm_bo_cleanup_refs_and_unlock+0x27/0x170 [ttm]
Nov 18 14:00:50 hopa kernel:  [] ?
ttm_bo_delayed_delete+0xbf/0x200 [ttm]
Nov 18 14:00:50 hopa kernel:  [] ?
ttm_bo_delayed_workqueue+0x17/0x40 [ttm]
Nov 18 14:00:50 hopa kernel:  [] ?
process_one_work+0x19f/0x3d0
Nov 18 14:00:50 hopa kernel:  [] ? worker_thread+0x4d/0x450
Nov 18 14:00:50 hopa kernel:  [] ?
process_one_work+0x3d0/0x3d0
Nov 18 14:00:50 hopa kernel:  [] ? kthread+0xbd/0xe0
Nov 18 14:00:50 hopa kernel:  [] ?
kthread_create_on_node+0x170/0x170
Nov 18 14:00:50 hopa kernel:  [] ? ret_from_fork+0x3f/0x70
Nov 18 14:00:50 hopa kernel:  [] ?
kthread_create_on_node+0x170/0x170
Nov 18 14:00:50 hopa kernel: Code: 85 ff 74 71 41 8b 47 10 ba a6 0e 00 00 85 c0
74 64 31 db eb 0e 83 c3 01 48 85 d2 7e 4f 41 39 5f 10 76 52 48 63 c3 49 8b 6c
c7 18 <48> 8b 45 40 a8 01 75 e2 48 8b 45 08 48 8b 40 18 48 85 c0 74 11 
Nov 18 14:00:50 hopa kernel: RIP  [] ttm_bo_wait+0x6b/0x170
[ttm]

Not sure if this particular traceback is associated with all the stalls -- I
think that in majority of the cases system stalls before any log/journal gets
dumped to the drive so it is not usually accessible after reboot.

I also setup xrandr providers to enable external displays connected to the
docking station:

xrandr --setprovideroffloadsink radeon Intel
xrandr --setprovideroutputsource radeon Intel

but I think I had stalls prior doing that (but it was with older kernels etc)

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

[PATCH v3 03/12] drm/rockchip: return a true clock rate to adjusted_mode

[Mark yao]

On 2015年11月19日 11:35, Chris Zhong wrote:
> +
> + /*
> +  * Sometimes the clock driver can not set a accurate clock_rate for vop,
> +  * get the true rate of vop_dclk and set it back to adjusted_mode.
> +  */
> + adjusted_mode->clock = clk_get_rate(vop->dclk) / 1000;
>   out:
>   ret_clk = clk_enable(vop->dclk);
>   if (ret_clk < 0) {
Hi Chris
  How about use clk_round_rate to check the clock rate first?
  I think we can check it on vop_crtc_mode_fixup.

Thanks.
- ï¼­ark Yao

[PATCH] drm/atomic-helper: Check encoder/crtc constraints

[Daniel Vetter]

On Thu, Nov 19, 2015 at 12:12:28PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 18, 2015 at 06:46:48PM +0100, Daniel Vetter wrote:
> > This was totally lost when I originally created the atomic helpers.
> > 
> > We probably should also check possible_clones in the helpers, but
> > since the legacy ones didn't do that this is for a separate patch.
> > 
> > Reported-by: Ville Syrjälä 
> > Cc: Ville Syrjälä 
> > Cc: Daniel Stone 
> > Signed-off-by: Daniel Vetter 
> 
> Reviewed-by: Ville Syrjälä 
> Tested-by: Ville Syrjälä 
> 
> But the rest of update_connector_routing() still looks somewhat bonkers
> to me. For one, it assumes that both the old and new crtc for the
> connector are part of the atomic state, but 
> drm_atomic_set_crtc_for_connector()
> only adds the new crtc, not the old one.

Nothing bonkers about it since drm_atomic_get_connector_state ensures that
the corresponding crtc state is part of the update. Same logic applies for
planes.
-Daniel

> 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 0c6f62168776..cfdc9931b08a 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -210,6 +210,14 @@ update_connector_routing(struct drm_atomic_state 
> > *state, int conn_idx)
> > return -EINVAL;
> > }
> >  
> > +   if (!drm_encoder_crtc_ok(new_encoder, connector_state->crtc)) {
> > +   DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] incompatible with 
> > [CRTC:%d]\n",
> > +new_encoder->base.id,
> > +new_encoder->name,
> > +connector_state->crtc->base.id);
> > +   return -EINVAL;
> > +   }
> > +
> > if (new_encoder == connector_state->best_encoder) {
> > DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] keeps [ENCODER:%d:%s], now 
> > on [CRTC:%d]\n",
> >  connector->base.id,
> > -- 
> > 2.5.1
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 92953] Segfault loading UT4 map/server

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

) limit (overrides VirtualMemoryLimitInKB value
from .ini)
[2015.11.19-14.45.05:289][  0]LogInit: Setting LC_NUMERIC to en_US
[2015.11.19-14.45.05:289][  0]LogInit: Initializing SDL.
Signal 11 caught.
EngineCrashHandler: Signal=11
Unreal.sh: line 3: 23220 Segmentation fault  (core dumped)

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

[PATCH v3 10/12] drm/panel: simple: Add support for BOE TV080WUM-NL0

[Emil Velikov]

Hi Chris,

Missing Thierry from the To/Cc list ? His name/email should have
popped up when using the get_mainteiners.pl script.

On 19 November 2015 at 03:35, Chris Zhong  wrote:
> This adds support for the BOE TV080WUM-NL0 1200x1920 mipi panel to the
> DRM simple panel driver.
>
> Signed-off-by: Chris Zhong 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/gpu/drm/panel/panel-simple.c | 33 +
>  1 file changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index f97b73e..3610e1c 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1348,6 +1348,36 @@ static const struct panel_desc_dsi 
> panasonic_vvx10f004b00 = {
> .lanes = 4,
>  };
>
> +static const struct drm_display_mode boe_tv080wum_nl0_mode = {
> +   .clock = 16,
> +   .hdisplay = 1200,
> +   .hsync_start = 1200 + 120,
> +   .hsync_end = 1200 + 120 + 20,
> +   .htotal = 1200 + 120 + 20 + 21,
> +   .vdisplay = 1920,
> +   .vsync_start = 1920 + 21,
> +   .vsync_end = 1920 + 21 + 3,
> +   .vtotal = 1920 + 21 + 3 + 18,
> +   .vrefresh = 60,
> +   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +};
> +
> +static const struct panel_desc_dsi boe_tv080wum_nl0 = {
> +   .desc = {
> +   .modes = _tv080wum_nl0_mode,
> +   .num_modes = 1,
> +   .size = {
> +   .width = 107,
> +   .height = 172,
> +   },
> +   },
> +   .flags = MIPI_DSI_MODE_VIDEO |
> +MIPI_DSI_MODE_VIDEO_BURST |
> +MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
> +   .format = MIPI_DSI_FMT_RGB888,
> +   .lanes = 4,
> +};
> +
>  static const struct of_device_id dsi_of_match[] = {
> {
> .compatible = "auo,b080uan01",
> @@ -1362,6 +1392,9 @@ static const struct of_device_id dsi_of_match[] = {
> .compatible = "panasonic,vvx10f004b00",
> .data = _vvx10f004b00
> }, {
> +   .compatible = "boe,tv080wum-nl0",
> +   .data = _tv080wum_nl0
> +   }, {

All the new additional should be sorted alphabetically - first by
vendor and then product name.

Regards,
Emil

[Bug 93015] Tonga Elemental segfault + VM faults since radeon: implement r600_query_hw_get_result via function pointers

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

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

Bug ID: 93015
   Summary: Tonga Elemental segfault + VM faults since  radeon:
implement r600_query_hw_get_result via function
pointers
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com

Unreal 4.5 Elemental demo on r9 285 using powerplay kernel.

Since mesa commit -

commit 50f0f938e3a577647fdfb6bdbb4ad3da252aa791
Author: Nicolai Hähnle 
Date:   Fri Nov 13 00:27:34 2015 +0100

radeon: implement r600_query_hw_get_result via function pointers

We will need the clear_result override for the batch query implementation.

About a minute into the demo (always same place) the demo will catch a segfault
and quit.

In dmesg I see a few VM faults.

While confirming the bisect I see that though it doesn't crash on the commit
before above =

commit c207c55fc08a1bf3dd40e79b3aaec34afbee2e55
Author: Nicolai Hähnle 
Date:   Wed Nov 18 12:05:11 2015 +0100

radeon: split hw query buffer handling from cs emit

The idea here is that driver queries implemented outside of common code
will use the same query buffer handling with different logic for starting
and stopping the corresponding counters.

At the point where it would have crashed I start getting flooded with VM faults

[17771.298259] VM fault (0x14, vmid 5) at page 1204016, write from 'TC0'
(0x54433000) (8)
[17771.330661] amdgpu :01:00.0: GPU fault detected: 146 0x04c20814
[17771.330665] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x00125E98
[17771.330666] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0B008014
[17771.330668] VM fault (0x14, vmid 5) at page 1203864, write from 'TC0'
(0x54433000) (8)
[17771.363320] amdgpu :01:00.0: GPU fault detected: 146 0x05e20814
[17771.363323] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001264BC
[17771.363325] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0B008014
[17771.363326] VM fault (0x14, vmid 5) at page 1205436, write from 'TC0'
(0x54433000) (8)
[17771.395828] amdgpu :01:00.0: GPU fault detected: 146 0x06620814
[17771.395832] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001260CC
[17771.395833] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0B008014
[17771.395834] VM fault (0x14, vmid 5) at page 1204428, write from 'TC0'
(0x54433000) (8)

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

[PATCH v3 00/12] Add mipi dsi support for rk3288

[Emil Velikov]

On 19 November 2015 at 03:35, Chris Zhong  wrote:
> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
> IP. This series adds support for a Synopsys DesignWare MIPI DSI host
> controller DRM bridge driver and a rockchip MIPI DSI specific DRM
> driver.
>
> This series also includes a DRM panel driver for BOE TV080WUM-NL0 panel.
> This panel only use the MIPI DSI video mode.
>
> The MIPI DSI feature is tested on rk3288 evb board, backport them to
> chrome os kernel v3.14, and it can display normally.
>
> This patchset is base on the patchset from Ying.liu at freescale.com.
> 
>
>
> Changes in v3:
> move the dw_mipi_dsi.txt to Documentation/devicetree/bindings/display/bridge
> move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/
> move boe,tv080wum-nl0.txt to bindings/display/panel/
>
> Changes in v2:
> add the mipi clk id in a single patch
> As Thierry.Reding comment, add a documentation for this panel.
>
> Chris Zhong (10):
>   clk: rockchip: add id for mipidsi sclk on rk3288
>   clk: rockchip: add mipidsi clocks on rk3288
>   drm/rockchip: return a true clock rate to adjusted_mode
>   drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
Did you actually rewrite the patch from Liu Ying ?
Out of curiosity what was the obstacle of this work getting merged ?

>   drm: rockchip: Support Synopsys DesignWare MIPI DSI host controller
>   Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
>   ARM: dts: rockchip: add rk3288 mipi_dsi nodes
>   drm/panel: simple: Add support for BOE TV080WUM-NL0
>   drm/panel: simple: Add boe,tv080wum-nl0 simple panel device tree
> binding
As the DT people will tell you - there is no BOE vendor in
bindings/vendor-prefixes.txt.

>   ARM: dts: rockchip: add support mipi panel tv080wum-nl0 for rk3288-evb
>
> Liu Ying (2):
>   drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
>   Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM
> bridge driver
>
>From the above 12 patches only ~6 reached this mailing list is that
intentional ? Previously I've seen people CC dri-devel for their
panel/bridge DT patches.

Regards,
Emil

[PATCH] drm/tegra: fix locking of SET_TILING ioctl

[Alexandre Courbot]

On Tue, Nov 17, 2015 at 7:02 PM, Daniel Vetter  wrote:
> On Thu, Nov 12, 2015 at 04:09:56PM +0900, Alexandre Courbot wrote:
>> drm_gem_object_unreference() now expects obj->dev->struct_mutex to be
>> held. Use the newly-introduced drm_gem_object_unreference_unlocked()
>> which handles locking for us.
>
> This rule has been really old, I simply made the checking more anal in
>
> commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
> Author: Daniel Vetter 
> Date:   Thu Oct 15 09:36:25 2015 +0200
>
> drm/gem: Check locking in drm_gem_object_unreference
>
> With the above added this is:
>
> Reviewed-by: Daniel Vetter 

[PATCH v2] drm/tegra: fix locking of SET_TILING ioctl

[Alexandre Courbot]

Commit ef4c6270bf28 made the check of whether struct_mutex is held more
verbose, and this triggers a warning when calling
drm_gem_object_unreference() from tegra_gem_set_tiling() which does not
acquire that lock.

Use drm_gem_object_unreference_unlocked() instead to ensure locking is
handled correctly.

Signed-off-by: Alexandre Courbot 
Reviewed-by: Daniel Vetter 
---
v2: fix commit log according to Daniel's comments, add review tag.

 drivers/gpu/drm/tegra/drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index cc48334ef164..c0ae89865958 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -683,7 +683,7 @@ static int tegra_gem_set_tiling(struct drm_device *drm, 
void *data,
bo->tiling.mode = mode;
bo->tiling.value = value;

-   drm_gem_object_unreference(gem);
+   drm_gem_object_unreference_unlocked(gem);

return 0;
 }
-- 
2.6.2

[PATCH] drm: Send a hotplug uevent after performing a sysfs connection probe

[Chris Wilson]

If we probe the connector status from sysfs and find it has a new value,
we should synthesize the associated hotplug uevent. This keeps our
behaviour consistent and informs userspace of any override or change
imposed by the user.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_sysfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 615b7e667320..382b82f871bc 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -208,6 +208,8 @@ static ssize_t status_store(struct device *device,
if (dev->mode_config.poll_enabled)

schedule_delayed_work(>mode_config.output_poll_work,
  0);
+
+   drm_kms_helper_hotplug_event(dev);
}

mutex_unlock(>mode_config.mutex);
-- 
2.6.2

[PATCH] [media] hdmi: added functions for MPEG InfoFrames

[Enric Balletbo Serra]

Hello Thierry,

2015-11-19 12:51 GMT+01:00 Thierry Reding :
> On Tue, Nov 17, 2015 at 11:55:53PM +0100, Enric Balletbo Serra wrote:
>> Hello Thierry,
>>
>> 2015-11-17 13:55 GMT+01:00 Thierry Reding :
>> > On Mon, Nov 16, 2015 at 05:28:24PM +0100, Enric Balletbo Serra wrote:
>> >> Hello Thierry,
>> >>
>> >> Many thanks for your comments.
>> >>
>> >> 2015-11-16 12:50 GMT+01:00 Thierry Reding :
>> >> > On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wrote:
>> >> >> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes 
>> >> >> aspects of
>> >> >> the compressed video stream that were used to produce the uncompressed
>> >> >> video.
>> >> >>
>> >> >> The patch adds functions to work with MPEG InfoFrames.
>> >> >>
>> >> >> Signed-off-by: Enric Balletbo i Serra 
>> >> >> ---
>> >> >>  drivers/video/hdmi.c | 156 
>> >> >> +++
>> >> >>  include/linux/hdmi.h |  24 
>> >> >>  2 files changed, 180 insertions(+)
>> >> >
>> >> > According to the CEA specification a source is expected to send this
>> >> > type of infoframe once per video frame. I'm curious how you envision
>> >> > this to be ensured. Would hardware provide a mechanism to store this
>> >> > data and send the infoframe automatically? How would you ensure that
>> >> > updates sent to the hardware match the upcoming frame?
>> >> >
>> >>
>> >> To be honest I'm not sure if I have the full picture. In the use case
>> >> I'm trying there is a hardware mechanism to store the data and send
>> >> the infoframe through a "Packet Send Control Register".
>> >
>> > Okay, sounds like the hardware will automatically send out packets at
>> > the right time. That still leaves open the issue of how to ensure this
>> > is synchronized with userspace. Perhaps this could be done by attaching
>> > a property to a framebuffer, so that we'd know what exact frame the meta
>> > data is attached to and when to update the FIFOs for the infoframe.
>> >
>> > Usually it's a good idea to send this type of patch as part of a larger
>> > series precisely so that people can see how it is used. That should make
>> > it easier to see if this is good enough or needs some more thought on
>> > how to synchronize. Do you have any code that you could post that makes
>> > use of this new infoframe?
>> >
>>
>> I was thinking use this and other helpers in the anx7814 bridge
>> driver[1], I thought that this patch should go through another tree,
>> this is the reason why I send it separately, but If you want or you
>> prefer I can send as part of these patch series.
>>
>> [1] https://lkml.org/lkml/2015/11/13/284
>
> I haven't seen those patches yet. I should've been Cc'ed on those
> patches since I'm technically the maintainer of drm/bridge. Did the
> get_maintainer.pl script not list me?
>

Mmm, just checked and yes, get_maintainer list you, so probably I did
something getting the maintainers.
Sorry.

> In my opinion, it's usually a good idea to keep all dependencies in a
> single series, just so people get a better picture of what you're
> submitting. Of course that's just my opinion, somebody else may yell at
> you because they get Cc'ed on patches that they're not interested in...
>
> As for merging patches, it's usually best to let maintainers figure that
> out once the series is in good shape.
>
> Thierry

[PATCH v3 06/12] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver

[kbuild test robot]

Hi Chris,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.4-rc1 next-20151118]
[cannot apply to rockchip/for-next]

url:
https://github.com/0day-ci/linux/commits/Chris-Zhong/Add-mipi-dsi-support-for-rk3288/20151119-114228
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: xtensa-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

   In file included from arch/xtensa/include/generated/asm/div64.h:1:0,
from include/linux/kernel.h:136,
from include/linux/clk.h:16,
from drivers/gpu/drm/bridge/dw_mipi_dsi.c:10:
   drivers/gpu/drm/bridge/dw_mipi_dsi.c: In function 
'dw_mipi_dsi_get_hcomponent_lbcc':
   include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer 
types lacks a cast
 (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
   ^
>> drivers/gpu/drm/bridge/dw_mipi_dsi.c:819:9: note: in expansion of macro 
>> 'do_div'
 frac = do_div(lbcc, dsi->mode->clock);
^
   drivers/gpu/drm/bridge/dw_mipi_dsi.c:819:2: warning: right shift count >= 
width of type
 frac = do_div(lbcc, dsi->mode->clock);
 ^
   In file included from arch/xtensa/include/generated/asm/div64.h:1:0,
from include/linux/kernel.h:136,
from include/linux/clk.h:16,
from drivers/gpu/drm/bridge/dw_mipi_dsi.c:10:
   include/asm-generic/div64.h:48:11: warning: passing argument 1 of 
'__div64_32' from incompatible pointer type
  __rem = __div64_32(&(n), __base); \
  ^
>> drivers/gpu/drm/bridge/dw_mipi_dsi.c:819:9: note: in expansion of macro 
>> 'do_div'
 frac = do_div(lbcc, dsi->mode->clock);
^
   include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but argument 
is of type 'u32 *'
extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
^

vim +/do_div +819 drivers/gpu/drm/bridge/dw_mipi_dsi.c

   803  static void dw_mipi_dsi_command_mode_config(struct dw_mipi_dsi *dsi)
   804  {
   805  dsi_write(dsi, DSI_TO_CNT_CFG, HSTX_TO_CNT(1000) | 
LPRX_TO_CNT(1000));
   806  dsi_write(dsi, DSI_BTA_TO_CNT, 0xd00);
   807  dsi_write(dsi, DSI_CMD_MODE_CFG, CMD_MODE_ALL_LP);
   808  dsi_write(dsi, DSI_MODE_CFG, ENABLE_CMD_MODE);
   809  }
   810  
   811  /* Get lane byte clock cycles. */
   812  static u32 dw_mipi_dsi_get_hcomponent_lbcc(struct dw_mipi_dsi *dsi,
   813 u32 hcomponent)
   814  {
   815  u32 frac, lbcc;
   816  
   817  lbcc = hcomponent * dsi->lane_mbps * MSEC_PER_SEC / 8;
   818  
 > 819  frac = do_div(lbcc, dsi->mode->clock);
   820  if (frac)
   821  lbcc++;
   822  
   823  return lbcc;
   824  }
   825  
   826  static void dw_mipi_dsi_line_timer_config(struct dw_mipi_dsi *dsi)
   827  {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 42991 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151119/d65fb6b8/attachment-0001.obj>

[PATCH] [media] hdmi: added functions for MPEG InfoFrames

[Thierry Reding]

On Tue, Nov 17, 2015 at 11:55:53PM +0100, Enric Balletbo Serra wrote:
> Hello Thierry,
> 
> 2015-11-17 13:55 GMT+01:00 Thierry Reding :
> > On Mon, Nov 16, 2015 at 05:28:24PM +0100, Enric Balletbo Serra wrote:
> >> Hello Thierry,
> >>
> >> Many thanks for your comments.
> >>
> >> 2015-11-16 12:50 GMT+01:00 Thierry Reding :
> >> > On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wrote:
> >> >> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes aspects 
> >> >> of
> >> >> the compressed video stream that were used to produce the uncompressed
> >> >> video.
> >> >>
> >> >> The patch adds functions to work with MPEG InfoFrames.
> >> >>
> >> >> Signed-off-by: Enric Balletbo i Serra 
> >> >> ---
> >> >>  drivers/video/hdmi.c | 156 
> >> >> +++
> >> >>  include/linux/hdmi.h |  24 
> >> >>  2 files changed, 180 insertions(+)
> >> >
> >> > According to the CEA specification a source is expected to send this
> >> > type of infoframe once per video frame. I'm curious how you envision
> >> > this to be ensured. Would hardware provide a mechanism to store this
> >> > data and send the infoframe automatically? How would you ensure that
> >> > updates sent to the hardware match the upcoming frame?
> >> >
> >>
> >> To be honest I'm not sure if I have the full picture. In the use case
> >> I'm trying there is a hardware mechanism to store the data and send
> >> the infoframe through a "Packet Send Control Register".
> >
> > Okay, sounds like the hardware will automatically send out packets at
> > the right time. That still leaves open the issue of how to ensure this
> > is synchronized with userspace. Perhaps this could be done by attaching
> > a property to a framebuffer, so that we'd know what exact frame the meta
> > data is attached to and when to update the FIFOs for the infoframe.
> >
> > Usually it's a good idea to send this type of patch as part of a larger
> > series precisely so that people can see how it is used. That should make
> > it easier to see if this is good enough or needs some more thought on
> > how to synchronize. Do you have any code that you could post that makes
> > use of this new infoframe?
> >
> 
> I was thinking use this and other helpers in the anx7814 bridge
> driver[1], I thought that this patch should go through another tree,
> this is the reason why I send it separately, but If you want or you
> prefer I can send as part of these patch series.
> 
> [1] https://lkml.org/lkml/2015/11/13/284

I haven't seen those patches yet. I should've been Cc'ed on those
patches since I'm technically the maintainer of drm/bridge. Did the
get_maintainer.pl script not list me?

In my opinion, it's usually a good idea to keep all dependencies in a
single series, just so people get a better picture of what you're
submitting. Of course that's just my opinion, somebody else may yell at
you because they get Cc'ed on patches that they're not interested in...

As for merging patches, it's usually best to let maintainers figure that
out once the series is in good shape.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151119/20600a54/attachment.sig>

[PATCH v2 0/7] drm/exynos: add pm runtime support

[Javier Martinez Canillas]

On 11/19/2015 11:55 AM, Javier Martinez Canillas wrote:
>>>
>>
>> This series causes a boot failure on at least an Exynos5800 Peach Pi
>> Chromebook (tested myself) and seems to be the cause of other Exynos
>> boards failing to boot: http://kernelci.org/boot/?exynos
>>
>> [snip]
>>
>>>   drm/exynos: add pm_runtime to Mixer
>>>   drm/exynos: add pm_runtime to FIMD
>>
>> I had to revert these patches in order to get the machine in a bootable
>> state again, the sha1 hash for these patches in next-20151119 are:
>>
>> 045febd5f813 drm/exynos: add pm_runtime to FIMD

On a closer look, only reverting the FIMD patch is enough
to make at least the Exynos5800 Peach Pi to boot again.

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

[PATCH v3 06/12] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver

[kbuild test robot]

Hi Chris,

[auto build test WARNING on: drm/drm-next]
[also build test WARNING on: v4.4-rc1 next-20151118]
[cannot apply to: rockchip/for-next]

url:
https://github.com/0day-ci/linux/commits/Chris-Zhong/Add-mipi-dsi-support-for-rk3288/20151119-114228
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: sparc-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/bridge/dw_mipi_dsi.c: In function 
'dw_mipi_dsi_dcs_short_write':
>> drivers/gpu/drm/bridge/dw_mipi_dsi.c:525:4: warning: format '%d' expects 
>> argument of type 'int', but argument 3 has type 'size_t' [-Wformat=]
   msg->tx_len);
   ^
   drivers/gpu/drm/bridge/dw_mipi_dsi.c: In function 
'dw_mipi_dsi_dcs_long_write':
   drivers/gpu/drm/bridge/dw_mipi_dsi.c:542:4: warning: format '%d' expects 
argument of type 'int', but argument 3 has type 'size_t' [-Wformat=]
   msg->tx_len);
   ^

vim +525 drivers/gpu/drm/bridge/dw_mipi_dsi.c

   509  if (ret < 0) {
   510  dev_err(dsi->dev, "failed to write command FIFO\n");
   511  return ret;
   512  }
   513  
   514  return 0;
   515  }
   516  
   517  static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
   518 const struct mipi_dsi_msg *msg)
   519  {
   520  const u16 *tx_buf = msg->tx_buf;
   521  u32 val = GEN_HDATA(*tx_buf) | GEN_HTYPE(msg->type);
   522  
   523  if (msg->tx_len > 2) {
   524  dev_err(dsi->dev, "too long tx buf length %d for short 
write\n",
 > 525  msg->tx_len);
   526  return -EINVAL;
   527  }
   528  
   529  return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);
   530  }
   531  
   532  static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
   533const struct mipi_dsi_msg *msg)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 44466 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151119/683f0d0e/attachment-0001.obj>

[PATCH v3 06/12] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver

[kbuild test robot]

Hi Chris,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.4-rc1 next-20151118]
[cannot apply to rockchip/for-next]

url:
https://github.com/0day-ci/linux/commits/Chris-Zhong/Add-mipi-dsi-support-for-rk3288/20151119-114228
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: openrisc-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/bridge/dw_mipi_dsi.c: In function 
'dw_mipi_dsi_get_hcomponent_lbcc':
>> drivers/gpu/drm/bridge/dw_mipi_dsi.c:819:9: warning: comparison of distinct 
>> pointer types lacks a cast
>> drivers/gpu/drm/bridge/dw_mipi_dsi.c:819:2: warning: right shift count >= 
>> width of type
>> drivers/gpu/drm/bridge/dw_mipi_dsi.c:819:2: warning: passing argument 1 of 
>> '__div64_32' from incompatible pointer type
   include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but argument 
is of type 'u32 *'

vim +819 drivers/gpu/drm/bridge/dw_mipi_dsi.c

   803  static void dw_mipi_dsi_command_mode_config(struct dw_mipi_dsi *dsi)
   804  {
   805  dsi_write(dsi, DSI_TO_CNT_CFG, HSTX_TO_CNT(1000) | 
LPRX_TO_CNT(1000));
   806  dsi_write(dsi, DSI_BTA_TO_CNT, 0xd00);
   807  dsi_write(dsi, DSI_CMD_MODE_CFG, CMD_MODE_ALL_LP);
   808  dsi_write(dsi, DSI_MODE_CFG, ENABLE_CMD_MODE);
   809  }
   810  
   811  /* Get lane byte clock cycles. */
   812  static u32 dw_mipi_dsi_get_hcomponent_lbcc(struct dw_mipi_dsi *dsi,
   813 u32 hcomponent)
   814  {
   815  u32 frac, lbcc;
   816  
   817  lbcc = hcomponent * dsi->lane_mbps * MSEC_PER_SEC / 8;
   818  
 > 819  frac = do_div(lbcc, dsi->mode->clock);
   820  if (frac)
   821  lbcc++;
   822  
   823  return lbcc;
   824  }
   825  
   826  static void dw_mipi_dsi_line_timer_config(struct dw_mipi_dsi *dsi)
   827  {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 35778 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151119/f2eeb661/attachment-0001.obj>

[PATCH] drm/atomic-helper: Check encoder/crtc constraints

[Ville Syrjälä]

On Wed, Nov 18, 2015 at 06:46:48PM +0100, Daniel Vetter wrote:
> This was totally lost when I originally created the atomic helpers.
> 
> We probably should also check possible_clones in the helpers, but
> since the legacy ones didn't do that this is for a separate patch.
> 
> Reported-by: Ville Syrjälä 
> Cc: Ville Syrjälä 
> Cc: Daniel Stone 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Ville Syrjälä 
Tested-by: Ville Syrjälä 

But the rest of update_connector_routing() still looks somewhat bonkers
to me. For one, it assumes that both the old and new crtc for the
connector are part of the atomic state, but drm_atomic_set_crtc_for_connector()
only adds the new crtc, not the old one.

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 0c6f62168776..cfdc9931b08a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -210,6 +210,14 @@ update_connector_routing(struct drm_atomic_state *state, 
> int conn_idx)
>   return -EINVAL;
>   }
>  
> + if (!drm_encoder_crtc_ok(new_encoder, connector_state->crtc)) {
> + DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] incompatible with 
> [CRTC:%d]\n",
> +  new_encoder->base.id,
> +  new_encoder->name,
> +  connector_state->crtc->base.id);
> + return -EINVAL;
> + }
> +
>   if (new_encoder == connector_state->best_encoder) {
>   DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] keeps [ENCODER:%d:%s], now 
> on [CRTC:%d]\n",
>connector->base.id,
> -- 
> 2.5.1

-- 
Ville Syrjälä
Intel OTC

[PATCH v2 0/7] drm/exynos: add pm runtime support

[Javier Martinez Canillas]

On 11/19/2015 11:51 AM, Javier Martinez Canillas wrote:
> [adding Kevin and Tyler to cc list]
>
> Hello Inki and Gustavo,

I didn't notice before that Gustavo was not cc'ed in the
original email from Inki so I'm adding him as well.

Sorry to others for the noise.

> 
> On 11/03/2015 07:47 AM, Inki Dae wrote:
>> This patch series adds pm runtime support for Exynos drm.
>>
>> Originally, this patch was posted by Gustavo but there was no any
>> answer about some comments. So I rebased this patch series on top of
>> exynos-drm-next, removed unnecessary patches and modified wrong macro.
>>
>> Changelog v2:
>> - Remove patch 5 and 6.
>>   . commit callback are already removed so isn't required anymore.
>> - Remove patch 8 which makes dp clock enabled directly from FIMD.
>>   . Really not mendatory for FIMD uses DP, and it could be different
>> according to Board.
>> - Modified CONFIG_PM_SLEEP to CONFIG_PM.
>>   . In case of runtime pm, CONFIG_PM macro should be used instead of
>> CONFIG_PM_SLEEP.
>>
> 
> This series causes a boot failure on at least an Exynos5800 Peach Pi
> Chromebook (tested myself) and seems to be the cause of other Exynos
> boards failing to boot: http://kernelci.org/boot/?exynos
> 
> [snip]
> 
>>   drm/exynos: add pm_runtime to Mixer
>>   drm/exynos: add pm_runtime to FIMD
> 
> I had to revert these patches in order to get the machine in a bootable
> state again, the sha1 hash for these patches in next-20151119 are:
> 
> 045febd5f813 drm/exynos: add pm_runtime to FIMD
> dd766fb8479b drm/exynos: add pm_runtime to Mixer
> 
> Best regards,
> 

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

[PATCH v2 0/7] drm/exynos: add pm runtime support

[Javier Martinez Canillas]

[adding Kevin and Tyler to cc list]

Hello Inki and Gustavo,

On 11/03/2015 07:47 AM, Inki Dae wrote:
> This patch series adds pm runtime support for Exynos drm.
> 
> Originally, this patch was posted by Gustavo but there was no any
> answer about some comments. So I rebased this patch series on top of
> exynos-drm-next, removed unnecessary patches and modified wrong macro.
> 
> Changelog v2:
> - Remove patch 5 and 6.
>   . commit callback are already removed so isn't required anymore.
> - Remove patch 8 which makes dp clock enabled directly from FIMD.
>   . Really not mendatory for FIMD uses DP, and it could be different
> according to Board.
> - Modified CONFIG_PM_SLEEP to CONFIG_PM.
>   . In case of runtime pm, CONFIG_PM macro should be used instead of
> CONFIG_PM_SLEEP.
>

This series causes a boot failure on at least an Exynos5800 Peach Pi
Chromebook (tested myself) and seems to be the cause of other Exynos
boards failing to boot: http://kernelci.org/boot/?exynos

[snip]

>   drm/exynos: add pm_runtime to Mixer
>   drm/exynos: add pm_runtime to FIMD

I had to revert these patches in order to get the machine in a bootable
state again, the sha1 hash for these patches in next-20151119 are:

045febd5f813 drm/exynos: add pm_runtime to FIMD
dd766fb8479b drm/exynos: add pm_runtime to Mixer

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

[PATCH v3 11/12] drm/panel: simple: Add boe, tv080wum-nl0 simple panel device tree binding

[Chris Zhong]

This binding specifies a set of common properties for display panels. It
can be used as a basis by bindings for specific panels.
Bindings for three specific panels are provided to show how the
simple panel binding can be used.

Signed-off-by: Chris Zhong 

---

Changes in v3:
move boe,tv080wum-nl0.txt to bindings/display/panel/

Changes in v2:
As Thierry.Reding comment, add a documentation for this panel.

 .../devicetree/bindings/display/panel/boe,tv080wum-nl0.txt | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt 
b/Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt
new file mode 100644
index 000..50be5e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt
@@ -0,0 +1,7 @@
+Boe Corporation 8.0" WUXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,tv080wum-nl0"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
2.6.3

[PATCH v3 10/12] drm/panel: simple: Add support for BOE TV080WUM-NL0

[Chris Zhong]

This adds support for the BOE TV080WUM-NL0 1200x1920 mipi panel to the
DRM simple panel driver.

Signed-off-by: Chris Zhong 
---

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/panel/panel-simple.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f97b73e..3610e1c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1348,6 +1348,36 @@ static const struct panel_desc_dsi 
panasonic_vvx10f004b00 = {
.lanes = 4,
 };

+static const struct drm_display_mode boe_tv080wum_nl0_mode = {
+   .clock = 16,
+   .hdisplay = 1200,
+   .hsync_start = 1200 + 120,
+   .hsync_end = 1200 + 120 + 20,
+   .htotal = 1200 + 120 + 20 + 21,
+   .vdisplay = 1920,
+   .vsync_start = 1920 + 21,
+   .vsync_end = 1920 + 21 + 3,
+   .vtotal = 1920 + 21 + 3 + 18,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc_dsi boe_tv080wum_nl0 = {
+   .desc = {
+   .modes = _tv080wum_nl0_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 107,
+   .height = 172,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO |
+MIPI_DSI_MODE_VIDEO_BURST |
+MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 4,
+};
+
 static const struct of_device_id dsi_of_match[] = {
{
.compatible = "auo,b080uan01",
@@ -1362,6 +1392,9 @@ static const struct of_device_id dsi_of_match[] = {
.compatible = "panasonic,vvx10f004b00",
.data = _vvx10f004b00
}, {
+   .compatible = "boe,tv080wum-nl0",
+   .data = _tv080wum_nl0
+   }, {
/* sentinel */
}
 };
-- 
2.6.3

[PATCH v3 07/12] drm: rockchip: Support Synopsys DesignWare MIPI DSI host controller

[Chris Zhong]

Add support for Synopsys DesignWare MIPI DSI host controller which is
embedded in the rk3288 SoCs.

Signed-off-by: Chris Zhong 
---

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/rockchip/Kconfig|  10 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c | 249 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   3 +
 4 files changed, 263 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..24395f3 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,13 @@ config ROCKCHIP_DW_HDMI
  for the Synopsys DesignWare HDMI driver. If you want to
  enable HDMI on RK3288 based SoC, you should selet this
  option.
+
+config ROCKCHIP_DW_MIPI_DSI
+   bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
+   depends on DRM_ROCKCHIP
+   select DRM_DW_MIPI_DSI
+   help
+This selects support for Rockchip SoC specific extensions
+for the Synopsys DesignWare HDMI driver. If you want to
+enable MIPI DSI on RK3288 based SoC, you should selet this
+option.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index f3d8a19..6a97059 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,5 +6,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o 
rockchip_drm_fbdev.o \
rockchip_drm_gem.o

 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw_mipi_dsi_rockchip.o

 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
diff --git a/drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c 
b/drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c
new file mode 100644
index 000..a0bb4eb
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c
@@ -0,0 +1,249 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define DRIVER_NAME"rockchip-mipi-dsi"
+
+#define GRF_SOC_CON60x025c
+#define DSI0_SEL_VOP_LIT(1 << 6)
+#define DSI1_SEL_VOP_LIT(1 << 9)
+
+struct rockchip_mipi_dsi {
+   struct drm_encoder encoder;
+   struct device *dev;
+   struct regmap *regmap;
+};
+
+static inline struct rockchip_mipi_dsi *enc_to_dsi(struct drm_encoder *enc)
+{
+   return container_of(enc, struct rockchip_mipi_dsi, encoder);
+}
+
+static struct drm_encoder_funcs rockchip_mipi_dsi_encoder_funcs = {
+   .destroy = drm_encoder_cleanup,
+};
+
+static int rockchip_mipi_parse_dt(struct rockchip_mipi_dsi *dsi)
+{
+   struct device_node *np = dsi->dev->of_node;
+
+   dsi->regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+   if (IS_ERR(dsi->regmap)) {
+   dev_err(dsi->dev, "Unable to get rockchip,grf\n");
+   return PTR_ERR(dsi->regmap);
+   }
+
+   return 0;
+}
+
+static bool rockchip_mipi_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
+   const struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
+{
+   return true;
+}
+
+static void rockchip_mipi_dsi_encoder_prepare(struct drm_encoder *encoder)
+{
+   u32 encoder_pix_fmt, interface_pix_fmt;
+
+   encoder_pix_fmt = dw_mipi_dsi_get_encoder_pixel_format(encoder);
+
+   switch (encoder_pix_fmt) {
+   case MIPI_DSI_FMT_RGB888:
+   interface_pix_fmt = ROCKCHIP_OUT_MODE_P888;
+   break;
+   case MIPI_DSI_FMT_RGB666:
+   interface_pix_fmt = ROCKCHIP_OUT_MODE_P666;
+   break;
+   case MIPI_DSI_FMT_RGB565:
+   interface_pix_fmt = ROCKCHIP_OUT_MODE_P565;
+   break;
+   default:
+   WARN_ON(1);
+   return;
+   }
+
+   rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_DSI,
+ interface_pix_fmt);
+}
+
+static void rockchip_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,
+   struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
+{
+}
+
+static void rockchip_mipi_dsi_encoder_commit(struct drm_encoder *encoder)
+{
+   struct rockchip_mipi_dsi *dsi = enc_to_dsi(encoder);
+   

[PATCH v3 06/12] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver

[Chris Zhong]

add Synopsys DesignWare MIPI DSI host controller driver support.

Signed-off-by: Chris Zhong 
---

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/Kconfig   |   11 +
 drivers/gpu/drm/bridge/Makefile  |1 +
 drivers/gpu/drm/bridge/dw_mipi_dsi.c | 1055 ++
 include/drm/bridge/dw_mipi_dsi.h |   27 +
 4 files changed, 1094 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/dw_mipi_dsi.c
 create mode 100644 include/drm/bridge/dw_mipi_dsi.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 639..c0900e0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -22,6 +22,17 @@ config DRM_DW_HDMI_AHB_AUDIO
  Designware HDMI block.  This is used in conjunction with
  the i.MX6 HDMI driver.

+config DRM_DW_MIPI_DSI
+   tristate "Synopsys DesignWare MIPI DSI host controller bridge"
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL
+   help
+ Choose this if you want to use the Synopsys DesignWare MIPI DSI host
+ controller bridge. If M is selected, the module will be
+ called dw_mipi_dsi. DRM_MIPI_DSI support is required for this driver
+ to work.

 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d4e28be..d908c4b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,5 +2,6 @@ ccflags-y := -Iinclude/drm

 obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw_hdmi-ahb-audio.o
+obj-$(CONFIG_DRM_DW_MIPI_DSI) += dw_mipi_dsi.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
diff --git a/drivers/gpu/drm/bridge/dw_mipi_dsi.c 
b/drivers/gpu/drm/bridge/dw_mipi_dsi.c
new file mode 100644
index 000..442fc7c
--- /dev/null
+++ b/drivers/gpu/drm/bridge/dw_mipi_dsi.c
@@ -0,0 +1,1055 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DSI_VERSION0x00
+
+#define DSI_PWR_UP 0x04
+#define RESET  0
+#define POWERUPBIT(0)
+
+#define DSI_CLKMGR_CFG 0x08
+#define TO_CLK_DIVIDSION(div)  (((div) & 0xff) << 8)
+#define TX_ESC_CLK_DIVIDSION(div)  (((div) & 0xff) << 0)
+
+#define DSI_DPI_VCID   0x0c
+#define DPI_VID(vid)   (((vid) & 0x3) << 0)
+
+#define DSI_DPI_COLOR_CODING   0x10
+#define EN18_LOOSELY   BIT(8)
+#define DPI_COLOR_CODING_16BIT_1   0x0
+#define DPI_COLOR_CODING_16BIT_2   0x1
+#define DPI_COLOR_CODING_16BIT_3   0x2
+#define DPI_COLOR_CODING_18BIT_1   0x3
+#define DPI_COLOR_CODING_18BIT_2   0x4
+#define DPI_COLOR_CODING_24BIT 0x5
+
+#define DSI_DPI_CFG_POL0x14
+#define COLORM_ACTIVE_LOW  BIT(4)
+#define SHUTD_ACTIVE_LOW   BIT(3)
+#define HSYNC_ACTIVE_LOW   BIT(2)
+#define VSYNC_ACTIVE_LOW   BIT(1)
+#define DATAEN_ACTIVE_LOW  BIT(0)
+
+#define DSI_DPI_LP_CMD_TIM 0x18
+#define OUTVACT_LPCMD_TIME(p)  (((p) & 0xff) << 16)
+#define INVACT_LPCMD_TIME(p)   ((p) & 0xff)
+
+#define DSI_DBI_CFG0x20
+#define DSI_DBI_CMDSIZE0x28
+
+#define DSI_PCKHDL_CFG 0x2c
+#define EN_CRC_RX  BIT(4)
+#define EN_ECC_RX  BIT(3)
+#define EN_BTA BIT(2)
+#define EN_EOTP_RX BIT(1)
+#define EN_EOTP_TX BIT(0)
+
+#define DSI_MODE_CFG   0x34
+#define ENABLE_VIDEO_MODE  0
+#define ENABLE_CMD_MODEBIT(0)
+
+#define DSI_VID_MODE_CFG   0x38
+#define FRAME_BTA_ACK  BIT(14)
+#define ENABLE_LOW_POWER   (0x3f << 8)
+#define ENABLE_LOW_POWER_MASK  (0x3f << 8)
+#define VID_MODE_TYPE_BURST_SYNC_PULSES0x2
+#define VID_MODE_TYPE_MASK 0x3
+
+#define DSI_VID_PKT_SIZE   0x3c
+#define VID_PKT_SIZE(p)(((p) & 0x3fff) << 0)
+#define VID_PKT_MAX_SIZE   0x3fff
+
+#define DSI_VID_HSA_TIME   0x48
+#define DSI_VID_HBP_TIME   0x4c
+#define DSI_VID_HLINE_TIME 0x50
+#define DSI_VID_VSA_LINES  0x54
+#define DSI_VID_VBP_LINES  0x58
+#define 

[PATCH v3 04/12] drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format

[Chris Zhong]

From: Liu Ying 

Signed-off-by: Liu Ying 
Acked-by: Thierry Reding 
Signed-off-by: Chris Zhong 
---

Changes in v3: None
Changes in v2: None

 include/drm/drm_mipi_dsi.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index f1d8d0d..3662021 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -163,6 +163,20 @@ static inline struct mipi_dsi_device 
*to_mipi_dsi_device(struct device *dev)
return container_of(dev, struct mipi_dsi_device, dev);
 }

+static inline int mipi_dsi_pixel_format_to_bpp(enum mipi_dsi_pixel_format fmt)
+{
+   switch (fmt) {
+   case MIPI_DSI_FMT_RGB888:
+   case MIPI_DSI_FMT_RGB666:
+   return 24;
+   case MIPI_DSI_FMT_RGB666_PACKED:
+   return 18;
+   case MIPI_DSI_FMT_RGB565:
+   return 16;
+   }
+   return -EINVAL;
+}
+
 struct mipi_dsi_device *of_find_mipi_dsi_device_by_node(struct device_node 
*np);
 int mipi_dsi_attach(struct mipi_dsi_device *dsi);
 int mipi_dsi_detach(struct mipi_dsi_device *dsi);
-- 
2.6.3

[PATCH v3 03/12] drm/rockchip: return a true clock rate to adjusted_mode

[Chris Zhong]

Sometimes the clock driver can not set a accurate clock_rate for vop,
get the true rate of vop_dclk and set it back to adjusted_mode, since
the mipi dsi driver need to use the clock to make the calculation of
Blanking.

Signed-off-by: Chris Zhong 
---

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 5d8ae5e..9986b311ed 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1232,6 +1232,12 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc,
reset_control_deassert(vop->dclk_rst);

clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
+
+   /*
+* Sometimes the clock driver can not set a accurate clock_rate for vop,
+* get the true rate of vop_dclk and set it back to adjusted_mode.
+*/
+   adjusted_mode->clock = clk_get_rate(vop->dclk) / 1000;
 out:
ret_clk = clk_enable(vop->dclk);
if (ret_clk < 0) {
-- 
2.6.3

[PATCH v3 00/12] Add mipi dsi support for rk3288

[Chris Zhong]

The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
IP. This series adds support for a Synopsys DesignWare MIPI DSI host
controller DRM bridge driver and a rockchip MIPI DSI specific DRM
driver.

This series also includes a DRM panel driver for BOE TV080WUM-NL0 panel.
This panel only use the MIPI DSI video mode.

The MIPI DSI feature is tested on rk3288 evb board, backport them to
chrome os kernel v3.14, and it can display normally.

This patchset is base on the patchset from Ying.liu at freescale.com.



Changes in v3:
move the dw_mipi_dsi.txt to Documentation/devicetree/bindings/display/bridge
move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/
move boe,tv080wum-nl0.txt to bindings/display/panel/

Changes in v2:
add the mipi clk id in a single patch
As Thierry.Reding comment, add a documentation for this panel.

Chris Zhong (10):
  clk: rockchip: add id for mipidsi sclk on rk3288
  clk: rockchip: add mipidsi clocks on rk3288
  drm/rockchip: return a true clock rate to adjusted_mode
  drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
  drm: rockchip: Support Synopsys DesignWare MIPI DSI host controller
  Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
  ARM: dts: rockchip: add rk3288 mipi_dsi nodes
  drm/panel: simple: Add support for BOE TV080WUM-NL0
  drm/panel: simple: Add boe,tv080wum-nl0 simple panel device tree
binding
  ARM: dts: rockchip: add support mipi panel tv080wum-nl0 for rk3288-evb

Liu Ying (2):
  drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
  Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM
bridge driver

 .../bindings/display/bridge/dw_mipi_dsi.txt|   76 ++
 .../bindings/display/panel/boe,tv080wum-nl0.txt|7 +
 .../display/rockchip/dw_mipi_dsi_rockchip.txt  |   56 ++
 arch/arm/boot/dts/rk3288-evb.dtsi  |   20 +-
 arch/arm/boot/dts/rk3288.dtsi  |   39 +
 drivers/clk/rockchip/clk-rk3288.c  |2 +-
 drivers/gpu/drm/bridge/Kconfig |   11 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/dw_mipi_dsi.c   | 1055 
 drivers/gpu/drm/panel/panel-simple.c   |   33 +
 drivers/gpu/drm/rockchip/Kconfig   |   10 +
 drivers/gpu/drm/rockchip/Makefile  |1 +
 drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c|  249 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|9 +
 include/drm/bridge/dw_mipi_dsi.h   |   27 +
 include/drm/drm_mipi_dsi.h |   14 +
 include/dt-bindings/clock/rk3288-cru.h |1 +
 17 files changed, 1609 insertions(+), 2 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
 create mode 100644 drivers/gpu/drm/bridge/dw_mipi_dsi.c
 create mode 100644 drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c
 create mode 100644 include/drm/bridge/dw_mipi_dsi.h

-- 
2.6.3

[PATCH 14/25] drm/exynos: introduce exynos_drm_plane_config structure

[Marek Szyprowski]

Hello,

On 2015-11-18 16:40, Tobias Jakobi wrote:
> Marek Szyprowski wrote:
>> On 2015-11-17 19:00, Tobias Jakobi wrote:
>>> Marek Szyprowski wrote:
 This patch adds common structure for keeping plane configuration and
 capabilities data. This patch is inspired by similar code developed by
 Tobias Jakobi.

 Signed-off-by: Marek Szyprowski 
 ---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 18 +++---
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 23 +++-
drivers/gpu/drm/exynos/exynos_drm_drv.h   | 22 
drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 25 -
drivers/gpu/drm/exynos/exynos_drm_plane.c | 34 --
drivers/gpu/drm/exynos/exynos_drm_plane.h |  7 ++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 25 -
drivers/gpu/drm/exynos/exynos_mixer.c | 51
 ---
8 files changed, 131 insertions(+), 74 deletions(-)

>>> 
 diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
 b/drivers/gpu/drm/exynos/exynos_mixer.c
 index 015e85cabcc9..cdec3c1827c6 100644
 --- a/drivers/gpu/drm/exynos/exynos_mixer.c
 +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
 @@ -43,7 +43,6 @@
  #define MIXER_WIN_NR3
#define VP_DEFAULT_WIN2
 -#define CURSOR_WIN1
  /* The pixelformats that are natively supported by the mixer. */
#define MXR_FORMAT_RGB5654
 @@ -112,6 +111,31 @@ struct mixer_drv_data {
boolhas_sclk;
};
+static const struct exynos_drm_plane_config
 plane_configs[MIXER_WIN_NR] = {
 +{
 +.zpos = 0,
 +.type = DRM_PLANE_TYPE_PRIMARY,
 +.pixel_formats = mixer_formats,
 +.num_pixel_formats = ARRAY_SIZE(mixer_formats),
 +.capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE_X |
 +EXYNOS_DRM_PLANE_CAP_DOUBLE_Y,
 +}, {
 +.zpos = 1,
 +.type = DRM_PLANE_TYPE_CURSOR,
 +.pixel_formats = mixer_formats,
 +.num_pixel_formats = ARRAY_SIZE(mixer_formats),
 +.capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE_X |
 +EXYNOS_DRM_PLANE_CAP_DOUBLE_Y,
 +}, {
 +.zpos = 2,
 +.type = DRM_PLANE_TYPE_OVERLAY,
 +.pixel_formats = vp_formats,
 +.num_pixel_formats = ARRAY_SIZE(vp_formats),
 +.capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE_X |
 +EXYNOS_DRM_PLANE_CAP_DOUBLE_Y,
>>> As far as I know the video plane supports arbitrary scaling and provides
>>> no dedicated 'pixel doubling' mode.
>> Right, I've forgotten that, I will update the code then. BTW, do you
>> plan to
>> submit your patches for Mixer, which fixes alpha blending setup?
> I'll try to send a new version out this weekend. Any specific branch I
> should base these on? (e.g. Inki's exynos-drm-next)

exynos-drm-next will be okay.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/intel_runtime_pm.c

between commitis:

  bc5f2ab11ca6 ("drm/i915/skl: Don't call intel_prepare_ddi when encoder list 
isn't yet initialized.")
  1b0e3a049efe ("drm/i915/skl: disable display side power well support for now")

from Linus' tree and commit:

  f0ab43e6c338 ("drm/i915: Introduce a gmbus power domain")
  c2b16152e0b3 ("drm/i915/skl: remove redundant DDI/IRQ reinitialization during 
PW1 enabling")

from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

diff --cc drivers/gpu/drm/i915/intel_runtime_pm.c
index d89c1d0aa1b7,f8167753f91b..
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@@ -1808,24 -1831,9 +1831,24 @@@ static struct i915_power_well bxt_power
.domains = BXT_DISPLAY_POWERWELL_2_POWER_DOMAINS,
.ops = _power_well_ops,
.data = SKL_DISP_PW_2,
-   }
+   },
  };

 +static int
 +sanitize_disable_power_well_option(const struct drm_i915_private *dev_priv,
 + int disable_power_well)
 +{
 +  if (disable_power_well >= 0)
 +  return !!disable_power_well;
 +
 +  if (IS_SKYLAKE(dev_priv)) {
 +  DRM_DEBUG_KMS("Disabling display power well support\n");
 +  return 0;
 +  }
 +
 +  return 1;
 +}
 +
  #define set_power_wells(power_domains, __power_wells) ({  \
(power_domains)->power_wells = (__power_wells); \
(power_domains)->power_well_count = ARRAY_SIZE(__power_wells);  \
@@@ -1842,9 -1850,8 +1865,11 @@@ int intel_power_domains_init(struct drm
  {
struct i915_power_domains *power_domains = _priv->power_domains;

+   BUILD_BUG_ON(POWER_DOMAIN_NUM > 31);
+ 
 +  i915.disable_power_well = sanitize_disable_power_well_option(dev_priv,
 +   i915.disable_power_well);
 +
mutex_init(_domains->lock);

/*

[PATCH v3 11/12] drm/panel: simple: Add boe,tv080wum-nl0 simple panel device tree binding

[Rob Herring]

On Thu, Nov 19, 2015 at 11:35:29AM +0800, Chris Zhong wrote:
> This binding specifies a set of common properties for display panels. It
> can be used as a basis by bindings for specific panels.
> Bindings for three specific panels are provided to show how the
> simple panel binding can be used.
> 
> Signed-off-by: Chris Zhong 

Acked-by: Rob Herring 

> 
> ---
> 
> Changes in v3:
> move boe,tv080wum-nl0.txt to bindings/display/panel/
> 
> Changes in v2:
> As Thierry.Reding comment, add a documentation for this panel.
> 
>  .../devicetree/bindings/display/panel/boe,tv080wum-nl0.txt | 7 
> +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt 
> b/Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt
> new file mode 100644
> index 000..50be5e2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt
> @@ -0,0 +1,7 @@
> +Boe Corporation 8.0" WUXGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "boe,tv080wum-nl0"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> -- 
> 2.6.3
> 

[PATCH v6 00/12] MT8173 DRM support

[Daniel Vetter]

On Wed, Nov 18, 2015 at 06:34:08PM +0100, Philipp Zabel wrote:
> Hi,
> 
> another update to the MT8173 DRM support patchset. Since the device tree
> bindings are now in order, I have dropped the RFC.
> The irq handler is still writing to hardware registers, as on MT8173 vblank
> synchronised register updates need help from a separate hardware command
> queue unit. A driver for that is currently being written, so this will be
> fixed later.

Imo this is minor enough that it shouldn't block merging, and otherwise
the driver looks rather neat. Once you have acks for the arm/clk parts I
think you should just send a pull requests for this to Dave for 4.5. And
yes, that means Acked-by: Daniel Vetter  (too lazy
to do a full review again) for the drm side.

Cheers, Daniel

> 
> Changes since v5:
> - Updated DISP_MUTEX description in binding documentation
> - Register and unregister drivers in a loop
> - Combined mtk_drm_crtc and mtk_crtc_ddp_context, added mtk_disp_ovl
>   structure to contain ovl ddp component
> - Reworked component callbacks (removed comp_ prefix from
>   mtk_ddp_comp_funcs, move id into mtk_ddp_comp added inline
>   functions to wrap callbacks)
> - Use non-sync pm_runtime_put variant
> - Use RGB888 as fallback format
> - Removed unused pipe parameter from mtk_ddp_add_comp_to_path
> - Renamed mtk_drm_private->pipe to ->num_pipes
> - Updated mtk specific crtc and plane atomic state handling
> - Moved mtk_drm_crtc_plane_config to plane local mtk_plane_config
> - Let layer_config take a struct mtk_plane_state
> - Use writel_relaxed in mtk_ddp_add_comp_to_path
> - Removed some unused parameters, functions, and local variables
> - Removed custom crtc enable flag
> - Removed unnecessary comp->funcs NULL checks
> - Moved LARB handling out of drm driver code into crtc code,
>   request LARB during component initialization
> - Updated display data path / mutex code
> - Moved initialization of driverless ddp components into the drm driver
> - Commented crtc_disable
> - Removed support for multiplanar framebuffers
> - Configure width/height of the color engine even if it is bypassed
> - Added static keyword to unexported structures and functions
> - Unlink display data path in hw_fini
> - Added static keyword to unexported structures and functions
> 
> The following patches are still needed to apply this on top of v4.4-rc1:
> 
> https://patchwork.kernel.org/patch/6825601/ ("arm64: dts: mt8173: add MT8173 
> display PWM driver support node"),
> https://patchwork.kernel.org/patch/7138531/ ("arm64: dts: mediatek: add xHCI 
> & usb phy for mt8173"),
> https://patchwork.kernel.org/patch/6928651/ ("dts: mt8173: Add iommu/smi 
> nodes for mt8173"), and
> 
> And to build:
> 
> https://patchwork.kernel.org/patch/6928621/ ("memory: mediatek: Add SMI 
> driver"),
> 
> regards
> Philipp
> 
> CK Hu (5):
>   dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
>   drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
>   drm/mediatek: Add DSI sub driver
>   arm64: dts: mt8173: Add display subsystem related nodes
>   arm64: dts: mt8173: Add HDMI related nodes
> 
> Jie Qiu (3):
>   drm/mediatek: Add DPI sub driver
>   drm/mediatek: Add HDMI support
>   drm/mediatek: enable hdmi output control bit
> 
> Philipp Zabel (4):
>   dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding
>   clk: mediatek: make dpi0_sel and hdmi_sel not propagate rate changes
>   clk: mediatek: Add hdmi_ref HDMI PHY PLL reference clock output
>   dt-bindings: hdmi-connector: add DDC I2C bus phandle documentation
> 
>  .../bindings/display/connector/hdmi-connector.txt  |   1 +
>  .../bindings/display/mediatek/mediatek,disp.txt| 183 +
>  .../bindings/display/mediatek/mediatek,dpi.txt |  35 +
>  .../bindings/display/mediatek/mediatek,dsi.txt |  53 ++
>  .../bindings/display/mediatek/mediatek,hdmi.txt| 142 
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi   | 282 
>  drivers/clk/mediatek/clk-mt8173.c  |   9 +-
>  drivers/clk/mediatek/clk-mtk.h |   7 +-
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/mediatek/Kconfig   |  22 +
>  drivers/gpu/drm/mediatek/Makefile  |  21 +
>  drivers/gpu/drm/mediatek/mtk_cec.c | 245 +++
>  drivers/gpu/drm/mediatek/mtk_cec.h |  25 +
>  drivers/gpu/drm/mediatek/mtk_dpi.c | 683 ++
>  drivers/gpu/drm/mediatek/mtk_dpi.h |  80 +++
>  drivers/gpu/drm/mediatek/mtk_dpi_regs.h| 228 ++
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 596 
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.h|  41 ++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 362 ++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h |  41 ++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 431 

[Bug 92953] Segfault loading UT4 map/server

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

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

--- Comment #7 from Michel Dänzer  ---
Can you try running the game with the environment variable R600_DEBUG=check_vm
and reproducing the problem? It should generate some debugging output on
stderr, if so please attach that here.

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

[PATCH] drm/panel: simple: Add support for G121X1-L03

[Rob Herring]

On Wed, Nov 18, 2015 at 03:57:47PM -0500, Akshay Bhat wrote:
> Add support for Innolux CheMei 12" G121X1-L03 XGA LVDS display.
> 
> Datasheet: http://www.azdisplays.com/PDF/G121X1-L03.pdf
> Signed-off-by: Akshay Bhat 

Acked-by: Rob Herring 

> ---
>  .../bindings/display/panel/innolux,g121x1-l03.txt  |  7 +
>  drivers/gpu/drm/panel/panel-simple.c   | 31 
> ++
>  2 files changed, 38 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/innolux,g121x1-l03.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/innolux,g121x1-l03.txt 
> b/Documentation/devicetree/bindings/display/panel/innolux,g121x1-l03.txt
> new file mode 100644
> index 000..6497446
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/innolux,g121x1-l03.txt
> @@ -0,0 +1,7 @@
> +Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "innolux,g121x1-l03"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index f97b73e..d1821f7 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -832,6 +832,34 @@ static const struct panel_desc innolux_g121i1_l01 = {
>   },
>  };
>  
> +static const struct drm_display_mode innolux_g121x1_l03_mode = {
> + .clock = 65000,
> + .hdisplay = 1024,
> + .hsync_start = 1024 + 0,
> + .hsync_end = 1024 + 1,
> + .htotal = 1024 + 0 + 1 + 320,
> + .vdisplay = 768,
> + .vsync_start = 768 + 38,
> + .vsync_end = 768 + 38 + 1,
> + .vtotal = 768 + 38 + 1 + 0,
> + .vrefresh = 60,
> +};
> +
> +static const struct panel_desc innolux_g121x1_l03 = {
> + .modes = _g121x1_l03_mode,
> + .num_modes = 1,
> + .bpc = 6,
> + .size = {
> + .width = 246,
> + .height = 185,
> + },
> + .delay = {
> + .enable = 200,
> + .unprepare = 200,
> + .disable = 400,
> + },
> +};
> +
>  static const struct drm_display_mode innolux_n116bge_mode = {
>   .clock = 76420,
>   .hdisplay = 1366,
> @@ -1158,6 +1186,9 @@ static const struct of_device_id platform_of_match[] = {
>   .compatible ="innolux,g121i1-l01",
>   .data = _g121i1_l01
>   }, {
> + .compatible = "innolux,g121x1-l03",
> + .data = _g121x1_l03,
> + }, {
>   .compatible = "innolux,n116bge",
>   .data = _n116bge,
>   }, {
> -- 
> 2.6.3
> 

[Intel-gfx] [PATCH] drm/atomic-helper: Check encoder/crtc constraints

[Daniel Stone]

Hi,

On 18 November 2015 at 17:46, Daniel Vetter  wrote:
> This was totally lost when I originally created the atomic helpers.
>
> We probably should also check possible_clones in the helpers, but
> since the legacy ones didn't do that this is for a separate patch.

Heh, before reading this chunk of the commit message, I also went
looking for possible_clones and came to the same conclusion. On the
grounds that great minds think alike (or fools never differ, not
sure):
Reviewed-by: Daniel Stone 

Cheers,
Daniel

[Bug 92258] [regression] Opening context menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash

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

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

--- Comment #11 from Maarten Lankhorst  ---
If this causes a GPF in ttm_bo_wait my guess is radeon has a fence refcounting
bug, but if that's the case this patch will cause an infinite loop in
reservation_object_wait_timeout_rcu called from ttm_bo_wait.

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

[Bug 92258] [regression] Opening context menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash

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

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

--- Comment #10 from Maarten Lankhorst  ---
Created attachment 119927
  --> https://bugs.freedesktop.org/attachment.cgi?id=119927=edit
Use reservation_object_wait_timeout_rcu

I have no idea what can go wrong, lets find out if adding refcounts during wait
helps..

Could you check the output with this patch? ^

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

[Bug 90404] [Steam] Unity3D Games: Shaders are choppy

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

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

Christopher Weigle  changed:

   What|Removed |Added

Summary|[Steam] Assault Android |[Steam] Unity3D Games:
   |Cactus demo: Shaders are|Shaders are choppy
   |choppy  |

--- Comment #3 from Christopher Weigle  ---
Sorry about that, I accidentally deleted the trace when clearing excess files
from dropbox. I made a new one from Reignmaker as it is common among Unity3D
games using the standard shaders. If you like, I can upload another trace to
compare.

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

[Bug 90404] [Steam] Assault Android Cactus demo: Shaders are choppy

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

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

Christopher Weigle  changed:

   What|Removed |Added

 Attachment #115700|0   |1
is obsolete||

--- Comment #2 from Christopher Weigle  ---
Created attachment 119926
  --> https://bugs.freedesktop.org/attachment.cgi?id=119926=edit
[Unity3D] Reignmaker Trace

Link to the apitrace

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

[Bug 92953] Segfault loading UT4 map/server

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

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

--- Comment #6 from bellamorte42 at gmail.com ---
Created attachment 119925
  --> https://bugs.freedesktop.org/attachment.cgi?id=119925=edit
dmesg

Can't open the server list to try to join a game anymore.

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