date:20180405

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

--- Comment #6 from Lyberta  ---
I'm 100% sure it is PulseWave because that's the only kernel I use to one of my
programs and it still crashes at cl::Program::build.

How to upgrade to llvm/clang 6?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101976] glmark2 random blank or background only screen freeze over amdgpu rx550 AMD POLARIS12 due to dpm

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

Pablo Estigarribia  changed:

   What|Removed |Added

   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1478219

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

2018-04-05 Thread Rob Clark

On Thu, Apr 5, 2018 at 9:30 AM, Thomas Hellstrom  wrote:
> On 04/04/2018 11:56 AM, Daniel Vetter wrote:
>>
>> On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellstrom wrote:
>>>
>>> On 04/04/2018 10:43 AM, Daniel Vetter wrote:

 On Wed, Apr 04, 2018 at 10:22:21AM +0200, Thomas Hellstrom wrote:
>
> Hi,
>
> On 04/04/2018 08:58 AM, Daniel Vetter wrote:
>>
>> On Wed, Apr 4, 2018 at 12:42 AM, Rob Clark 
>> wrote:
>>>
>>> Add an atomic helper to implement dirtyfb support.  This is needed to
>>> support DSI command-mode panels with x11 userspace (ie. when we can't
>>> rely on pageflips to trigger a flush to the panel).
>>>
>>> To signal to the driver that the async atomic update needs to
>>> synchronize with fences, even though the fb didn't change, the
>>> drm_atomic_state::dirty flag is added.
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>> Background: there are a number of different folks working on getting
>>> upstream kernel working on various different phones/tablets with qcom
>>> SoC's.. many of them have command mode panels, so we kind of need a
>>> way to support the legacy dirtyfb ioctl for x11 support.
>>>
>>> I know there is work on a proprer non-legacy atomic property for
>>> userspace to communicate dirty-rect(s) to the kernel, so this can
>>> be improved from triggering a full-frame flush once that is in
>>> place.  But we kinda needa a stop-gap solution.
>>>
>>> I had considered an in-driver solution for this, but things get a
>>> bit tricky if userspace ands up combining dirtyfb ioctls with page-
>>> flips, because we need to synchronize setting various CTL.FLUSH bits
>>> with setting the CTL.START bit.  (ie. really all we need to do for
>>> cmd mode panels is bang CTL.START, but is this ends up racing with
>>> pageflips setting FLUSH bits, then bad things.)  The easiest soln
>>> is to wrap this up as an atomic commit and rely on the worker to
>>> serialize things.  Hence adding an atomic dirtyfb helper.
>>>
>>> I guess at least the helper, with some small addition to translate
>>> and pass-thru the dirty rect(s) is useful to the final atomic dirty-
>>> rect property solution.  Depending on how far off that is, a stop-
>>> gap solution could be useful.
>>
>> Adding Noralf, who iirc already posted the full dirty helpers already
>> somewhere.
>> -Daniel
>
> I've asked Deepak to RFC the core changes suggested for the full dirty
> blob
> on dri-devel. It builds on DisplayLink's suggestion, with a simple
> helper to
> get to the desired coordinates.
>
> One thing to perhaps discuss is how we would like to fit this with
> front-buffer rendering and the dirty ioctl. In the page-flip context,
> the
> dirty rects, like egl's swapbuffer_with_damage is a hint to restrict
> the
> damage region that can be fully ignored by the driver, new content is
> indicated by a new framebuffer.
>
> We could do the same for frontbuffer rendering: Either set a dirty flag
> like
> you do here, or provide a content_age state member. Since we clear the
> dirty
> flag on state copies, I guess that would be sufficient. The blob
> rectangles
> would then become a hint to restrict the damage region.

 I'm not entirely following here - I thought for frontbuffer rendering
 the
 dirty rects have always just been a hint, and that the driver was always
 free to re-upload the entire buffer to the screen.

 And through a helper like Rob's proposing here (and have floated around
 in
 different versions already) we'd essentially map a frontbuffer dirtyfb
 call to a fake flip with dirty rect. Manual upload drivers already need
 to
 upload the entire screen if they get a flip, since some userspace uses
 that to flush out frontbuffer rendering (instead of calling dirtyfb).

 So from that pov the new dirty flag is kinda not necessary imo.

> Another approach would be to have the presence of dirty rects without
> framebuffer change to indicate frontbuffer rendering.
>
> I think I like the first approach best, although it may be tempting for
> user-space apps to just set the dirty bit instead of providing the full
> damage region.

 Or I'm not following you here, because I don't quite see the difference
 between dirtyfb and a flip.
 -Daniel
>>>
>>> OK, let me rephrase:
>>>
>>>  From the driver's point-of-view, in the atomic world, new content and
>>> the
>>> need for manual upload is indicated by a change in fb attached to the
>>> plane.
>>>
>>> With Rob's patch here, (correct me if I'm wrong) in addition new content
>>> and
>>> the need for manual upload is identified by the dirty flag, (since the fb
>>>

RE: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

> >>> 1) Expose a dirty (or content_age property)
> >>> 2) Attach a clip-rect blob property.
> >>> 3) Fake a page-flip by ping-ponging two frame-buffers pointing to the
> >>> same
> >>> underlying buffer object.
> >>>
> >>> Are you saying that people are already using 3) and we should keep
> using
> >>> that?
> >>
> >> I'm saying they're using 3b), flip the same buffer wrapped in the same
> >> drm_framebuffer, and expect it to work.
> >>
> >> The only advantage dirtyfb has is that it allows you to supply the
> >> optimized upload rectangles, but at the cost of a funny api (it's working
> >> on the fb, not the plane/crtc you want to upload) and lack of drm_event
> to
> >> confirm when exactly you uploaded your stuff. But imo they should be
> the
> >> same underlying operation.
> >>
> >
> > FWIW, vmwgfx has always treated a dirtyfb as a pure front-buffer like
> > rendering operation without any synchronization,
> > We've guaranteed that only the rects that are present are uploaded, but
> only
> > xf86-video-vmware has taken advantage of this to keep
> > CPU- and GPU rendered content apart.
> > I think we've at some point run into problems with number of cliprects,
> (Old
> > KDE lock screen?) and use multiple dirtyfb for the same
> > update...
> 
> Ok, if we can hit this in practices then I think it's ok to have the
> limit. Just need to make sure userspace actually condenses the
> cliprects down to something within the limit, since with atomic flips
> you can't just do multiple updates - that would tear badly.

So I think the conclusion is to have damage clip rect limit with proper
documentation stating limitation of doing multiple updates.

> 
> Wrt not syncing: I think general use pretty clearly says lots of
> userspace renders into buffers with gpus (not even necessarily your
> own) and then expects dirtyfb or a flip to upload all the bits.
> Otherwise Rob Clark wouldn't need his patch. Given that I think we
> need to make general semantics follow that requirement - I don't
> expect it'll harm vmwgfx since it doesn't render into the frontbuffer
> anyway?
> 
> > IIRC the reason for working with the fb, is that it's much easier for
> > user-space, which doesn't have to care where planes are scanning out and
> > why.
> > "Present my new content on any screen that's affected".
> 
> Yeah, dirtyfb makes tons of sense for frontbuffer-rendering X, which
> also doesn't do per-scanout pixmaps. But for atomic flips you really
> want to flip on the crtc (or well plane), since otherwise with
> multiple planes it comes up all teared up. vmwgfx doesn't care I guess
> since you only have 1 primary plane, but all the SoC chips very much
> do.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__blog.ffwll.ch=DwIBaQ=uilaK90D4TOVoH58JNXRgQ=zOOG28inJK
> 0762SxAf-cyZdStnd2NQpRu98lJP2iYGw=XKgN7GPElFapBWdozPSC-
> 9rcfKmDvQC1QHhsFghexWc=SH9q5tw-
> UqpUBJVrr2v1mLpRo28Aau7iJ3YWlrgbPmU=
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RfC PATCH] Add udmabuf misc device

2018-04-05 Thread Matt Roper

On Thu, Apr 05, 2018 at 10:32:04PM +0200, Daniel Vetter wrote:
> Pulling this out of the shadows again.
> 
> We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff
> from Matt and Dongwong.
> 
> At least from the intel side there seems to be the idea to just have 1
> special device that can handle cross-gues/host sharing for all kinds
> of hypervisors, so I guess you all need to work together :-)
> 
> Or we throw out the idea that hyper dmabuf will be cross-hypervisor
> (not sure how useful/reasonable that is, someone please convince me
> one way or the other).
> 
> Cheers, Daniel

Dongwon (DW) is the one doing all the real work on hyper_dmabuf, but I'm
familiar with the use cases he's trying to address, and I think there
are a couple high-level goals of his work that are worth calling out as
we discuss the various options for sharing buffers produced in one VM
with a consumer running in another VM:

 * We should try to keep the interface/usage separate from the
   underlying hypervisor implementation details.  I.e., in DW's design
   the sink/source drivers that handle the actual buffer passing in the
   two VM's should provide a generic interface that does not depend on a
   specific hypervisor.  Behind the scenes there could be various
   implementations for specific hypervisors (Xen, KVM, ACRN, etc.), and
   some of those backends may have additional restrictions, but it would
   be best if userspace didn't have to know the specific hypervisor
   running on the system and could just query the general capabilities
   available to it.  We've already got projects in flight that are
   wanting this functionality on Xen and ACRN today.

 * The general interface should be able to express sharing from any
   guest:guest, not just guest:host.  Arbitrary G:G sharing might be
   something some hypervisors simply aren't able to support, but the
   userspace API itself shouldn't make assumptions or restrict that.  I
   think ideally the sharing API would include some kind of
   query_targets interface that would return a list of VM's that your
   current OS is allowed to share with; that list would be depend on the
   policy established by the system integrator, but obviously wouldn't
   include targets that the hypervisor itself wouldn't be capable of
   handling.

 * A lot of the initial use cases are in the realm of graphics, but this
   shouldn't be a graphics-specific API.  Buffers might contain other
   types of content as well (e.g., audio).  Really the content producer
   could potentially be any driver (or userspace) running in the VM that
   knows how to import/export dma_buf's (or maybe just import given
   danvet's suggestion that we should make the sink driver do all the
   actual memory allocation for any buffers that may be shared).

 * We need to be able to handle cross-VM coordination of buffer usage as
   well, so I think we'd want to include fence forwarding support in the
   API as well to signal back and forth about production/consumption
   completion.  And of course document really well what should happen
   if, for example, the entire VM you're sharing with/from dies.

 * The sharing API could be used to share multiple kinds of content in a
   single system.  The sharing sink driver running in the content
   producer's VM should accept some additional metadata that will be
   passed over to the target VM as well.  The sharing source driver
   running in the content consumer's VM would then be able to use this
   metadata to determine the purpose of a new buffer that arrives and
   filter/dispatch it to the appropriate consumer.

For reference, the terminology I'm using is

 /--\  dma_buf   /--\ HV /\  dma_buf   /--\
 | Producer |--->| Sink | HV | Source |--->| Consumer |
 \--/   ioctls   \--/ HV \/  uevents   \--/

In the realm of graphics, "Producer" could potentially be something like
an EGL client that sends the buffer at context setup and then signals
with fences on each SwapBuffers.  "Consumer" could be a Wayland client
that proxies the buffers into surfaces or dispatches them to other
userspace software that's waiting for buffers.

With the hyper_dmabuf approach, there's a lot of ABI details that need
to be worked out and really clearly documented before we worry too much
about the backend hypervisor-specific stuff.

I'm not super familiar with xen-zcopy and udmabuf, but it sounds like
they're approaching similar problems from slightly different directions,
so we should make sure we can come up with something that satisfies
everyone's requirements. 

Matt

> 
> On Wed, Mar 14, 2018 at 9:03 AM, Gerd Hoffmann  wrote:
> >   Hi,
> >
> >> Either mlock account (because it's mlocked defacto), and get_user_pages
> >> won't do that for you.
> >>
> >> Or you write the full-blown userptr implementation, including mmu_notifier
> >> support (see i915 or amdgpu), but that also requires

RE: [RFC 2/3] drm: Add helper iterator functions to iterate over plane damage.

> plane damage.
> 
> On 04/05/2018 09:52 AM, Daniel Vetter wrote:
> >
> > TYPE_PLANE I have no idea who needs that. I suggest we just drop it.
> 
> I'm assuming CRTC plane coordinates here. They are used for uploading
> contents of hardware planes. Like, in the simplest case, cursor images.

Yes they are CRTC plane coordinates, so is TYPE_PLANE naming confusing ?
And should be named to TYPE_CRTC_PLANE but then it is confusing with
TYPE_CRTC.

> 
> /Thomas

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

Re: [PATCH v4] drm: Fix downstream dev count read

2018-04-05 Thread Rodrigo Vivi

On Thu, Apr 05, 2018 at 04:04:14AM +0530, Ramalingam C wrote:
> 
> 
> On Thursday 05 April 2018 12:53 AM, Sean Paul wrote:
> > On Wed, Apr 04, 2018 at 12:07:41PM -0700, Rodrigo Vivi wrote:
> > > On Wed, Apr 04, 2018 at 11:57:42PM +0530, Ramalingam C wrote:
> > > > In both HDMI and DP, device count is represented by 6:0 bits of a
> > > > register(BInfo/Bstatus)
> > > > 
> > > > So macro for bitmasking the device_count is fixed(0x3F->0x7F).
> > > > 
> > > > v3:
> > > >Retained the Rb-ed.
> > > > v4:
> > > >%s/drm\/i915/drm [rodrigo]
> > > > 
> > > Shouldn't this patch have a "Fixes:" ?
> > Yes, I think that'd be good.
> Will add
> Fixes: 495eb7f877ab drm: Add some HDCP related #defines
> > 
> > > cc: stable?
> > It couldn't hurt.
> Sorry what is needed here?

nothing actually...

$ dim fixes 495eb7f877ab3
Fixes: 495eb7f877ab ("drm: Add some HDCP related #defines")
Cc: Daniel Vetter 
Cc: Ramalingam C 
Cc: Sean Paul 
Cc: Gustavo Padovan 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org

CC: Stable wasn't returned here so it is not needed.

> > 
> > > I pushed first 3 patches on the series to dinq.
> > > I believe this one here could be there with Dave's ack or
> > > maybe on drm-misc-fixes?
> > Meh. The severity of this isn't too big, given that I doubt people care 
> > _too_
> > much about plugging in more than 64 HDCP-enabled devices. If you want to 
> > drop it
> > in -misc-next-fixes, I can send it out next week.
> > 
> > While we're asking for a respin, could we add HDCP somewhere in the subject?
> will change the sub to
> drm: Fix HDCP downstream dev count read
> 
> --Ram
> > 
> > Sean
> > 
> > > > Signed-off-by: Ramalingam C 
> > > > cc: Sean Paul 
> > > > Reviewed-by: Sean Paul 
> > > > ---
> > > >   include/drm/drm_hdcp.h | 2 +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> > > > index 562fa7df2637..98e63d870139 100644
> > > > --- a/include/drm/drm_hdcp.h
> > > > +++ b/include/drm/drm_hdcp.h
> > > > @@ -19,7 +19,7 @@
> > > >   #define DRM_HDCP_RI_LEN   2
> > > >   #define DRM_HDCP_V_PRIME_PART_LEN 4
> > > >   #define DRM_HDCP_V_PRIME_NUM_PARTS5
> > > > -#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x3f)
> > > > +#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x7f)
> > > >   #define DRM_HDCP_MAX_CASCADE_EXCEEDED(x)  (x & BIT(3))
> > > >   #define DRM_HDCP_MAX_DEVICE_EXCEEDED(x)   (x & BIT(7))
> > > > -- 
> > > > 2.7.4
> > > > 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [RFC 3/3] drm: Add helper to validate damage during modeset_check

> 
> On Wed, Apr 04, 2018 at 04:49:08PM -0700, Deepak Rawat wrote:
> > This patch adds a helper which should be called by driver which enable
> > damage (by calling drm_plane_enable_damage_clips) from atomic_check
> > hook. This helper for now set the damage to NULL for the planes on crtc
> > which need full modeset.
> >
> > The driver also need to check for other crtc properties which can
> > affect damage in atomic_check hook, like gamma, ctm, etc. Plane related
> > properties which affect damage can be handled in damage iterator.
> >
> > Signed-off-by: Deepak Rawat 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 47
> +
> >  include/drm/drm_atomic_helper.h |  2 ++
> >  2 files changed, 49 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> > index 355b514..23f44ab 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -3987,3 +3987,50 @@ drm_atomic_helper_damage_iter_next(struct
> drm_atomic_helper_damage_iter *iter,
> > return true;
> >  }
> >  EXPORT_SYMBOL(drm_atomic_helper_damage_iter_next);
> > +
> > +/**
> > + * drm_atomic_helper_check_damage - validate state object for damage
> changes
> > + * @dev: DRM device
> > + * @state: the driver state object
> > + *
> > + * Check the state object if damage is required or not. In case damage is
> not
> > + * required e.g. need modeset, the damage blob is set to NULL.
> 
> Why is that needed?
> 
> I can imagine that drivers unconditionally upload everything for a
> modeset, and hence don't need special damage tracking. But for that it's
> imo better to have a clear_damage() helper.

Don't we need a generic helper which all drivers can use to see if anything
in drm_atomic_state will result in full update? My intention for calling that
function from atomic_check hook was because state access can
return -EDEADLK.

I think for now having drm_damage_helper_clear_damage helper and 
calling it from atomic_check seems better option. In future once I have
clear idea, a generic function can be done.


> 
> But even for modesets (e.g. resolution changes) I'd expect that virtual
> drivers don't want to upload unecessary amounts of data. Manual upload
> hw drivers probably need to upload everything, because the panel will have
> forgotten all the old data once power cycled.

AFAIK current vmwgfx will do full upload for resolution change.

> 
> And if you think this is really the right thing, then we need to rename
> the function to tell what it does, e.g.
> 
> drm_damage_helper_clear_damage_on_modeset()
> 
> drm_damage_helper because I think we should stuff this all into
> drm_damage_helper.c, see previous patch.
> 
> But I think a
> 
> drm_damage_helper_clear_damage(crtc_state)
> 
> which you can use in your crtc->atomic_check function like
> 
> crtc_atomic_check(state)
> {
>   if (drm_atomic_crtc_needs_modeset(state))
>   drm_damage_helper_clear_damage(state);
> }
> 
> is more flexible and useful for drivers. There might be other cases where
> clearing damage is the right thing to do. Also, there's the question of
> whether no damage clips == full damage or not, so maybe we should call
> this helper full_damage() instead.

In my opinion if via proper documentation it is conveyed that no damage
means full-update the clear_damage makes sense.

> -Daniel
> 
> > + *
> > + * NOTE: This helper is not called by core. Those driver which enable
> damage
> > + * using drm_plane_enable_damage_clips should call this from their
> @atomic_check
> > + * hook.
> > + */
> > +int drm_atomic_helper_check_damage(struct drm_device *dev,
> > +  struct drm_atomic_state *state)
> > +{
> > +   struct drm_crtc *crtc;
> > +   struct drm_plane *plane;
> > +   struct drm_crtc_state *crtc_state;
> > +   unsigned plane_mask;
> > +   int i;
> > +
> > +   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> > +   if (!drm_atomic_crtc_needs_modeset(crtc_state))
> > +   continue;
> > +
> > +   plane_mask = crtc_state->plane_mask;
> > +   plane_mask |= crtc->state->plane_mask;
> > +
> > +   drm_for_each_plane_mask(plane, dev, plane_mask) {
> > +   struct drm_plane_state *plane_state =
> > +   drm_atomic_get_plane_state(state, plane);
> > +
> > +   if (IS_ERR(plane_state))
> > +   return PTR_ERR(plane_state);
> > +
> > +   if (plane_state->damage_clips) {
> > +   drm_property_blob_put(plane_state-
> >damage_clips);
> > +   plane_state->damage_clips = NULL;
> > +   plane_state->num_clips = 0;
> > +   }
> > +   }
> > +   }
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(drm_atomic_helper_check_damage);
> > diff --git

RE: [RFC 2/3] drm: Add helper iterator functions to iterate over plane damage.

> 
> On Wed, Apr 04, 2018 at 04:49:07PM -0700, Deepak Rawat wrote:
> > With damage property in drm_plane_state, this patch adds helper iterator
> > to traverse the damage clips. Iterator will return the damage rectangles
> > in framebuffer, plane or crtc coordinates as need by driver
> > implementation.
> >
> > Signed-off-by: Deepak Rawat 
> 
> I'd really like selftest/unittests for this stuff. There's an awful lot of
> cornercases in this here (for any of the transformed iterators at least),
> and unit tests is the best way to make sure we handle them all correctly.
> 
> Bonus points if you integrate the new selftests into igt so intel CI can
> run them, seel igt/tests/drm_mm.c for an example. drm_mm selftest is also
> the framework I'd copy for this stuff.
> 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 122
> 
> >  include/drm/drm_atomic_helper.h |  39 
> >  2 files changed, 161 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> > index 55b44e3..355b514 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -3865,3 +3865,125 @@ void
> __drm_atomic_helper_private_obj_duplicate_state(struct drm_private_obj
> *obj
> > memcpy(state, obj->state, sizeof(*state));
> >  }
> >  EXPORT_SYMBOL(__drm_atomic_helper_private_obj_duplicate_state);
> > +
> > +/**
> > + * drm_atomic_helper_damage_iter_init - initialize the damage iterator
> > + * @iter: The iterator to initialize.
> > + * @type: Coordinate type caller is interested in.
> > + * @state: plane_state from which to iterate the damage clips.
> > + * @hdisplay: Width of crtc on which plane is scanned out.
> > + * @vdisplay: Height of crtc on which plane is scanned out.
> > + *
> > + * Initialize an iterator that is used to translate and clip a set of 
> > damage
> > + * rectangles in framebuffer coordinates to plane and crtc coordinates.
> The type
> > + * argument specify which type of coordinate to iterate in.
> > + *
> > + * Returns: 0 on success and negative error code on error. If an error code
> is
> > + * returned then it means the plane state should not update.
> > + */
> > +int
> > +drm_atomic_helper_damage_iter_init(struct
> drm_atomic_helper_damage_iter *iter,
> > +  enum
> drm_atomic_helper_damage_clip_type type,
> > +  const struct drm_plane_state *state,
> > +  uint32_t hdisplay, uint32_t vdisplay)
> > +{
> > +   if (!state || !state->crtc || !state->fb)
> > +   return -EINVAL;
> > +
> > +   memset(iter, 0, sizeof(*iter));
> > +   iter->clips = (struct drm_rect *)state->damage_clips->data;
> > +   iter->num_clips = state->num_clips;
> > +   iter->type = type;
> > +
> > +   /*
> > +* Full update in case of scaling or rotation. In future support for
> > +* scaling/rotating damage clips can be added
> > +*/
> > +   if (state->crtc_w != (state->src_w >> 16) ||
> > +   state->crtc_h != state->src_h >> 16 || state->rotation != 0) {
> > +   iter->curr_clip = iter->num_clips;
> > +   return 0;
> 
> Given there's no user of this I have no idea how this manages to provoke a
> full clip rect. selftest code would be perfect for stuff like this.
> 
> Also, I think we should provide a full clip for the case of num_clips ==
> 0, so that driver code can simply iterate over all clips and doesn't ever
> have to handle the "no clip rects provided" case as a special case itself.

The notion was if iterator does not provide any clip rect then driver need a
full update but yes I will work on providing a full clip here.

> 
> > +   }
> > +
> > +   iter->fb_src.x1 = 0;
> > +   iter->fb_src.y1 = 0;
> > +   iter->fb_src.x2 = state->fb->width;
> > +   iter->fb_src.y2 = state->fb->height;
> > +
> > +   iter->plane_src.x1 = state->src_x >> 16;
> > +   iter->plane_src.y1 = state->src_y >> 16;
> > +   iter->plane_src.x2 = iter->plane_src.x1 + (state->src_w >> 16);
> > +   iter->plane_src.y2 = iter->plane_src.y1 + (state->src_h >> 16);
> > +   iter->translate_plane_x = -iter->plane_src.x1;
> > +   iter->translate_plane_y = -iter->plane_src.y1;
> > +
> > +   /* Clip plane src rect to fb dimensions */
> > +   drm_rect_intersect(>plane_src, >fb_src);
> 
> This smells like driver bug. Also, see Ville's recent efforts to improve
> the atomic plane clipping, I think drm_plane_state already has all the
> clip rects you want.
> 
> > +
> > +   iter->crtc_src.x1 = 0;
> > +   iter->crtc_src.y1 = 0;
> > +   iter->crtc_src.x2 = hdisplay;
> > +   iter->crtc_src.y2 = vdisplay;
> > +   iter->translate_crtc_x = -(iter->plane_src.x1 - state->crtc_x);
> > +   iter->translate_crtc_x = -(iter->plane_src.y1 - state->crtc_y);
> > +
> > +   /* Clip crtc src rect to plane dimensions */
> > +   drm_rect_translate(>crtc_src, -iter->translate_crtc_x,
> > +

RE: [RFC 1/3] drm: Add DAMAGE_CLIPS property to plane

> 
> On Wed, Apr 04, 2018 at 04:49:06PM -0700, Deepak Rawat wrote:
> > From: Lukasz Spintzyk 
> >
> > Optional plane property to mark damaged regions on the plane in
> > framebuffer coordinates of the framebuffer attached to the plane.
> >
> > The layout of blob data is simply an array of drm_mode_rect with
> maximum
> > array size limited by DRM_MODE_FB_DIRTY_MAX_CLIPS. Unlike plane src
> > coordinates, damage clips are not in 16.16 fixed point.
> >
> > Damage clips are a hint to kernel as which area of framebuffer has
> > changed since last page-flip. This should be helpful for some drivers
> > especially for virtual devices where each framebuffer change needs to
> > be transmitted over network, usb, etc.
> >
> > Driver which are interested in enabling DAMAGE_CLIPS property for a
> > plane should enable this property using drm_plane_enable_damage_clips.
> >
> > Signed-off-by: Lukasz Spintzyk 
> > Signed-off-by: Deepak Rawat 
> 
> The property uapi section is missing, see:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__dri.freedesktop.org_docs_drm_gpu_drm-2Dkms.html-23plane-
> 2Dcomposition-
> 2Dproperties=DwIBAg=uilaK90D4TOVoH58JNXRgQ=zOOG28inJK0762
> SxAf-
> cyZdStnd2NQpRu98lJP2iYGw=ELAUsNTjD0ICwUEDFjPW4jsmy2A5AkhS5Q
> z_3vlEC9Q=nH-HNXPczoJQMj1iwHiGfrhXz4-00b0M8-3kirjm-EY=
> 
> Plane composition feels like the best place to put this. Please use that
> section to tie all the various bits together, including the helpers you're
> adding in the following patches for drivers to use.
> 
> Bunch of nitpicks below, but overall I'm agreeing now with just going with
> fb coordinate damage rects.
> 
> Like you say, the thing needed here now is userspace + driver actually
> implementing this. I'd also say the compat helper to map the legacy
> fb->dirty to this new atomic way of doing things should be included here
> (gives us a lot more testing for these new paths).
> 
> Icing on the cake would be an igt to make sure kernel rejects invalid clip
> rects correctly.
> 
> > ---
> >  drivers/gpu/drm/drm_atomic.c| 42
> +
> >  drivers/gpu/drm/drm_atomic_helper.c |  4 
> >  drivers/gpu/drm/drm_mode_config.c   |  5 +
> >  drivers/gpu/drm/drm_plane.c | 12 +++
> >  include/drm/drm_mode_config.h   | 15 +
> >  include/drm/drm_plane.h | 16 ++
> >  include/uapi/drm/drm_mode.h | 15 +
> >  7 files changed, 109 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c
> b/drivers/gpu/drm/drm_atomic.c
> > index 7d25c42..9226d24 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -669,6 +669,40 @@ static void drm_atomic_crtc_print_state(struct
> drm_printer *p,
> >  }
> >
> >  /**
> > + * drm_atomic_set_damage_for_plane - sets the damage clips property
> to plane
> > + * @state: plane state
> > + * @blob: damage clips in framebuffer coordinates
> > + *
> > + * Returns:
> > + *
> > + * Zero on success, error code on failure.
> > + */
> > +static int drm_atomic_set_damage_for_plane(struct drm_plane_state
> *state,
> > +  struct drm_property_blob *blob)
> > +{
> > +   if (blob == state->damage_clips)
> > +   return 0;
> > +
> > +   drm_property_blob_put(state->damage_clips);
> > +   state->damage_clips = NULL;
> > +
> > +   if (blob) {
> > +   uint32_t count = blob->length/sizeof(struct drm_rect);
> > +
> > +   if (count > DRM_MODE_FB_DIRTY_MAX_CLIPS)
> > +   return -EINVAL;
> > +
> > +   state->damage_clips = drm_property_blob_get(blob);
> > +   state->num_clips = count;
> > +   } else {
> > +   state->damage_clips = NULL;
> > +   state->num_clips = 0;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +/**
> >   * drm_atomic_get_plane_state - get plane state
> >   * @state: global atomic state object
> >   * @plane: plane to get state object for
> > @@ -793,6 +827,12 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> > state->color_encoding = val;
> > } else if (property == plane->color_range_property) {
> > state->color_range = val;
> > +   } else if (property == config->prop_damage_clips) {
> > +   struct drm_property_blob *blob =
> > +   drm_property_lookup_blob(dev, val);
> > +   int ret = drm_atomic_set_damage_for_plane(state, blob);
> 
> There's already a helper with size-checking built-in, see
> drm_atomic_replace_property_blob_from_id(). Wrt computing num_clips
> I'd
> just provide a little inline helper that does the
> blob->length/sizeof(drm_rect) conversion (it's just a shift, so fast).
> 
> > +   drm_property_blob_put(blob);
> > +   return ret;
> > } else if (plane->funcs->atomic_set_property) {
> > return

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: Send DPCD ON for MST before phy_up

2018-04-05 Thread Dhinakaran Pandiyan




On Thu, 2018-04-05 at 17:19 -0400, Lyude Paul wrote:
> When doing a modeset where the sink is transitioning from D3 to D0 , it
> would sometimes be possible for the initial power_up_phy() to start
> timing out. This would only be observed in the last action before the
> sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
> originally thought this might be an issue with us accidentally shutting
> off the aux block when putting the sink into D3, but since the DP spec
> mandates that sinks must wake up within 1ms while we have 100ms to
> respond to an ESI irq, this didn't really add up. Turns out that the
> problem is more subtle then that:
> 
> It turns out that the timeout is from us not enabling DPMS on the MST
> hub before actually trying to initiate sideband communications. This
> would cause the first sideband communication (power_up_phy()), to start
> timing out because the sink wasn't ready to respond. Afterwards, we
> would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in
> intel_ddi_pre_enable_dp(), which would actually result in waking up the
> sink so that sideband requests would work again.
> 
> Since DPMS is what lets us actually bring the hub up into a state where
> sideband communications become functional again, we just need to make
> sure to enable DPMS on the display before attempting to perform sideband
> communications.
> 
> Changes since v1:
> - Remove comment above if (!intel_dp->is_mst) - vsryjala
> - Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to
>   keep enable/disable paths symmetrical
> - Improve commit message - dhnkrn
> Changes since v2:
> - Only send DPMS off when we're disabling the last sink, and only send
>   DPMS on when we're enabling the first sink - dhnkrn
> 
> Signed-off-by: Lyude Paul 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Cc: Laura Abbott 
> Cc: sta...@vger.kernel.org
> Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST 
> hub.")
> ---
>  drivers/gpu/drm/i915/intel_ddi.c| 6 --
>  drivers/gpu/drm/i915/intel_dp_mst.c | 8 +++-
>  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index a6672a9abd85..c0bf7419e1c1 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   intel_prepare_dp_ddi_buffers(encoder, crtc_state);
>  
>   intel_ddi_init_dp_buf_reg(encoder);
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> + if (!intel_dp->is_mst)
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);



I believe Ville recommended to check for
is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)
here. The question is, are there cases where 
intel_dp->is_mst != is_mst? A disconnect in the middle of a modeset
would cause intel_dp->is_mst to be false, wouldn't it?







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

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: Send DPCD ON for MST before phy_up

2018-04-05 Thread Pandiyan, Dhinakaran




On Thu, 2018-04-05 at 17:19 -0400, Lyude Paul wrote:
> When doing a modeset where the sink is transitioning from D3 to D0 , it
> would sometimes be possible for the initial power_up_phy() to start
> timing out. This would only be observed in the last action before the
> sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
> originally thought this might be an issue with us accidentally shutting
> off the aux block when putting the sink into D3, but since the DP spec
> mandates that sinks must wake up within 1ms while we have 100ms to
> respond to an ESI irq, this didn't really add up. Turns out that the
> problem is more subtle then that:
> 
> It turns out that the timeout is from us not enabling DPMS on the MST
> hub before actually trying to initiate sideband communications. This
> would cause the first sideband communication (power_up_phy()), to start
> timing out because the sink wasn't ready to respond. Afterwards, we
> would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in
> intel_ddi_pre_enable_dp(), which would actually result in waking up the
> sink so that sideband requests would work again.
> 
> Since DPMS is what lets us actually bring the hub up into a state where
> sideband communications become functional again, we just need to make
> sure to enable DPMS on the display before attempting to perform sideband
> communications.
> 
> Changes since v1:
> - Remove comment above if (!intel_dp->is_mst) - vsryjala
> - Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to
>   keep enable/disable paths symmetrical
> - Improve commit message - dhnkrn
> Changes since v2:
> - Only send DPMS off when we're disabling the last sink, and only send
>   DPMS on when we're enabling the first sink - dhnkrn
> 
> Signed-off-by: Lyude Paul 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Cc: Laura Abbott 
> Cc: sta...@vger.kernel.org
> Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST 
> hub.")
> ---
>  drivers/gpu/drm/i915/intel_ddi.c| 6 --
>  drivers/gpu/drm/i915/intel_dp_mst.c | 8 +++-
>  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index a6672a9abd85..c0bf7419e1c1 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   intel_prepare_dp_ddi_buffers(encoder, crtc_state);
>  
>   intel_ddi_init_dp_buf_reg(encoder);
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> + if (!intel_dp->is_mst)
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);



I believe Ville recommended to check for
is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)
here. The question is, are there cases where 
intel_dp->is_mst != is_mst? A disconnect in the middle of a modeset
would cause intel_dp->is_mst to be false, wouldn't it?






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

Re: [Freedreno] [PATCH 01/10] include: Move ascii85 functions from i915 to linux/ascii85.h

On Thu, Apr 05, 2018 at 04:00:47PM -0600, Jordan Crouse wrote:
> The i915 DRM driver very cleverly used ascii85 encoding for their
> GPU state file. Move the encode functions to a general header file to
> support other drivers that might be interested in the same
> functionality.

In a previous version of this patch, Chris asked what tree I wanted this applied
to, and the answer is: I'm not sure?  I'm hoping that Rob will be cool with
picking the rest up for msm-next for 4.18 but I'm okay with putting this
particular patch wherever it is easiest for the maintainers.

Jordan

> Reviewed-by: Chris Wilson 
> Signed-off-by: Jordan Crouse 
>  drivers/gpu/drm/i915/i915_gpu_error.c | 35 ---
>  include/linux/ascii85.h   | 39 
> +++
>  2 files changed, 43 insertions(+), 31 deletions(-)
>  create mode 100644 include/linux/ascii85.h
> 
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 67c902412193..969d967e58c7 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -31,7 +31,7 @@
>  #include 
>  #include 
>  #include 
> -
> +#include 
>  #include "i915_drv.h"
>  
>  static inline const struct intel_engine_cs *
> @@ -518,35 +518,12 @@ void i915_error_printf(struct drm_i915_error_state_buf 
> *e, const char *f, ...)
>   va_end(args);
>  }
>  
> -static int
> -ascii85_encode_len(int len)
> -{
> - return DIV_ROUND_UP(len, 4);
> -}
> -
> -static bool
> -ascii85_encode(u32 in, char *out)
> -{
> - int i;
> -
> - if (in == 0)
> - return false;
> -
> - out[5] = '\0';
> - for (i = 5; i--; ) {
> - out[i] = '!' + in % 85;
> - in /= 85;
> - }
> -
> - return true;
> -}
> -
>  static void print_error_obj(struct drm_i915_error_state_buf *m,
>   struct intel_engine_cs *engine,
>   const char *name,
>   struct drm_i915_error_object *obj)
>  {
> - char out[6];
> + char out[ASCII85_BUFSZ];
>   int page;
>  
>   if (!obj)
> @@ -568,12 +545,8 @@ static void print_error_obj(struct 
> drm_i915_error_state_buf *m,
>   len -= obj->unused;
>   len = ascii85_encode_len(len);
>  
> - for (i = 0; i < len; i++) {
> - if (ascii85_encode(obj->pages[page][i], out))
> - err_puts(m, out);
> - else
> - err_puts(m, "z");
> - }
> + for (i = 0; i < len; i++)
> + error_puts(m, ascii85_encode(obj->pages[page][i], out));
>   }
>   err_puts(m, "\n");
>  }
> diff --git a/include/linux/ascii85.h b/include/linux/ascii85.h
> new file mode 100644
> index ..322bbed731ae
> --- /dev/null
> +++ b/include/linux/ascii85.h
> @@ -0,0 +1,39 @@
> +
> +/*
> + * SPDX-License-Identifier: GPL-2.0
> + *
> + * Copyright (c) 2008 Intel Corporation
> + * Copyright (c) The Linux Foundation. All rights reserved.
> + */
> +
> +#ifndef _ASCII85_H_
> +#define _ASCII85_H_
> +
> +#include 
> +
> +#define ASCII85_BUFSZ 6
> +
> +static inline long
> +ascii85_encode_len(long len)
> +{
> + return DIV_ROUND_UP(len, 4);
> +}
> +
> +static inline char *
> +ascii85_encode(u32 in, char *out)
> +{
> + int i;
> +
> + if (in == 0)
> + return "z";
> +
> + out[5] = '\0';
> + for (i = 5; i--; ) {
> + out[i] = '!' + in % 85;
> + in /= 85;
> + }
> +
> + return out;
> +}
> +
> +#endif
> -- 
> 2.16.1
> 
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 06/10] drm/msm/gpu: Capture the GPU state on a GPU hang

Capture the GPU state on a GPU hang and store it for later playback
via the devcoredump facility. Only one crash state is stored at a
time on the assumption that the first hang is usually the most
interesting. The existing crash state can be cleared after capturing
it and then a new one will be captured on the next hang.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/Kconfig |  1 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |  2 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |  2 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   |  4 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 36 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  4 +-
 drivers/gpu/drm/msm/msm_debugfs.c   |  7 ++-
 drivers/gpu/drm/msm/msm_gpu.c   | 83 -
 drivers/gpu/drm/msm/msm_gpu.h   | 38 ++-
 9 files changed, 155 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 38cbde971b48..843a9d40c05e 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -12,6 +12,7 @@ config DRM_MSM
select SHMEM
select TMPFS
select QCOM_SCM
+   select WANT_DEV_COREDUMP
select SND_SOC_HDMI_CODEC if SND_SOC
select SYNC_FILE
select PM_OPP
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 4cffec2b6adc..fc502e412132 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -454,7 +454,7 @@ static const struct adreno_gpu_funcs funcs = {
.active_ring = adreno_active_ring,
.irq = a3xx_irq,
.destroy = a3xx_destroy,
-#ifdef CONFIG_DEBUG_FS
+#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
.show = adreno_show,
 #endif
.gpu_state_get = a3xx_gpu_state_get,
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 95f08c22e8d7..8129cf037db1 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -540,7 +540,7 @@ static const struct adreno_gpu_funcs funcs = {
.active_ring = adreno_active_ring,
.irq = a4xx_irq,
.destroy = a4xx_destroy,
-#ifdef CONFIG_DEBUG_FS
+#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
.show = adreno_show,
 #endif
.gpu_state_get = a4xx_gpu_state_get,
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index b0910bbe5190..836a1df1f257 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1243,8 +1243,10 @@ static const struct adreno_gpu_funcs funcs = {
.active_ring = a5xx_active_ring,
.irq = a5xx_irq,
.destroy = a5xx_destroy,
-#ifdef CONFIG_DEBUG_FS
+#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
.show = adreno_show,
+#endif
+#if defined(CONFIG_DEBUG_FS)
.debugfs_init = a5xx_debugfs_init,
 #endif
.gpu_busy = a5xx_gpu_busy,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 522d47ac36e1..d46ae2ede616 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -378,6 +378,8 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
if (!state)
return ERR_PTR(-ENOMEM);
 
+   kref_init(>ref);
+
do_gettimeofday(>time);
 
for (i = 0; i < gpu->nr_rings; i++) {
@@ -413,18 +415,28 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
return state;
 }
 
-void adreno_gpu_state_put(struct msm_gpu_state *state)
+static void adreno_gpu_state_destroy(struct kref *kref)
 {
-   if (IS_ERR_OR_NULL(state))
-   return;
+   struct msm_gpu_state *state = container_of(kref,
+   struct msm_gpu_state, ref);
 
+   kfree(state->comm);
+   kfree(state->cmd);
kfree(state->registers);
kfree(state);
 }
 
-#ifdef CONFIG_DEBUG_FS
+int adreno_gpu_state_put(struct msm_gpu_state *state)
+{
+   if (IS_ERR_OR_NULL(state))
+   return 1;
+
+   return kref_put(>ref, adreno_gpu_state_destroy);
+}
+
+#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
 void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
-   struct seq_file *m)
+   struct drm_printer *p)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
int i;
@@ -432,23 +444,23 @@ void adreno_show(struct msm_gpu *gpu, struct 
msm_gpu_state *state,
if (IS_ERR_OR_NULL(state))
return;
 
-   seq_printf(m, "status:   %08x\n", state->rbbm_status);
-   seq_printf(m, "revision: %d (%d.%d.%d.%d)\n",
+   drm_printf(p, "status:   %08x\n",

[PATCH 04/10] drm/msm/gpu: Convert the GPU show function to use the GPU state

Convert the existing GPU show function to use the GPU state to
dump the information rather than reading it directly from the hardware.
This will require an additional step to capture the state before
dumping it for the existing nodes but it will greatly facilitate reusing
the same code for dumping a previously captured state from a GPU hang.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 11 +--
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 12 +---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 18 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 30 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  4 ++--
 drivers/gpu/drm/msm/msm_debugfs.c   | 21 +++--
 drivers/gpu/drm/msm/msm_gpu.h   |  3 ++-
 7 files changed, 35 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index b707b5bca9ab..4cffec2b6adc 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -411,15 +411,6 @@ static const unsigned int a3xx_registers[] = {
~0   /* sentinel */
 };
 
-#ifdef CONFIG_DEBUG_FS
-static void a3xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
-   seq_printf(m, "status:   %08x\n",
-   gpu_read(gpu, REG_A3XX_RBBM_STATUS));
-   adreno_show(gpu, m);
-}
-#endif
-
 /* would be nice to not have to duplicate the _show() stuff with printk(): */
 static void a3xx_dump(struct msm_gpu *gpu)
 {
@@ -464,7 +455,7 @@ static const struct adreno_gpu_funcs funcs = {
.irq = a3xx_irq,
.destroy = a3xx_destroy,
 #ifdef CONFIG_DEBUG_FS
-   .show = a3xx_show,
+   .show = adreno_show,
 #endif
.gpu_state_get = a3xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 17e97ebc1077..95f08c22e8d7 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -455,16 +455,6 @@ static const unsigned int a4xx_registers[] = {
~0 /* sentinel */
 };
 
-#ifdef CONFIG_DEBUG_FS
-static void a4xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
-   seq_printf(m, "status:   %08x\n",
-   gpu_read(gpu, REG_A4XX_RBBM_STATUS));
-   adreno_show(gpu, m);
-
-}
-#endif
-
 static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
 {
struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
@@ -551,7 +541,7 @@ static const struct adreno_gpu_funcs funcs = {
.irq = a4xx_irq,
.destroy = a4xx_destroy,
 #ifdef CONFIG_DEBUG_FS
-   .show = a4xx_show,
+   .show = adreno_show,
 #endif
.gpu_state_get = a4xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 08f25798abdb..b0910bbe5190 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1215,22 +1215,6 @@ static struct msm_gpu_state *a5xx_gpu_state_get(struct 
msm_gpu *gpu)
return state;
 }
 
-#ifdef CONFIG_DEBUG_FS
-static void a5xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
-   seq_printf(m, "status:   %08x\n",
-   gpu_read(gpu, REG_A5XX_RBBM_STATUS));
-
-   /*
-* Temporarily disable hardware clock gating before going into
-* adreno_show to avoid issues while reading the registers
-*/
-   a5xx_set_hwcg(gpu, false);
-   adreno_show(gpu, m);
-   a5xx_set_hwcg(gpu, true);
-}
-#endif
-
 static struct msm_ringbuffer *a5xx_active_ring(struct msm_gpu *gpu)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -1260,7 +1244,7 @@ static const struct adreno_gpu_funcs funcs = {
.irq = a5xx_irq,
.destroy = a5xx_destroy,
 #ifdef CONFIG_DEBUG_FS
-   .show = a5xx_show,
+   .show = adreno_show,
.debugfs_init = a5xx_debugfs_init,
 #endif
.gpu_busy = a5xx_gpu_busy,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index b2ccaf25767c..522d47ac36e1 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -423,38 +423,34 @@ void adreno_gpu_state_put(struct msm_gpu_state *state)
 }
 
 #ifdef CONFIG_DEBUG_FS
-void adreno_show(struct msm_gpu *gpu, struct seq_file *m)
+void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
+   struct seq_file *m)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
int i;
 
+   if (IS_ERR_OR_NULL(state))
+   return;
+
+   seq_printf(m, "status:   %08x\n", state->rbbm_status);
seq_printf(m, "revision: %d

[PATCH 07/10] drm/msm/adreno: Convert the show/crash file format

Convert the format of the 'show' debugfs file and the crash
dump to a  format resembling YAML. This should be easier to
parse and be more flexible for future changes and expansions.

Signed-off-by: Jordan Crouse 
---
 Documentation/gpu/drm-msm-crash-dump.txt | 30 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 21 +
 2 files changed, 43 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/gpu/drm-msm-crash-dump.txt

diff --git a/Documentation/gpu/drm-msm-crash-dump.txt 
b/Documentation/gpu/drm-msm-crash-dump.txt
new file mode 100644
index ..902d9769f401
--- /dev/null
+++ b/Documentation/gpu/drm-msm-crash-dump.txt
@@ -0,0 +1,30 @@
+# drm/msm GPU crash dump format
+#
+# This is a description of the format of the drm/msm GPU crash dump format that
+# can be read from /sys/kernel/dri/X/show or from devcoredump following a GPU
+# hang or fault
+
+---
+kernel:# [string] The kernel version as printed by UTS_RELEASE
+module:# [string] The module that generated the crash dump
+time:  # [seconds.microseconds] The kernel time at crash
+comm:  # [string] comm string for the binary that generated the fault
+   # (if known)
+cmdline:   # [string] the cmdline for the binary that generated the fault
+   # (if known)
+revision:  # [ id core.major.minor.patchlevel] The GPU id followed by the
+   # individual components of the id separated by dots
+rbbm-status:   # [hex] The current value of RBBM_STATUS which shows what GPU
+   # components were in use at the time of the crash
+ringbuffer:# Ringbuffer data. There will be a sequence for each ringbuffer
+  -id: # [decimal] Ringbuffer identifier (0 based index)
+   last-fence: # [decimal] The last fence issued on the ring
+   retired-fence:  # [decimal] THe last fence retired on the ring
+   rptr:   # [decimal] The current read pointer (rptr) for the ring
+   wptr:   # [decimal] The current write pointer (wptr) for the
+   # ring
+registers: # Sets of register values. This section can be used multiple
+   # times for different ranges of registers. Each register will be
+   # on its own line.
+  - [offset, value]# offset: [hex] byte offset of the register
+   # value: [hex] value of the register
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index d46ae2ede616..395885504503 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -444,23 +444,28 @@ void adreno_show(struct msm_gpu *gpu, struct 
msm_gpu_state *state,
if (IS_ERR_OR_NULL(state))
return;
 
-   drm_printf(p, "status:   %08x\n", state->rbbm_status);
drm_printf(p, "revision: %d (%d.%d.%d.%d)\n",
adreno_gpu->info->revn, adreno_gpu->rev.core,
adreno_gpu->rev.major, adreno_gpu->rev.minor,
adreno_gpu->rev.patchid);
 
-   for (i = 0; i < gpu->nr_rings; i++) {
-   drm_printf(p, "rb %d: fence:%d/%d\n", i,
-   state->ring[i].fence, state->ring[i].seqno);
+   drm_printf(p, "rbbm-status: 0x%08x\n", state->rbbm_status);
+
+   drm_printf(p, "ringbuffer:\n");
 
-   drm_printf(p, "  rptr: %d\n", state->ring[i].rptr);
-   drm_printf(p, "rb wptr:  %d\n", state->ring[i].wptr);
+   for (i = 0; i < gpu->nr_rings; i++) {
+   drm_printf(p, "  - id: %d\n", i);
+   drm_printf(p, "last-fence: %d\n", state->ring[i].seqno);
+   drm_printf(p, "retired-fence: %d\n", state->ring[i].fence);
+   drm_printf(p, "rptr: %d\n", state->ring[i].rptr);
+   drm_printf(p, "wptr: %d\n", state->ring[i].wptr);
}
 
-   drm_printf(p, "IO:region %s  0002\n", gpu->name);
+   drm_printf(p, "registers:\n");
+   drm_printf(p, "  - [offset, value]\n");
+
for (i = 0; i < state->nr_registers; i++) {
-   drm_printf(p, "IO:R %08x %08x\n",
+   drm_printf(p, "  - [0x%04x, 0x%08x]\n",
state->registers[i * 2] << 2,
state->registers[(i * 2) + 1]);
}
-- 
2.16.1

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

[PATCH 08/10] drm/msm/adreno: Add ringbuffer data to the GPU state

Add the contents of each ringbuffer to the GPU state and dump the
data in the crash file encoded with ascii85. To save space only
the used portions of the ringbuffer are dumped.

Signed-off-by: Jordan Crouse 
---
 Documentation/gpu/drm-msm-crash-dump.txt |  5 
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 41 
 drivers/gpu/drm/msm/msm_gpu.h|  2 ++
 3 files changed, 48 insertions(+)

diff --git a/Documentation/gpu/drm-msm-crash-dump.txt 
b/Documentation/gpu/drm-msm-crash-dump.txt
index 902d9769f401..df25afd10602 100644
--- a/Documentation/gpu/drm-msm-crash-dump.txt
+++ b/Documentation/gpu/drm-msm-crash-dump.txt
@@ -23,6 +23,11 @@ ringbuffer:  # Ringbuffer data. There will be a sequence for 
each ringbuffer
rptr:   # [decimal] The current read pointer (rptr) for the ring
wptr:   # [decimal] The current write pointer (wptr) for the
# ring
+   size:   # [decimal] The maximum size of the ring programmed in
+   # the hardware
+   data:   # [ascii85] The contents of the ring encoded as ascii85.
+   # Only the unused portions of the ring will be printed
+   # (up to a maximum of 'size' bytes)
 registers: # Sets of register values. This section can be used multiple
# times for different ranges of registers. Each register will be
# on its own line.
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 395885504503..a6414b6d5c0b 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -17,6 +17,7 @@
  * this program.  If not, see .
  */
 
+#include 
 #include 
 #include "adreno_gpu.h"
 #include "msm_gem.h"
@@ -383,10 +384,30 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
do_gettimeofday(>time);
 
for (i = 0; i < gpu->nr_rings; i++) {
+   int size = 0, j;
+
state->ring[i].fence = gpu->rb[i]->memptrs->fence;
state->ring[i].seqno = gpu->rb[i]->seqno;
state->ring[i].rptr = get_rptr(adreno_gpu, gpu->rb[i]);
state->ring[i].wptr = get_wptr(gpu->rb[i]);
+
+   /*
+* Only copy used parts of the ring buffers (this should save
+* data size for lightly used rings)
+*/
+   for (j = 0; j < MSM_GPU_RINGBUFFER_SZ >> 2; j++)
+   if (gpu->rb[i]->start[j])
+   size = j;
+
+   if (size) {
+   state->ring[i].data = kmalloc((size + 1) << 2,
+   GFP_KERNEL);
+   if (state->ring[i].data) {
+   memcpy(state->ring[i].data, gpu->rb[i]->start,
+   (size + 1) << 2);
+   state->ring[i].data_size = (size + 1) << 2;
+   }
+   }
}
 
/* Count the number of registers */
@@ -417,9 +438,13 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
 
 static void adreno_gpu_state_destroy(struct kref *kref)
 {
+   int i;
struct msm_gpu_state *state = container_of(kref,
struct msm_gpu_state, ref);
 
+   for (i = 0; i < ARRAY_SIZE(state->ring); i++)
+   kfree(state->ring[i].data);
+
kfree(state->comm);
kfree(state->cmd);
kfree(state->registers);
@@ -459,6 +484,22 @@ void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state 
*state,
drm_printf(p, "retired-fence: %d\n", state->ring[i].fence);
drm_printf(p, "rptr: %d\n", state->ring[i].rptr);
drm_printf(p, "wptr: %d\n", state->ring[i].wptr);
+   drm_printf(p, "size: %d\n", MSM_GPU_RINGBUFFER_SZ);
+
+   if (state->ring[i].data && state->ring[i].data_size) {
+   u32 *ptr = (u32 *) state->ring[i].data;
+   char out[ASCII85_BUFSZ];
+   long len = ascii85_encode_len(state->ring[i].data_size);
+   int j;
+
+   drm_printf(p, "data: !!ascii85 |\n");
+   drm_printf(p, " ");
+
+   for (j = 0; j < len; j++)
+   drm_printf(p, ascii85_encode(ptr[j], out));
+
+   drm_printf(p, "\n");
+   }
}
 
drm_printf(p, "registers:\n");
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index e65f507954c0..48f7b21f1cae 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -190,6 +190,8 @@ struct msm_gpu_state {
u32 seqno;
u32 rptr;
u32 wptr;
+

[PATCH 02/10] drm: drm_printer: Add printer for devcoredump

Add a drm printer suitable for use with the read callback for
devcoredump or any other file operation read() function that
isn't otherwise covered by seq_file.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/drm_print.c | 54 +
 include/drm/drm_print.h | 27 +++
 2 files changed, 81 insertions(+)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 781518fd88e3..f6efde48f8b3 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -30,6 +30,60 @@
 #include 
 #include 
 
+void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf)
+{
+   struct drm_print_iterator *iterator = p->arg;
+
+   ssize_t len;
+
+   if (!iterator->remain)
+   return;
+
+   if (iterator->offset < iterator->start) {
+   char *buf;
+   ssize_t copy;
+
+   /* Figure out how big the string will be */
+   len = snprintf(NULL, 0, "%pV", vaf);
+
+   if (iterator->offset + len <= iterator->start) {
+   iterator->offset += len;
+   return;
+   }
+
+   /* Print the string into a temporary buffer */
+   buf = kmalloc(len + 1,
+   GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
+   if (!buf)
+   return;
+
+   snprintf(buf, len + 1, "%pV", vaf);
+
+   copy = len - (iterator->start - iterator->offset);
+
+   if (copy > iterator->remain)
+   copy = iterator->remain;
+
+   /* Copy out the bit of the string that we need */
+   memcpy(iterator->data,
+   buf + (iterator->start - iterator->offset), copy);
+
+   iterator->offset = iterator->start + copy;
+   iterator->remain -= copy;
+
+   kfree(buf);
+   } else {
+   ssize_t pos = iterator->offset - iterator->start;
+
+   len = scnprintf(((char *) iterator->data) + pos,
+   iterator->remain, "%pV", vaf);
+
+   iterator->offset += len;
+   iterator->remain -= len;
+   }
+}
+EXPORT_SYMBOL(__drm_printfn_coredump);
+
 void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf)
 {
seq_printf(p->arg, "%pV", vaf);
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 2a4a42e59a47..29eee5175eac 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -73,6 +73,7 @@ struct drm_printer {
const char *prefix;
 };
 
+void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf);
@@ -104,6 +105,32 @@ drm_vprintf(struct drm_printer *p, const char *fmt, 
va_list *va)
 #define drm_printf_indent(printer, indent, fmt, ...) \
drm_printf((printer), "%.*s" fmt, (indent), "\t\t\t\t\tX", 
##__VA_ARGS__)
 
+struct drm_print_iterator {
+   void *data;
+
+   ssize_t start;
+   ssize_t offset;
+   ssize_t remain;
+};
+
+/**
+ * drm_coredump_printer - construct a _printer that can output to a buffer
+ * from the read function for devcoredump
+ * @iter: A pointer to a struct drm_print_iterator for the read instance
+ *
+ * RETURNS:
+ * The _printer object
+ */
+static inline struct drm_printer
+drm_coredump_printer(struct drm_print_iterator *iter)
+{
+   struct drm_printer p = {
+   .printfn = __drm_printfn_coredump,
+   .arg = iter,
+   };
+   return p;
+}
+
 /**
  * drm_seq_file_printer - construct a _printer that outputs to _file
  * @f:  the  seq_file to output to
-- 
2.16.1

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

[PATCH 10/10] drm/msm/gpu: Add the buffer objects from the submit to the crash dump

On a hang copy out the contents of the buffer objects attached to the
guilty submission and print them in the crash dump report.

Signed-off-by: Jordan Crouse 
---
 Documentation/gpu/drm-msm-crash-dump.txt |  7 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 54 ++--
 drivers/gpu/drm/msm/msm_gpu.c| 48 ++--
 drivers/gpu/drm/msm/msm_gpu.h|  9 ++
 4 files changed, 105 insertions(+), 13 deletions(-)

diff --git a/Documentation/gpu/drm-msm-crash-dump.txt 
b/Documentation/gpu/drm-msm-crash-dump.txt
index f84a47a9ca92..930e4c970a62 100644
--- a/Documentation/gpu/drm-msm-crash-dump.txt
+++ b/Documentation/gpu/drm-msm-crash-dump.txt
@@ -28,6 +28,13 @@ ringbuffer:  # Ringbuffer data. There will be a sequence for 
each ringbuffer
data:   # [ascii85] The contents of the ring encoded as ascii85.
# Only the unused portions of the ring will be printed
# (up to a maximum of 'size' bytes)
+bos:   # List of buffers from the hanging submission (if known)
+  -iova:   # [hex] GPU address of the buffer
+   size:   # [decimal] Size of the buffer (in bytes)
+   data:   # [ascii85] The contents of the buffer encoded as
+   # ascii85. Only the contents of buffers marked as
+   # readable are dumped. Trailing zeros at the end of the
+   # buffer won't be dumped.
 registers: # Sets of register values. This section can be used multiple
# times for different ranges of registers. Each register will be
# on its own line.
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index b92bcbde688e..5daca5ba7e06 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -438,6 +438,10 @@ void adreno_gpu_state_destroy(struct msm_gpu_state *state)
for (i = 0; i < ARRAY_SIZE(state->ring); i++)
kfree(state->ring[i].data);
 
+   for (i = 0; state->bos && i < state->nr_bos; i++)
+   kfree(state->bos[i].data);
+
+   kfree(state->bos);
kfree(state->comm);
kfree(state->cmd);
kfree(state->registers);
@@ -461,6 +465,35 @@ int adreno_gpu_state_put(struct msm_gpu_state *state)
 }
 
 #if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
+
+static void adreno_show_object(struct drm_printer *p, u32 *ptr, int len)
+{
+   char out[ASCII85_BUFSZ];
+   long l, datalen, i;
+
+   if (!ptr || !len)
+   return;
+
+   /*
+* Only dump the non-zero part of the buffer - rarely will any data
+* completely fill the entire allocated size of the buffer
+*/
+   for (datalen = 0, i = 0; i < len >> 2; i++) {
+   if (ptr[i])
+   datalen = i << 2;
+   }
+
+   l = ascii85_encode_len(datalen);
+
+   drm_printf(p, "data: !!ascii85 |\n");
+   drm_printf(p, " ");
+
+   for (i = 0; i < l; i++)
+   drm_printf(p, ascii85_encode(ptr[i], out));
+
+   drm_printf(p, "\n");
+}
+
 void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
struct drm_printer *p)
 {
@@ -487,19 +520,20 @@ void adreno_show(struct msm_gpu *gpu, struct 
msm_gpu_state *state,
drm_printf(p, "wptr: %d\n", state->ring[i].wptr);
drm_printf(p, "size: %d\n", MSM_GPU_RINGBUFFER_SZ);
 
-   if (state->ring[i].data && state->ring[i].data_size) {
-   u32 *ptr = (u32 *) state->ring[i].data;
-   char out[ASCII85_BUFSZ];
-   long len = ascii85_encode_len(state->ring[i].data_size);
-   int j;
+   adreno_show_object(p, state->ring[i].data,
+   state->ring[i].data_size);
+   }
 
-   drm_printf(p, "data: !!ascii85 |\n");
-   drm_printf(p, " ");
+   if (state->bos) {
+   drm_printf(p, "bos:\n");
 
-   for (j = 0; j < len; j++)
-   drm_printf(p, ascii85_encode(ptr[j], out));
+   for (i = 0; i < state->nr_bos; i++) {
+   drm_printf(p, "  - iova: 0x%016llx\n",
+   state->bos[i].iova);
+   drm_printf(p, "size: %ld\n", state->bos[i].size);
 
-   drm_printf(p, "\n");
+   adreno_show_object(p, state->bos[i].data,
+   state->bos[i].size);
}
}
 
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index f36b415e123b..92395c5ef442 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -318,8 +318,39 @@ static void

[v4 00/10] drm/msm: GPU crash state

This is revision 4 implementing a GPU crash state for drm/msm
(https://patchwork.freedesktop.org/series/36097/).  I think its mature enough
to pull out of RFC status and think about merging.

The goal is to store and provide enough information to debug software
and hardware issues on the Adreno hardware in a semi human-readable
format that can also be parsed by scripts.

THe full set of changes here capture basic information about the GPU, the
status and contents of the ringbuffers, a snapshot of the current register state
and the active buffers from the hanging submit.

The data is printed with devcoredump.  For example, after a hang you can get
the data from /sys/class/devcoredump/devcdX/data where X is a unique number.

You can see an example of the output for a simple invalid opcode error on the
db820c here: https://hastebin.com/yivozimoki.bash

v4: Add buffer dump for the active submit. Fix refcount issue with devcoredump.
Change header for a5xx registers to registers-hlsq because I'm told YAML
requires unique tags.
v3: Make recommended changes to ascii85 per Chris Wilson. Use devcoredump to
dump crash states as suggested by Bjorn Andersson and add a new drm_print
facility to facilitate that. Remove the now obsolete 'crash' debugfs node.
Add documentation for the crash dump output.

v2: Convert output to yaml, use ascii85 to dump ringbuffer contents.

Jordan Crouse (10):
  include: Move ascii85 functions from i915 to linux/ascii85.h
  drm: drm_printer: Add printer for devcoredump
  drm/msm/gpu: Capture the state of the GPU
  drm/msm/gpu: Convert the GPU show function to use the GPU state
  drm/msm/gpu: Rearrange the code that collects the task during a hang
  drm/msm/gpu: Capture the GPU state on a GPU hang
  drm/msm/adreno: Convert the show/crash file format
  drm/msm/adreno: Add ringbuffer data to the GPU state
  drm/msm/adreno: Add a5xx specific registers for the GPU state
  drm/msm/gpu: Add the buffer objects from the submit to the crash dump

 Documentation/gpu/drm-msm-crash-dump.txt |  46 ++
 drivers/gpu/drm/drm_print.c  |  54 +++
 drivers/gpu/drm/i915/i915_gpu_error.c|  35 +
 drivers/gpu/drm/msm/Kconfig  |   1 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c|  30 ++--
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c|  22 ++-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c| 243 +--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 181 ---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h  |   7 +-
 drivers/gpu/drm/msm/msm_debugfs.c|  24 ++-
 drivers/gpu/drm/msm/msm_gpu.c| 143 --
 drivers/gpu/drm/msm/msm_gpu.h|  67 -
 include/drm/drm_print.h  |  27 
 include/linux/ascii85.h  |  39 +
 14 files changed, 821 insertions(+), 98 deletions(-)
 create mode 100644 Documentation/gpu/drm-msm-crash-dump.txt
 create mode 100644 include/linux/ascii85.h

-- 
2.16.1

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

[PATCH 09/10] drm/msm/adreno: Add a5xx specific registers for the GPU state

HLSQ, SP and TP registers are only accessible from a special
aperture and to make matters worse the aperture is blocked from
the CPU on targets that can support secure rendering. Luckily the
GPU hardware has its own purpose built register dumper that can
access the registers from the aperture.  Add a5xx specific code
to program the crashdumper and retrieve the wayward registers
and dump them for the crash state.

Also, remove a block of registers the regular CPU accessible
list that aren't useful for debug which helps reduce the size
of the crash state file by a goodly amount.

Signed-off-by: Jordan Crouse 
---
 Documentation/gpu/drm-msm-crash-dump.txt |   4 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c|   8 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c|   8 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c| 237 +--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  |  23 +--
 drivers/gpu/drm/msm/adreno/adreno_gpu.h  |   4 +-
 6 files changed, 253 insertions(+), 31 deletions(-)

diff --git a/Documentation/gpu/drm-msm-crash-dump.txt 
b/Documentation/gpu/drm-msm-crash-dump.txt
index df25afd10602..f84a47a9ca92 100644
--- a/Documentation/gpu/drm-msm-crash-dump.txt
+++ b/Documentation/gpu/drm-msm-crash-dump.txt
@@ -33,3 +33,7 @@ registers:# Sets of register values. This section can be 
used multiple
# on its own line.
   - [offset, value]# offset: [hex] byte offset of the register
# value: [hex] value of the register
+
+registers-hlsq: # (5xx only) Same format as registers. Register data that
+   # only accessible from the HLSQ aperture captured by the
+   # HW based crashdumper
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index fc502e412132..669c2d4b070d 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -421,10 +421,12 @@ static void a3xx_dump(struct msm_gpu *gpu)
 
 static struct msm_gpu_state *a3xx_gpu_state_get(struct msm_gpu *gpu)
 {
-   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+   struct msm_gpu_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
 
-   if (IS_ERR(state))
-   return state;
+   if (!state)
+   return ERR_PTR(-ENOMEM);
+
+   adreno_gpu_state_get(gpu, state);
 
state->rbbm_status = gpu_read(gpu, REG_A3XX_RBBM_STATUS);
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 8129cf037db1..7c4e6dc1ed59 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -457,10 +457,12 @@ static const unsigned int a4xx_registers[] = {
 
 static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
 {
-   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+   struct msm_gpu_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
 
-   if (IS_ERR(state))
-   return state;
+   if (!state)
+   return ERR_PTR(-ENOMEM);
+
+   adreno_gpu_state_get(gpu, state);
 
state->rbbm_status = gpu_read(gpu, REG_A4XX_RBBM_STATUS);
 
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 836a1df1f257..0090fec862c1 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "msm_gem.h"
 #include "msm_mmu.h"
 #include "a5xx_gpu.h"
@@ -1123,8 +1124,9 @@ static const u32 a5xx_registers[] = {
0xE800, 0xE806, 0xE810, 0xE89A, 0xE8A0, 0xE8A4, 0xE8AA, 0xE8EB,
0xE900, 0xE905, 0xEB80, 0xEB8F, 0xEBB0, 0xEBB0, 0xEC00, 0xEC05,
0xEC08, 0xECE9, 0xECF0, 0xECF0, 0xEA80, 0xEA80, 0xEA82, 0xEAA3,
-   0xEAA5, 0xEAC2, 0xA800, 0xA8FF, 0xAC60, 0xAC60, 0xB000, 0xB97F,
-   0xB9A0, 0xB9BF, ~0
+   0xEAA5, 0xEAC2, 0xA800, 0xA800, 0xA820, 0xA828, 0xA840, 0xA87D,
+   0XA880, 0xA88D, 0xA890, 0xA8A3, 0xA8D0, 0xA8D8, 0xA8E0, 0xA8F5,
+   0xAC60, 0xAC60, ~0,
 };
 
 static void a5xx_dump(struct msm_gpu *gpu)
@@ -1195,25 +1197,234 @@ static int a5xx_get_timestamp(struct msm_gpu *gpu, 
uint64_t *value)
return 0;
 }
 
+struct a5xx_crashdumper {
+   void *ptr;
+   struct drm_gem_object *bo;
+   u64 iova;
+};
+
+struct a5xx_gpu_state {
+   struct msm_gpu_state base;
+   u32 *hlsqregs;
+};
+
+#define gpu_poll_timeout(gpu, addr, val, cond, interval, timeout) \
+   readl_poll_timeout((gpu)->mmio + ((addr) << 2), val, cond, \
+   interval, timeout)
+
+static int a5xx_crashdumper_init(struct msm_gpu *gpu,
+   struct a5xx_crashdumper *dumper)
+{
+   dumper->ptr = msm_gem_kernel_new_locked(gpu->dev,
+   SZ_1M, MSM_BO_UNCACHED, gpu->aspace,
+   >bo, >iova);
+
+   if (IS_ERR(dumper->ptr))
+   return PTR_ERR(dumper->ptr);
+
+   return 0;
+}
+
+static void

[PATCH 03/10] drm/msm/gpu: Capture the state of the GPU

Add the infrastructure to capture the state current state of the
GPU and store it in memory. This is useful for storing the state
of a hung GPU so it can be dumped later.

For now grab the same basic ringbuffer information and registers
that are provided by the debugfs 'gpu' node but obviously this can
be extended to capture a much larger set of GPU information.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 15 +
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 14 +
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 22 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 54 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  3 ++
 drivers/gpu/drm/msm/msm_gpu.h   | 19 
 6 files changed, 127 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 3ebbeb3a9b68..b707b5bca9ab 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -427,6 +427,19 @@ static void a3xx_dump(struct msm_gpu *gpu)
gpu_read(gpu, REG_A3XX_RBBM_STATUS));
adreno_dump(gpu);
 }
+
+static struct msm_gpu_state *a3xx_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+
+   if (IS_ERR(state))
+   return state;
+
+   state->rbbm_status = gpu_read(gpu, REG_A3XX_RBBM_STATUS);
+
+   return state;
+}
+
 /* Register offset defines for A3XX */
 static const unsigned int a3xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_AXXX_CP_RB_BASE),
@@ -453,6 +466,8 @@ static const struct adreno_gpu_funcs funcs = {
 #ifdef CONFIG_DEBUG_FS
.show = a3xx_show,
 #endif
+   .gpu_state_get = a3xx_gpu_state_get,
+   .gpu_state_put = adreno_gpu_state_put,
},
 };
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 16d3d596638e..17e97ebc1077 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -465,6 +465,18 @@ static void a4xx_show(struct msm_gpu *gpu, struct seq_file 
*m)
 }
 #endif
 
+static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+
+   if (IS_ERR(state))
+   return state;
+
+   state->rbbm_status = gpu_read(gpu, REG_A4XX_RBBM_STATUS);
+
+   return state;
+}
+
 /* Register offset defines for A4XX, in order of enum adreno_regs */
 static const unsigned int a4xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_A4XX_CP_RB_BASE),
@@ -541,6 +553,8 @@ static const struct adreno_gpu_funcs funcs = {
 #ifdef CONFIG_DEBUG_FS
.show = a4xx_show,
 #endif
+   .gpu_state_get = a4xx_gpu_state_get,
+   .gpu_state_put = adreno_gpu_state_put,
},
.get_timestamp = a4xx_get_timestamp,
 };
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index a4f68affc13b..08f25798abdb 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1195,6 +1195,26 @@ static int a5xx_get_timestamp(struct msm_gpu *gpu, 
uint64_t *value)
return 0;
 }
 
+static struct msm_gpu_state *a5xx_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct msm_gpu_state *state;
+
+   /*
+* Temporarily disable hardware clock gating before going into
+* adreno_show to avoid issues while reading the registers
+*/
+   a5xx_set_hwcg(gpu, false);
+
+   state = adreno_gpu_state_get(gpu);
+
+   if (!IS_ERR(state))
+   state->rbbm_status = gpu_read(gpu, REG_A5XX_RBBM_STATUS);
+
+   a5xx_set_hwcg(gpu, true);
+
+   return state;
+}
+
 #ifdef CONFIG_DEBUG_FS
 static void a5xx_show(struct msm_gpu *gpu, struct seq_file *m)
 {
@@ -1244,6 +1264,8 @@ static const struct adreno_gpu_funcs funcs = {
.debugfs_init = a5xx_debugfs_init,
 #endif
.gpu_busy = a5xx_gpu_busy,
+   .gpu_state_get = a5xx_gpu_state_get,
+   .gpu_state_put = adreno_gpu_state_put,
},
.get_timestamp = a5xx_get_timestamp,
 };
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 17d0506d058c..b2ccaf25767c 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -368,6 +368,60 @@ bool adreno_idle(struct msm_gpu *gpu, struct 
msm_ringbuffer *ring)
return false;
 }
 
+struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct msm_gpu_state *state;
+   int i, count = 0;
+
+   state = kzalloc(sizeof(*state), GFP_KERNEL);
+   if (!state)
+   return

[PATCH 01/10] include: Move ascii85 functions from i915 to linux/ascii85.h

The i915 DRM driver very cleverly used ascii85 encoding for their
GPU state file. Move the encode functions to a general header file to
support other drivers that might be interested in the same
functionality.

Reviewed-by: Chris Wilson 
Signed-off-by: Jordan Crouse 
 drivers/gpu/drm/i915/i915_gpu_error.c | 35 ---
 include/linux/ascii85.h   | 39 +++
 2 files changed, 43 insertions(+), 31 deletions(-)
 create mode 100644 include/linux/ascii85.h

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 67c902412193..969d967e58c7 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 #include 
-
+#include 
 #include "i915_drv.h"
 
 static inline const struct intel_engine_cs *
@@ -518,35 +518,12 @@ void i915_error_printf(struct drm_i915_error_state_buf 
*e, const char *f, ...)
va_end(args);
 }
 
-static int
-ascii85_encode_len(int len)
-{
-   return DIV_ROUND_UP(len, 4);
-}
-
-static bool
-ascii85_encode(u32 in, char *out)
-{
-   int i;
-
-   if (in == 0)
-   return false;
-
-   out[5] = '\0';
-   for (i = 5; i--; ) {
-   out[i] = '!' + in % 85;
-   in /= 85;
-   }
-
-   return true;
-}
-
 static void print_error_obj(struct drm_i915_error_state_buf *m,
struct intel_engine_cs *engine,
const char *name,
struct drm_i915_error_object *obj)
 {
-   char out[6];
+   char out[ASCII85_BUFSZ];
int page;
 
if (!obj)
@@ -568,12 +545,8 @@ static void print_error_obj(struct 
drm_i915_error_state_buf *m,
len -= obj->unused;
len = ascii85_encode_len(len);
 
-   for (i = 0; i < len; i++) {
-   if (ascii85_encode(obj->pages[page][i], out))
-   err_puts(m, out);
-   else
-   err_puts(m, "z");
-   }
+   for (i = 0; i < len; i++)
+   error_puts(m, ascii85_encode(obj->pages[page][i], out));
}
err_puts(m, "\n");
 }
diff --git a/include/linux/ascii85.h b/include/linux/ascii85.h
new file mode 100644
index ..322bbed731ae
--- /dev/null
+++ b/include/linux/ascii85.h
@@ -0,0 +1,39 @@
+
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (c) 2008 Intel Corporation
+ * Copyright (c) The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _ASCII85_H_
+#define _ASCII85_H_
+
+#include 
+
+#define ASCII85_BUFSZ 6
+
+static inline long
+ascii85_encode_len(long len)
+{
+   return DIV_ROUND_UP(len, 4);
+}
+
+static inline char *
+ascii85_encode(u32 in, char *out)
+{
+   int i;
+
+   if (in == 0)
+   return "z";
+
+   out[5] = '\0';
+   for (i = 5; i--; ) {
+   out[i] = '!' + in % 85;
+   in /= 85;
+   }
+
+   return out;
+}
+
+#endif
-- 
2.16.1

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

[PATCH 05/10] drm/msm/gpu: Rearrange the code that collects the task during a hang

Do a bit of cleanup to prepare for upcoming changes to pass the
hanging task comm and cmdline to the crash dump function.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/msm_gpu.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 1c09acfb4028..2ca354047250 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -314,6 +314,7 @@ static void recover_worker(struct work_struct *work)
struct msm_drm_private *priv = dev->dev_private;
struct msm_gem_submit *submit;
struct msm_ringbuffer *cur_ring = gpu->funcs->active_ring(gpu);
+   char *comm = NULL, *cmd = NULL;
int i;
 
mutex_lock(>struct_mutex);
@@ -327,7 +328,7 @@ static void recover_worker(struct work_struct *work)
rcu_read_lock();
task = pid_task(submit->pid, PIDTYPE_PID);
if (task) {
-   char *cmd;
+   comm = kstrdup(task->comm, GFP_KERNEL);
 
/*
 * So slightly annoying, in other paths like
@@ -342,20 +343,21 @@ static void recover_worker(struct work_struct *work)
mutex_unlock(>struct_mutex);
cmd = kstrdup_quotable_cmdline(task, GFP_KERNEL);
mutex_lock(>struct_mutex);
+   }
+   rcu_read_unlock();
 
+   if (comm && cmd) {
dev_err(dev->dev, "%s: offending task: %s (%s)\n",
-   gpu->name, task->comm, cmd);
+   gpu->name, comm, cmd);
 
msm_rd_dump_submit(priv->hangrd, submit,
-   "offending task: %s (%s)", task->comm, cmd);
-
-   kfree(cmd);
-   } else {
+   "offending task: %s (%s)", comm, cmd);
+   } else
msm_rd_dump_submit(priv->hangrd, submit, NULL);
-   }
-   rcu_read_unlock();
}
 
+   kfree(cmd);
+   kfree(comm);
 
/*
 * Update all the rings with the latest and greatest fence.. this
-- 
2.16.1

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

[Bug 105869] clang crashes when compiling OpenCL kernel

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

Jan Vesely  changed:

   What|Removed |Added

 Status|NEEDINFO|NEW

--- Comment #5 from Jan Vesely  ---
OK, I tried adding -mcpu=tonga to the command line to match the asic. Still no
crash.
Are you sure it's the PulseWave kernel that's crashing?

At any rate, you should check llvm/clang-6 (that one can still be fixed if the
problem persists).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104412] RX 460 HDMI 4k 60fps not working, DisplayPort is.

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

--- Comment #16 from S.H.  ---
(In reply to S.H. from comment #15)
> (In reply to Harry Wentland from comment #13)
> > The problem with 4k60 being blocked due to a BIOS bit should be fixed now. I
> > recommend trying the drm-next-4.17-wip from
> > https://cgit.freedesktop.org/~agd5f/linux
> 
> Hi,
> thanks for the update. I wasn't able to check out and test until today.
> 4k@60Hz is still not detected automatically, but:
> - I was able to set 60Hz manually and
> - I do NOT need to remove any patches anymore from kernel source
> 
> Cheers,
> Sven

Hi,
me again.
I noticed random flickering with drm-next-4.17-wip which is not present with
kernel 4.15.x.

Cheers,
Sven

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

2018-04-05 Thread Rob Herring

On Thu, Apr 5, 2018 at 1:53 PM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Thursday, 5 April 2018 19:33:33 EEST Rob Herring wrote:
>> On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart wrote:
>> > On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
>> >> On 03/27/2018 01:10 PM, jacopo mondi wrote:
>> >>> On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
>>  On 03/27/2018 11:57 AM, jacopo mondi wrote:
>> > On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
>> >> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
>> >>> On 3/27/2018 10:33 AM, jacopo mondi wrote:
>> >>> [...]
>> >>>
>> > Document Thine THC63LVD1024 LVDS decoder device tree
>> > bindings.
>> >
>> > Signed-off-by: Jacopo Mondi 
>> > Reviewed-by: Andrzej Hajda 
>> > Reviewed-by: Niklas Söderlund
>> > 
>> > ---
>> >
>> >   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
>> >   1 file changed, 66 insertions(+)
>> >   create mode 100644
>> >
>> > Documentation/devicetree/bindings/display/bridge/thine,thc63l
>> > vd1024.txt
>> > diff --git
>> > a/Documentation/devicetree/bindings/display/bridge/thine,thc6
>> > 3lvd1024.txt
>> > b/Documentation/devicetree/bindings/display/bridge/thine,thc6
>> > 3lvd1024.txt
>> > new file mode 100644
>> > index 000..8225c6a
>> > --- /dev/null
>> > +++
>> > b/Documentation/devicetree/bindings/display/bridge/thine,thc6
>> > 3lvd1024.txt
>> > @@ -0,0 +1,66 @@
>> > +Thine Electronics THC63LVD1024 LVDS decoder
>> > +---
>> > +
>> > +The THC63LVD1024 is a dual link LVDS receiver designed to
>> > convert LVDS streams
>> > +to parallel data outputs. The chip supports single/dual
>> > input/output modes,
>> > +handling up to two two input LVDS stream and up to two
>> > digital CMOS/TTL outputs.
>> > +
>> > +Single or dual operation modes, output data mapping and DDR
>> > output modes are
>> > +configured through input signals and the chip does not
>> > expose any control bus.
>> > +
>> > +Required properties:
>> > +- compatible: Shall be "thine,thc63lvd1024"
>> > +
>> > +Optional properties:
>> > +- vcc-supply: Power supply for TTL output and digital
>> > circuitry
>> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>> > +- lvcc-supply: Power supply for LVDS inputs
>> > +- pvcc-supply: Power supply for PLL circuitry
>> 
>>  As explained in a comment to one of the previous versions of
>>  this series, I'm tempted to make vcc-supply mandatory and drop
>>  the three other power supplies for now, as I believe there's
>>  very little chance they will be connected to separately
>>  controllable regulators (all supplies use the same voltage). In
>>  the very unlikely event that this occurs in design we need to
>>  support in the future, the cvcc, lvcc and pvcc supplies can be
>>  added later as optional without breaking backward
>>  compatibility.
>> >>>
>> >>> I'm okay with that.
>> >>>
>>  Apart from that,
>> 
>>  Reviewed-by: Laurent Pinchart
>>  
>> 
>> > +- pdwn-gpios: Power down GPIO signal. Active low
>> >>>
>> >>> powerdown-gpios is the semi-standard name.
>> >>
>> >> right, I've also noticed it. If possible please avoid
>> >> shortenings in property names.
>> >
>> > It is not shortening, it just follow pin name from decoder's
>> > datasheet.
>> >
>> > +- oe-gpios: Output enable GPIO signal. Active high
>> > +
>> >>
>> >> And this one is also a not ever met property name, please
>> >> consider to rename it to 'enable-gpios', for instance display
>> >> panels define it.
>> >
>> > Again, it follows datasheet naming scheme. Has something changed
>> > in DT conventions?
>> 
>>  Seconded. My understanding is that the property name should
>>  reflect what reported in the the chip manual. For THC63LVD1024 the
>>  enable and power down pins are named 'OE' and

[PATCH v3] drm/i915/dp: Send DPCD ON for MST before phy_up

2018-04-05 Thread Lyude Paul

When doing a modeset where the sink is transitioning from D3 to D0 , it
would sometimes be possible for the initial power_up_phy() to start
timing out. This would only be observed in the last action before the
sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
originally thought this might be an issue with us accidentally shutting
off the aux block when putting the sink into D3, but since the DP spec
mandates that sinks must wake up within 1ms while we have 100ms to
respond to an ESI irq, this didn't really add up. Turns out that the
problem is more subtle then that:

It turns out that the timeout is from us not enabling DPMS on the MST
hub before actually trying to initiate sideband communications. This
would cause the first sideband communication (power_up_phy()), to start
timing out because the sink wasn't ready to respond. Afterwards, we
would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in
intel_ddi_pre_enable_dp(), which would actually result in waking up the
sink so that sideband requests would work again.

Since DPMS is what lets us actually bring the hub up into a state where
sideband communications become functional again, we just need to make
sure to enable DPMS on the display before attempting to perform sideband
communications.

Changes since v1:
- Remove comment above if (!intel_dp->is_mst) - vsryjala
- Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to
  keep enable/disable paths symmetrical
- Improve commit message - dhnkrn
Changes since v2:
- Only send DPMS off when we're disabling the last sink, and only send
  DPMS on when we're enabling the first sink - dhnkrn

Signed-off-by: Lyude Paul 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Cc: Laura Abbott 
Cc: sta...@vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
---
 drivers/gpu/drm/i915/intel_ddi.c| 6 --
 drivers/gpu/drm/i915/intel_dp_mst.c | 8 +++-
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a6672a9abd85..c0bf7419e1c1 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_prepare_dp_ddi_buffers(encoder, crtc_state);
 
intel_ddi_init_dp_buf_reg(encoder);
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+   if (!intel_dp->is_mst)
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
@@ -2427,7 +2428,8 @@ static void intel_ddi_post_disable_dp(struct 
intel_encoder *encoder,
 * Power down sink before disabling the port, otherwise we end
 * up getting interrupts from the sink on detecting link loss.
 */
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+   if (!intel_dp->is_mst)
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
 
intel_disable_ddi_buf(encoder);
 
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index c3de0918ee13..9e6956c08688 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -180,9 +180,11 @@ static void intel_mst_post_disable_dp(struct intel_encoder 
*encoder,
intel_dp->active_mst_links--;
 
intel_mst->connector = NULL;
-   if (intel_dp->active_mst_links == 0)
+   if (intel_dp->active_mst_links == 0) {
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_dig_port->base.post_disable(_dig_port->base,
  old_crtc_state, NULL);
+   }
 
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
 }
@@ -223,7 +225,11 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
 
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
 
+   if (intel_dp->active_mst_links == 0)
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+
drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
+
if (intel_dp->active_mst_links == 0)
intel_dig_port->base.pre_enable(_dig_port->base,
pipe_config, NULL);
-- 
2.14.3

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

Re: [PATCH v2] drm/i915/dp: Send DPCD ON for MST before phy_up

2018-04-05 Thread Pandiyan, Dhinakaran




On Thu, 2018-04-05 at 16:36 -0400, Lyude Paul wrote:
> When doing a modeset where the sink is transitioning from D3 to D0 , it
> would sometimes be possible for the initial power_up_phy() to start
> timing out. This would only be observed in the last action before the
> sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
> originally thought this might be an issue with us accidentally shutting
> off the aux block when putting the sink into D3, but since the DP spec
> mandates that sinks must wake up within 1ms while we have 100ms to
> respond to an ESI irq, this didn't really add up. Turns out that the
> problem is more subtle then that:
> 
> It turns out that the timeout is from us not enabling DPMS on the MST
> hub before actually trying to initiate sideband communications. This
> would cause the first sideband communication (power_up_phy()), to start
> timing out because the sink wasn't ready to respond. Afterwards, we
> would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in
> intel_ddi_pre_enable_dp(), which would actually result in waking up the
> sink so that sideband requests would work again.
> 
> Since DPMS is what lets us actually bring the hub up into a state where
> sideband communications become functional again, we just need to make
> sure to enable DPMS on the display before attempting to perform sideband
> communications.
> 
> Changes since v1:
> - Remove comment above if (!intel_dp->is_mst) - vsryjala
> - Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to
>   keep enable/disable paths symmetrical
> - Improve commit message - dhnkrn
> 
> Signed-off-by: Lyude Paul 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Cc: Laura Abbott 
> Cc: sta...@vger.kernel.org
> Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST 
> hub.")
> ---
> This email should hopefully actually be picked up by patchwork this
> time, hooray!
> 
>  drivers/gpu/drm/i915/intel_ddi.c| 6 --
>  drivers/gpu/drm/i915/intel_dp_mst.c | 2 ++
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index a6672a9abd85..c0bf7419e1c1 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   intel_prepare_dp_ddi_buffers(encoder, crtc_state);
>  
>   intel_ddi_init_dp_buf_reg(encoder);
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> + if (!intel_dp->is_mst)
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
>   intel_dp_start_link_train(intel_dp);
>   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
>   intel_dp_stop_link_train(intel_dp);
> @@ -2427,7 +2428,8 @@ static void intel_ddi_post_disable_dp(struct 
> intel_encoder *encoder,
>* Power down sink before disabling the port, otherwise we end
>* up getting interrupts from the sink on detecting link loss.
>*/
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> + if (!intel_dp->is_mst)
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>  
>   intel_disable_ddi_buf(encoder);
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index c3de0918ee13..2493bd1e0e59 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -176,6 +176,7 @@ static void intel_mst_post_disable_dp(struct 
> intel_encoder *encoder,
>*/
>   drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port,
>false);
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);

Needed only when _links goes from 1 -> 0
>  
>   intel_dp->active_mst_links--;
>  
> @@ -223,6 +224,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
> *encoder,
>  
>   DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
>  
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
Needed only when _links goes from 0 -> 1
>   drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
>   if (intel_dp->active_mst_links == 0)
>   intel_dig_port->base.pre_enable(_dig_port->base,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/i915/dp: Send DPCD ON for MST before phy_up

2018-04-05 Thread Lyude Paul

Actually - ignore this patch, I'm going to do a v3 because i just noticed
there is something very silly and broken I just introduced into the disable
codepath

On Thu, 2018-04-05 at 16:36 -0400, Lyude Paul wrote:
> When doing a modeset where the sink is transitioning from D3 to D0 , it
> would sometimes be possible for the initial power_up_phy() to start
> timing out. This would only be observed in the last action before the
> sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
> originally thought this might be an issue with us accidentally shutting
> off the aux block when putting the sink into D3, but since the DP spec
> mandates that sinks must wake up within 1ms while we have 100ms to
> respond to an ESI irq, this didn't really add up. Turns out that the
> problem is more subtle then that:
> 
> It turns out that the timeout is from us not enabling DPMS on the MST
> hub before actually trying to initiate sideband communications. This
> would cause the first sideband communication (power_up_phy()), to start
> timing out because the sink wasn't ready to respond. Afterwards, we
> would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in
> intel_ddi_pre_enable_dp(), which would actually result in waking up the
> sink so that sideband requests would work again.
> 
> Since DPMS is what lets us actually bring the hub up into a state where
> sideband communications become functional again, we just need to make
> sure to enable DPMS on the display before attempting to perform sideband
> communications.
> 
> Changes since v1:
> - Remove comment above if (!intel_dp->is_mst) - vsryjala
> - Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to
>   keep enable/disable paths symmetrical
> - Improve commit message - dhnkrn
> 
> Signed-off-by: Lyude Paul 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Cc: Laura Abbott 
> Cc: sta...@vger.kernel.org
> Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST
> hub.")
> ---
> This email should hopefully actually be picked up by patchwork this
> time, hooray!
> 
>  drivers/gpu/drm/i915/intel_ddi.c| 6 --
>  drivers/gpu/drm/i915/intel_dp_mst.c | 2 ++
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index a6672a9abd85..c0bf7419e1c1 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
>   intel_prepare_dp_ddi_buffers(encoder, crtc_state);
>  
>   intel_ddi_init_dp_buf_reg(encoder);
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> + if (!intel_dp->is_mst)
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
>   intel_dp_start_link_train(intel_dp);
>   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
>   intel_dp_stop_link_train(intel_dp);
> @@ -2427,7 +2428,8 @@ static void intel_ddi_post_disable_dp(struct
> intel_encoder *encoder,
>* Power down sink before disabling the port, otherwise we end
>* up getting interrupts from the sink on detecting link loss.
>*/
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> + if (!intel_dp->is_mst)
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>  
>   intel_disable_ddi_buf(encoder);
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index c3de0918ee13..2493bd1e0e59 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -176,6 +176,7 @@ static void intel_mst_post_disable_dp(struct
> intel_encoder *encoder,
>*/
>   drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port,
>false);
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>  
>   intel_dp->active_mst_links--;
>  
> @@ -223,6 +224,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
> *encoder,
>  
>   DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
>  
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
>   drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port,
> true);
>   if (intel_dp->active_mst_links == 0)
>   intel_dig_port->base.pre_enable(_dig_port->base,
-- 
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/7] drm/arc: Stop consulting plane->fb

On Thu, Apr 05, 2018 at 11:19:44PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 05, 2018 at 10:08:57PM +0200, Daniel Vetter wrote:
> > On Thu, Apr 05, 2018 at 10:50:29PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > We want to stop using plane->fb with atomic driver, so stop looking at
> > > it.
> > > 
> > > I have no idea what this code is trying to achieve. There is no
> > > corresponding check in the enable path. Also since
> > > arc_pgu_set_pxl_fmt() will anyway oops if there is no fb I'm going
> > > to assuming that I can just remove the check entirely. There seems
> > > to be a general shortage of .atomic_check() in this driver...
> > 
> > I think arcpgu is the perfect example of a small driver that _really_
> > wants to use drm_simple_display_pipe_helper. Which would address the
> > outright lack of any and all atomic_check code (beyond basic mode
> > validation through mode_valid).
> > 
> > I also just noticed that it still has a bunch of the legacy hooks set,
> > e.g. mode_set, mode_set_base are all no longer used in atomic.
> > 
> > I think the code won't be able to oops, since if there's no fb, we don't
> > enable the plane (and it happily allows that), so should be all
> > non-oopsing. Even with this check here removed.
> 
> arc_pgu_set_pxl_fmt() gets called from the .mode_set_nofb() hook
> which I assume doesn't care about planes at all. So to me it looks like
> it'll definitely oops.

Indeed, I was blind. Commit message looks good.

Reviewed-by: Daniel Vetter 

> 
> > 
> > Ofc the hw might get pissed at us in this case, but I can't tell that.
> > Like I said, conversion to drm_simple_display_pipe_helper is probably the
> > way to go.
> > 
> > Anyway, this patch here looks good, if you adjust the commit message to
> > explain why it can't oops:
> > 
> > Reviewed-by: Daniel Vetter 
> > 
> > > 
> > > Cc: Alexey Brodkin 
> > > Cc: Daniel Vetter 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/arc/arcpgu_crtc.c | 3 ---
> > >  1 file changed, 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
> > > b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > > index 16903dc7fe0d..c3349b8fb58b 100644
> > > --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> > > +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > > @@ -136,9 +136,6 @@ static void arc_pgu_crtc_atomic_disable(struct 
> > > drm_crtc *crtc,
> > >  {
> > >   struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> > >  
> > > - if (!crtc->primary->fb)
> > > - return;
> > > -
> > >   clk_disable_unprepare(arcpgu->clk);
> > >   arc_pgu_write(arcpgu, ARCPGU_REG_CTRL,
> > > arc_pgu_read(arcpgu, ARCPGU_REG_CTRL) &
> > > -- 
> > > 2.16.1
> > > 
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] drm/vmwgfx: Stop messing about with plane->fb/old_fb/crtc

On Thu, Apr 05, 2018 at 10:50:35PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> plane->fb/old_fb/crtc should no longer be used by atomic
> drivers. Stop messing about with them.
> 
> TODO: Squash with the core/helper patch?

Not possible, because the core setconfig one does no longer work with
atomic drivers ever since I've thrown away the magic backoff. Since then
we have the rule that for any atomic driver, you need a real atomic commit
(including passing the acquire_ctx down to that very call to
drm_atomic_commit).

See the patch that introduced this copypasta for full details plus how to
fix it up properly:

commit 3bacf4361cd07f988a13de78d672928606df24ad
Author: Daniel Vetter 
Date:   Thu Apr 6 22:02:56 2017 +0200

drm/vmwgfx: Fix fbdev emulation using legacy functions

I've broken this by removing the backoff handling from the
set_config2atomic helper in

commit 38b6441e4e75c0b319cfe4d9364c1059fc1e3c2b
Author: Daniel Vetter 
Date:   Wed Mar 22 22:50:58 2017 +0100

drm/atomic-helper: Remove the backoff hack from set_config

Fixing this properly would mean we get to wire the acquire_ctx all the
way through vmwgfx fbdev code, and doing the same was tricky for the
shared fbdev layer. Probably much better to look into refactoring the
entire code to use the helpers, but since that's not a viable
long-term solution fix the issue by open-coding a vmwgfx version of
set_config, that does the legacy backoff dance internally.

Note: Just compile-tested. The idea is to take
drm_mode_set_config_internal(), remove the "is this a legacy driver"
check, and whack the drm_atomic_legacy_backoff trickery at the end.
Since drm_atomic_legacy_backoff is for atomic commits only we need to
open-code it.

Cc: Thomas Hellstrom 
Signed-off-by: Daniel Vetter 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Sean Paul 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170406200256.26040-1-daniel.vet...@ffwll.ch

I scrolled through your vmwgfx patches, and will try to look at them maybe
next week. Too complicated for this late, and tomorrow I'm ooo.
-Daniel

> 
> Cc: Thomas Hellstrom 
> Cc: Sinclair Yeh 
> Cc: VMware Graphics 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 24 
>  1 file changed, 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> index 2582ffd36bb5..3c5935f3d49e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> @@ -439,8 +439,6 @@ static int vmw_fb_compute_depth(struct fb_var_screeninfo 
> *var,
>  static int vmwgfx_set_config_internal(struct drm_mode_set *set)
>  {
>   struct drm_crtc *crtc = set->crtc;
> - struct drm_framebuffer *fb;
> - struct drm_crtc *tmp;
>   struct drm_modeset_acquire_ctx *ctx;
>   struct drm_device *dev = set->crtc->dev;
>   int ret;
> @@ -448,29 +446,7 @@ static int vmwgfx_set_config_internal(struct 
> drm_mode_set *set)
>   ctx = dev->mode_config.acquire_ctx;
>  
>  restart:
> - /*
> -  * NOTE: ->set_config can also disable other crtcs (if we steal all
> -  * connectors from it), hence we need to refcount the fbs across all
> -  * crtcs. Atomic modeset will have saner semantics ...
> -  */
> - drm_for_each_crtc(tmp, dev)
> - tmp->primary->old_fb = tmp->primary->fb;
> -
> - fb = set->fb;
> -
>   ret = crtc->funcs->set_config(set, ctx);
> - if (ret == 0) {
> - crtc->primary->crtc = crtc;
> - crtc->primary->fb = fb;
> - }
> -
> - drm_for_each_crtc(tmp, dev) {
> - if (tmp->primary->fb)
> - drm_framebuffer_get(tmp->primary->fb);
> - if (tmp->primary->old_fb)
> - drm_framebuffer_put(tmp->primary->old_fb);
> - tmp->primary->old_fb = NULL;
> - }
>  
>   if (ret == -EDEADLK) {
>   dev->mode_config.acquire_ctx = NULL;
> -- 
> 2.16.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105912] [IGT] gem_exec_reloc@cpu-30 iwlwifi 0000:00:14.3: Scan failed! ret -110 dmesg-warn

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

Chris Wilson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #1 from Chris Wilson  ---
The softlockup is expected, but the novelty here is the iwlwifi error and not
graphics related at all.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v2 21/23] meson: build exynos by default

2018-04-05 Thread Dylan Baker

Quoting Eric Engestrom (2018-04-05 02:48:50)
> On Wednesday, 2018-04-04 14:10:33 -0700, Dylan Baker wrote:
> > For exynos and omap, are they in active use anymore? I'm pretty sure that
> > development of omap (the hardware) stopped, and others have told me exynos 
> > has
> > stopped too. I also don't think there's any open source consumer, since 
> > there is
> > no mesa driver for either of these.
> 
> Happy to drop these enablement patches; I just like to have everything
> possible built by default, but if these are dead I'm fine with leaving
> them disabled by default.
> 

Yeah, I just don't know what the right thing is, it just seems like a bad idea
to enable something by default that never really got anywhere.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 2/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()

> 
> On Thu, Apr 05, 2018 at 08:15:05PM +, Deepak Singh Rawat wrote:
> >
> > >
> > > From: Ville Syrjälä 
> > >
> > > Instead of looking at plane->fb let's look at the proper new
> > > plane state.
> > >
> > > Not that the code makes a ton of sense. It's only going through the
> > > crtcs in the atomic state, so assuming not all of them are included
> > > we're not even calculating the total bandwidth here. Also we're
> > > not considering whether each crtc is actually enabled or not.
> > >
> > > Cc: Thomas Hellstrom 
> > > Cc: Sinclair Yeh 
> > > Cc: VMware Graphics 
> > > Cc: Daniel Vetter 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 +++---
> > >  1 file changed, 7 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > index 6728c6247b4b..a2a796b4cc23 100644
> > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > @@ -1536,9 +1536,13 @@ vmw_kms_atomic_check_modeset(struct
> > > drm_device *dev,
> > >   unsigned long requested_bb_mem = 0;
> > >
> > >   if (dev_priv->active_display_unit ==
> > > vmw_du_screen_target) {
> > > - if (crtc->primary->fb) {
> > > - int cpp = crtc->primary->fb->pitches[0] /
> > > -   crtc->primary->fb->width;
> > > + struct drm_plane *plane = crtc->primary;
> > > + struct drm_plane_state *plane_state;
> > > +
> > > + plane_state =
> > > drm_atomic_get_new_plane_state(state, plane);
> > > +
> > > + if (plane_state && plane_state->fb) {
> > > + int cpp = plane_state->fb->format->cpp[0];
> >
> > Hi Ville,
> >
> > Thanks for the patch, recently I have done some refactoring of this code
> area
> > which is no yet sent to dri-devel. But the refactored code eliminated the
> need
> > to look the fb
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__cgit.freedesktop.org_mesa_vmwgfx_commit_-3Fid-
> 3Dc54cdb6549b7d1c04ff61e639fc0e6de0dcc1ed6=DwIDAw=uilaK90D4T
> OVoH58JNXRgQ=zOOG28inJK0762SxAf-
> cyZdStnd2NQpRu98lJP2iYGw=lrHQqnjNpBdFNzU0f4b3rLTtaYp0VRzCgZztJ
> ew0kz0=mz1Kt2NO_HIpgVtQ9xHvKRQLGXx2HSqY8xt0oiEpGWg=
> 
> Hmm. What's the timelike for landing that stuff?

I am not sure, I still think there is more work here to clean this up. I guess 
for now
we can have your patch to take care of avoiding plane->fb.

> 
> A cursory glance tells me we should just change the current code with
> s/cpp/4/ and it should still be fine?

Yes replacing cpp with 4 is fine as that is what virtual hardware always look 
for.

> 
> BTW the drm_for_each_crtc(crtc, dev) loop in there doesn't look entirely
> kosher. It's potentially going to access crtc->state w/o holding the lock.

Thanks for the suggestion, I will look into this.

> 
> >
> > There is still some future work to be done in this area.
> >
> > >
> > >   requested_bb_mem += crtc->mode.hdisplay
> > > * cpp *
> > >   crtc->mode.vdisplay;
> > > --
> > > 2.16.1
> 
> --
> Ville Syrjälä
> Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM_UDL and GPU under Xserver

2018-04-05 Thread Alexey Brodkin

Hi Daniel, Lucas,

On Thu, 2018-04-05 at 12:59 +0200, Daniel Vetter wrote:
> On Thu, Apr 5, 2018 at 12:29 PM, Lucas Stach  wrote:
> > Am Donnerstag, den 05.04.2018, 11:32 +0200 schrieb Daniel Vetter:
> > > On Thu, Apr 5, 2018 at 9:16 AM, Alexey Brodkin
> > >  wrote:
> > > > Hi Daniel,
> > > > 
> > > > On Thu, 2018-04-05 at 08:18 +0200, Daniel Vetter wrote:
> > > > > On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin
> > > > >  wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > We're trying to use DisplayLink USB2-to-HDMI adapter to render
> > > > > > GPU-accelerated graphics.
> > > > > > Hardware setup is as simple as a devboard + DisplayLink
> > > > > > adapter.
> > > > > > Devboards we use for this experiment are:
> > > > > >  * Wandboard Quad (based on IMX6 SoC with Vivante GPU) or
> > > > > >  * HSDK (based on Synopsys ARC HS38 SoC with Vivante GPU as
> > > > > > well)
> > > > > > 
> > > > > > I'm sure any other board with DRM supported GPU will work,
> > > > > > those we just used
> > > > > > as the very recent Linux kernels could be easily run on them
> > > > > > both.
> > > > > > 
> > > > > > Basically the problem is UDL needs to be explicitly notified
> > > > > > about new data
> > > > > > to be rendered on the screen compared to typical bit-streamers
> > > > > > that infinitely
> > > > > > scan a dedicated buffer in memory.
> > > > > > 
> > > > > > In case of UDL there're just 2 ways for this notification:
> > > > > >  1) DRM_IOCTL_MODE_PAGE_FLIP that calls drm_crtc_funcs-
> > > > > > > page_flip()
> > > > > > 
> > > > > >  2) DRM_IOCTL_MODE_DIRTYFB that calls drm_framebuffer_funcs-
> > > > > > > dirty()
> > > > > > 
> > > > > > But neither of IOCTLs happen when we run Xserver with xf86-
> > > > > > video-armada driver
> > > > > > (see https://urldefense.proofpoint.com/v2/url?u=http-3A__git.ar
> > > > > > m.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh-
> > > > > > 3Dunstable-2Ddevel=DwIBaQ&;
> > > > > > c=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkh
> > > > > > pk5R81I=oEAlP64L9vkuUs_k3kGwwwlN1WJbDMJbCo0uDhwKwwk=3ZHj-
> > > > > > 6JXZBLSTWg_4KMnL0VNi7z8c0RxHzj2U5ywVIw=).
> > > > > > 
> > > > > > Is it something missing in Xserver or in UDL driver?
> > > > > 
> > > > > Use the -modesetting driverr for UDL, that one works correctly.
> > > > 
> > > > If you're talking about "modesetting" driver of Xserver [1] then
> > > > indeed
> > > > picture is displayed on the screen. But there I guess won't be any
> > > > 3D acceleration.
> > > > 
> > > > At least that's what was suggested to me earlier here [2] by Lucas:
> > > > >8---
> > > > For 3D acceleration to work under X you need the etnaviv specific
> > > > DDX
> > > > driver, which can be found here:
> > > > 
> > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.arm.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh-3Dunsta=DwIBaQ=DPL6_X_6Jk
> > > > XFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=FleDFAQb2lBcZk5DMld7qpeSrB5Srsb4XPQecA5BPvU=YUzMQWe3lpC_pjGqRjb4MvRYh16ZBbealqf
> > > > rywlqjKE=
> > > > ble-devel
> > > 
> > > You definitely want to use -modesetting for UDL. And I thought with
> > > glamour and the corresponding mesa work you should also get
> > > accelaration. Insisting that you must use a driver-specific ddx is
> > > broken, the world doesn't work like that anymore.
> > 
> > On etnaviv the world definitely still works like this. The etnaviv DDX
> > uses the dedicated 2D hardware of the Vivante GPUs, which is much
> > faster and efficient than going through Glamor.
> > Especially since almost all X accel operations are done on linear
> > buffers, while the 3D GPU can only ever do tiled on both sampler and
> > render, where some multi-pipe 3D cores can't even read the tiling they
> > write out. So Glamor is an endless copy fest using the resolve engine
> > on those.
> 
> Ah right, I've forgotten about the vivante 2d cores again.
> 
> > If using etnaviv with UDL is a use-case that need to be supported, one
> > would need to port the UDL specifics from -modesetting to the -armada
> > DDX.
> 
> I don't think this makes sense.

I'm not really sure it has something to do with Etnaviv in particular.
Given UDL might be attached to any board with any GPU that would mean we'd
need to add those "UDL specifics from -modesetting" in all xf86-video-drivers,
right?

> > > Lucas, can you pls clarify? Also, why does -armada bind against all
> > > kms drivers, that's probaly too much.
> > 
> > I think that's a local modification done by Alexey. The armada driver
> > only binds to armada and imx-drm by default.

Actually it all magically works without any modifications.
I just start X with the following xorg.conf [1]:
>8--
Section "Device"
Identifier  "Driver0"
Screen  0
Driver  "armada"

[PATCH v6 12/30] drm/bridge: analogix_dp: Reset aux channel if an error occurred

From: Lin Huang 

AUX errors are caused by many different reasons. We may not know what
happened in aux channel on failure, so let's reset aux channel if some
errors occurred.

Cc: 征增 王 
Cc: Douglas Anderson 
Signed-off-by: Lin Huang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index dee1ba109b5f..7b7fd227e1f9 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -466,6 +466,10 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
reg = RPLY_RECEIV | AUX_ERR;
writel(reg, dp->reg_base + ANALOGIX_DP_INT_STA);
 
+   analogix_dp_set_analog_power_down(dp, AUX_BLOCK, true);
+   usleep_range(10, 11);
+   analogix_dp_set_analog_power_down(dp, AUX_BLOCK, false);
+
analogix_dp_reset_aux(dp);
 
/* Disable AUX transaction H/W retry */
@@ -1159,7 +1163,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 reg, !(reg & AUX_EN), 25, 500 * 1000);
if (ret) {
dev_err(dp->dev, "AUX CH enable timeout!\n");
-   return -ETIMEDOUT;
+   goto aux_error;
}
 
/* TODO: Wait for an interrupt instead of looping? */
@@ -1168,7 +1172,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 reg, reg & RPLY_RECEIV, 10, 20 * 1000);
if (ret) {
dev_err(dp->dev, "AUX CH cmd reply timeout!\n");
-   return -ETIMEDOUT;
+   goto aux_error;
}
 
/* Clear interrupt source for AUX CH command reply */
@@ -1178,7 +1182,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
if (reg & AUX_ERR) {
writel(AUX_ERR, dp->reg_base + ANALOGIX_DP_INT_STA);
-   return -EREMOTEIO;
+   goto aux_error;
}
 
/* Check AUX CH error access status */
@@ -1186,7 +1190,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
if ((reg & AUX_STATUS_MASK)) {
dev_err(dp->dev, "AUX CH error happened: %d\n\n",
reg & AUX_STATUS_MASK);
-   return -EREMOTEIO;
+   goto aux_error;
}
 
if (msg->request & DP_AUX_I2C_READ) {
@@ -1212,4 +1216,10 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
msg->reply = DP_AUX_NATIVE_REPLY_ACK;
 
return num_transferred > 0 ? num_transferred : -EBUSY;
+
+aux_error:
+   /* if aux err happen, reset aux */
+   analogix_dp_init_aux(dp);
+
+   return -EREMOTEIO;
 }
-- 
2.16.3

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

[PATCH v6 00/30] DRM Rockchip rk3399 (Kevin)

Hi,

This patchset includes cleanups, improvements, and bug fixes for
Rockchip DRM driver and PSR support.

This new version is the same as before removing some of the patches
already applied and fixing the Exynos issue due patch '[v4 15/38]
drm/bridge: analogix_dp: Ensure edp is disabled when shutting down
the panel' reported by Marek.

Regards,
Enric

Changes in v6:
- Removed the following patches as are already applied.
  [PATCH v5 01/36] drm/bridge: analogix_dp: detect Sink PSR state after
  configuring the PSR
  [PATCH v5 02/36] drm/rockchip: Remove analogix psr worker
  [PATCH v5 03/36] drm/bridge: analogix_dp: Don't change psr while
  bridge is disabled
- Explain in the commit message why we need to increase
  the delay in the timeout loop in
  [PATCH v5 07/36] drm/bridge: analogix_dp: Move enable video into
  config_video()
- Add Reviewed-by: Archit Taneja  for the
  drm/bridge parts
- Add Reviewed-by: Heiko Stuebner  for
  [PATCH v5 19/36] drm/rockchip: Restore psr->state when enable/disable
  psr failed

Changes in v5:
- Removed the following patches as are already applied.
  [PATCH v4 01/38] drm/bridge: analogix_dp: set psr activate/deactivate
  when enable/disable bridge
  [PATCH v4 02/38] drm/rockchip: Don't use atomic constructs for psr
- Add Mareks tested-tag and including the missing people.
- [PATCH v4 15/38] move analogix_dp_set_analog_power_down() before
  phy_power_off() to fix Exynos issue.

Changes in v4:
- Rebased all on top of drm-misc-next
- Removed the following patches as are already applied.
  [PATCH v3 01/43] drm/rockchip: Get rid of unnecessary struct fields
  [PATCH v3 02/43] drm/rockchip: support prime import sg table
  [PATCH v3 03/43] drm/rockchip: Respect page offset for PRIME mmap
  calls
- Removed the following patches as now are part of another patchset
  [PATCH v3 05/43] drm/bridge: analogix_dp: Don't power bridge in
  analogix_dp_bind
  [PATCH v3 33/43] drm/panel: simple: Change mode for Sharp lq123p1jx31

Changes in v3:
- Addressed some of the comments from Sean on the v2

Changes in v2:
- A few patches have been replaced by newer and cleaner versions from
  the ChromeOS kernel gerrit, especially about disallowing PSR for the
  whole atomic commit.


Douglas Anderson (4):
  drm/bridge: analogix_dp: Reorder plat_data->power_off to happen sooner
  drm/bridge: analogix_dp: Properly log AUX CH errors
  drm/bridge: analogix_dp: Properly disable aux chan retries on rockchip
  drm/bridge: analogix_dp: Split the platform-specific poweron in two
parts

Kristian H. Kristensen (1):
  drm/rockchip: Disable PSR on input events

Lin Huang (6):
  drm/bridge: analogix_dp: Move enable video into config_video()
  drm/bridge: analogix_dp: Check AUX_EN status when doing AUX transfer
  drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the
panel
  drm/bridge: analogix_dp: Extend hpd check time to 100ms
  drm/bridge: analogix_dp: Check dpcd write/read status
  drm/bridge: analogix_dp: Reset aux channel if an error occurred

Mark Yao (1):
  drm/rockchip: pre dither down when output bpc is 8bit

Tomasz Figa (7):
  drm/rockchip: analogix_dp: Do not call Analogix code before bind
  drm/rockchip: Cancel PSR enable work before changing the state
  drm/rockchip: psr: Avoid redundant calls to .set() callback
  drm/rockchip: psr: Sanitize semantics of allow/disallow API
  drm/rockchip: Disable PSR from reboot notifier
  drm/rockchip: Disallow PSR for the whole atomic commit
  drm/rockchip: psr: Remove flush by CRTC

zain wang (11):
  drm/bridge: analogix_dp: Don't use fast link training when panel just
powered up
  drm/bridge: analogix_dp: Retry bridge enable when it failed
  drm/bridge: analogix_dp: Wait for HPD signal before configuring link
  drm/bridge: analogix_dp: Set PD_INC_BG first when powering up edp phy
  drm/bridge: analogix_dp: Fix incorrect usage of enhanced mode
  drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip
  drm/rockchip: Restore psr->state when enable/disable psr failed
  drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll
  drm/bridge: analogix_dp: Fix timeout of video streamclk config
  drm/bridge: analogix_dp: Fix incorrect operations with register
ANALOGIX_DP_FUNC_EN_1
  drm/bridge: analogix_dp: Move fast link training detect to set_bridge

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 331 +++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   5 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 236 +--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  |   7 +
 drivers/gpu/drm/exynos/exynos_dp.c |   2 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  37 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  61 +++-
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c| 309 +--
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h

[PATCH v6 26/30] drm/rockchip: psr: Avoid redundant calls to .set() callback

From: Tomasz Figa 

The first time after we call rockchip_drm_do_flush() after
rockchip_drm_psr_register(), we go from PSR_DISABLE to PSR_FLUSH. The
difference between PSR_DISABLE and PSR_FLUSH is whether or not we have a
delayed work pending - PSR is off in either state.  However
psr_set_state() only catches the transition from PSR_FLUSH to
PSR_DISABLE (which never happens), while going from PSR_DISABLE to
PSR_FLUSH triggers a call to psr->set() to disable PSR while it's
already disabled. This triggers the eDP PHY power-on sequence without
being shut down first and this seems to occasionally leave the encoder
unable to later enable PSR. Let's just simplify the state machine and
simply consider PSR_DISABLE and PSR_FLUSH the same state. This lets us
represent the hardware state by a simple boolean called "enabled" and,
while at it, rename the misleading "active" boolean to "inhibit", which
represents the purpose much better.

Also, userspace can (and does) trigger the rockchip_drm_do_flush() path
from drmModeDirtyFB() at any time, whether or the encoder is active. If
no mode is set, we call into analogix_dp_psr_set() which returns -EINVAL
because encoder->crtc is NULL. Avoid this by starting out with
psr->allowed set to false.

Signed-off-by: Kristian H. Kristensen 
Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 79 +
 1 file changed, 23 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index c8655e625ba2..448c5fde241c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -22,19 +22,13 @@
 
 #define PSR_FLUSH_TIMEOUT_MS   100
 
-enum psr_state {
-   PSR_FLUSH,
-   PSR_ENABLE,
-   PSR_DISABLE,
-};
-
 struct psr_drv {
struct list_headlist;
struct drm_encoder  *encoder;
 
struct mutexlock;
boolactive;
-   enum psr_state  state;
+   boolenabled;
 
struct delayed_work flush_work;
struct work_struct  disable_work;
@@ -78,52 +72,22 @@ static struct psr_drv *find_psr_by_encoder(struct 
drm_encoder *encoder)
return psr;
 }
 
-static void psr_set_state_locked(struct psr_drv *psr, enum psr_state state)
+static int psr_set_state_locked(struct psr_drv *psr, bool enable)
 {
-   /*
-* Allowed finite state machine:
-*
-*   PSR_ENABLE  < = = = = = >  PSR_FLUSH
-*   | ^|
-*   | ||
-*   v ||
-*   PSR_DISABLE < - - - - - - - - -
-*/
-   if (state == psr->state || !psr->active)
-   return;
-
-   /* Already disabled in flush, change the state, but not the hardware */
-   if (state == PSR_DISABLE && psr->state == PSR_FLUSH) {
-   psr->state = state;
-   return;
-   }
+   int ret;
 
-   /* Actually commit the state change to hardware */
-   switch (state) {
-   case PSR_ENABLE:
-   if (psr->set(psr->encoder, true))
-   return;
-   break;
-
-   case PSR_DISABLE:
-   case PSR_FLUSH:
-   if (psr->set(psr->encoder, false))
-   return;
-   break;
-
-   default:
-   pr_err("%s: Unknown state %d\n", __func__, state);
-   return;
-   }
+   if (!psr->active)
+   return -EINVAL;
 
-   psr->state = state;
-}
+   if (enable == psr->enabled)
+   return 0;
 
-static void psr_set_state(struct psr_drv *psr, enum psr_state state)
-{
-   mutex_lock(>lock);
-   psr_set_state_locked(psr, state);
-   mutex_unlock(>lock);
+   ret = psr->set(psr->encoder, enable);
+   if (ret)
+   return ret;
+
+   psr->enabled = enable;
+   return 0;
 }
 
 static void psr_flush_handler(struct work_struct *work)
@@ -131,10 +95,8 @@ static void psr_flush_handler(struct work_struct *work)
struct psr_drv *psr = container_of(to_delayed_work(work),
   struct psr_drv, flush_work);
 
-   /* If the state has changed since we initiated the flush, do nothing */
mutex_lock(>lock);
-   if (psr->state == PSR_FLUSH)
-   psr_set_state_locked(psr, PSR_ENABLE);
+   psr_set_state_locked(psr, true);
mutex_unlock(>lock);
 }
 
@@ -176,6 +138,7 @@ int rockchip_drm_psr_deactivate(struct drm_encoder *encoder)
 
mutex_lock(>lock);
psr->active = false;
+   psr->enabled =

[PATCH v6 29/30] drm/rockchip: Disallow PSR for the whole atomic commit

From: Tomasz Figa 

Currently PSR flush is triggered from CRTC's .atomic_begin() callback,
which is executed after modeset disables and enables and before plane
updates are committed. Since PSR flush and re-enable can be triggered
asynchronously by external sources (input event, delayed work), it can
race with hardware programming done in the aforementioned stages.

This patch blocks the PSR completely before hardware programming part
begins and unblock after it ends. This relies on reference counted PSR
disable introduced with previous patch.

Cc: Kristian H. Kristensen 
Signed-off-by: Tomasz Figa 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 61 -
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  7 
 2 files changed, 60 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index e266539e04e5..d4f4118b482d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -167,8 +167,67 @@ rockchip_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
return ERR_PTR(ret);
 }
 
+static void
+rockchip_drm_psr_inhibit_get_state(struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   struct drm_encoder *encoder;
+   u32 encoder_mask = 0;
+   int i;
+
+   for_each_old_crtc_in_state(state, crtc, crtc_state, i) {
+   encoder_mask |= crtc_state->encoder_mask;
+   encoder_mask |= crtc->state->encoder_mask;
+   }
+
+   drm_for_each_encoder_mask(encoder, state->dev, encoder_mask)
+   rockchip_drm_psr_inhibit_get(encoder);
+}
+
+static void
+rockchip_drm_psr_inhibit_put_state(struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   struct drm_encoder *encoder;
+   u32 encoder_mask = 0;
+   int i;
+
+   for_each_old_crtc_in_state(state, crtc, crtc_state, i) {
+   encoder_mask |= crtc_state->encoder_mask;
+   encoder_mask |= crtc->state->encoder_mask;
+   }
+
+   drm_for_each_encoder_mask(encoder, state->dev, encoder_mask)
+   rockchip_drm_psr_inhibit_put(encoder);
+}
+
+static void
+rockchip_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state)
+{
+   struct drm_device *dev = old_state->dev;
+
+   rockchip_drm_psr_inhibit_get_state(old_state);
+
+   drm_atomic_helper_commit_modeset_disables(dev, old_state);
+
+   drm_atomic_helper_commit_modeset_enables(dev, old_state);
+
+   drm_atomic_helper_commit_planes(dev, old_state,
+   DRM_PLANE_COMMIT_ACTIVE_ONLY);
+
+   rockchip_drm_psr_inhibit_put_state(old_state);
+
+   drm_atomic_helper_commit_hw_done(old_state);
+
+   drm_atomic_helper_wait_for_vblanks(dev, old_state);
+
+   drm_atomic_helper_cleanup_planes(dev, old_state);
+}
+
 static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers 
= {
-   .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+   .atomic_commit_tail = rockchip_atomic_helper_commit_tail_rpm,
 };
 
 static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 00f7f3441cf6..f14a10ca4792 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1029,16 +1029,9 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
}
 }
 
-static void vop_crtc_atomic_begin(struct drm_crtc *crtc,
- struct drm_crtc_state *old_crtc_state)
-{
-   rockchip_drm_psr_flush(crtc);
-}
-
 static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
.mode_fixup = vop_crtc_mode_fixup,
.atomic_flush = vop_crtc_atomic_flush,
-   .atomic_begin = vop_crtc_atomic_begin,
.atomic_enable = vop_crtc_atomic_enable,
.atomic_disable = vop_crtc_atomic_disable,
 };
-- 
2.16.3

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

[PATCH v6 21/30] drm/rockchip: pre dither down when output bpc is 8bit

From: Mark Yao 

Some encoder have a crc verification check, crc check fail if
input and output data is not equal.

That means encoder input and output need use same color depth,
vop can output 10bit data to encoder, but some panel only support
8bit depth, that would make crc check die.

So pre dither down vop data to 8bit if panel's bpc is 8.

Signed-off-by: Mark Yao 
[seanpaul resolved conflict in rockchip_drm_vop.c]
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 2 ++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
 5 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8c884f9ce713..b3f46ed24cdc 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -218,6 +218,7 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder 
*encoder,
  struct drm_connector_state *conn_state)
 {
struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
+   struct drm_display_info *di = _state->connector->display_info;
 
/*
 * The hardware IC designed that VOP must output the RGB10 video
@@ -229,6 +230,7 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder 
*encoder,
 
s->output_mode = ROCKCHIP_OUT_MODE_;
s->output_type = DRM_MODE_CONNECTOR_eDP;
+   s->output_bpc = di->bpc;
 
return 0;
 }
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 9c064a40458b..3a6ebfc26036 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -36,6 +36,7 @@ struct rockchip_crtc_state {
struct drm_crtc_state base;
int output_type;
int output_mode;
+   int output_bpc;
 };
 #define to_rockchip_crtc_state(s) \
container_of(s, struct rockchip_crtc_state, base)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 53d4afe15278..00f7f3441cf6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -925,6 +925,12 @@ static void vop_crtc_atomic_enable(struct drm_crtc *crtc,
if (s->output_mode == ROCKCHIP_OUT_MODE_ &&
!(vop_data->feature & VOP_FEATURE_OUTPUT_RGB10))
s->output_mode = ROCKCHIP_OUT_MODE_P888;
+
+   if (s->output_mode == ROCKCHIP_OUT_MODE_ && s->output_bpc == 8)
+   VOP_REG_SET(vop, common, pre_dither_down, 1);
+   else
+   VOP_REG_SET(vop, common, pre_dither_down, 0);
+
VOP_REG_SET(vop, common, out_mode, s->output_mode);
 
VOP_REG_SET(vop, modeset, htotal_pw, (htotal << 16) | hsync_len);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 56bbd2e2a8ef..084acdd0019a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -67,6 +67,7 @@ struct vop_common {
struct vop_reg cfg_done;
struct vop_reg dsp_blank;
struct vop_reg data_blank;
+   struct vop_reg pre_dither_down;
struct vop_reg dither_down;
struct vop_reg dither_up;
struct vop_reg gate_en;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 2e4eea3459fe..08023d3ecb76 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -264,6 +264,7 @@ static const struct vop_common rk3288_common = {
.standby = VOP_REG_SYNC(RK3288_SYS_CTRL, 0x1, 22),
.gate_en = VOP_REG(RK3288_SYS_CTRL, 0x1, 23),
.mmu_en = VOP_REG(RK3288_SYS_CTRL, 0x1, 20),
+   .pre_dither_down = VOP_REG(RK3288_DSP_CTRL1, 0x1, 1),
.dither_down = VOP_REG(RK3288_DSP_CTRL1, 0xf, 1),
.dither_up = VOP_REG(RK3288_DSP_CTRL1, 0x1, 6),
.data_blank = VOP_REG(RK3288_DSP_CTRL0, 0x1, 19),
-- 
2.16.3

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

GPU/DRM issue with DSI commands on msm 8916

2018-04-05 Thread Daniel Mack

Hi,

I'm having issues with the GPU/DRM drivers on a msm8916 based platform
which is very similar to the DragonBoard 410c. In my setup, a DSI
display is directly connected to the SoC, and the video link is stable.

However, when the host sends DCS commands down to the DSI panel (for
instance to set the backlight brightness), the image drops out, most of
the time only in terms of a short flicker, but sometimes it will
completely kill the image. In the latter case, only restarting the
Wayland compositor in userspace helps. This is also quite reproducible;
sending a NOP command once a second would give a visual flicker in 90%
of the cases, and it needs at most a minute to make the screen turn black.

The interesting thing is that this used to work in a v4.9 based version,
but it broke somewhere on the way to v4.14. Unfortunately, the platform
does not boot a vanilla kernel, so I can't really bisect this. We
currently depend on the Linaro downstream patches which can be found here:

http://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=release/qcomlt-4.9

http://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=release/qcomlt-4.14

I've looked at the development that has happened in the area for some
time now, but I can't really pin-point any specific commit. Also, I
cherry-picked most of the patches to these drivers that came in after
v4.14, but that didn't help either.

Has this has been observed before? A pointer what to investigate on
would be very much appreciated. If there is any more information I can
provide, please let me know.

Thanks,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 13/30] drm/rockchip: Restore psr->state when enable/disable psr failed

From: zain wang 

If we failed disable psr, it would hang the display until next psr
cycle coming. So we should restore psr->state when it failed.

Cc: Tomasz Figa 
Signed-off-by: zain wang 
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Heiko Stuebner 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  4 +++-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 10 +-
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c| 20 +---
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h|  2 +-
 4 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 75e61ebf6722..5540e2dfc2ec 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -153,8 +153,10 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
psr_vsc.DB1 = 0;
 
ret = drm_dp_dpcd_writeb(>aux, DP_SET_POWER, DP_SET_POWER_D0);
-   if (ret != 1)
+   if (ret != 1) {
dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
+   return ret;
+   }
 
return analogix_dp_send_psr_spd(dp, _vsc, false);
 }
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 3e8bf79bea58..8c884f9ce713 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -77,13 +77,13 @@ struct rockchip_dp_device {
struct analogix_dp_plat_data plat_data;
 };
 
-static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
+static int analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
 {
struct rockchip_dp_device *dp = to_dp(encoder);
int ret;
 
if (!analogix_dp_psr_enabled(dp->adp))
-   return;
+   return 0;
 
DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
 
@@ -91,13 +91,13 @@ static void analogix_dp_psr_set(struct drm_encoder 
*encoder, bool enabled)
 PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
if (ret) {
DRM_DEV_ERROR(dp->dev, "line flag interrupt did not arrive\n");
-   return;
+   return -ETIMEDOUT;
}
 
if (enabled)
-   analogix_dp_enable_psr(dp->adp);
+   return analogix_dp_enable_psr(dp->adp);
else
-   analogix_dp_disable_psr(dp->adp);
+   return analogix_dp_disable_psr(dp->adp);
 }
 
 static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index b339ca943139..9376f4396b6b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -36,7 +36,7 @@ struct psr_drv {
 
struct delayed_work flush_work;
 
-   void (*set)(struct drm_encoder *encoder, bool enable);
+   int (*set)(struct drm_encoder *encoder, bool enable);
 };
 
 static struct psr_drv *find_psr_by_crtc(struct drm_crtc *crtc)
@@ -93,19 +93,25 @@ static void psr_set_state_locked(struct psr_drv *psr, enum 
psr_state state)
return;
}
 
-   psr->state = state;
-
/* Actually commit the state change to hardware */
-   switch (psr->state) {
+   switch (state) {
case PSR_ENABLE:
-   psr->set(psr->encoder, true);
+   if (psr->set(psr->encoder, true))
+   return;
break;
 
case PSR_DISABLE:
case PSR_FLUSH:
-   psr->set(psr->encoder, false);
+   if (psr->set(psr->encoder, false))
+   return;
break;
+
+   default:
+   pr_err("%s: Unknown state %d\n", __func__, state);
+   return;
}
+
+   psr->state = state;
 }
 
 static void psr_set_state(struct psr_drv *psr, enum psr_state state)
@@ -229,7 +235,7 @@ EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
  * Zero on success, negative errno on failure.
  */
 int rockchip_drm_psr_register(struct drm_encoder *encoder,
-   void (*psr_set)(struct drm_encoder *, bool enable))
+   int (*psr_set)(struct drm_encoder *, bool enable))
 {
struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
struct psr_drv *psr;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h

[PATCH v6 23/30] drm/rockchip: analogix_dp: Do not call Analogix code before bind

From: Tomasz Figa 

Driver callbacks, such as system suspend or resume can be called any
time, specifically they can be called before the component bind
callback. Let's use dp->adp pointer as a safeguard and skip calling
Analogix entry points if it is an ERR_PTR().

Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 23317a2269e1..6d45d62466b3 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -368,6 +368,8 @@ static void rockchip_dp_unbind(struct device *dev, struct 
device *master,
analogix_dp_unbind(dp->adp);
rockchip_drm_psr_unregister(>encoder);
dp->encoder.funcs->destroy(>encoder);
+
+   dp->adp = ERR_PTR(-ENODEV);
 }
 
 static const struct component_ops rockchip_dp_component_ops = {
@@ -391,6 +393,7 @@ static int rockchip_dp_probe(struct platform_device *pdev)
return -ENOMEM;
 
dp->dev = dev;
+   dp->adp = ERR_PTR(-ENODEV);
dp->plat_data.panel = panel;
 
ret = rockchip_dp_of_probe(dp);
@@ -414,6 +417,9 @@ static int rockchip_dp_suspend(struct device *dev)
 {
struct rockchip_dp_device *dp = dev_get_drvdata(dev);
 
+   if (IS_ERR(dp->adp))
+   return 0;
+
return analogix_dp_suspend(dp->adp);
 }
 
@@ -421,6 +427,9 @@ static int rockchip_dp_resume(struct device *dev)
 {
struct rockchip_dp_device *dp = dev_get_drvdata(dev);
 
+   if (IS_ERR(dp->adp))
+   return 0;
+
return analogix_dp_resume(dp->adp);
 }
 #endif
-- 
2.16.3

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

[PATCH 1/2] drm/msm: remove unbalanced mutex unlock

2018-04-05 Thread Daniel Mack

This regression stems from 0e08270a1f01 ("drm/msm: Separate locking of
buffer resources from struct_mutex").

Signed-off-by: Daniel Mack 
Cc: Sushmita Susheelendra 
Cc: Rob Clark 
Fixes: 0e08270a1f01 ("drm/msm: Separate locking of buffer resources from 
struct_mutex")
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 0f7324a686ca..27637d8a99ff 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -994,7 +994,6 @@ static int dsi_tx_buf_alloc(struct msm_dsi_host *msm_host, 
int size)
 
ret = msm_gem_get_iova(msm_host->tx_gem_obj,
priv->kms->aspace, );
-   mutex_unlock(>struct_mutex);
if (ret) {
pr_err("%s: failed to get iova, %d\n", __func__, ret);
return ret;
-- 
2.14.3

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

[PATCH v6 18/30] drm/bridge: analogix_dp: Reorder plat_data->power_off to happen sooner

From: Douglas Anderson 

The current user of the analogix power_off is "analogix_dp-rockchip".
That driver does this:
- deactivate PSR
- turn off a clock

Both of these things (especially deactive PSR) should be done before
we turn the PHY power off and turn off analog power.  Let's move the
callback up.

Note that without this patch (and with
https://patchwork.kernel.org/patch/9553349/ [seanpaul: this patch was
not applied, but it seems like the race can still occur]), I experienced
an error in reboot testing where one thread was at:

  rockchip_drm_psr_deactivate
  rockchip_dp_powerdown
  analogix_dp_bridge_disable
  drm_bridge_disable

...and the other thread was at:

  analogix_dp_send_psr_spd
  analogix_dp_enable_psr
  analogix_dp_psr_set
  psr_flush_handler

The flush handler thread was finding AUX channel errors and eventually
reported "Failed to apply PSR", where I had a kgdb breakpoint. Presumably
the device would have eventually given up and shut down anyway, but it
seems better to fix the order to be more correct.

Cc: Kristian H. Kristensen 
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 69b2c16e5776..a260de4f0bd8 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1337,12 +1337,13 @@ static void analogix_dp_bridge_disable(struct 
drm_bridge *bridge)
}
 
disable_irq(dp->irq);
-   analogix_dp_set_analog_power_down(dp, POWER_ALL, 1);
-   phy_power_off(dp->phy);
 
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
 
+   analogix_dp_set_analog_power_down(dp, POWER_ALL, 1);
+   phy_power_off(dp->phy);
+
clk_disable_unprepare(dp->clock);
 
pm_runtime_put_sync(dp->dev);
-- 
2.16.3

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

Re: DRM_UDL and GPU under Xserver

2018-04-05 Thread Alexey Brodkin

Hi Daniel, all,

On Thu, 2018-04-05 at 15:44 +0200, Daniel Vetter wrote:
> On Thu, Apr 05, 2018 at 11:10:03AM +, Alexey Brodkin wrote:
> > Hi Daniel, Lucas,
> > 
> > On Thu, 2018-04-05 at 12:59 +0200, Daniel Vetter wrote:
> > > On Thu, Apr 5, 2018 at 12:29 PM, Lucas Stach  
> > > wrote:
> > > > Am Donnerstag, den 05.04.2018, 11:32 +0200 schrieb Daniel Vetter:
> > > > > On Thu, Apr 5, 2018 at 9:16 AM, Alexey Brodkin
> > > > >  wrote:
> > > > > > Hi Daniel,
> > > > > > 
> > > > > > On Thu, 2018-04-05 at 08:18 +0200, Daniel Vetter wrote:
> > > > > > > On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin
> > > > > > >  wrote:
> > > > > > > > Hello,
> > > > > > > > 
> > > > > > > > We're trying to use DisplayLink USB2-to-HDMI adapter to render
> > > > > > > > GPU-accelerated graphics.
> > > > > > > > Hardware setup is as simple as a devboard + DisplayLink
> > > > > > > > adapter.
> > > > > > > > Devboards we use for this experiment are:
> > > > > > > >  * Wandboard Quad (based on IMX6 SoC with Vivante GPU) or
> > > > > > > >  * HSDK (based on Synopsys ARC HS38 SoC with Vivante GPU as
> > > > > > > > well)
> > > > > > > > 
> > > > > > > > I'm sure any other board with DRM supported GPU will work,
> > > > > > > > those we just used
> > > > > > > > as the very recent Linux kernels could be easily run on them
> > > > > > > > both.
> > > > > > > > 
> > > > > > > > Basically the problem is UDL needs to be explicitly notified
> > > > > > > > about new data
> > > > > > > > to be rendered on the screen compared to typical bit-streamers
> > > > > > > > that infinitely
> > > > > > > > scan a dedicated buffer in memory.
> > > > > > > > 
> > > > > > > > In case of UDL there're just 2 ways for this notification:
> > > > > > > >  1) DRM_IOCTL_MODE_PAGE_FLIP that calls drm_crtc_funcs-
> > > > > > > > > page_flip()
> > > > > > > > 
> > > > > > > >  2) DRM_IOCTL_MODE_DIRTYFB that calls drm_framebuffer_funcs-
> > > > > > > > > dirty()
> > > > > > > > 
> > > > > > > > But neither of IOCTLs happen when we run Xserver with xf86-
> > > > > > > > video-armada driver
> > > > > > > > (see https://urldefense.proofpoint.com/v2/url?u=http-3A__git.ar
> > > > > > > > m.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh-
> > > > > > > > 3Dunstable-2Ddevel=DwIBaQ&;
> > > > > > > > c=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkh
> > > > > > > > pk5R81I=oEAlP64L9vkuUs_k3kGwwwlN1WJbDMJbCo0uDhwKwwk=3ZHj-
> > > > > > > > 6JXZBLSTWg_4KMnL0VNi7z8c0RxHzj2U5ywVIw=).
> > > > > > > > 
> > > > > > > > Is it something missing in Xserver or in UDL driver?
> > > > > > > 
> > > > > > > Use the -modesetting driverr for UDL, that one works correctly.
> > > > > > 
> > > > > > If you're talking about "modesetting" driver of Xserver [1] then
> > > > > > indeed
> > > > > > picture is displayed on the screen. But there I guess won't be any
> > > > > > 3D acceleration.
> > > > > > 
> > > > > > At least that's what was suggested to me earlier here [2] by Lucas:
> > > > > > >8---
> > > > > > For 3D acceleration to work under X you need the etnaviv specific
> > > > > > DDX
> > > > > > driver, which can be found here:
> > > > > > 
> > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.arm.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh-3Dunsta=DwIBaQ=DPL6_X
> > > > > > _6Jk
> > > > > > XFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=FleDFAQb2lBcZk5DMld7qpeSrB5Srsb4XPQecA5BPvU=YUzMQWe3lpC_pjGqRjb4MvRYh16ZBbe
> > > > > > alqf
> > > > > > rywlqjKE=
> > > > > > ble-devel
> > > > > 
> > > > > You definitely want to use -modesetting for UDL. And I thought with
> > > > > glamour and the corresponding mesa work you should also get
> > > > > accelaration. Insisting that you must use a driver-specific ddx is
> > > > > broken, the world doesn't work like that anymore.
> > > > 
> > > > On etnaviv the world definitely still works like this. The etnaviv DDX
> > > > uses the dedicated 2D hardware of the Vivante GPUs, which is much
> > > > faster and efficient than going through Glamor.
> > > > Especially since almost all X accel operations are done on linear
> > > > buffers, while the 3D GPU can only ever do tiled on both sampler and
> > > > render, where some multi-pipe 3D cores can't even read the tiling they
> > > > write out. So Glamor is an endless copy fest using the resolve engine
> > > > on those.
> > > 
> > > Ah right, I've forgotten about the vivante 2d cores again.
> > > 
> > > > If using etnaviv with UDL is a use-case that need to be supported, one
> > > > would need to port the UDL specifics from -modesetting to the -armada
> > > > DDX.
> > > 
> > > I don't think this makes sense.
> > 
> > I'm not really sure it has something to do with Etnaviv in particular.
> > Given UDL might be attached to any board with any GPU that would mean we'd
> > need to add those "UDL specifics from -modesetting" in all

[PATCH v2 15/19] omap2: omapfb: allow building it with COMPILE_TEST

This driver builds cleanly with COMPILE_TEST, and it is
needed in order to allow building drivers/media omap2
driver.

So, change the logic there to allow building it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/video/fbdev/omap2/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/Kconfig 
b/drivers/video/fbdev/omap2/Kconfig
index 0921c4de8407..82008699d253 100644
--- a/drivers/video/fbdev/omap2/Kconfig
+++ b/drivers/video/fbdev/omap2/Kconfig
@@ -1,4 +1,4 @@
-if ARCH_OMAP2PLUS
+if ARCH_OMAP2PLUS || COMPILE_TEST
 
 source "drivers/video/fbdev/omap2/omapfb/Kconfig"
 
-- 
2.14.3

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

[PATCH v6 20/30] drm/bridge: analogix_dp: Properly disable aux chan retries on rockchip

From: Douglas Anderson 

The comments in analogix_dp_init_aux() claim that we're disabling aux
channel retries, but then right below it for Rockchip it sets them to
3.  If we actually need 3 retries for Rockchip then we could adjust
the comment, but it seems more likely that we want the same retry
behavior across all platforms.

Cc: Stéphane Marchesin 
Cc: 征增 王 
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 58e8a28e99aa..a5f2763d72e4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -481,15 +481,16 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
 
analogix_dp_reset_aux(dp);
 
-   /* Disable AUX transaction H/W retry */
+   /* AUX_BIT_PERIOD_EXPECTED_DELAY doesn't apply to Rockchip IP */
if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
-   reg = AUX_BIT_PERIOD_EXPECTED_DELAY(0) |
- AUX_HW_RETRY_COUNT_SEL(3) |
- AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
+   reg = 0;
else
-   reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3) |
- AUX_HW_RETRY_COUNT_SEL(0) |
- AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
+   reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3);
+
+   /* Disable AUX transaction H/W retry */
+   reg |= AUX_HW_RETRY_COUNT_SEL(0) |
+  AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
+
writel(reg, dp->reg_base + ANALOGIX_DP_AUX_HW_RETRY_CTL);
 
/* Receive AUX Channel DEFER commands equal to DEFFER_COUNT*64 */
-- 
2.16.3

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

Re: [PATCH] drm/omap: fix crash if there's no video PLL

2018-04-05 Thread Keerthy



On Thursday 05 April 2018 12:25 PM, Tomi Valkeinen wrote:
> Commit 8a7eda7686675b73d74c22c0d5b83059f9d783f6 ("drm: omapdrm: dispc:
> Pass DISPC pointer to remaining dispc API functions") made dpi.c use
> ctx->pll even when there's no PLL, causing a crash at modeset on AM4
> EVM, and presumably all OMAP2/3 boards.
> 
> Fix this by having struct dpi_data pointer in the ctx instead, giving
> access to dispc without going through the pll.

Tested for display coming up on boot which was earlier broken on
am437x-gp-evm.

Tested-by: Keerthy 

> 
> Signed-off-by: Tomi Valkeinen 
> Reported-by: Keerthy 
> Cc: Laurent Pinchart 
> ---
>  drivers/gpu/drm/omapdrm/dss/dpi.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
> b/drivers/gpu/drm/omapdrm/dss/dpi.c
> index fb1c27f69e3a..3d662e6805eb 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> @@ -142,7 +142,7 @@ static enum dss_clk_source dpi_get_clk_src(struct 
> dpi_data *dpi)
>  }
>  
>  struct dpi_clk_calc_ctx {
> - struct dss_pll *pll;
> + struct dpi_data *dpi;
>   unsigned int clkout_idx;
>  
>   /* inputs */
> @@ -191,7 +191,7 @@ static bool dpi_calc_hsdiv_cb(int m_dispc, unsigned long 
> dispc,
>   ctx->pll_cinfo.mX[ctx->clkout_idx] = m_dispc;
>   ctx->pll_cinfo.clkout[ctx->clkout_idx] = dispc;
>  
> - return dispc_div_calc(ctx->pll->dss->dispc, dispc,
> + return dispc_div_calc(ctx->dpi->dss->dispc, dispc,
> ctx->pck_min, ctx->pck_max,
> dpi_calc_dispc_cb, ctx);
>  }
> @@ -208,8 +208,8 @@ static bool dpi_calc_pll_cb(int n, int m, unsigned long 
> fint,
>   ctx->pll_cinfo.fint = fint;
>   ctx->pll_cinfo.clkdco = clkdco;
>  
> - return dss_pll_hsdiv_calc_a(ctx->pll, clkdco,
> - ctx->pck_min, dss_get_max_fck_rate(ctx->pll->dss),
> + return dss_pll_hsdiv_calc_a(ctx->dpi->pll, clkdco,
> + ctx->pck_min, dss_get_max_fck_rate(ctx->dpi->dss),
>   dpi_calc_hsdiv_cb, ctx);
>  }
>  
> @@ -219,7 +219,7 @@ static bool dpi_calc_dss_cb(unsigned long fck, void *data)
>  
>   ctx->fck = fck;
>  
> - return dispc_div_calc(ctx->pll->dss->dispc, fck,
> + return dispc_div_calc(ctx->dpi->dss->dispc, fck,
> ctx->pck_min, ctx->pck_max,
> dpi_calc_dispc_cb, ctx);
>  }
> @@ -230,7 +230,7 @@ static bool dpi_pll_clk_calc(struct dpi_data *dpi, 
> unsigned long pck,
>   unsigned long clkin;
>  
>   memset(ctx, 0, sizeof(*ctx));
> - ctx->pll = dpi->pll;
> + ctx->dpi = dpi;
>   ctx->clkout_idx = dss_pll_get_clkout_idx_for_src(dpi->clk_src);
>  
>   clkin = clk_get_rate(dpi->pll->clkin);
> @@ -244,7 +244,7 @@ static bool dpi_pll_clk_calc(struct dpi_data *dpi, 
> unsigned long pck,
>   pll_min = 0;
>   pll_max = 0;
>  
> - return dss_pll_calc_a(ctx->pll, clkin,
> + return dss_pll_calc_a(ctx->dpi->pll, clkin,
>   pll_min, pll_max,
>   dpi_calc_pll_cb, ctx);
>   } else { /* DSS_PLL_TYPE_B */
> @@ -275,6 +275,7 @@ static bool dpi_dss_clk_calc(struct dpi_data *dpi, 
> unsigned long pck,
>   bool ok;
>  
>   memset(ctx, 0, sizeof(*ctx));
> + ctx->dpi = dpi;
>   if (pck > 1000 * i * i * i)
>   ctx->pck_min = max(pck - 1000 * i * i * i, 0lu);
>   else
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 14/30] drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll

From: zain wang 

There is no register named ANALOGIX_DP_PLL_CTL in Rockchip edp phy reg
list.  We should use BIT_4 in ANALOGIX_DP_PD to control the pll power
instead of ANALOGIX_DP_PLL_CTL.

Cc: Douglas Anderson 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 7b7fd227e1f9..02ab1aaa9993 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -230,16 +230,20 @@ enum pll_status analogix_dp_get_pll_lock_status(struct 
analogix_dp_device *dp)
 void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool enable)
 {
u32 reg;
+   u32 mask = DP_PLL_PD;
+   u32 pd_addr = ANALOGIX_DP_PLL_CTL;
 
-   if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
-   reg |= DP_PLL_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
-   } else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
-   reg &= ~DP_PLL_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
+   if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+   pd_addr = ANALOGIX_DP_PD;
+   mask = RK_PLL_PD;
}
+
+   reg = readl(dp->reg_base + pd_addr);
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + pd_addr);
 }
 
 void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
-- 
2.16.3

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

[PATCH 00/16] Make all drivers under drivers/media to build with COMPILE_TEST


The current media policy has been for a while to only accept new drivers 
that compile with COMPILE_TEST.

However, there are still several drivers under drivers/media that 
doesn't build with COMPILE_TEST.

So, this series makes the existing ones also compatible with it.

Not building with COMPILE_TEST is a bad thing, for several reasons.

The main ones is that:

1) the licence the Kernel community has for Coverity only builds for 
   x86. So, drivers that don't build on such archtecture were likely 
   never tested by it.

2) That affects my per-patch handling process, with should be quick 
   enough to not delay my patch handling process. So, I only build for one 
   architecture (i386).

3) When appliying a patch, I always run two static code analyzers (W=1, 
   smatch and sparse). Those drivers weren't checked by me. At the end 
   of the day, that leads to a lower quality check for the drivers that 
   don't build on i386.

There are two situations on this patch series that proof the lower 
quality of those drivers:

- There is a case of a driver that was added broken in 2013. Only two 
  years later, someone noticed and "fixed" it by markin it as BROKEN!

- 5 patches in this series (about 1/3) are just to fix build issues on 
  those drivers, most of them due to gcc warnings.


Mauro Carvalho Chehab (16):
  omap: omap-iommu.h: allow building drivers with COMPILE_TEST
  media: omap3isp: allow it to build with COMPILE_TEST
  media: omap3isp/isp: remove an unused static var
  media: fsl-viu: mark static functions as such
  media: fsl-viu: allow building it with COMPILE_TEST
  media: cec_gpio: allow building CEC_GPIO with COMPILE_TEST
  media: exymos4-is: allow compile test for EXYNOS FIMC-LITE
  media: mmp-camera.h: add missing platform data
  media: marvel-ccic: re-enable mmp-driver build
  media: mmp-driver: make two functions static
  media: davinci: allow building isif code
  media: davinci: allow build vpbe_display with COMPILE_TEST
  media: vpbe_venc: don't store return codes if they won't be used
  media: davinci: get rid of lots of kernel-doc warnings
  media: omapfb_dss.h: add stubs to build with COMPILE_TEST
  media: omap: allow building it with COMPILE_TEST

 drivers/media/platform/Kconfig   | 12 +++---
 drivers/media/platform/davinci/Kconfig   |  6 ++-
 drivers/media/platform/davinci/isif.c|  2 -
 drivers/media/platform/davinci/vpbe.c| 38 +
 drivers/media/platform/davinci/vpbe_display.c| 21 +
 drivers/media/platform/davinci/vpbe_osd.c| 16 ---
 drivers/media/platform/davinci/vpbe_venc.c   |  9 ++--
 drivers/media/platform/exynos4-is/Kconfig|  4 +-
 drivers/media/platform/fsl-viu.c | 20 ++---
 drivers/media/platform/marvell-ccic/Kconfig  |  5 ++-
 drivers/media/platform/marvell-ccic/mmp-driver.c |  4 +-
 drivers/media/platform/omap/Kconfig  |  6 +--
 drivers/media/platform/omap3isp/isp.c| 14 +++---
 include/linux/omap-iommu.h   |  5 +++
 include/linux/platform_data/media/mmp-camera.h   | 19 +
 include/video/omapfb_dss.h   | 54 +++-
 16 files changed, 162 insertions(+), 73 deletions(-)

-- 
2.14.3


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

[PATCH v6 15/30] drm/bridge: analogix_dp: Fix timeout of video streamclk config

From: zain wang 

The STRM_VALID bit in register ANALOGIX_DP_SYS_CTL_3 may be unstable,
so we may hit the error log "Timeout of video streamclk ok" since
checked this unstable bit.
In fact, we can go continue and the streamclk is ok if we wait enough time,
it does no effect on display.
Let's change this error to warn.

Cc: Douglas Anderson 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5540e2dfc2ec..a72e454a7292 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -921,8 +921,9 @@ static int analogix_dp_config_video(struct 
analogix_dp_device *dp)
done_count = 0;
}
if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
-   dev_err(dp->dev, "Timeout of video streamclk ok\n");
-   return -ETIMEDOUT;
+   dev_warn(dp->dev,
+"Ignoring timeout of video streamclk ok\n");
+   break;
}
 
usleep_range(1000, 1001);
-- 
2.16.3

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

[PATCH v6 10/30] drm/bridge: analogix_dp: Check dpcd write/read status

From: Lin Huang 

We need to check the dpcd write/read return value to see whether the
write/read was successful

Cc: Kristian H. Kristensen 
Signed-off-by: Lin Huang 
Signed-off-by: zain wang 
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 169 -
 1 file changed, 127 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 1e1743b59c77..75e61ebf6722 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -160,80 +160,137 @@ int analogix_dp_disable_psr(struct analogix_dp_device 
*dp)
 }
 EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
 
-static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
+static int analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
 {
unsigned char psr_version;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(>aux, DP_PSR_SUPPORT, _version);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to get PSR version, disable it\n");
+   return ret;
+   }
 
-   drm_dp_dpcd_readb(>aux, DP_PSR_SUPPORT, _version);
dev_dbg(dp->dev, "Panel PSR version : %x\n", psr_version);
 
-   return (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
+   dp->psr_enable = (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
+
+   return 0;
 }
 
-static void analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
+static int analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
 {
unsigned char psr_en;
+   int ret;
 
/* Disable psr function */
-   drm_dp_dpcd_readb(>aux, DP_PSR_EN_CFG, _en);
+   ret = drm_dp_dpcd_readb(>aux, DP_PSR_EN_CFG, _en);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to get psr config\n");
+   goto end;
+   }
+
psr_en &= ~DP_PSR_ENABLE;
-   drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
+   ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to disable panel psr\n");
+   goto end;
+   }
 
/* Main-Link transmitter remains active during PSR active states */
psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
-   drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
+   ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to set panel psr\n");
+   goto end;
+   }
 
/* Enable psr function */
psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
 DP_PSR_CRC_VERIFICATION;
-   drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
+   ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to set panel psr\n");
+   goto end;
+   }
 
analogix_dp_enable_psr_crc(dp);
+
+   return 0;
+end:
+   dev_err(dp->dev, "enable psr fail, force to disable psr\n");
+   dp->psr_enable = false;
+
+   return ret;
 }
 
-static void
+static int
 analogix_dp_enable_rx_to_enhanced_mode(struct analogix_dp_device *dp,
   bool enable)
 {
u8 data;
+   int ret;
 
-   drm_dp_dpcd_readb(>aux, DP_LANE_COUNT_SET, );
+   ret = drm_dp_dpcd_readb(>aux, DP_LANE_COUNT_SET, );
+   if (ret != 1)
+   return ret;
 
if (enable)
-   drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
-  DP_LANE_COUNT_ENHANCED_FRAME_EN |
-   DPCD_LANE_COUNT_SET(data));
+   ret = drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
+DP_LANE_COUNT_ENHANCED_FRAME_EN |
+DPCD_LANE_COUNT_SET(data));
else
-   drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
-  DPCD_LANE_COUNT_SET(data));
+   ret = drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
+DPCD_LANE_COUNT_SET(data));
+
+   return ret < 0 ? ret : 0;
 }
 
-static int analogix_dp_is_enhanced_mode_available(struct analogix_dp_device 
*dp)
+static int analogix_dp_is_enhanced_mode_available(struct analogix_dp_device 
*dp,
+ u8 *enhanced_mode_support)
 {
u8 data;
-

[PATCH v6 22/30] drm/bridge: analogix_dp: Split the platform-specific poweron in two parts

From: Douglas Anderson 

Some of the platform-specific stuff in rockchip_dp_poweron() needs to
happen before the generic code.  Some needs to happen after.  Let's
split the callback in two.

Specifically we can't start doing PSR work until _after_ the whole
controller is up, so don't set the enable until the end.

Cc: Kristian H. Kristensen 
Signed-off-by: Douglas Anderson 
[seanpaul added exynos change]
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  7 +--
 drivers/gpu/drm/exynos/exynos_dp.c |  2 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 12 ++--
 include/drm/bridge/analogix_dp.h   |  3 ++-
 4 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a260de4f0bd8..2bcbfadb6ac5 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1260,8 +1260,8 @@ static int analogix_dp_set_bridge(struct 
analogix_dp_device *dp)
goto out_dp_clk_pre;
}
 
-   if (dp->plat_data->power_on)
-   dp->plat_data->power_on(dp->plat_data);
+   if (dp->plat_data->power_on_start)
+   dp->plat_data->power_on_start(dp->plat_data);
 
phy_power_on(dp->phy);
 
@@ -1286,6 +1286,9 @@ static int analogix_dp_set_bridge(struct 
analogix_dp_device *dp)
goto out_dp_init;
}
 
+   if (dp->plat_data->power_on_end)
+   dp->plat_data->power_on_end(dp->plat_data);
+
enable_irq(dp->irq);
return 0;
 
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
b/drivers/gpu/drm/exynos/exynos_dp.c
index 964831dab102..86330f396784 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -162,7 +162,7 @@ static int exynos_dp_bind(struct device *dev, struct device 
*master, void *data)
dp->drm_dev = drm_dev;
 
dp->plat_data.dev_type = EXYNOS_DP;
-   dp->plat_data.power_on = exynos_dp_poweron;
+   dp->plat_data.power_on_start = exynos_dp_poweron;
dp->plat_data.power_off = exynos_dp_poweroff;
dp->plat_data.attach = exynos_dp_bridge_attach;
dp->plat_data.get_modes = exynos_dp_get_modes;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index b3f46ed24cdc..23317a2269e1 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -109,7 +109,7 @@ static int rockchip_dp_pre_init(struct rockchip_dp_device 
*dp)
return 0;
 }
 
-static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
+static int rockchip_dp_poweron_start(struct analogix_dp_plat_data *plat_data)
 {
struct rockchip_dp_device *dp = to_dp(plat_data);
int ret;
@@ -127,6 +127,13 @@ static int rockchip_dp_poweron(struct 
analogix_dp_plat_data *plat_data)
return ret;
}
 
+   return ret;
+}
+
+static int rockchip_dp_poweron_end(struct analogix_dp_plat_data *plat_data)
+{
+   struct rockchip_dp_device *dp = to_dp(plat_data);
+
return rockchip_drm_psr_activate(>encoder);
 }
 
@@ -330,7 +337,8 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
dp->plat_data.encoder = >encoder;
 
dp->plat_data.dev_type = dp->data->chip_type;
-   dp->plat_data.power_on = rockchip_dp_poweron;
+   dp->plat_data.power_on_start = rockchip_dp_poweron_start;
+   dp->plat_data.power_on_end = rockchip_dp_poweron_end;
dp->plat_data.power_off = rockchip_dp_powerdown;
dp->plat_data.get_modes = rockchip_dp_get_modes;
 
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index e9a1116d2f8e..475b706b49de 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -33,7 +33,8 @@ struct analogix_dp_plat_data {
struct drm_connector *connector;
bool skip_connector;
 
-   int (*power_on)(struct analogix_dp_plat_data *);
+   int (*power_on_start)(struct analogix_dp_plat_data *);
+   int (*power_on_end)(struct analogix_dp_plat_data *);
int (*power_off)(struct analogix_dp_plat_data *);
int (*attach)(struct analogix_dp_plat_data *, struct drm_bridge *,
  struct drm_connector *);
-- 
2.16.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH v6 03/30] drm/bridge: analogix_dp: Don't use fast link training when panel just powered up

From: zain wang 

Panel would reset its setting when it powers down. It would forget the last
succeeded link training setting. So we can't use the last successful link
training setting to do fast link training. Let's reset fast_train_enable in
analogix_dp_bridge_disable();

Cc: Stéphane Marchesin 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 9 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 05a0ca4af057..85dbb1ca9886 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -579,14 +579,14 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
if (retval != 1) {
dev_err(dp->dev, "failed to read downspread %d\n",
retval);
-   dp->fast_train_support = false;
+   dp->fast_train_enable = false;
} else {
-   dp->fast_train_support =
+   dp->fast_train_enable =
(spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ?
true : false;
}
dev_dbg(dp->dev, "fast link training %s\n",
-   dp->fast_train_support ? "supported" : "unsupported");
+   dp->fast_train_enable ? "supported" : "unsupported");
 
/* set enhanced mode if available */
analogix_dp_set_enhanced_mode(dp);
@@ -793,7 +793,7 @@ static int analogix_dp_fast_link_train(struct 
analogix_dp_device *dp)
 
 static int analogix_dp_train_link(struct analogix_dp_device *dp)
 {
-   if (dp->fast_train_support)
+   if (dp->fast_train_enable)
return analogix_dp_fast_link_train(dp);
 
return analogix_dp_full_link_train(dp, dp->video_info.max_lane_count,
@@ -1197,6 +1197,7 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
 
dp->psr_enable = false;
+   dp->fast_train_enable = false;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 6a96ef7e6934..403ff853464b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -173,7 +173,7 @@ struct analogix_dp_device {
int hpd_gpio;
boolforce_hpd;
boolpsr_enable;
-   boolfast_train_support;
+   boolfast_train_enable;
 
struct mutexpanel_lock;
boolpanel_is_modeset;
-- 
2.16.3

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

[PATCH v6 17/30] drm/bridge: analogix_dp: Move fast link training detect to set_bridge

From: zain wang 

It's too early to detect fast link training, if other step after it
failed, we will set fast_link flag to 1, and retry set_bridge again. In
this case we will power down and power up panel power supply, and we
will do fast link training since we have set fast_link flag to 1. In
fact, we should do full link training now, not the fast link training.
So we should move the fast link detection at the end of set_bridge.

Cc: Tomasz Figa 
Signed-off-by: zain wang 
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 42 +-
 1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a72e454a7292..69b2c16e5776 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -601,7 +601,7 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
 {
int lane, lane_count, retval;
u32 reg;
-   u8 link_align, link_status[2], adjust_request[2], spread;
+   u8 link_align, link_status[2], adjust_request[2];
 
usleep_range(400, 401);
 
@@ -645,20 +645,6 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
dev_dbg(dp->dev, "final lane count = %.2x\n",
dp->link_train.lane_count);
 
-   retval = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD,
-  );
-   if (retval != 1) {
-   dev_err(dp->dev, "failed to read downspread %d\n",
-   retval);
-   dp->fast_train_enable = false;
-   } else {
-   dp->fast_train_enable =
-   (spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ?
-   true : false;
-   }
-   dev_dbg(dp->dev, "fast link training %s\n",
-   dp->fast_train_enable ? "supported" : "unsupported");
-
dp->link_train.lt_state = FINISHED;
 
return 0;
@@ -996,6 +982,22 @@ static irqreturn_t analogix_dp_irq_thread(int irq, void 
*arg)
return IRQ_HANDLED;
 }
 
+static int analogix_dp_fast_link_train_detection(struct analogix_dp_device *dp)
+{
+   int ret;
+   u8 spread;
+
+   ret = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD, );
+   if (ret != 1) {
+   dev_err(dp->dev, "failed to read downspread %d\n", ret);
+   return ret;
+   }
+   dp->fast_train_enable = !!(spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING);
+   dev_dbg(dp->dev, "fast link training %s\n",
+   dp->fast_train_enable ? "supported" : "unsupported");
+   return 0;
+}
+
 static int analogix_dp_commit(struct analogix_dp_device *dp)
 {
int ret;
@@ -1038,8 +1040,16 @@ static int analogix_dp_commit(struct analogix_dp_device 
*dp)
if (ret)
return ret;
 
-   if (dp->psr_enable)
+   if (dp->psr_enable) {
ret = analogix_dp_enable_sink_psr(dp);
+   if (ret)
+   return ret;
+   }
+
+   /* Check whether panel supports fast training */
+   ret =  analogix_dp_fast_link_train_detection(dp);
+   if (ret)
+   dp->psr_enable = false;
 
return ret;
 }
-- 
2.16.3

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

[PATCH v6 11/30] drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip

From: zain wang 

There are some different bits between Rockchip and Exynos in register
"AUX_PD". This patch fixes the incorrect operations about it.

Cc: Douglas Anderson 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 117 --
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h |   2 +
 2 files changed, 65 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index bb72f8b0e603..dee1ba109b5f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -248,76 +248,85 @@ void analogix_dp_set_analog_power_down(struct 
analogix_dp_device *dp,
 {
u32 reg;
u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+   u32 mask;
 
if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
phy_pd_addr = ANALOGIX_DP_PD;
 
switch (block) {
case AUX_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg |= AUX_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   } else {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg &= ~AUX_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   }
+   if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+   mask = RK_AUX_PD;
+   else
+   mask = AUX_PD;
+
+   reg = readl(dp->reg_base + phy_pd_addr);
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH0_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg |= CH0_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   } else {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg &= ~CH0_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   }
+   mask = CH0_PD;
+   reg = readl(dp->reg_base + phy_pd_addr);
+
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH1_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg |= CH1_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   } else {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg &= ~CH1_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   }
+   mask = CH1_PD;
+   reg = readl(dp->reg_base + phy_pd_addr);
+
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH2_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg |= CH2_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   } else {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg &= ~CH2_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   }
+   mask = CH2_PD;
+   reg = readl(dp->reg_base + phy_pd_addr);
+
+   if (enable)
+   reg |= mask;
+   else
+   reg &= ~mask;
+   writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH3_BLOCK:
-   if (enable) {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg |= CH3_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   } else {
-   reg = readl(dp->reg_base + phy_pd_addr);
-   reg &= ~CH3_PD;
-   writel(reg, dp->reg_base + phy_pd_addr);
-   }
+   mask = CH3_PD;
+   reg = readl(dp->reg_base + phy_pd_addr);
+
+   if

[PATCH v6 16/30] drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1

From: zain wang 

Register ANALOGIX_DP_FUNC_EN_1(offset 0x18), Rockchip is different to
Exynos:

on Exynos edp phy,
BIT 7   MASTER_VID_FUNC_EN_N
BIT 6   reserved
BIT 5   SLAVE_VID_FUNC_EN_N

on Rockchip edp phy,
BIT 7   reserved
BIT 6   RK_VID_CAP_FUNC_EN_N
BIT 5   RK_VID_FIFO_FUNC_EN_N

So, we should do some private operations to Rockchip.

Cc: Tomasz Figa 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 19 ++-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h |  2 ++
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 02ab1aaa9993..4eae206ec31b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -126,9 +126,14 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
analogix_dp_stop_video(dp);
analogix_dp_enable_video_mute(dp, 0);
 
-   reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
-   AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
-   HDCP_FUNC_EN_N | SW_FUNC_EN_N;
+   if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+   reg = RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N |
+   SW_FUNC_EN_N;
+   else
+   reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
+   AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
+   HDCP_FUNC_EN_N | SW_FUNC_EN_N;
+
writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 
reg = SSC_FUNC_EN_N | AUX_FUNC_EN_N |
@@ -971,8 +976,12 @@ void analogix_dp_config_video_slave_mode(struct 
analogix_dp_device *dp)
u32 reg;
 
reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
-   reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
-   reg |= MASTER_VID_FUNC_EN_N;
+   if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+   reg &= ~(RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N);
+   } else {
+   reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
+   reg |= MASTER_VID_FUNC_EN_N;
+   }
writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 
reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index b633a4a5082a..0cf27c731727 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -127,7 +127,9 @@
 
 /* ANALOGIX_DP_FUNC_EN_1 */
 #define MASTER_VID_FUNC_EN_N   (0x1 << 7)
+#define RK_VID_CAP_FUNC_EN_N   (0x1 << 6)
 #define SLAVE_VID_FUNC_EN_N(0x1 << 5)
+#define RK_VID_FIFO_FUNC_EN_N  (0x1 << 5)
 #define AUD_FIFO_FUNC_EN_N (0x1 << 4)
 #define AUD_FUNC_EN_N  (0x1 << 3)
 #define HDCP_FUNC_EN_N (0x1 << 2)
-- 
2.16.3

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

[PATCH v6 06/30] drm/bridge: analogix_dp: Set PD_INC_BG first when powering up edp phy

From: zain wang 

Following the correct power up sequence:
dp_pd=ff => dp_pd=7f => wait 10us => dp_pd=00

Cc: Stéphane Marchesin 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 --
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h |  3 +++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index b47c5af43560..bb72f8b0e603 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -321,10 +321,16 @@ void analogix_dp_set_analog_power_down(struct 
analogix_dp_device *dp,
break;
case POWER_ALL:
if (enable) {
-   reg = DP_PHY_PD | AUX_PD | CH3_PD | CH2_PD |
-   CH1_PD | CH0_PD;
+   reg = DP_ALL_PD;
writel(reg, dp->reg_base + phy_pd_addr);
} else {
+   reg = DP_ALL_PD;
+   writel(reg, dp->reg_base + phy_pd_addr);
+   usleep_range(10, 15);
+   reg &= ~DP_INC_BG;
+   writel(reg, dp->reg_base + phy_pd_addr);
+   usleep_range(10, 15);
+
writel(0x00, dp->reg_base + phy_pd_addr);
}
break;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index 40200c652533..9602668669f4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -342,12 +342,15 @@
 #define DP_PLL_REF_BIT_1_2500V (0x7 << 0)
 
 /* ANALOGIX_DP_PHY_PD */
+#define DP_INC_BG  (0x1 << 7)
+#define DP_EXP_BG  (0x1 << 6)
 #define DP_PHY_PD  (0x1 << 5)
 #define AUX_PD (0x1 << 4)
 #define CH3_PD (0x1 << 3)
 #define CH2_PD (0x1 << 2)
 #define CH1_PD (0x1 << 1)
 #define CH0_PD (0x1 << 0)
+#define DP_ALL_PD  (0xff)
 
 /* ANALOGIX_DP_PHY_TEST */
 #define MACRO_RST  (0x1 << 5)
-- 
2.16.3

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

Re: [PATCH] drm/virtio: fix vq wait_event condition

2018-04-05 Thread Sasha Levin

Hi.

[This is an automated email]

This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all

The bot has also determined it's probably a bug fixing patch. (score: 97.5752)

The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, 

v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Build OK!

Please let us know if you'd like to have this patch included in a stable tree.

--
Thanks.
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 27/30] drm/rockchip: psr: Sanitize semantics of allow/disallow API

From: Tomasz Figa 

Currently both rockchip_drm_psr_activate() and _deactivate() only set the
boolean "active" flag without actually making sure that hardware state
complies with it.

Since we are going to extend the usage of this API to properly lock PSR
for the duration of atomic commits, we change the semantics in following
way:
 - a counter is used to track the number of disallow requests,
 - PSR is actually disabled in hardware on first disallow request,
 - PSR enable work is scheduled on last disallow request.

The above allows using the API as a way to deterministically synchronize
PSR state changes with other DRM events, i.e. atomic commits and cursor
updates. As a nice side effect, the naming is sorted out and we have
"inhibit" for stopping the software logic and "enable" for hardware
state.

Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |  4 +-
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 57 ++---
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h |  4 +-
 3 files changed, 46 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 6d45d62466b3..080f05352195 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -134,7 +134,7 @@ static int rockchip_dp_poweron_end(struct 
analogix_dp_plat_data *plat_data)
 {
struct rockchip_dp_device *dp = to_dp(plat_data);
 
-   return rockchip_drm_psr_activate(>encoder);
+   return rockchip_drm_psr_inhibit_put(>encoder);
 }
 
 static int rockchip_dp_powerdown(struct analogix_dp_plat_data *plat_data)
@@ -142,7 +142,7 @@ static int rockchip_dp_powerdown(struct 
analogix_dp_plat_data *plat_data)
struct rockchip_dp_device *dp = to_dp(plat_data);
int ret;
 
-   ret = rockchip_drm_psr_deactivate(>encoder);
+   ret = rockchip_drm_psr_inhibit_get(>encoder);
if (ret != 0)
return ret;
 
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index 448c5fde241c..e7e16d92d5a1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -27,7 +27,7 @@ struct psr_drv {
struct drm_encoder  *encoder;
 
struct mutexlock;
-   boolactive;
+   int inhibit_count;
boolenabled;
 
struct delayed_work flush_work;
@@ -76,7 +76,7 @@ static int psr_set_state_locked(struct psr_drv *psr, bool 
enable)
 {
int ret;
 
-   if (!psr->active)
+   if (psr->inhibit_count > 0)
return -EINVAL;
 
if (enable == psr->enabled)
@@ -101,13 +101,18 @@ static void psr_flush_handler(struct work_struct *work)
 }
 
 /**
- * rockchip_drm_psr_activate - activate PSR on the given pipe
+ * rockchip_drm_psr_inhibit_put - release PSR inhibit on given encoder
  * @encoder: encoder to obtain the PSR encoder
  *
+ * Decrements PSR inhibit count on given encoder. Should be called only
+ * for a PSR inhibit count increment done before. If PSR inhibit counter
+ * reaches zero, PSR flush work is scheduled to make the hardware enter
+ * PSR mode in PSR_FLUSH_TIMEOUT_MS.
+ *
  * Returns:
  * Zero on success, negative errno on failure.
  */
-int rockchip_drm_psr_activate(struct drm_encoder *encoder)
+int rockchip_drm_psr_inhibit_put(struct drm_encoder *encoder)
 {
struct psr_drv *psr = find_psr_by_encoder(encoder);
 
@@ -115,21 +120,29 @@ int rockchip_drm_psr_activate(struct drm_encoder *encoder)
return PTR_ERR(psr);
 
mutex_lock(>lock);
-   psr->active = true;
+   --psr->inhibit_count;
+   if (!psr->inhibit_count)
+   mod_delayed_work(system_wq, >flush_work,
+PSR_FLUSH_TIMEOUT_MS);
mutex_unlock(>lock);
 
return 0;
 }
-EXPORT_SYMBOL(rockchip_drm_psr_activate);
+EXPORT_SYMBOL(rockchip_drm_psr_inhibit_put);
 
 /**
- * rockchip_drm_psr_deactivate - deactivate PSR on the given pipe
+ * rockchip_drm_psr_inhibit_get - acquire PSR inhibit on given encoder
  * @encoder: encoder to obtain the PSR encoder
  *
+ * Increments PSR inhibit count on given encoder. This function guarantees
+ * that after it returns PSR is turned off on given encoder and no PSR-related
+ * hardware state change occurs at least until a matching call to
+ * rockchip_drm_psr_inhibit_put() is done.
+ *
  * Returns:
  * Zero on success, negative errno on failure.
  */
-int rockchip_drm_psr_deactivate(struct drm_encoder *encoder)
+int rockchip_drm_psr_inhibit_get(struct drm_encoder *encoder)
 {
struct

Re: DRM_UDL and GPU under Xserver

2018-04-05 Thread Alexey Brodkin

Hi Daniel,

On Thu, 2018-04-05 at 08:18 +0200, Daniel Vetter wrote:
> On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin
>  wrote:
> > Hello,
> > 
> > We're trying to use DisplayLink USB2-to-HDMI adapter to render 
> > GPU-accelerated graphics.
> > Hardware setup is as simple as a devboard + DisplayLink adapter.
> > Devboards we use for this experiment are:
> >  * Wandboard Quad (based on IMX6 SoC with Vivante GPU) or
> >  * HSDK (based on Synopsys ARC HS38 SoC with Vivante GPU as well)
> > 
> > I'm sure any other board with DRM supported GPU will work, those we just 
> > used
> > as the very recent Linux kernels could be easily run on them both.
> > 
> > Basically the problem is UDL needs to be explicitly notified about new data
> > to be rendered on the screen compared to typical bit-streamers that 
> > infinitely
> > scan a dedicated buffer in memory.
> > 
> > In case of UDL there're just 2 ways for this notification:
> >  1) DRM_IOCTL_MODE_PAGE_FLIP that calls drm_crtc_funcs->page_flip()
> >  2) DRM_IOCTL_MODE_DIRTYFB that calls drm_framebuffer_funcs->dirty()
> > 
> > But neither of IOCTLs happen when we run Xserver with xf86-video-armada 
> > driver
> > (see 
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.arm.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh-3Dunstable-2Ddevel=DwIBaQ;
> > c=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=oEAlP64L9vkuUs_k3kGwwwlN1WJbDMJbCo0uDhwKwwk=3ZHj-
> > 6JXZBLSTWg_4KMnL0VNi7z8c0RxHzj2U5ywVIw=).
> > 
> > Is it something missing in Xserver or in UDL driver?
> 
> Use the -modesetting driverr for UDL, that one works correctly.

If you're talking about "modesetting" driver of Xserver [1] then indeed
picture is displayed on the screen. But there I guess won't be any 3D 
acceleration.

At least that's what was suggested to me earlier here [2] by Lucas:
>8---
For 3D acceleration to work under X you need the etnaviv specific DDX
driver, which can be found here:

http://git.arm.linux.org.uk/cgit/xf86-video-armada.git/log/?h=unstable-devel
>8---

[1] 
https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/drivers/modesetting
[2] 
http://lists.infradead.org/pipermail/linux-snps-arc/2017-November/003031.html

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

[PATCH v6 08/30] drm/bridge: analogix_dp: Extend hpd check time to 100ms

From: Lin Huang 

There was a 1ms delay to detect the hpd signal, which is too short to
detect a short pulse. This patch extends this delay to 100ms.

Cc: Stéphane Marchesin 
Cc: 征增 王 
Signed-off-by: Lin Huang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

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

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5957e2338071..1f4f34149019 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -76,7 +76,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
return 0;
 
timeout_loop++;
-   usleep_range(10, 11);
+   usleep_range(1000, 1100);
}
 
/*
-- 
2.16.3

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

[PATCH v6 02/30] drm/bridge: analogix_dp: Check AUX_EN status when doing AUX transfer

From: Lin Huang 

We should check AUX_EN bit to confirm the AUX CH operation is completed.

Cc: Stéphane Marchesin 
Signed-off-by: Lin Huang 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 25 +--
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 9df2f3ef000c..e78c861b9e06 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1073,9 +1073,9 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 {
u32 reg;
u8 *buffer = msg->buffer;
-   int timeout_loop = 0;
unsigned int i;
int num_transferred = 0;
+   int ret;
 
/* Buffer size of AUX CH is 16 bytes */
if (WARN_ON(msg->size > 16))
@@ -1139,17 +1139,20 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 
writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
 
-   /* Is AUX CH command reply received? */
+   ret = readx_poll_timeout(readl, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2,
+reg, !(reg & AUX_EN), 25, 500 * 1000);
+   if (ret) {
+   dev_err(dp->dev, "AUX CH enable timeout!\n");
+   return -ETIMEDOUT;
+   }
+
/* TODO: Wait for an interrupt instead of looping? */
-   reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
-   while (!(reg & RPLY_RECEIV)) {
-   timeout_loop++;
-   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
-   dev_err(dp->dev, "AUX CH command reply failed!\n");
-   return -ETIMEDOUT;
-   }
-   reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
-   usleep_range(10, 11);
+   /* Is AUX CH command reply received? */
+   ret = readx_poll_timeout(readl, dp->reg_base + ANALOGIX_DP_INT_STA,
+reg, reg & RPLY_RECEIV, 10, 20 * 1000);
+   if (ret) {
+   dev_err(dp->dev, "AUX CH cmd reply timeout!\n");
+   return -ETIMEDOUT;
}
 
/* Clear interrupt source for AUX CH command reply */
-- 
2.16.3

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

[PATCH 15/16] media: omapfb_dss.h: add stubs to build with COMPILE_TEST

Add stubs for omapfb_dss.h, in the case it is included by
some driver when CONFIG_FB_OMAP2 is not defined.

That allows building such driver(s) with COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/video/omapfb_dss.h | 54 --
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/include/video/omapfb_dss.h b/include/video/omapfb_dss.h
index 1d38901d599d..e9775144ff3b 100644
--- a/include/video/omapfb_dss.h
+++ b/include/video/omapfb_dss.h
@@ -774,6 +774,12 @@ struct omap_dss_driver {
const struct hdmi_avi_infoframe *avi);
 };
 
+#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
+
+typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
+
+#ifdef CONFIG_FB_OMAP2
+
 enum omapdss_version omapdss_get_version(void);
 bool omapdss_is_initialized(void);
 
@@ -785,7 +791,6 @@ void omapdss_unregister_display(struct omap_dss_device 
*dssdev);
 
 struct omap_dss_device *omap_dss_get_device(struct omap_dss_device *dssdev);
 void omap_dss_put_device(struct omap_dss_device *dssdev);
-#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
 struct omap_dss_device *omap_dss_get_next_device(struct omap_dss_device *from);
 struct omap_dss_device *omap_dss_find_device(void *data,
int (*match)(struct omap_dss_device *dssdev, void *data));
@@ -826,7 +831,6 @@ int omapdss_default_get_recommended_bpp(struct 
omap_dss_device *dssdev);
 void omapdss_default_get_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings);
 
-typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
 int omap_dispc_register_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 int omap_dispc_unregister_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 
@@ -856,5 +860,51 @@ omapdss_of_get_first_endpoint(const struct device_node 
*parent);
 
 struct omap_dss_device *
 omapdss_of_find_source_for_first_ep(struct device_node *node);
+#else
+
+static inline enum omapdss_version omapdss_get_version(void)
+{ return OMAPDSS_VER_UNKNOWN; };
+
+static inline bool omapdss_is_initialized(void)
+{ return false; };
+
+static inline int omap_dispc_register_isr(omap_dispc_isr_t isr,
+ void *arg, u32 mask)
+{ return 0; };
+
+static inline int omap_dispc_unregister_isr(omap_dispc_isr_t isr,
+   void *arg, u32 mask)
+{ return 0; };
+
+static inline struct omap_dss_device
+*omap_dss_get_device(struct omap_dss_device *dssdev)
+{ return NULL; };
+
+static inline struct omap_dss_device
+*omap_dss_get_next_device(struct omap_dss_device *from)
+{return NULL; };
+
+static inline void omap_dss_put_device(struct omap_dss_device *dssdev) {};
+
+static inline int omapdss_compat_init(void)
+{ return 0; };
+
+static inline void omapdss_compat_uninit(void) {};
+
+static inline int omap_dss_get_num_overlay_managers(void)
+{ return 0; };
+
+static inline struct omap_overlay_manager *omap_dss_get_overlay_manager(int 
num)
+{ return NULL; };
+
+static inline int omap_dss_get_num_overlays(void)
+{ return 0; };
+
+static inline struct omap_overlay *omap_dss_get_overlay(int num)
+{ return NULL; };
+
+
+#endif /* FB_OMAP2 */
+
 
 #endif /* __OMAPFB_DSS_H */
-- 
2.14.3

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

[PATCH v6 04/30] drm/bridge: analogix_dp: Retry bridge enable when it failed

From: zain wang 

When we enable bridge failed, we have to retry it, otherwise we would get
the abnormal display.

Cc: Stéphane Marchesin 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 65 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  3 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  5 +-
 3 files changed, 56 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 85dbb1ca9886..bf805f156272 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -43,8 +43,10 @@ struct bridge_init {
struct device_node *node;
 };
 
-static void analogix_dp_init_dp(struct analogix_dp_device *dp)
+static int analogix_dp_init_dp(struct analogix_dp_device *dp)
 {
+   int ret;
+
analogix_dp_reset(dp);
 
analogix_dp_swreset(dp);
@@ -56,10 +58,13 @@ static void analogix_dp_init_dp(struct analogix_dp_device 
*dp)
analogix_dp_enable_sw_function(dp);
 
analogix_dp_config_interrupt(dp);
-   analogix_dp_init_analog_func(dp);
+   ret = analogix_dp_init_analog_func(dp);
+   if (ret)
+   return ret;
 
analogix_dp_init_hpd(dp);
analogix_dp_init_aux(dp);
+   return 0;
 }
 
 static int analogix_dp_detect_hpd(struct analogix_dp_device *dp)
@@ -918,7 +923,7 @@ static irqreturn_t analogix_dp_irq_thread(int irq, void 
*arg)
return IRQ_HANDLED;
 }
 
-static void analogix_dp_commit(struct analogix_dp_device *dp)
+static int analogix_dp_commit(struct analogix_dp_device *dp)
 {
int ret;
 
@@ -928,11 +933,10 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}
 
-   ret = readx_poll_timeout(analogix_dp_train_link, dp, ret, !ret, 100,
-DP_TIMEOUT_TRAINING_US * 5);
+   ret = analogix_dp_train_link(dp);
if (ret) {
dev_err(dp->dev, "unable to do link train, ret=%d\n", ret);
-   return;
+   return ret;
}
 
analogix_dp_enable_scramble(dp, 1);
@@ -953,6 +957,7 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
dp->psr_enable = analogix_dp_detect_sink_psr(dp);
if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);
+   return 0;
 }
 
 /*
@@ -1149,12 +1154,9 @@ static void analogix_dp_bridge_pre_enable(struct 
drm_bridge *bridge)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
 }
 
-static void analogix_dp_bridge_enable(struct drm_bridge *bridge)
+static int analogix_dp_set_bridge(struct analogix_dp_device *dp)
 {
-   struct analogix_dp_device *dp = bridge->driver_private;
-
-   if (dp->dpms_mode == DRM_MODE_DPMS_ON)
-   return;
+   int ret;
 
pm_runtime_get_sync(dp->dev);
 
@@ -1162,11 +1164,46 @@ static void analogix_dp_bridge_enable(struct drm_bridge 
*bridge)
dp->plat_data->power_on(dp->plat_data);
 
phy_power_on(dp->phy);
-   analogix_dp_init_dp(dp);
+
+   ret = analogix_dp_init_dp(dp);
+   if (ret)
+   goto out_dp_init;
+
+   ret = analogix_dp_commit(dp);
+   if (ret)
+   goto out_dp_init;
+
enable_irq(dp->irq);
-   analogix_dp_commit(dp);
+   return 0;
 
-   dp->dpms_mode = DRM_MODE_DPMS_ON;
+out_dp_init:
+   phy_power_off(dp->phy);
+   if (dp->plat_data->power_off)
+   dp->plat_data->power_off(dp->plat_data);
+   pm_runtime_put_sync(dp->dev);
+
+   return ret;
+}
+
+static void analogix_dp_bridge_enable(struct drm_bridge *bridge)
+{
+   struct analogix_dp_device *dp = bridge->driver_private;
+   int timeout_loop = 0;
+
+   if (dp->dpms_mode == DRM_MODE_DPMS_ON)
+   return;
+
+   while (timeout_loop < MAX_PLL_LOCK_LOOP) {
+   if (analogix_dp_set_bridge(dp) == 0) {
+   dp->dpms_mode = DRM_MODE_DPMS_ON;
+   return;
+   }
+   dev_err(dp->dev, "failed to set bridge, retry: %d\n",
+   timeout_loop);
+   timeout_loop++;
+   usleep_range(10, 11);
+   }
+   dev_err(dp->dev, "too many times retry set bridge, give it up\n");
 }
 
 static void analogix_dp_bridge_disable(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h

[PATCH v6 07/30] drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the panel

From: Lin Huang 

When panel is shut down, we should make sure edp can be disabled to avoid
undefined behavior.

Cc: Stéphane Marchesin 
Signed-off-by: Lin Huang 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 3269deec739d..5957e2338071 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1160,6 +1160,12 @@ static int analogix_dp_set_bridge(struct 
analogix_dp_device *dp)
 
pm_runtime_get_sync(dp->dev);
 
+   ret = clk_prepare_enable(dp->clock);
+   if (ret < 0) {
+   DRM_ERROR("Failed to prepare_enable the clock clk [%d]\n", ret);
+   goto out_dp_clk_pre;
+   }
+
if (dp->plat_data->power_on)
dp->plat_data->power_on(dp->plat_data);
 
@@ -1191,6 +1197,8 @@ static int analogix_dp_set_bridge(struct 
analogix_dp_device *dp)
phy_power_off(dp->phy);
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
+   clk_disable_unprepare(dp->clock);
+out_dp_clk_pre:
pm_runtime_put_sync(dp->dev);
 
return ret;
@@ -1233,11 +1241,14 @@ static void analogix_dp_bridge_disable(struct 
drm_bridge *bridge)
}
 
disable_irq(dp->irq);
+   analogix_dp_set_analog_power_down(dp, POWER_ALL, 1);
phy_power_off(dp->phy);
 
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
 
+   clk_disable_unprepare(dp->clock);
+
pm_runtime_put_sync(dp->dev);
 
ret = analogix_dp_prepare_panel(dp, false, true);
-- 
2.16.3

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

[PATCH v6 30/30] drm/rockchip: psr: Remove flush by CRTC

From: Tomasz Figa 

It is not used anymore after last changes and it was not even correct to
begin with as it assumed a 1:1 relation between a CRTC and encoder,
while in fact a CRTC can be attached to multiple encoders.

Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 35 -
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h |  1 -
 2 files changed, 36 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index 1bf5cba9a64d..b1988ac758d5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -40,23 +40,6 @@ struct psr_drv {
int (*set)(struct drm_encoder *encoder, bool enable);
 };
 
-static struct psr_drv *find_psr_by_crtc(struct drm_crtc *crtc)
-{
-   struct rockchip_drm_private *drm_drv = crtc->dev->dev_private;
-   struct psr_drv *psr;
-
-   mutex_lock(_drv->psr_list_lock);
-   list_for_each_entry(psr, _drv->psr_list, list) {
-   if (psr->encoder->crtc == crtc)
-   goto out;
-   }
-   psr = ERR_PTR(-ENODEV);
-
-out:
-   mutex_unlock(_drv->psr_list_lock);
-   return psr;
-}
-
 static struct psr_drv *find_psr_by_encoder(struct drm_encoder *encoder)
 {
struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
@@ -173,24 +156,6 @@ static void rockchip_drm_do_flush(struct psr_drv *psr)
mutex_unlock(>lock);
 }
 
-/**
- * rockchip_drm_psr_flush - flush a single pipe
- * @crtc: CRTC of the pipe to flush
- *
- * Returns:
- * 0 on success, -errno on fail
- */
-int rockchip_drm_psr_flush(struct drm_crtc *crtc)
-{
-   struct psr_drv *psr = find_psr_by_crtc(crtc);
-   if (IS_ERR(psr))
-   return PTR_ERR(psr);
-
-   rockchip_drm_do_flush(psr);
-   return 0;
-}
-EXPORT_SYMBOL(rockchip_drm_psr_flush);
-
 /**
  * rockchip_drm_psr_flush_all - force to flush all registered PSR encoders
  * @dev: drm device
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
index 40e026c14168..860c62494496 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
@@ -16,7 +16,6 @@
 #define __ROCKCHIP_DRM_PSR___
 
 void rockchip_drm_psr_flush_all(struct drm_device *dev);
-int rockchip_drm_psr_flush(struct drm_crtc *crtc);
 
 int rockchip_drm_psr_inhibit_put(struct drm_encoder *encoder);
 int rockchip_drm_psr_inhibit_get(struct drm_encoder *encoder);
-- 
2.16.3

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

[PATCH 2/2] drm/msm: use correct aspace pointer in msm_gem_put_iova()

2018-04-05 Thread Daniel Mack

Even though msm_gem_put_iova() is currently a NOP function, the caller
should pass in the address space pointer it used to obtain the object.

Other call sites were changed in 8bdcd949bbe7e ("drm/msm: pass
address-space to _get_iova() and friends"), but this one seems to have
been forgotten.

Signed-off-by: Daniel Mack 
Cc: Rob Clark 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index c9b14948dc25..f844ca1f8e5a 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1059,9 +1059,10 @@ static int dsi_tx_buf_alloc(struct msm_dsi_host 
*msm_host, int size)
 static void dsi_tx_buf_free(struct msm_dsi_host *msm_host)
 {
struct drm_device *dev = msm_host->dev;
+   struct msm_drm_private *priv = dev->dev_private;
 
if (msm_host->tx_gem_obj) {
-   msm_gem_put_iova(msm_host->tx_gem_obj, 0);
+   msm_gem_put_iova(msm_host->tx_gem_obj, priv->kms->aspace);
drm_gem_object_put_unlocked(msm_host->tx_gem_obj);
msm_host->tx_gem_obj = NULL;
}
-- 
2.14.3

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

[PATCH v6 28/30] drm/rockchip: Disable PSR from reboot notifier

From: Tomasz Figa 

It looks like the driver subsystem detaches devices from power domains
at shutdown without consent of the drivers. This means that we might have
our power domain turned off behind our back and the only way to avoid
problems is to stop doing any hardware programming at some point before
the power is cut. A reboot notifier, despite being a misnomer and
handling shutdowns as well, is a good place to do it.

Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

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

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index e7e16d92d5a1..1bf5cba9a64d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 
 #include 
 #include 
@@ -33,6 +34,7 @@ struct psr_drv {
struct delayed_work flush_work;
struct work_struct  disable_work;
 
+   struct notifier_block   reboot_nb;
struct input_handlerinput_handler;
 
int (*set)(struct drm_encoder *encoder, bool enable);
@@ -309,6 +311,24 @@ static const struct input_device_id psr_ids[] = {
{ },
 };
 
+static int rockchip_drm_psr_reboot_notifier(struct notifier_block *nb,
+   unsigned long action, void *data)
+{
+   struct psr_drv *psr = container_of(nb, struct psr_drv, reboot_nb);
+
+   /*
+* It looks like the driver subsystem detaches devices from power
+* domains at shutdown without consent of the drivers. This means
+* that we might have our power domain turned off behind our back
+* and the only way to avoid problems is to stop doing any hardware
+* programming after this point, which is achieved by the unbalanced
+* call below.
+*/
+   rockchip_drm_psr_inhibit_get(psr->encoder);
+
+   return 0;
+}
+
 /**
  * rockchip_drm_psr_register - register encoder to psr driver
  * @encoder: encoder that obtain the PSR function
@@ -361,6 +381,9 @@ int rockchip_drm_psr_register(struct drm_encoder *encoder,
if (error)
goto err1;
 
+   psr->reboot_nb.notifier_call = rockchip_drm_psr_reboot_notifier;
+   register_reboot_notifier(>reboot_nb);
+
mutex_lock(_drv->psr_list_lock);
list_add_tail(>list, _drv->psr_list);
mutex_unlock(_drv->psr_list_lock);
@@ -403,6 +426,7 @@ void rockchip_drm_psr_unregister(struct drm_encoder 
*encoder)
WARN_ON(psr->inhibit_count != 1);
 
list_del(>list);
+   unregister_reboot_notifier(>reboot_nb);
input_unregister_handler(>input_handler);
kfree(psr->input_handler.name);
kfree(psr);
-- 
2.16.3

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

[PATCH v6 19/30] drm/bridge: analogix_dp: Properly log AUX CH errors

From: Douglas Anderson 

The code in analogix_dp_transfer() that was supposed to print out:
  AUX CH error happened

Was actually dead code. That's because the previous check (whether
the interrupt status indicated any errors) would have hit for all
errors anyway.

Let's combine the two error checks so we can actually see AUX CH
errors.  We'll also downgrade the message to a warning since some of
these types of errors might be expected for some displays.  If this
gets too noisy we can downgrade again to debug.

Cc: 征增 王 
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 4eae206ec31b..58e8a28e99aa 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1105,6 +1105,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 struct drm_dp_aux_msg *msg)
 {
u32 reg;
+   u32 status_reg;
u8 *buffer = msg->buffer;
unsigned int i;
int num_transferred = 0;
@@ -1193,16 +1194,12 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 
/* Clear interrupt source for AUX CH access error */
reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
-   if (reg & AUX_ERR) {
+   status_reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_STA);
+   if ((reg & AUX_ERR) || (status_reg & AUX_STATUS_MASK)) {
writel(AUX_ERR, dp->reg_base + ANALOGIX_DP_INT_STA);
-   goto aux_error;
-   }
 
-   /* Check AUX CH error access status */
-   reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_STA);
-   if ((reg & AUX_STATUS_MASK)) {
-   dev_err(dp->dev, "AUX CH error happened: %d\n\n",
-   reg & AUX_STATUS_MASK);
+   dev_warn(dp->dev, "AUX CH error happened: %#x (%d)\n",
+status_reg & AUX_STATUS_MASK, !!(reg & AUX_ERR));
goto aux_error;
}
 
-- 
2.16.3

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

[PATCH v6 24/30] drm/rockchip: Disable PSR on input events

From: "Kristian H. Kristensen" 

To improve PSR exit latency, we speculatively start exiting when we
receive input events. Occasionally, this may lead to false positives,
but most of the time we get a head start on coming out of PSR. Depending
on how userspace takes to produce a new frame in response to the event,
this can completely hide the exit latency. In case of Chrome OS, we
typically get the input notifier 50ms or more before the dirty_fb
triggered exit.

Signed-off-by: Kristian H. Kristensen 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

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

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index 9376f4396b6b..a107845ba97c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -12,6 +12,8 @@
  * GNU General Public License for more details.
  */
 
+#include 
+
 #include 
 #include 
 
@@ -35,6 +37,9 @@ struct psr_drv {
enum psr_state  state;
 
struct delayed_work flush_work;
+   struct work_struct  disable_work;
+
+   struct input_handlerinput_handler;
 
int (*set)(struct drm_encoder *encoder, bool enable);
 };
@@ -133,6 +138,18 @@ static void psr_flush_handler(struct work_struct *work)
mutex_unlock(>lock);
 }
 
+static void psr_disable_handler(struct work_struct *work)
+{
+   struct psr_drv *psr = container_of(work, struct psr_drv, disable_work);
+
+   /* If the state has changed since we initiated the flush, do nothing */
+   mutex_lock(>lock);
+   if (psr->state == PSR_ENABLE)
+   psr_set_state_locked(psr, PSR_FLUSH);
+   mutex_unlock(>lock);
+   mod_delayed_work(system_wq, >flush_work, PSR_FLUSH_TIMEOUT_MS);
+}
+
 /**
  * rockchip_drm_psr_activate - activate PSR on the given pipe
  * @encoder: encoder to obtain the PSR encoder
@@ -173,6 +190,7 @@ int rockchip_drm_psr_deactivate(struct drm_encoder *encoder)
psr->active = false;
mutex_unlock(>lock);
cancel_delayed_work_sync(>flush_work);
+   cancel_work_sync(>disable_work);
 
return 0;
 }
@@ -226,6 +244,95 @@ void rockchip_drm_psr_flush_all(struct drm_device *dev)
 }
 EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
 
+static void psr_input_event(struct input_handle *handle,
+   unsigned int type, unsigned int code,
+   int value)
+{
+   struct psr_drv *psr = handle->handler->private;
+
+   schedule_work(>disable_work);
+}
+
+static int psr_input_connect(struct input_handler *handler,
+struct input_dev *dev,
+const struct input_device_id *id)
+{
+   struct input_handle *handle;
+   int error;
+
+   handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL);
+   if (!handle)
+   return -ENOMEM;
+
+   handle->dev = dev;
+   handle->handler = handler;
+   handle->name = "rockchip-psr";
+
+   error = input_register_handle(handle);
+   if (error)
+   goto err2;
+
+   error = input_open_device(handle);
+   if (error)
+   goto err1;
+
+   return 0;
+
+err1:
+   input_unregister_handle(handle);
+err2:
+   kfree(handle);
+   return error;
+}
+
+static void psr_input_disconnect(struct input_handle *handle)
+{
+   input_close_device(handle);
+   input_unregister_handle(handle);
+   kfree(handle);
+}
+
+/* Same device ids as cpu-boost */
+static const struct input_device_id psr_ids[] = {
+   {
+   .flags = INPUT_DEVICE_ID_MATCH_EVBIT |
+INPUT_DEVICE_ID_MATCH_ABSBIT,
+   .evbit = { BIT_MASK(EV_ABS) },
+   .absbit = { [BIT_WORD(ABS_MT_POSITION_X)] =
+   BIT_MASK(ABS_MT_POSITION_X) |
+   BIT_MASK(ABS_MT_POSITION_Y) },
+   }, /* multi-touch touchscreen */
+   {
+   .flags = INPUT_DEVICE_ID_MATCH_EVBIT,
+   .evbit = { BIT_MASK(EV_ABS) },
+   .absbit = { [BIT_WORD(ABS_X)] = BIT_MASK(ABS_X) }
+
+   }, /* stylus or joystick device */
+   {
+   .flags = INPUT_DEVICE_ID_MATCH_EVBIT,
+   .evbit = { BIT_MASK(EV_KEY) },
+   .keybit = { [BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT) },
+   }, /* pointer (e.g. trackpad, mouse) */
+   {
+   .flags = INPUT_DEVICE_ID_MATCH_EVBIT,
+   .evbit = { BIT_MASK(EV_KEY) },
+   .keybit = { [BIT_WORD(KEY_ESC)] = BIT_MASK(KEY_ESC) },
+   }, /* keyboard */
+   {
+   .flags = INPUT_DEVICE_ID_MATCH_EVBIT |
+

[PATCH v6 25/30] drm/rockchip: Cancel PSR enable work before changing the state

From: Tomasz Figa 

If we change the state first and reschedule later, we might have the
work executed according to previous scheduled time and end up with PSR
re-enabled instantly. Let's cancel the work before changing the state.

While at it, consolidate psr_disable_handler() to just call
rockchip_drm_do_flush(), as they are both supposed to do the same.

Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index a107845ba97c..c8655e625ba2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -138,18 +138,6 @@ static void psr_flush_handler(struct work_struct *work)
mutex_unlock(>lock);
 }
 
-static void psr_disable_handler(struct work_struct *work)
-{
-   struct psr_drv *psr = container_of(work, struct psr_drv, disable_work);
-
-   /* If the state has changed since we initiated the flush, do nothing */
-   mutex_lock(>lock);
-   if (psr->state == PSR_ENABLE)
-   psr_set_state_locked(psr, PSR_FLUSH);
-   mutex_unlock(>lock);
-   mod_delayed_work(system_wq, >flush_work, PSR_FLUSH_TIMEOUT_MS);
-}
-
 /**
  * rockchip_drm_psr_activate - activate PSR on the given pipe
  * @encoder: encoder to obtain the PSR encoder
@@ -198,6 +186,7 @@ EXPORT_SYMBOL(rockchip_drm_psr_deactivate);
 
 static void rockchip_drm_do_flush(struct psr_drv *psr)
 {
+   cancel_delayed_work_sync(>flush_work);
psr_set_state(psr, PSR_FLUSH);
mod_delayed_work(system_wq, >flush_work, PSR_FLUSH_TIMEOUT_MS);
 }
@@ -244,6 +233,13 @@ void rockchip_drm_psr_flush_all(struct drm_device *dev)
 }
 EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
 
+static void psr_disable_handler(struct work_struct *work)
+{
+   struct psr_drv *psr = container_of(work, struct psr_drv, disable_work);
+
+   rockchip_drm_do_flush(psr);
+}
+
 static void psr_input_event(struct input_handle *handle,
unsigned int type, unsigned int code,
int value)
-- 
2.16.3

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

Re: [PATCH 15/16] media: omapfb_dss.h: add stubs to build with COMPILE_TEST

Em Thu, 05 Apr 2018 21:41:18 +0300
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> Thank you for the patch.
> 
> On Thursday, 5 April 2018 20:54:15 EEST Mauro Carvalho Chehab wrote:
> > Add stubs for omapfb_dss.h, in the case it is included by
> > some driver when CONFIG_FB_OMAP2 is not defined.  
> 
> The omapfb driver doesn't include any asm/ header, so it should probably 
> build 
> fine on non-ARM architectures. Instead of adding stubs here, you can enable 
> compilation of the driver on all platforms, in which case the omap_vout 
> driver 
> could keep depending on FB_OMAP2 as it should.

True. The patch for that is simple. 

Patch enclosed. Please notice that, now with W=1, several new warnings
will popup. I'll let to the others to touch there, as I don't have any
clue about what's there under omapfb.

Those are the new warnings:

drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function 
‘omapfb_setup_overlay’:
drivers/video/fbdev/omap2/omapfb/omapfb-main.c:891:6: warning: this statement 
may fall through [-Wimplicit-fallthrough=]
   if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
  ^
drivers/video/fbdev/omap2/omapfb/omapfb-main.c:896:2: note: here
  default:
  ^~~
drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c: In function 
‘tpd_probe’:
drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c:221:26: warning: 
variable ‘in’ set but not used [-Wunused-but-set-variable]
  struct omap_dss_device *in, *dssdev;
  ^~
drivers/video/fbdev/omap2/omapfb/dss/dispc.c: In function 
‘calc_vrfb_rotation_offset’:
drivers/video/fbdev/omap2/omapfb/dss/dispc.c:1905:6: warning: this statement 
may fall through [-Wimplicit-fallthrough=]
   if (color_mode == OMAP_DSS_COLOR_YUV2 ||
  ^
drivers/video/fbdev/omap2/omapfb/dss/dispc.c:1908:2: note: here
  case OMAP_DSS_ROT_90:
  ^~~~
drivers/video/fbdev/omap2/omapfb/dss/dispc.c:1927:6: warning: this statement 
may fall through [-Wimplicit-fallthrough=]
   if (color_mode == OMAP_DSS_COLOR_YUV2 ||
  ^
drivers/video/fbdev/omap2/omapfb/dss/dispc.c:1930:2: note: here
  case OMAP_DSS_ROT_90 + 4:
  ^~~~
drivers/video/fbdev/omap2/omapfb/dss/venc.c:223:33: warning: 
‘venc_config_pal_bdghi’ defined but not used [-Wunused-const-variable=]
 static const struct venc_config venc_config_pal_bdghi = {
 ^
drivers/video/fbdev/omap2/omapfb/dss/dsi.c: In function 
‘_dsi_print_reset_status’:
drivers/video/fbdev/omap2/omapfb/dss/dsi.c:1189:6: warning: variable ‘l’ set 
but not used [-Wunused-but-set-variable]
  u32 l;
  ^
drivers/video/fbdev/omap2/omapfb/dss/dsi.c: In function ‘dsi_proto_timings’:
drivers/video/fbdev/omap2/omapfb/dss/dsi.c:3638:42: warning: variable 
‘tclk_trail’ set but not used [-Wunused-but-set-variable]
  unsigned tlpx, tclk_zero, tclk_prepare, tclk_trail;
  ^~
drivers/video/fbdev/omap2/omapfb/dss/dsi.c: In function ‘dsi_update’:
drivers/video/fbdev/omap2/omapfb/dss/dsi.c:4051:10: warning: variable ‘dh’ set 
but not used [-Wunused-but-set-variable]
  u16 dw, dh;
  ^~
drivers/video/fbdev/omap2/omapfb/dss/dsi.c:4051:6: warning: variable ‘dw’ set 
but not used [-Wunused-but-set-variable]
  u16 dw, dh;
  ^~
drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c: In function 
‘hdmi4_audio_config’:
drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c:693:6: warning: variable 
‘err’ set but not used [-Wunused-but-set-variable]
  int err, n, cts, channel_count;
  ^~~
drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c: In function 
‘hdmi5_audio_config’:
drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c:804:6: warning: variable 
‘err’ set but not used [-Wunused-but-set-variable]
  int err, n, cts, channel_count;
  ^~~

Thanks,
Mauro

---

[PATCH] omap2: omapfb: allow building it with COMPILE_TEST

This driver builds cleanly with COMPILE_TEST, and it is
needed in order to allow building drivers/media omap2
driver.

So, change the logic there to allow building it.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/video/fbdev/omap2/Kconfig 
b/drivers/video/fbdev/omap2/Kconfig
index 0921c4de8407..82008699d253 100644
--- a/drivers/video/fbdev/omap2/Kconfig
+++ b/drivers/video/fbdev/omap2/Kconfig
@@ -1,4 +1,4 @@
-if ARCH_OMAP2PLUS
+if ARCH_OMAP2PLUS || COMPILE_TEST
 
 source "drivers/video/fbdev/omap2/omapfb/Kconfig"
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 05/30] drm/bridge: analogix_dp: Wait for HPD signal before configuring link

From: zain wang 

According to DP spec v1.3 chap 3.5.1.2 Link Training, Link Policy Maker
must first detect that the HPD signal is asserted high by the Downstream
Device before establishing a link with it.

Cc: Stéphane Marchesin 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index bf805f156272..3269deec739d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1169,6 +1169,17 @@ static int analogix_dp_set_bridge(struct 
analogix_dp_device *dp)
if (ret)
goto out_dp_init;
 
+   /*
+* According to DP spec v1.3 chap 3.5.1.2 Link Training,
+* We should first make sure the HPD signal is asserted high by device
+* when we want to establish a link with it.
+*/
+   ret = analogix_dp_detect_hpd(dp);
+   if (ret) {
+   DRM_ERROR("failed to get hpd single ret = %d\n", ret);
+   goto out_dp_init;
+   }
+
ret = analogix_dp_commit(dp);
if (ret)
goto out_dp_init;
-- 
2.16.3

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

[PATCH v6 09/30] drm/bridge: analogix_dp: Fix incorrect usage of enhanced mode

From: zain wang 

Enhanced mode is required by the eDP 1.2 specification, and not doing it
early could result in a period of time where we have a link transmitting
idle packets without it. Since there is no reason to disable it, we just
enable it at the beginning of link training and then keep it on all the
time.

Cc: Tomasz Figa 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 1f4f34149019..1e1743b59c77 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -281,6 +281,8 @@ static int analogix_dp_link_start(struct analogix_dp_device 
*dp)
retval = drm_dp_dpcd_write(>aux, DP_LINK_BW_SET, buf, 2);
if (retval < 0)
return retval;
+   /* set enhanced mode if available */
+   analogix_dp_set_enhanced_mode(dp);
 
/* Set TX pre-emphasis to minimum */
for (lane = 0; lane < lane_count; lane++)
@@ -593,8 +595,6 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
dev_dbg(dp->dev, "fast link training %s\n",
dp->fast_train_enable ? "supported" : "unsupported");
 
-   /* set enhanced mode if available */
-   analogix_dp_set_enhanced_mode(dp);
dp->link_train.lt_state = FINISHED;
 
return 0;
@@ -940,8 +940,6 @@ static int analogix_dp_commit(struct analogix_dp_device *dp)
}
 
analogix_dp_enable_scramble(dp, 1);
-   analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
-   analogix_dp_enable_enhanced_mode(dp, 1);
 
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
-- 
2.16.3

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

Re: Fwd: DRM MIPI DSI device and I2C device?

2018-04-05 Thread Carsten Behling

> 2018-04-05 13:39 GMT+02:00 Laurent Pinchart <
laurent.pinch...@ideasonboard.com>:
> Hi Andrzej,
>
> On Thursday, 5 April 2018 14:28:51 EEST Andrzej Hajda wrote:
>> On 05.04.2018 12:28, Laurent Pinchart wrote:
>>> On Wednesday, 4 April 2018 11:41:05 EEST Carsten Behling wrote:
> Hi,
>
> I would like to write a DRM bridge driver that is an I2C device and a
> DRM MIPI DSI device.
>
> It looks like that both - 'i2c-core.c: of_i2c_register_devices' and
> 'drm_mipi_dsi.c: mipi_dsi_host_register'  are registering their
devices
> by iterating over devicetree child nodes with
> for_each_available_child_of_node.
>
>> Since I can't make the bridge a child node of both, I don't know how
to
> resolve it.

 Found the answer myself. adv7533 driver is a good example. Devicetree
 exists for qcom apq8016-sbc. No need to make the bridge a MIPI DSI
child
 node.
>>>
>>> This is an issue that has largely been ignored so far in Linux. Both DT
>>> and the Linux kernel device model organize devices in a tree structure
>>> based on the control buses. Devices that are connected to multiple
control
>>> buses haven't been taken into account in the design and are thus hard to
>>> support.
>>>
>>> As you may know, DSI can work in command mode or data mode. In data mode
>>> the DSI bus is only use to transfer video data, while in command mode it
>>> is also used to control the device (reading and writing registers).
>>
>> I am not sure what you mean by data and command mode. MIPI DSI specs
>> says about video and command mode - modes to transfer video data. In
>> both cases DSI can be used to control the device.
>
> Sorry, I meant pure video mode, when a panel only uses DSI to receive
video
> data but handles all control communication through a separate control bus.
>
>>> A DSI device operating in data mode and controlled through I2C isn't a
>>> problem, as there's a single control bus in that case. The device should
>>> be a child of the I2C controller in DT, and will be instantiated through
>>> of_i2c_register_devices(). A DSI device operating in command mode
without
>>> any other control bus isn't a problem either, it will be a child of the
>>> DSI master in DT, and will bee instantiated through
>>> mipi_dsi_host_register().
>>>
>>> A DSI device operating in command mode that also require configuration
>>> through a separate control bus (such as I2C, but also SPI) is much more
>>> problematic to support. Fortunately those devices are rare. Hopefully
>>> your device won't fall in this category. If it does, we can discuss how
>>> to best support it.
>>
>> As you have already found adv bridge is a good example. It is not clear
>> from the emails if DSI is used only to send video, or also to control?
>> And if to control, is it used to pass only specific commands
>> or can be used as alternative to i2c interface?
>
>Carsten, could you please provide more information about the panel you're
>using ?

Sure, it's an TI SN65DSI84. It is just receiving pixel data on the input
lines.
I got an incomplete driver from Variscite that just writes a hardcoded  I2C
regmap from
DTS. I'm currently writing a real DRM bridge driver based on that. I didn't
find
a better one.

Regards
-Carsten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 01/30] drm/bridge: analogix_dp: Move enable video into config_video()

From: Lin Huang 

We need to enable video before analogix_dp_is_video_stream_on(), so
we can get the right video stream status.

We needed to increase the delay in the timeout loop because there is
random "Timeout of video streamclk ok" message happen when debug edp
panel, this time do not define in the spec.

Cc: 征增 王 
Cc: Stéphane Marchesin 
Signed-off-by: Lin Huang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5c52307146c7..05a0ca4af057 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -819,11 +819,10 @@ static int analogix_dp_config_video(struct 
analogix_dp_device *dp)
if (analogix_dp_is_slave_video_stream_clock_on(dp) == 0)
break;
if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
-   dev_err(dp->dev, "Timeout of video streamclk ok\n");
+   dev_err(dp->dev, "Timeout of slave video streamclk 
ok\n");
return -ETIMEDOUT;
}
-
-   usleep_range(1, 2);
+   usleep_range(1000, 1001);
}
 
/* Set to use the register calculated M/N video */
@@ -838,6 +837,9 @@ static int analogix_dp_config_video(struct 
analogix_dp_device *dp)
/* Configure video slave mode */
analogix_dp_enable_video_master(dp, 0);
 
+   /* Enable video */
+   analogix_dp_start_video(dp);
+
timeout_loop = 0;
 
for (;;) {
@@ -948,9 +950,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to enable the panel\n");
}
 
-   /* Enable video */
-   analogix_dp_start_video(dp);
-
dp->psr_enable = analogix_dp_detect_sink_psr(dp);
if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);
-- 
2.16.3

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

[PATCH v2] drm/i915/dp: Send DPCD ON for MST before phy_up

2018-04-05 Thread Lyude Paul

When doing a modeset where the sink is transitioning from D3 to D0 , it
would sometimes be possible for the initial power_up_phy() to start
timing out. This would only be observed in the last action before the
sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
originally thought this might be an issue with us accidentally shutting
off the aux block when putting the sink into D3, but since the DP spec
mandates that sinks must wake up within 1ms while we have 100ms to
respond to an ESI irq, this didn't really add up. Turns out that the
problem is more subtle then that:

It turns out that the timeout is from us not enabling DPMS on the MST
hub before actually trying to initiate sideband communications. This
would cause the first sideband communication (power_up_phy()), to start
timing out because the sink wasn't ready to respond. Afterwards, we
would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in
intel_ddi_pre_enable_dp(), which would actually result in waking up the
sink so that sideband requests would work again.

Since DPMS is what lets us actually bring the hub up into a state where
sideband communications become functional again, we just need to make
sure to enable DPMS on the display before attempting to perform sideband
communications.

Changes since v1:
- Remove comment above if (!intel_dp->is_mst) - vsryjala
- Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to
  keep enable/disable paths symmetrical
- Improve commit message - dhnkrn

Signed-off-by: Lyude Paul 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Cc: Laura Abbott 
Cc: sta...@vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
---
This email should hopefully actually be picked up by patchwork this
time, hooray!

 drivers/gpu/drm/i915/intel_ddi.c| 6 --
 drivers/gpu/drm/i915/intel_dp_mst.c | 2 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a6672a9abd85..c0bf7419e1c1 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_prepare_dp_ddi_buffers(encoder, crtc_state);
 
intel_ddi_init_dp_buf_reg(encoder);
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+   if (!intel_dp->is_mst)
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
@@ -2427,7 +2428,8 @@ static void intel_ddi_post_disable_dp(struct 
intel_encoder *encoder,
 * Power down sink before disabling the port, otherwise we end
 * up getting interrupts from the sink on detecting link loss.
 */
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+   if (!intel_dp->is_mst)
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
 
intel_disable_ddi_buf(encoder);
 
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index c3de0918ee13..2493bd1e0e59 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -176,6 +176,7 @@ static void intel_mst_post_disable_dp(struct intel_encoder 
*encoder,
 */
drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port,
 false);
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
 
intel_dp->active_mst_links--;
 
@@ -223,6 +224,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
 
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
 
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
if (intel_dp->active_mst_links == 0)
intel_dig_port->base.pre_enable(_dig_port->base,
-- 
2.14.3

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

[Bug 105913] [IGT] igt@gem_shrink@pread Test assertion failure function gem_read, file ioctl_wrappers.c

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

Chris Wilson  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEW |RESOLVED

--- Comment #1 from Chris Wilson  ---
The test isn't expected to PASS in the traditional sense, the test itself is
expected to crash and burn. The only thing we want is for it to not take the
kernel with it, i.e. failure here is an oops or system lockup.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()

From: Ville Syrjälä 

Instead of plane->fb (which we're going to deprecate for atomic drivers)
we need to look at plane->state->fb. The maze of code leading to
vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
concluded that the calls originating from vmw_*_primary_plane_atomic_update()
all pass in the crtc which means we'll never end up in this branch
of the function. All other callers use drm_modeset_lock_all() somewhere
higher up, which means accessing plane->state is safe. We'll toss in
a lockdep assert to catch wrongdoers.

v2: Drop the comment and make the code do what it did before (Thomas)

Cc: Thomas Hellstrom 
Cc: Sinclair Yeh 
Cc: VMware Graphics 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index a2a796b4cc23..73484ad1ceeb 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2326,9 +2326,12 @@ int vmw_kms_helper_dirty(struct vmw_private *dev_priv,
} else {
list_for_each_entry(crtc, _priv->dev->mode_config.crtc_list,
head) {
-   if (crtc->primary->fb != >base)
-   continue;
-   units[num_units++] = vmw_crtc_to_du(crtc);
+   struct drm_plane *plane = crtc->primary;
+
+   lockdep_assert_held(>mutex);
+
+   if (plane->state->fb == >base)
+   units[num_units++] = vmw_crtc_to_du(crtc);
}
}
 
-- 
2.16.1

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

Re: [RfC PATCH] Add udmabuf misc device

Pulling this out of the shadows again.

We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff
from Matt and Dongwong.

At least from the intel side there seems to be the idea to just have 1
special device that can handle cross-gues/host sharing for all kinds
of hypervisors, so I guess you all need to work together :-)

Or we throw out the idea that hyper dmabuf will be cross-hypervisor
(not sure how useful/reasonable that is, someone please convince me
one way or the other).

Cheers, Daniel

On Wed, Mar 14, 2018 at 9:03 AM, Gerd Hoffmann  wrote:
>   Hi,
>
>> Either mlock account (because it's mlocked defacto), and get_user_pages
>> won't do that for you.
>>
>> Or you write the full-blown userptr implementation, including mmu_notifier
>> support (see i915 or amdgpu), but that also requires Christian Königs
>> latest ->invalidate_mapping RFC for dma-buf (since atm exporting userptr
>> buffers is a no-go).
>
> I guess I'll look at mlock accounting for starters then.  Easier for
> now, and leaves the door open to switch to userptr later as this should
> be transparent to userspace.
>
>> > Known issue:  Driver API isn't complete yet.  Need add some flags, for
>> > example to support read-only buffers.
>>
>> dma-buf has no concept of read-only. I don't think we can even enforce
>> that (not many iommus can enforce this iirc), so pretty much need to
>> require r/w memory.
>
> Ah, ok.  Just saw the 'write' arg for get_user_pages_fast and figured we
> might support that, but if iommus can't handle that anyway it's
> pointless indeed.
>
>> > Cc: David Airlie 
>> > Cc: Tomeu Vizoso 
>> > Signed-off-by: Gerd Hoffmann 
>>
>> btw there's also the hyperdmabuf stuff from the xen folks, but imo their
>> solution of forwarding the entire dma-buf api is over the top. This here
>> looks _much_ better, pls cc all the hyperdmabuf people on your next
>> version.
>
> Fun fact: googling for "hyperdmabuf" found me your mail and nothing else :-o
> (Trying "hyper dmabuf" instead worked better then).
>
> Yes, will cc them on the next version.  Not sure it'll help much on xen
> though due to the memory management being very different.  Basically xen
> owns the memory, not the kernel of the control domain (dom0), so
> creating dmabufs for guest memory chunks isn't that simple ...
>
> Also it's not clear whenever they really need guest -> guest exports or
> guest -> dom0 exports.
>
>> Overall I like the idea, but too lazy to review.
>
> Cool.  General comments on the idea was all I was looking for for the
> moment.  Spare yor review cycles for the next version ;)
>
>> Oh, some kselftests for this stuff would be lovely.
>
> I'll look into it.
>
> thanks,
>   Gerd
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()

2018-04-05 Thread Ville Syrjälä

On Thu, Apr 05, 2018 at 08:15:05PM +, Deepak Singh Rawat wrote:
> 
> > 
> > From: Ville Syrjälä 
> > 
> > Instead of looking at plane->fb let's look at the proper new
> > plane state.
> > 
> > Not that the code makes a ton of sense. It's only going through the
> > crtcs in the atomic state, so assuming not all of them are included
> > we're not even calculating the total bandwidth here. Also we're
> > not considering whether each crtc is actually enabled or not.
> > 
> > Cc: Thomas Hellstrom 
> > Cc: Sinclair Yeh 
> > Cc: VMware Graphics 
> > Cc: Daniel Vetter 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 +++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > index 6728c6247b4b..a2a796b4cc23 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > @@ -1536,9 +1536,13 @@ vmw_kms_atomic_check_modeset(struct
> > drm_device *dev,
> > unsigned long requested_bb_mem = 0;
> > 
> > if (dev_priv->active_display_unit ==
> > vmw_du_screen_target) {
> > -   if (crtc->primary->fb) {
> > -   int cpp = crtc->primary->fb->pitches[0] /
> > - crtc->primary->fb->width;
> > +   struct drm_plane *plane = crtc->primary;
> > +   struct drm_plane_state *plane_state;
> > +
> > +   plane_state =
> > drm_atomic_get_new_plane_state(state, plane);
> > +
> > +   if (plane_state && plane_state->fb) {
> > +   int cpp = plane_state->fb->format->cpp[0];
> 
> Hi Ville,
> 
> Thanks for the patch, recently I have done some refactoring of this code area
> which is no yet sent to dri-devel. But the refactored code eliminated the need
> to look the fb
> 
> https://cgit.freedesktop.org/mesa/vmwgfx/commit/?id=c54cdb6549b7d1c04ff61e639fc0e6de0dcc1ed6

Hmm. What's the timelike for landing that stuff?

A cursory glance tells me we should just change the current code with
s/cpp/4/ and it should still be fine?

BTW the drm_for_each_crtc(crtc, dev) loop in there doesn't look entirely
kosher. It's potentially going to access crtc->state w/o holding the lock.

> 
> There is still some future work to be done in this area. 
> 
> > 
> > requested_bb_mem += crtc->mode.hdisplay
> > * cpp *
> > crtc->mode.vdisplay;
> > --
> > 2.16.1

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105915] [IGT] igt@kms_cursor_crc@cursor-128x128-rapid-movement / cursor-256x256-rapid-movement igt-debugfs-WARNING: Warning on condition crc->crc[i] == 0xffffffff in function crc_sanity_checks, f

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

Bug ID: 105915
   Summary: [IGT] igt@kms_cursor_crc@cursor-128x128-rapid-movement
/ cursor-256x256-rapid-movement igt-debugfs-WARNING:
Warning on condition crc->crc[i] == 0x in
function crc_sanity_checks, file igt_debugfs.c:833
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ricardo.o.pe...@intel.com

Created attachment 138642
  --> https://bugs.freedesktop.org/attachment.cgi?id=138642=edit
dmesg and kern-logs

CNL QA systems are showing a WARN with the following tests:

igt@kms_cursor_crc@cursor-128x128-rapid-movement
igt@kms_cursor_crc@cursor-256x256-rapid-movement

Software Version:

IGT-Version: 1.22-g0721161 (x86_64) (Linux:
4.16.0-rc6-drm-intel-qa-ww12-commit-4db112a+ x86_64)

Warn:

Beginning cursor-256x256-rapid-movement on pipe A, connector eDP-1

cursor-256x256-rapid-movement on pipe A, connector eDP-1: PASSED

Beginning cursor-256x256-rapid-movement on pipe A, connector HDMI-A-1

cursor-256x256-rapid-movement on pipe A, connector HDMI-A-1: PASSED

Beginning cursor-256x256-rapid-movement on pipe B, connector eDP-1

cursor-256x256-rapid-movement on pipe B, connector eDP-1: PASSED

Beginning cursor-256x256-rapid-movement on pipe B, connector HDMI-A-1

cursor-256x256-rapid-movement on pipe B, connector HDMI-A-1: PASSED

Beginning cursor-256x256-rapid-movement on pipe C, connector eDP-1

cursor-256x256-rapid-movement on pipe C, connector eDP-1: PASSED

Beginning cursor-256x256-rapid-movement on pipe C, connector HDMI-A-1

cursor-256x256-rapid-movement on pipe C, connector HDMI-A-1: PASSED

Subtest cursor-256x256-rapid-movement: SUCCESS (4.677s)

-

kms_cursor_crc:18385) igt-debugfs-WARNING: Warning on condition crc->crc[i] ==
0x in function crc_sanity_checks, file igt_debugfs.c:833
(kms_cursor_crc:18385) igt-debugfs-WARNING: Suspicious CRC: it looks like the
CRC read back was from a register in a powered down well

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()

2018-04-05 Thread Ville Syrjälä

On Thu, Apr 05, 2018 at 10:15:57PM +0200, Thomas Hellstrom wrote:
> On 04/05/2018 09:50 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > Instead of plane->fb (which we're going to deprecate for atomic drivers)
> > we need to look at plane->state->fb. The maze of code leading to
> > vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
> > concluded that the calls originating from 
> > vmw_*_primary_plane_atomic_update()
> > all pass in the crtc which means we'll never end up in this branch
> > of the function. All other callers use drm_modeset_lock_all() somewhere
> > higher up, which means accessing plane->state is safe. We'll toss in
> > a lockdep assert to catch wrongdoers.
> >
> > Cc: Thomas Hellstrom 
> > Cc: Sinclair Yeh 
> > Cc: VMware Graphics 
> > Cc: Daniel Vetter 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 15 ---
> >   1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > index a2a796b4cc23..5a824125c231 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > @@ -2326,9 +2326,18 @@ int vmw_kms_helper_dirty(struct vmw_private 
> > *dev_priv,
> > } else {
> > list_for_each_entry(crtc, _priv->dev->mode_config.crtc_list,
> > head) {
> > -   if (crtc->primary->fb != >base)
> > -   continue;
> > -   units[num_units++] = vmw_crtc_to_du(crtc);
> > +   struct drm_plane *plane = crtc->primary;
> > +
> > +   /*
> > +* vmw_*_primary_plane_atomic_update() pass in the crtc,
> > +* and so don't end up here. All other callers use
> > +* drm_modeset_lock_all(), hence we can access the
> > +* plane state safely.
> > +*/
> > +   lockdep_assert_held(>mutex);
> > +
> I think we can remove the comment (it's a helper, so current users may 
> not be future users),
> but the lockdep assert should be OK.

OK.

> > +   if (plane->state->fb != >base)
> > +   units[num_units++] = vmw_crtc_to_du(crtc);
> 
> This doesn't seem to do what the original code did...

Whoops. Good catch.

> 
> > }
> > }
> >   
> 
> /Thomas
> 

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/7] drm/arc: Stop consulting plane->fb

2018-04-05 Thread Ville Syrjälä

On Thu, Apr 05, 2018 at 10:08:57PM +0200, Daniel Vetter wrote:
> On Thu, Apr 05, 2018 at 10:50:29PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > We want to stop using plane->fb with atomic driver, so stop looking at
> > it.
> > 
> > I have no idea what this code is trying to achieve. There is no
> > corresponding check in the enable path. Also since
> > arc_pgu_set_pxl_fmt() will anyway oops if there is no fb I'm going
> > to assuming that I can just remove the check entirely. There seems
> > to be a general shortage of .atomic_check() in this driver...
> 
> I think arcpgu is the perfect example of a small driver that _really_
> wants to use drm_simple_display_pipe_helper. Which would address the
> outright lack of any and all atomic_check code (beyond basic mode
> validation through mode_valid).
> 
> I also just noticed that it still has a bunch of the legacy hooks set,
> e.g. mode_set, mode_set_base are all no longer used in atomic.
> 
> I think the code won't be able to oops, since if there's no fb, we don't
> enable the plane (and it happily allows that), so should be all
> non-oopsing. Even with this check here removed.

arc_pgu_set_pxl_fmt() gets called from the .mode_set_nofb() hook
which I assume doesn't care about planes at all. So to me it looks like
it'll definitely oops.

> 
> Ofc the hw might get pissed at us in this case, but I can't tell that.
> Like I said, conversion to drm_simple_display_pipe_helper is probably the
> way to go.
> 
> Anyway, this patch here looks good, if you adjust the commit message to
> explain why it can't oops:
> 
> Reviewed-by: Daniel Vetter 
> 
> > 
> > Cc: Alexey Brodkin 
> > Cc: Daniel Vetter 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/arc/arcpgu_crtc.c | 3 ---
> >  1 file changed, 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
> > b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > index 16903dc7fe0d..c3349b8fb58b 100644
> > --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> > +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > @@ -136,9 +136,6 @@ static void arc_pgu_crtc_atomic_disable(struct drm_crtc 
> > *crtc,
> >  {
> > struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> >  
> > -   if (!crtc->primary->fb)
> > -   return;
> > -
> > clk_disable_unprepare(arcpgu->clk);
> > arc_pgu_write(arcpgu, ARCPGU_REG_CTRL,
> >   arc_pgu_read(arcpgu, ARCPGU_REG_CTRL) &
> > -- 
> > 2.16.1
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()

2018-04-05 Thread Thomas Hellstrom


On 04/05/2018 09:50 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Instead of plane->fb (which we're going to deprecate for atomic drivers)
we need to look at plane->state->fb. The maze of code leading to
vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
concluded that the calls originating from vmw_*_primary_plane_atomic_update()
all pass in the crtc which means we'll never end up in this branch
of the function. All other callers use drm_modeset_lock_all() somewhere
higher up, which means accessing plane->state is safe. We'll toss in
a lockdep assert to catch wrongdoers.

Cc: Thomas Hellstrom 
Cc: Sinclair Yeh 
Cc: VMware Graphics 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 15 ---
  1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index a2a796b4cc23..5a824125c231 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2326,9 +2326,18 @@ int vmw_kms_helper_dirty(struct vmw_private *dev_priv,
} else {
list_for_each_entry(crtc, _priv->dev->mode_config.crtc_list,
head) {
-   if (crtc->primary->fb != >base)
-   continue;
-   units[num_units++] = vmw_crtc_to_du(crtc);
+   struct drm_plane *plane = crtc->primary;
+
+   /*
+* vmw_*_primary_plane_atomic_update() pass in the crtc,
+* and so don't end up here. All other callers use
+* drm_modeset_lock_all(), hence we can access the
+* plane state safely.
+*/
+   lockdep_assert_held(>mutex);
+
I think we can remove the comment (it's a helper, so current users may 
not be future users),

but the lockdep assert should be OK.

+   if (plane->state->fb != >base)
+   units[num_units++] = vmw_crtc_to_du(crtc);


This doesn't seem to do what the original code did...


}
}
  


/Thomas


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

[Bug 105883] booting with kernel using amd-staging-drm-next on 2400G hangs

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

--- Comment #6 from Harry Wentland  ---
On Ubuntu the kernel log keeps appending to /var/log/kern.log, but that might
look different on different distros.

If you have a luxury of a second system you might be able to ssh into the Ryzen
system and run dmesg that way.

As for the options Edward mentioned, you can pass them to the kernel command
line. If you use grub for your bootloader you'd press 'e' on the selected
kernel and append " amdgpu.dpm=0 amdgpu.dc=1" at the end of the line that
starts with "linux". Alternatively you can append those to GRUB_CMDLINE_LINUX
in /etc/default/grub and run "sudo update-grub"

Keep in mind that this is how I'd do it on Ubuntu. There' might be a way to
pass these through /etc/modconf.d as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 2/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()


> 
> From: Ville Syrjälä 
> 
> Instead of looking at plane->fb let's look at the proper new
> plane state.
> 
> Not that the code makes a ton of sense. It's only going through the
> crtcs in the atomic state, so assuming not all of them are included
> we're not even calculating the total bandwidth here. Also we're
> not considering whether each crtc is actually enabled or not.
> 
> Cc: Thomas Hellstrom 
> Cc: Sinclair Yeh 
> Cc: VMware Graphics 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 6728c6247b4b..a2a796b4cc23 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -1536,9 +1536,13 @@ vmw_kms_atomic_check_modeset(struct
> drm_device *dev,
>   unsigned long requested_bb_mem = 0;
> 
>   if (dev_priv->active_display_unit ==
> vmw_du_screen_target) {
> - if (crtc->primary->fb) {
> - int cpp = crtc->primary->fb->pitches[0] /
> -   crtc->primary->fb->width;
> + struct drm_plane *plane = crtc->primary;
> + struct drm_plane_state *plane_state;
> +
> + plane_state =
> drm_atomic_get_new_plane_state(state, plane);
> +
> + if (plane_state && plane_state->fb) {
> + int cpp = plane_state->fb->format->cpp[0];

Hi Ville,

Thanks for the patch, recently I have done some refactoring of this code area
which is no yet sent to dri-devel. But the refactored code eliminated the need
to look the fb

https://cgit.freedesktop.org/mesa/vmwgfx/commit/?id=c54cdb6549b7d1c04ff61e639fc0e6de0dcc1ed6

There is still some future work to be done in this area. 

> 
>   requested_bb_mem += crtc->mode.hdisplay
> * cpp *
>   crtc->mode.vdisplay;
> --
> 2.16.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105880] [dc][kabini] Cannot find any crtc or sizes

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

--- Comment #7 from Chí-Thanh Christopher Nguyễn  ---
The notebook also has HDMI and VGA connectors, but I do not use them currently.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105880] [dc][kabini] Cannot find any crtc or sizes

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

--- Comment #6 from Chí-Thanh Christopher Nguyễn  ---
It is a notebook and I am using the internal LVDS panel.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/7] drm/arc: Stop consulting plane->fb

On Thu, Apr 05, 2018 at 10:50:29PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> We want to stop using plane->fb with atomic driver, so stop looking at
> it.
> 
> I have no idea what this code is trying to achieve. There is no
> corresponding check in the enable path. Also since
> arc_pgu_set_pxl_fmt() will anyway oops if there is no fb I'm going
> to assuming that I can just remove the check entirely. There seems
> to be a general shortage of .atomic_check() in this driver...

I think arcpgu is the perfect example of a small driver that _really_
wants to use drm_simple_display_pipe_helper. Which would address the
outright lack of any and all atomic_check code (beyond basic mode
validation through mode_valid).

I also just noticed that it still has a bunch of the legacy hooks set,
e.g. mode_set, mode_set_base are all no longer used in atomic.

I think the code won't be able to oops, since if there's no fb, we don't
enable the plane (and it happily allows that), so should be all
non-oopsing. Even with this check here removed.

Ofc the hw might get pissed at us in this case, but I can't tell that.
Like I said, conversion to drm_simple_display_pipe_helper is probably the
way to go.

Anyway, this patch here looks good, if you adjust the commit message to
explain why it can't oops:

Reviewed-by: Daniel Vetter 

> 
> Cc: Alexey Brodkin 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/arc/arcpgu_crtc.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
> b/drivers/gpu/drm/arc/arcpgu_crtc.c
> index 16903dc7fe0d..c3349b8fb58b 100644
> --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> @@ -136,9 +136,6 @@ static void arc_pgu_crtc_atomic_disable(struct drm_crtc 
> *crtc,
>  {
>   struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
>  
> - if (!crtc->primary->fb)
> - return;
> -
>   clk_disable_unprepare(arcpgu->clk);
>   arc_pgu_write(arcpgu, ARCPGU_REG_CTRL,
> arc_pgu_read(arcpgu, ARCPGU_REG_CTRL) &
> -- 
> 2.16.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105913] [IGT] igt@gem_shrink@pread Test assertion failure function gem_read, file ioctl_wrappers.c

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

Bug ID: 105913
   Summary: [IGT] igt@gem_shrink@pread Test assertion failure
function gem_read, file ioctl_wrappers.c
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ricardo.o.pe...@intel.com

Created attachment 138639
  --> https://bugs.freedesktop.org/attachment.cgi?id=138639=edit
dmesg and kern-logs

CNL QA System is failing the following test:

igt@gem_shrink@pread


Software Version:

IGT-Version: 1.22-g0721161 (x86_64) (Linux:
4.16.0-rc6-drm-intel-qa-ww12-commit-4db112a+ x86_64)
Using 62 processes and 128MiB per process
Stack trace:
  #0 [__igt_fail_assert+0x101]
  #1 [gem_read+0x91]
  #2 [+0x91]
child 0 died with signal 9, Killed
Subtest pread: FAIL (179.205s)

Stderr:

(gem_shrink:10628) ioctl-wrappers-CRITICAL: Test assertion failure function
gem_read, file ioctl_wrappers.c:387:
(gem_shrink:10628) ioctl-wrappers-CRITICAL: Failed assertion: __gem_read(fd,
handle, offset, buf, length) == 0
(gem_shrink:10628) ioctl-wrappers-CRITICAL: Last errno: 12, Cannot allocate
memory
(gem_shrink:10628) ioctl-wrappers-CRITICAL: error: -12 != 0
Subtest pread failed.
No log.

Dmesg:

[  260.304006] 1 and 0 pages still available in the bound and unbound GPU page
lists.
[  260.304085] kworker/u9:2 invoked oom-killer:
gfp_mask=0x14002c0(GFP_KERNEL|__GFP_NOWARN), nodemask=(null), order=0,
oom_score_adj=0
[  260.304090] CPU: 2 PID: 348 Comm: kworker/u9:2 Not tainted
4.16.0-rc6-drm-intel-qa-ww12-commit-4db112a+ #1
[  260.304091] Hardware name: Intel Corporation CannonLake Client
Platform/CannonLake Y LPDDR4 RVP, BIOS CNLSFWR1.R00.X124.B02.1802051422
02/05/2018
[  260.304101] Workqueue: rb_allocator iwl_pcie_rx_allocator_work [iwlwifi]
[  260.304102] Call Trace:
[  260.304109]  dump_stack+0x5c/0x85
[  260.304112]  dump_header+0x6b/0x27c
[  260.304115]  oom_kill_process+0x239/0x480
[  260.304116]  ? oom_badness+0xeb/0x160
[  260.304118]  out_of_memory+0x10f/0x480
[  260.304120]  __alloc_pages_slowpath+0xcdd/0xdb0
[  260.304123]  ? __update_load_avg_se.isra.38+0x1c1/0x1d0
[  260.304126]  __alloc_pages_nodemask+0x246/0x280
[  260.304131]  iwl_pcie_rx_alloc_page+0x25/0x90 [iwlwifi]
[  260.304137]  iwl_pcie_rx_allocator_work+0x128/0x370 [iwlwifi]
[  260.304141]  process_one_work+0x147/0x3c0
[  260.304143]  worker_thread+0x4a/0x440
[  260.304145]  kthread+0xf8/0x130
[  260.304147]  ? rescuer_thread+0x360/0x360
[  260.304148]  ? kthread_associate_blkcg+0x90/0x90
[  260.304151]  ret_from_fork+0x35/0x40
[  260.304152] Mem-Info:
[  260.304157] active_anon:6190 inactive_anon:1909516 isolated_anon:448
active_file:60 inactive_file:60 isolated_file:0
unevictable:0 dirty:0 writeback:0 unstable:0
slab_reclaimable:9750 slab_unreclaimable:25610
mapped:543 shmem:1910538 pagetables:3122 bounce:0
free:27808 free_pcp:90 free_cma:0
[  260.304160] Node 0 active_anon:24760kB inactive_anon:7638064kB
active_file:240kB inactive_file:240kB unevictable:0kB isolated(anon):1792kB
isolated(file):0kB mapped:2172kB dirty:0kB writeback:0kB shmem:7642152kB
shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
unstable:0kB all_unreclaimable? yes
[  260.304161] Node 0 DMA free:15884kB min:132kB low:164kB high:196kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:0kB writepending:0kB present:15992kB managed:15884kB mlocked:0kB
kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
free_cma:0kB
[  260.304165] lowmem_reserve[]: 0 747 7758 7758 7758
[  260.304167] Node 0 DMA32 free:34540kB min:6500kB low:8124kB high:9748kB
active_anon:260kB inactive_anon:767444kB active_file:4kB inactive_file:0kB
unevictable:0kB writepending:0kB present:872780kB managed:807024kB mlocked:0kB
kernel_stack:16kB pagetables:4kB bounce:0kB free_pcp:0kB local_pcp:0kB
free_cma:0kB
[  260.304171] lowmem_reserve[]: 0 0 7010 7010 7010
[  260.304173] Node 0 Normal free:60808kB min:60944kB low:76180kB high:91416kB
active_anon:24500kB inactive_anon:6870480kB active_file:236kB
inactive_file:240kB unevictable:0kB writepending:0kB present:7335936kB
managed:7182840kB mlocked:0kB kernel_stack:4224kB pagetables:12484kB bounce:0kB
free_pcp:360kB local_pcp:360kB free_cma:0kB
[  260.304177] lowmem_reserve[]: 0 0 0 0 0
[  260.304179] Node 0 DMA: 1*4kB (U) 1*8kB (U) 2*16kB (U) 1*32kB (U) 1*64kB (U)
1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) =
15884kB
[  260.304190] Node 0 DMA32: 15*4kB (UM) 22*8kB (UM) 24*16kB (UM) 26*32kB (UME)
21*64kB (UME) 16*128kB (UM) 18*256kB (UME) 17*512kB (UME) 4*1024kB (M) 6*2048kB
(M) 0*4096kB = 34540kB
[  260.304200] Node 0 Normal: 568*4kB (UME) 299*8kB (UM) 149*16kB (UME)

Re: [PATCH v2 05/13] drm/i915: Stop updating plane->fb/crtc

On Thu, Apr 5, 2018 at 7:02 PM, Ville Syrjala
 wrote:
> From: Ville Syrjälä 
>
> We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
> them.
>
> v2: Fix up the comment in intel_crtc_active() and
> nuke the rest of the stale comments (Daniel)
>
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> Reviewed-by: Maarten Lankhorst  #v1
> Reviewed-by: Daniel Vetter 

lgtm, ack on adding my r-b.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_atomic_plane.c | 12 
>  drivers/gpu/drm/i915/intel_display.c  |  7 +++
>  2 files changed, 3 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index 7481ce85746b..eb0579fb5e54 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -120,12 +120,6 @@ int intel_plane_atomic_check_with_state(const struct 
> intel_crtc_state *old_crtc_
> _state->base.adjusted_mode;
> int ret;
>
> -   /*
> -* Both crtc and plane->crtc could be NULL if we're updating a
> -* property while the plane is disabled.  We don't actually have
> -* anything driver-specific we need to test in that case, so
> -* just return success.
> -*/
> if (!intel_state->base.crtc && !old_plane_state->base.crtc)
> return 0;
>
> @@ -204,12 +198,6 @@ static int intel_plane_atomic_check(struct drm_plane 
> *plane,
> const struct drm_crtc_state *old_crtc_state;
> struct drm_crtc_state *new_crtc_state;
>
> -   /*
> -* Both crtc and plane->crtc could be NULL if we're updating a
> -* property while the plane is disabled.  We don't actually have
> -* anything driver-specific we need to test in that case, so
> -* just return success.
> -*/
> if (!crtc)
> return 0;
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 415fb8cf2cf4..469792fa098d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -979,7 +979,7 @@ bool intel_crtc_active(struct intel_crtc *crtc)
>  * We can ditch the adjusted_mode.crtc_clock check as soon
>  * as Haswell has gained clock readout/fastboot support.
>  *
> -* We can ditch the crtc->primary->fb check as soon as we can
> +* We can ditch the crtc->primary->state->fb check as soon as we can
>  * properly reconstruct framebuffers.
>  *
>  * FIXME: The intel_crtc->active here should be switched to
> @@ -2877,9 +2877,8 @@ intel_find_initial_plane_obj(struct intel_crtc 
> *intel_crtc,
> if (i915_gem_object_is_tiled(obj))
> dev_priv->preserve_bios_swizzle = true;
>
> -   drm_framebuffer_get(fb);
> -   primary->fb = primary->state->fb = fb;
> -   primary->crtc = primary->state->crtc = _crtc->base;
> +   plane_state->fb = fb;
> +   plane_state->crtc = _crtc->base;
>
> intel_set_plane_visible(to_intel_crtc_state(crtc_state),
> to_intel_plane_state(plane_state),
> --
> 2.16.1
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/9] drm/vmwgfx: Remove no-op prepare/cleanup_fb callbacks

On Thu, Apr 5, 2018 at 7:06 PM, Thomas Hellstrom  wrote:
> On 04/05/2018 05:44 PM, Daniel Vetter wrote:
>>
>> Less hits to go through when I git grep over all drivers. These
>> callbacks are optional.
>>
>> Signed-off-by: Daniel Vetter 
>> Cc: VMware Graphics 
>> Cc: Sinclair Yeh 
>> Cc: Thomas Hellstrom 
>> ---
>>   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 35
>> ---
>>   1 file changed, 35 deletions(-)
>
> Reviewed-by: Thomas Hellstrom 
>
> Will you take this upstream?

Thanks for the review. Assuming I get positive review/testing on the
other patches I can apply them all through drm-misc. Or you can pick
this one up, it's really just a quick aside while I tried to
understand what various drivers are doing in their prepare_fb hook and
around handling implicit/explicit sync. No dependencies with anything
else in this series.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/7] drm/vmwgfx: Stop using plane->fb in atomic_enable()

From: Ville Syrjälä 

Instead of looking at the (soon to be deprecated) plane->fb we'll
examing plane->state->fb instead. We can do this because
vmw_du_crtc_atomic_check() prevents us from enabling a crtc
without the primary plane also being enabled.

Due to that same reason, I'm actually not sure what the checks here are
for NULL fb. If we can't enable the crtc without an enabled plane
we should always have an fb. But I'll leave that for someone else
to figure out.

Cc: Thomas Hellstrom 
Cc: Sinclair Yeh 
Cc: VMware Graphics 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 90445bc590cb..152e96cb1c01 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -414,6 +414,7 @@ static void vmw_stdu_crtc_helper_prepare(struct drm_crtc 
*crtc)
 static void vmw_stdu_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
 {
+   struct drm_plane_state *plane_state = crtc->primary->state;
struct vmw_private *dev_priv;
struct vmw_screen_target_display_unit *stdu;
struct vmw_framebuffer *vfb;
@@ -422,7 +423,7 @@ static void vmw_stdu_crtc_atomic_enable(struct drm_crtc 
*crtc,
 
stdu = vmw_crtc_to_stdu(crtc);
dev_priv = vmw_priv(crtc->dev);
-   fb   = crtc->primary->fb;
+   fb   = plane_state->fb;
 
vfb = (fb) ? vmw_framebuffer_to_vfb(fb) : NULL;
 
-- 
2.16.1

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

[PATCH 5/7] drm/vmwgfx: Stop updating plane->fb

From: Ville Syrjälä 

We want to get rid of plane->fb on atomic drivers. Stop setting it.

Cc: Thomas Hellstrom 
Cc: Sinclair Yeh 
Cc: VMware Graphics 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 --
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 --
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 648f8127f65a..bbd3f19b1a0b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -525,8 +525,6 @@ vmw_sou_primary_plane_atomic_update(struct drm_plane *plane,
 */
if (ret != 0)
DRM_ERROR("Failed to update screen.\n");
-
-   crtc->primary->fb = plane->state->fb;
} else {
/*
 * When disabling a plane, CRTC and FB should always be NULL
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 67331f01ef32..90445bc590cb 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -1285,8 +1285,6 @@ vmw_stdu_primary_plane_atomic_update(struct drm_plane 
*plane,
 1, 1, NULL, crtc);
if (ret)
DRM_ERROR("Failed to update STDU.\n");
-
-   crtc->primary->fb = plane->state->fb;
} else {
crtc = old_state->crtc;
stdu = vmw_crtc_to_stdu(crtc);
-- 
2.16.1

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

[PATCH 7/7] drm/vmwgfx: Stop messing about with plane->fb/old_fb/crtc