Re: missing signoff on drm-intel-gt-next pull
On Wed, 11 Aug 2021, Joonas Lahtinen wrote:
> Quoting Dave Airlie (2021-08-11 06:48:39)
>> dim: db47fe727e1f ("drm/i915/step:
>> s/_revid_tbl/_revids"): committer Signed-off-by
>> missing.
>>
>> I'm not sure how much pain it is to fix that up, but
>> commit db47fe727e1fc516cf60fc9ab8299605ef3c2d54
>> Author: Anusha Srivatsa
>> Commit: Matt Roper
>>
>> drm/i915/step: s/_revid_tbl/_revids
>>
>> Simplify the stepping info array name.
>>
>> Cc: Jani Nikula
>> Signed-off-by: Anusha Srivatsa
>> Reviewed-by: Jani Nikula
>> Link:
>> https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-2-matthew.d.ro...@intel.com
>>
>> It's definitely missing an S-o-b by anyone who handled the patch.
>>
>> Let me know if it's insanely painful to fix that.
>
> Added you to the earlier mail thread that discussed the incident.
>
> There are now 277 patches on top of that patch, so means rebasing all of
> those and changing the hashes and trying to fixup all the Fixes:.
>
> So it's painful but not insanely so. Let me know if you want the tree
> rebased.
>
> Regards, Joonas
The commit came in via a topic branch also to drm-intel-next, so that's
another 168 commits to rebase. There's a lot of people working on top of
those trees, so I'm leaning on the very painful side.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH] drm/doc/rfc: drop lmem uapi section
Op 10-08-2021 om 16:27 schreef Daniel Vetter:
> We still have quite a bit more work to do with overall reworking of
> the ttm-based dg1 code, but the uapi stuff is now finalized with the
> latest pull. So remove that.
>
> This also fixes kerneldoc build warnings because we've included the
> same headers in two places, resulting in sphinx complaining about
> duplicated symbols. This regression has been created when we moved the
> uapi definitions to the real include/uapi/ folder in 727ecd99a4c9
> ("drm/doc/rfc: drop the i915_gem_lmem.h header")
>
> v2: Fix a few references that I missed, the htmldocs build took
> forever.
>
> Acked-by: Jason Ekstrand
> Tested-by Stephen Rothwell (v1)
> References:
> https://lore.kernel.org/dri-devel/20210603193242.1ce99...@canb.auug.org.au/
> Reported-by: Stephen Rothwell
> Cc: Stephen Rothwell
> Fixes: 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header")
> Cc: Matthew Auld
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/rfc/i915_gem_lmem.rst | 109
> 1 file changed, 109 deletions(-)
Acked-by: Maarten Lankhorst
> diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst
> b/Documentation/gpu/rfc/i915_gem_lmem.rst
> index 675ba8620d66..b421a3c1806e 100644
> --- a/Documentation/gpu/rfc/i915_gem_lmem.rst
> +++ b/Documentation/gpu/rfc/i915_gem_lmem.rst
> @@ -18,114 +18,5 @@ real, with all the uAPI bits is:
> * Route shmem backend over to TTM SYSTEM for discrete
> * TTM purgeable object support
> * Move i915 buddy allocator over to TTM
> -* MMAP ioctl mode(see `I915 MMAP`_)
> -* SET/GET ioctl caching(see `I915 SET/GET CACHING`_)
> * Send RFC(with mesa-dev on cc) for final sign off on the uAPI
> * Add pciid for DG1 and turn on uAPI for real
> -
> -New object placement and region query uAPI
> -==
> -Starting from DG1 we need to give userspace the ability to allocate buffers
> from
> -device local-memory. Currently the driver supports gem_create, which can
> place
> -buffers in system memory via shmem, and the usual assortment of other
> -interfaces, like dumb buffers and userptr.
> -
> -To support this new capability, while also providing a uAPI which will work
> -beyond just DG1, we propose to offer three new bits of uAPI:
> -
> -DRM_I915_QUERY_MEMORY_REGIONS
> --
> -New query ID which allows userspace to discover the list of supported memory
> -regions(like system-memory and local-memory) for a given device. We identify
> -each region with a class and instance pair, which should be unique. The class
> -here would be DEVICE or SYSTEM, and the instance would be zero, on platforms
> -like DG1.
> -
> -Side note: The class/instance design is borrowed from our existing engine
> uAPI,
> -where we describe every physical engine in terms of its class, and the
> -particular instance, since we can have more than one per class.
> -
> -In the future we also want to expose more information which can further
> -describe the capabilities of a region.
> -
> -.. kernel-doc:: include/uapi/drm/i915_drm.h
> -:functions: drm_i915_gem_memory_class
> drm_i915_gem_memory_class_instance drm_i915_memory_region_info
> drm_i915_query_memory_regions
> -
> -GEM_CREATE_EXT
> ---
> -New ioctl which is basically just gem_create but now allows userspace to
> provide
> -a chain of possible extensions. Note that if we don't provide any extensions
> and
> -set flags=0 then we get the exact same behaviour as gem_create.
> -
> -Side note: We also need to support PXP[1] in the near future, which is also
> -applicable to integrated platforms, and adds its own gem_create_ext
> extension,
> -which basically lets userspace mark a buffer as "protected".
> -
> -.. kernel-doc:: include/uapi/drm/i915_drm.h
> -:functions: drm_i915_gem_create_ext
> -
> -I915_GEM_CREATE_EXT_MEMORY_REGIONS
> ---
> -Implemented as an extension for gem_create_ext, we would now allow userspace
> to
> -optionally provide an immutable list of preferred placements at creation
> time,
> -in priority order, for a given buffer object. For the placements we expect
> -them each to use the class/instance encoding, as per the output of the
> regions
> -query. Having the list in priority order will be useful in the future when
> -placing an object, say during eviction.
> -
> -.. kernel-doc:: include/uapi/drm/i915_drm.h
> -:functions: drm_i915_gem_create_ext_memory_regions
> -
> -One fair criticism here is that this seems a little over-engineered[2]. If we
> -just consider DG1 then yes, a simple gem_create.flags or something is totally
> -all that's needed to tell the kernel to allocate the buffer in local-memory
> or
> -whatever. However looking to the future we need uAPI which can also support
> -upcoming Xe HP multi-tile architecture in a sane way, where there can be
> -multiple local-memory instances for a given device
[Bug 213935] AMDGPU Renoir crash/freeze while using vaapi with some video types in some apps - drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!
https://bugzilla.kernel.org/show_bug.cgi?id=213935 Fabian (fabisc...@mailbox.org) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |ANSWERED --- Comment #2 from Fabian (fabisc...@mailbox.org) --- You're right. I was able to test with a more up-2-date version and it wont happen anymore. (21.1.6). Sadly this doesn't fix my system freeze when using vaapi in firefox. But that seems to be another bug. Thank you for your help :) This one is resolved -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel tree
On Tue, 10 Aug 2021, Daniel Vetter wrote:
> On Mon, Aug 09, 2021 at 09:19:39AM -0700, Matt Roper wrote:
>> On Mon, Aug 09, 2021 at 04:05:59PM +0200, Daniel Vetter wrote:
>> > On Fri, Aug 06, 2021 at 09:36:56AM +0300, Joonas Lahtinen wrote:
>> > > Hi Matt,
>> > >
>> > > Always use the dim tooling when applying patches, it will do the right
>> > > thing with regards to adding the S-o-b.
>> >
>> > fd.o server rejects any pushes that haven't been done by dim, so how did
>> > this get through?
>>
>> I definitely used dim for all of these patches, but I'm not sure how I
>> lost my s-o-b on this one. Maybe when I edited the commit message after
>> 'dim extract-tags' I accidentally deleted an extra line when I removed
>> the extract-tags marker? It's the only patch where the line is missing,
>> so it's almost certainly human error on my part rather than something
>> dim did wrong.
>
> Yeah that's an expected failure model, and dim is supposed to catch that
> by rechecking for sobs when you push. See dim_push_branch ->
> checkpatch_commit_push_range in dim. So you can hand-edit stuff however
> you want, dim /should/ catch it when pushing. That it didn't is kinda
> confusing and I'd like to know why that slipped through.
One of the failures that happened here was that the commit was part of a
topic branch that was merged and pushed directly. All merges should
happen via pull requests on the list, and applied (preferrably by
maintainers or at least with their acks recorded on the merge) using dim
apply-pull which should also have the checks.
BR,
Jani.
>
>> > Matt, can you pls figure out and type up the patch to
>> > plug that hole?
>>
>> Are you referring to a patch for dim here? The i915 patch has already
>> landed, so we can't change its commit message now.
>
> Yeah dim, not drm-intel, that can't be fixed anymore because it's all
> baked in.
> -Daniel
>
>>
>>
>> Matt
>>
>> >
>> > Thanks, Daniel
>> >
>> > >
>> > > Regards, Joonas
>> > >
>> > > Quoting Stephen Rothwell (2021-07-15 07:18:54)
>> > > > Hi all,
>> > > >
>> > > > Commit
>> > > >
>> > > > db47fe727e1f ("drm/i915/step:
>> > > > s/_revid_tbl/_revids")
>> > > >
>> > > > is missing a Signed-off-by from its committer.
>> > > >
>> > > > --
>> > > > Cheers,
>> > > > Stephen Rothwell
>> >
>> > --
>> > Daniel Vetter
>> > Software Engineer, Intel Corporation
>> > http://blog.ffwll.ch
>>
>> --
>> Matt Roper
>> Graphics Software Engineer
>> VTT-OSGC Platform Enablement
>> Intel Corporation
>> (916) 356-2795
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v3 0/6] add fixes to pass DP Link Layer compliance test cases
On Thu, 05 Aug 2021, Kuogee Hsieh wrote: > add fixes to pass DP Link Layer compliance test cases Nitpick, please also include the approriate subject prefix to the cover letter, e.g. "drm/msm" or "drm/msm/dp". Helps with mail filtering. :) BR, Jani. > > Kuogee Hsieh (6): > drm/msm/dp: use dp_ctrl_off_link_stream during PHY compliance test run > drm/msm/dp: reduce link rate if failed at link training 1 > drm/msm/dp: reset aux controller after dp_aux_cmd_fifo_tx() failed. > drm/msm/dp: replug event is converted into an unplug followed by an > plug events > drm/msm/dp: return correct edid checksum after corrupted edid checksum > read > drm/msm/dp: do not end dp link training until video is ready > > drivers/gpu/drm/msm/dp/dp_aux.c | 3 + > drivers/gpu/drm/msm/dp/dp_ctrl.c| 137 > +++- > drivers/gpu/drm/msm/dp/dp_display.c | 14 ++-- > drivers/gpu/drm/msm/dp/dp_panel.c | 9 ++- > 4 files changed, 102 insertions(+), 61 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
RE: [RFC v1 0/4] drm: Add support for DRM_CAP_DEFERRED_OUT_FENCE capability
Hi Daniel, > On Tue, Aug 10, 2021 at 08:21:09AM +, Kasireddy, Vivek wrote: > > Hi Daniel, > > > > > On Fri, Aug 06, 2021 at 07:27:13AM +, Kasireddy, Vivek wrote: > > > > Hi Daniel, > > > > > > > > > > > > >>> The solution: > > > > > > > > >>> - To ensure full framerate, the Guest compositor has to > > > > > > > > >>> start it's repaint > > > cycle > > > > > > > (including > > > > > > > > >>> the 9 ms wait) when the Host compositor sends the frame > > > > > > > > >>> callback event > to > > > its > > > > > > > clients. > > > > > > > > >>> In order for this to happen, the dma-fence that the Guest > > > > > > > > >>> KMS waits on - > - > > > before > > > > > > > sending > > > > > > > > >>> pageflip completion -- cannot be tied to a > > > > > > > > >>> wl_buffer.release event. This > > > means > > > > > that, > > > > > > > the > > > > > > > > >>> Guest compositor has to be forced to use a new buffer for > > > > > > > > >>> its next > repaint > > > cycle > > > > > > > when it > > > > > > > > >>> gets a pageflip completion. > > > > > > > > >> > > > > > > > > >> Is that really the only solution? > > > > > > > > > [Kasireddy, Vivek] There are a few others I mentioned here: > > > > > > > > > https://gitlab.freedesktop.org/wayland/weston/-/issues/514#note_986572 > > > > > > > > > But I think none of them are as compelling as this one. > > > > > > > > > > > > > > > > > >> > > > > > > > > >> If we fix the event timestamps so that both guest and host > > > > > > > > >> use the same > > > > > > > > >> timestamp, but then the guest starts 5ms (or something like > > > > > > > > >> that) earlier, > > > > > > > > >> then things should work too? I.e. > > > > > > > > >> - host compositor starts at (previous_frametime + 9ms) > > > > > > > > >> - guest compositor starts at (previous_frametime + 4ms) > > > > > > > > >> > > > > > > > > >> Ofc this only works if the frametimes we hand out to both > > > > > > > > >> match > _exactly_ > > > > > > > > >> and are as high-precision as the ones on the host side. > > > > > > > > >> Which for many > gpu > > > > > > > > >> drivers at least is the case, and all the ones you care > > > > > > > > >> about for sure :-) > > > > > > > > >> > > > > > > > > >> But if the frametimes the guest receives are the no_vblank > > > > > > > > >> fake ones, > then > > > > > > > > >> they'll be all over the place and this carefully tuned > > > > > > > > >> low-latency redraw > > > > > > > > >> loop falls apart. Aside fromm the fact that without tuning > > > > > > > > >> the guests to > > > > > > > > >> be earlier than the hosts, you're guaranteed to miss every > > > > > > > > >> frame (except > > > > > > > > >> when the timing wobbliness in the guest is big enough by > > > > > > > > >> chance to make > > > > > > > > >> the deadline on the oddball frame). > > > > > > > > > [Kasireddy, Vivek] The Guest and Host use different event > > > > > > > > > timestamps as > we > > > don't > > > > > > > > > share these between the Guest and the Host. It does not seem > > > > > > > > > to be causing > any > > > > > other > > > > > > > > > problems so far but we did try the experiment you mentioned > > > > > > > > > (i.e., > adjusting > > > the > > > > > > > delays) > > > > > > > > > and it works. However, this patch series is meant to fix the > > > > > > > > > issue without > > > having to > > > > > > > tweak > > > > > > > > > anything (delays) because we can't do this for every > > > > > > > > > compositor out there. > > > > > > > > > > > > > > > > Maybe there could be a mechanism which allows the compositor in > > > > > > > > the guest > to > > > > > > > automatically adjust its repaint cycle as needed. > > > > > > > > > > > > > > > > This might even be possible without requiring changes in each > > > > > > > > compositor, > by > > > > > adjusting > > > > > > > the vertical blank periods in the guest to be aligned with the > > > > > > > host compositor > > > repaint > > > > > > > cycles. Not sure about that though. > > > > > > > > > > > > > > > > Even if not, both this series or making it possible to queue > > > > > > > > multiple flips > require > > > > > > > corresponding changes in each compositor as well to have any > > > > > > > effect. > > > > > > > > > > > > > > Yeah from all the discussions and tests done it sounds even with a > > > > > > > deeper queue we have big coordination issues between the guest and > > > > > > > host compositor (like the example that the guest is now rendering > > > > > > > at > > > > > > > 90fps instead of 60fps like the host). > > > > > > [Kasireddy, Vivek] Oh, I think you are referring to my reply to > > > > > > Gerd. That 90 > FPS vs > > > > > > 60 FPS problem is a completely different issue that is associated > > > > > > with Qemu > GTK UI > > > > > > backend. With the GTK backend -- and also with SDL backend -- we > > > > > > Blit the > Guest > > > > > > scanout FB onto one of the backbuffers managed by EGL. > > > > > > > > > > > > I am trying
RE: [RFC v1 0/4] drm: Add support for DRM_CAP_DEFERRED_OUT_FENCE capability
Hi Michel, > On 2021-08-10 10:30 a.m., Daniel Vetter wrote: > > On Tue, Aug 10, 2021 at 08:21:09AM +, Kasireddy, Vivek wrote: > >>> On Fri, Aug 06, 2021 at 07:27:13AM +, Kasireddy, Vivek wrote: > >>> > >>> Hence my gut feeling reaction that first we need to get these two > >>> compositors aligned in their timings, which propobably needs > >>> consistent vblank periods/timestamps across them (plus/minux > >>> guest/host clocksource fun ofc). Without this any of the next steps > >>> will simply not work because there's too much jitter by the time the > >>> guest compositor gets the flip completion events. > >> [Kasireddy, Vivek] Timings are not a problem and do not significantly > >> affect the repaint cycles from what I have seen so far. > >> > >>> > >>> Once we have solid events I think we should look into statically > >>> tuning guest/host compositor deadlines (like you've suggested in a > >>> bunch of places) to consisently make that deadline and hit 60 fps. > >>> With that we can then look into tuning this automatically and what to > >>> do when e.g. switching between copying and zero-copy on the host side > >>> (which might be needed in some cases) and how to handle all that. > >> [Kasireddy, Vivek] As I confirm here: > >>> https://gitlab.freedesktop.org/wayland/weston/- > > /issues/514#note_984065 > >> tweaking the deadlines works (i.e., we get 60 FPS) as we expect. > >> However, > >> I feel that this zero-copy solution I am trying to create should be > >> independent > >> of compositors' deadlines, delays or other scheduling parameters. > > > > That's not how compositors work nowadays. Your problem is that you don't > > have the guest/host compositor in sync. zero-copy only changes the > > timing, > > so it changes things from "rendering way too many frames" to "rendering > > way too few frames". > > > > We need to fix the timing/sync issue here first, not paper over it with > > hacks. > [Kasireddy, Vivek] What I really meant is that the zero-copy solution > should be > independent of the scheduling policies to ensure that it works with all > compositors. > IIUC, Weston for example uses the vblank/pageflip completion timestamp, > the > configurable repaint-window value, refresh-rate, etc to determine when > to start > its next repaint -- if there is any damage: > timespec_add_nsec(&output->next_repaint, stamp, refresh_nsec); > timespec_add_msec(&output->next_repaint, &output->next_repaint, > -compositor- > repaint_msec); > > And, in the case of VKMS, since there is no real hardware, the timestamp > is always: > now = ktime_get(); > send_vblank_event(dev, e, seq, now); > >>> > >>> vkms has been fixed since a while to fake high-precision timestamps like > >>> from a real display. > >> [Kasireddy, Vivek] IIUC, that might be one of the reasons why the Guest > >> does not need > >> to have the same timestamp as that of the Host -- to work as expected. > >> > >>> > When you say that the Guest/Host compositor need to stay in sync, are you > suggesting that we need to ensure that the vblank timestamp on the Host > needs to be shared and be the same on the Guest and a vblank/pageflip > completion for the Guest needs to be sent at exactly the same time it is > sent > on the Host? If yes, I'd say that we do send the pageflip completion to > Guest > around the same time a vblank is generated on the Host but it does not > help > because the Guest compositor would only have 9 ms to submit a new frame > and if the Host is running Mutter, the Guest would only have 2 ms. > (https://gitlab.freedesktop.org/wayland/weston/-/issues/514#note_984341) > >>> > >>> Not at the same time, but the same timestamp. And yes there is some fun > >>> there, which is I think the fundamental issue. Or at least some of the > >>> compositor experts seem to think so, and it makes sense to me. > >> [Kasireddy, Vivek] It is definitely possible that if the timestamp is > >> messed up, then > >> the Guest repaint cycle would be affected. However, I do not believe that > >> is the case > >> here given the debug and instrumentation data we collected and > >> scrutinized. Hopefully, > >> compositor experts could chime in to shed some light on this matter. > >> > >>> > > > > Only, and I really mean only, when that shows that it's simply > > impossible > > to hit 60fps with zero-copy and the guest/host fully aligned should we > > look into making the overall pipeline deeper. > [Kasireddy, Vivek] From all the experiments conducted so far and given > the > discussion associated with > https://gitlab.freedesktop.org/wayland/weston/- > /issues/514 > I think we have already established that in order for
Re: missing signoff on drm-intel-gt-next pull
On Wed, 11 Aug 2021 at 17:11, Jani Nikula wrote:
>
> On Wed, 11 Aug 2021, Joonas Lahtinen wrote:
> > Quoting Dave Airlie (2021-08-11 06:48:39)
> >> dim: db47fe727e1f ("drm/i915/step:
> >> s/_revid_tbl/_revids"): committer Signed-off-by
> >> missing.
> >>
> >> I'm not sure how much pain it is to fix that up, but
> >> commit db47fe727e1fc516cf60fc9ab8299605ef3c2d54
> >> Author: Anusha Srivatsa
> >> Commit: Matt Roper
> >>
> >> drm/i915/step: s/_revid_tbl/_revids
> >>
> >> Simplify the stepping info array name.
> >>
> >> Cc: Jani Nikula
> >> Signed-off-by: Anusha Srivatsa
> >> Reviewed-by: Jani Nikula
> >> Link:
> >> https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-2-matthew.d.ro...@intel.com
> >>
> >> It's definitely missing an S-o-b by anyone who handled the patch.
> >>
> >> Let me know if it's insanely painful to fix that.
> >
> > Added you to the earlier mail thread that discussed the incident.
> >
> > There are now 277 patches on top of that patch, so means rebasing all of
> > those and changing the hashes and trying to fixup all the Fixes:.
> >
> > So it's painful but not insanely so. Let me know if you want the tree
> > rebased.
> >
> > Regards, Joonas
>
> The commit came in via a topic branch also to drm-intel-next, so that's
> another 168 commits to rebase. There's a lot of people working on top of
> those trees, so I'm leaning on the very painful side.
Okay I think we can let that one slide. Having an S-o-b by someone in
the org on it is also technically enough for legal purposes anyways.
I'll finish the pulls from both trees tomorrow.
Thanks,
Dave.
Re: missing signoff on drm-intel-gt-next pull
On Wed, 11 Aug 2021, Dave Airlie wrote:
> On Wed, 11 Aug 2021 at 17:11, Jani Nikula wrote:
>>
>> On Wed, 11 Aug 2021, Joonas Lahtinen wrote:
>> > Quoting Dave Airlie (2021-08-11 06:48:39)
>> >> dim: db47fe727e1f ("drm/i915/step:
>> >> s/_revid_tbl/_revids"): committer Signed-off-by
>> >> missing.
>> >>
>> >> I'm not sure how much pain it is to fix that up, but
>> >> commit db47fe727e1fc516cf60fc9ab8299605ef3c2d54
>> >> Author: Anusha Srivatsa
>> >> Commit: Matt Roper
>> >>
>> >> drm/i915/step: s/_revid_tbl/_revids
>> >>
>> >> Simplify the stepping info array name.
>> >>
>> >> Cc: Jani Nikula
>> >> Signed-off-by: Anusha Srivatsa
>> >> Reviewed-by: Jani Nikula
>> >> Link:
>> >> https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-2-matthew.d.ro...@intel.com
>> >>
>> >> It's definitely missing an S-o-b by anyone who handled the patch.
>> >>
>> >> Let me know if it's insanely painful to fix that.
>> >
>> > Added you to the earlier mail thread that discussed the incident.
>> >
>> > There are now 277 patches on top of that patch, so means rebasing all of
>> > those and changing the hashes and trying to fixup all the Fixes:.
>> >
>> > So it's painful but not insanely so. Let me know if you want the tree
>> > rebased.
>> >
>> > Regards, Joonas
>>
>> The commit came in via a topic branch also to drm-intel-next, so that's
>> another 168 commits to rebase. There's a lot of people working on top of
>> those trees, so I'm leaning on the very painful side.
>
> Okay I think we can let that one slide. Having an S-o-b by someone in
> the org on it is also technically enough for legal purposes anyways.
>
> I'll finish the pulls from both trees tomorrow.
Thanks; in the mean time we'll need to eyeball the tooling to see if we
can plug some of these holes.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v4 02/14] vfio/mbochs: Fix missing error unwind of mbochs_used_mbytes
On Thu, Aug 05 2021, Jason Gunthorpe wrote:
> Convert mbochs to use an atomic scheme for this like mtty was changed
> into. The atomic fixes various race conditions with probing. Add the
> missing error unwind. Also add the missing kfree of mdev_state->pages.
>
> Fixes: 681c1615f891 ("vfio/mbochs: Convert to use vfio_register_group_dev()")
> Reported-by: Cornelia Huck
> Co-developed-by: Alex Williamson
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Jason Gunthorpe
> ---
> samples/vfio-mdev/mbochs.c | 24 +++-
> 1 file changed, 15 insertions(+), 9 deletions(-)
Reviewed-by: Cornelia Huck
[PATCH v2 1/9] dt-bindings: phy: mediatek: tphy: support type switch by pericfg
Add support type switch by pericfg register between USB3, PCIe, SATA, SGMII, this is used to replace the way through efuse or jumper. Reviewed-by: Rob Herring Signed-off-by: Chunfeng Yun --- v2: add reviewed-by Rob --- .../devicetree/bindings/phy/mediatek,tphy.yaml | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index 838852cb8527..9e6c0f43f1c6 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -201,6 +201,22 @@ patternProperties: Specify the flag to enable BC1.2 if support it type: boolean + mediatek,syscon-type: +$ref: /schemas/types.yaml#/definitions/phandle-array +maxItems: 1 +description: + A phandle to syscon used to access the register of type switch, + the field should always be 3 cells long. +items: + items: +- description: +The first cell represents a phandle to syscon +- description: +The second cell represents the register offset +- description: +The third cell represents the index of config segment + enum: [0, 1, 2, 3] + required: - reg - "#phy-cells" -- 2.25.1
[PATCH v2 6/9] phy: phy-mtk-ufs: use clock bulk to get clocks
Use clock bulk helpers to get/enable/disable clocks
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
drivers/phy/mediatek/phy-mtk-ufs.c | 44 --
1 file changed, 11 insertions(+), 33 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-ufs.c
b/drivers/phy/mediatek/phy-mtk-ufs.c
index 769b00b038d8..a6af06941203 100644
--- a/drivers/phy/mediatek/phy-mtk-ufs.c
+++ b/drivers/phy/mediatek/phy-mtk-ufs.c
@@ -31,11 +31,12 @@
#define FRC_CDR_ISO_EN BIT(19)
#define CDR_ISO_EN BIT(20)
+#define UFSPHY_CLKS_CNT2
+
struct ufs_mtk_phy {
struct device *dev;
void __iomem *mmio;
- struct clk *mp_clk;
- struct clk *unipro_clk;
+ struct clk_bulk_data clks[UFSPHY_CLKS_CNT];
};
static inline u32 mphy_readl(struct ufs_mtk_phy *phy, u32 reg)
@@ -74,20 +75,11 @@ static struct ufs_mtk_phy *get_ufs_mtk_phy(struct phy
*generic_phy)
static int ufs_mtk_phy_clk_init(struct ufs_mtk_phy *phy)
{
struct device *dev = phy->dev;
+ struct clk_bulk_data *clks = phy->clks;
- phy->unipro_clk = devm_clk_get(dev, "unipro");
- if (IS_ERR(phy->unipro_clk)) {
- dev_err(dev, "failed to get clock: unipro");
- return PTR_ERR(phy->unipro_clk);
- }
-
- phy->mp_clk = devm_clk_get(dev, "mp");
- if (IS_ERR(phy->mp_clk)) {
- dev_err(dev, "failed to get clock: mp");
- return PTR_ERR(phy->mp_clk);
- }
-
- return 0;
+ clks[0].id = "unipro";
+ clks[1].id = "mp";
+ return devm_clk_bulk_get(dev, UFSPHY_CLKS_CNT, clks);
}
static void ufs_mtk_phy_set_active(struct ufs_mtk_phy *phy)
@@ -150,26 +142,13 @@ static int ufs_mtk_phy_power_on(struct phy *generic_phy)
struct ufs_mtk_phy *phy = get_ufs_mtk_phy(generic_phy);
int ret;
- ret = clk_prepare_enable(phy->unipro_clk);
- if (ret) {
- dev_err(phy->dev, "unipro_clk enable failed %d\n", ret);
- goto out;
- }
-
- ret = clk_prepare_enable(phy->mp_clk);
- if (ret) {
- dev_err(phy->dev, "mp_clk enable failed %d\n", ret);
- goto out_unprepare_unipro_clk;
- }
+ ret = clk_bulk_prepare_enable(UFSPHY_CLKS_CNT, phy->clks);
+ if (ret)
+ return ret;
ufs_mtk_phy_set_active(phy);
return 0;
-
-out_unprepare_unipro_clk:
- clk_disable_unprepare(phy->unipro_clk);
-out:
- return ret;
}
static int ufs_mtk_phy_power_off(struct phy *generic_phy)
@@ -178,8 +157,7 @@ static int ufs_mtk_phy_power_off(struct phy *generic_phy)
ufs_mtk_phy_set_deep_hibern(phy);
- clk_disable_unprepare(phy->unipro_clk);
- clk_disable_unprepare(phy->mp_clk);
+ clk_bulk_disable_unprepare(UFSPHY_CLKS_CNT, phy->clks);
return 0;
}
--
2.25.1
[PATCH v2 3/9] phy: phy-mtk-tphy: support type switch by pericfg
Add support type switch between USB3, PCIe, SATA and SGMII by
pericfg register, this is used to take the place of efuse or
jumper.
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
drivers/phy/mediatek/phy-mtk-tphy.c | 84 -
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c
b/drivers/phy/mediatek/phy-mtk-tphy.c
index 3259210f08a1..a6502058a1a5 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -10,11 +10,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
/* version V1 sub-banks offset base address */
/* banks shared by multiple phys */
@@ -280,6 +282,14 @@
#define RG_CDR_BIRLTD0_GEN3_MSKGENMASK(4, 0)
#define RG_CDR_BIRLTD0_GEN3_VAL(x) (0x1f & (x))
+/* PHY switch between pcie/usb3/sgmii/sata */
+#define USB_PHY_SWITCH_CTRL0x0
+#define RG_PHY_SW_TYPE GENMASK(3, 0)
+#define RG_PHY_SW_PCIE 0x0
+#define RG_PHY_SW_USB3 0x1
+#define RG_PHY_SW_SGMII0x2
+#define RG_PHY_SW_SATA 0x3
+
#define TPHY_CLKS_CNT 2
enum mtk_phy_version {
@@ -322,7 +332,10 @@ struct mtk_phy_instance {
};
struct clk_bulk_data clks[TPHY_CLKS_CNT];
u32 index;
- u8 type;
+ u32 type;
+ struct regmap *type_sw;
+ u32 type_sw_reg;
+ u32 type_sw_index;
int eye_src;
int eye_vrt;
int eye_term;
@@ -969,6 +982,64 @@ static void u2_phy_props_set(struct mtk_tphy *tphy,
}
}
+/* type switch for usb3/pcie/sgmii/sata */
+static int phy_type_syscon_get(struct mtk_phy_instance *instance,
+ struct device_node *dn)
+{
+ struct of_phandle_args args;
+ int ret;
+
+ /* type switch function is optional */
+ if (!of_property_read_bool(dn, "mediatek,syscon-type"))
+ return 0;
+
+ ret = of_parse_phandle_with_fixed_args(dn, "mediatek,syscon-type",
+ 2, 0, &args);
+ if (ret)
+ return ret;
+
+ instance->type_sw_reg = args.args[0];
+ instance->type_sw_index = args.args[1] & 0x3; /* <=3 */
+ instance->type_sw = syscon_node_to_regmap(args.np);
+ of_node_put(args.np);
+ dev_info(&instance->phy->dev, "type_sw - reg %#x, index %d\n",
+instance->type_sw_reg, instance->type_sw_index);
+
+ return PTR_ERR_OR_ZERO(instance->type_sw);
+}
+
+static int phy_type_set(struct mtk_phy_instance *instance)
+{
+ int type;
+ u32 mask;
+
+ if (!instance->type_sw)
+ return 0;
+
+ switch (instance->type) {
+ case PHY_TYPE_USB3:
+ type = RG_PHY_SW_USB3;
+ break;
+ case PHY_TYPE_PCIE:
+ type = RG_PHY_SW_PCIE;
+ break;
+ case PHY_TYPE_SGMII:
+ type = RG_PHY_SW_SGMII;
+ break;
+ case PHY_TYPE_SATA:
+ type = RG_PHY_SW_SATA;
+ break;
+ case PHY_TYPE_USB2:
+ default:
+ return 0;
+ }
+
+ mask = RG_PHY_SW_TYPE << (instance->type_sw_index * BITS_PER_BYTE);
+ regmap_update_bits(instance->type_sw, instance->type_sw_reg, mask,
type);
+
+ return 0;
+}
+
static int mtk_phy_init(struct phy *phy)
{
struct mtk_phy_instance *instance = phy_get_drvdata(phy);
@@ -993,6 +1064,9 @@ static int mtk_phy_init(struct phy *phy)
case PHY_TYPE_SATA:
sata_phy_instance_init(tphy, instance);
break;
+ case PHY_TYPE_SGMII:
+ /* nothing to do, only used to set type */
+ break;
default:
dev_err(tphy->dev, "incompatible PHY type\n");
clk_bulk_disable_unprepare(TPHY_CLKS_CNT, instance->clks);
@@ -1081,7 +1155,8 @@ static struct phy *mtk_phy_xlate(struct device *dev,
if (!(instance->type == PHY_TYPE_USB2 ||
instance->type == PHY_TYPE_USB3 ||
instance->type == PHY_TYPE_PCIE ||
- instance->type == PHY_TYPE_SATA)) {
+ instance->type == PHY_TYPE_SATA ||
+ instance->type == PHY_TYPE_SGMII)) {
dev_err(dev, "unsupported device type: %d\n", instance->type);
return ERR_PTR(-EINVAL);
}
@@ -1100,6 +1175,7 @@ static struct phy *mtk_phy_xlate(struct device *dev,
}
phy_parse_property(tphy, instance);
+ phy_type_set(instance);
return instance->phy;
}
@@ -1244,6 +1320,10 @@ static int mtk_tphy_probe(struct platform_device *pdev)
retval = devm_clk_bulk_get_optional(&phy->dev, TPHY_CLKS_CNT,
clks);
if (retval)
goto put_child;
+
+ retval = phy_type_syscon_get(instance, child_np);
+ if (retval)
+ goto put_child;
}
[PATCH v2 5/9] phy: phy-mtk-tphy: remove error log of ioremap failure
devm_ioremap_resource() will print log if error happens.
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
drivers/phy/mediatek/phy-mtk-tphy.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c
b/drivers/phy/mediatek/phy-mtk-tphy.c
index 9d4b34298137..cdcef865fe9e 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -1306,7 +1306,6 @@ static int mtk_tphy_probe(struct platform_device *pdev)
instance->port_base = devm_ioremap_resource(subdev, &res);
if (IS_ERR(instance->port_base)) {
- dev_err(subdev, "failed to remap phy regs\n");
retval = PTR_ERR(instance->port_base);
goto put_child;
}
--
2.25.1
[PATCH v2 9/9] phy: phy-mtk-mipi-dsi: convert to devm_platform_ioremap_resource
Use devm_platform_ioremap_resource to simplify code
Acked-by: Chun-Kuang Hu
Signed-off-by: Chunfeng Yun
---
v2: add acked-by CK
---
drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
index 61c942fbf4a1..28ad9403c441 100644
--- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
@@ -130,7 +130,6 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct mtk_mipi_tx *mipi_tx;
- struct resource *mem;
const char *ref_clk_name;
struct clk *ref_clk;
struct clk_init_data clk_init = {
@@ -148,11 +147,9 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
mipi_tx->driver_data = of_device_get_match_data(dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- mipi_tx->regs = devm_ioremap_resource(dev, mem);
- if (IS_ERR(mipi_tx->regs)) {
+ mipi_tx->regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(mipi_tx->regs))
return PTR_ERR(mipi_tx->regs);
- }
ref_clk = devm_clk_get(dev, NULL);
if (IS_ERR(ref_clk)) {
--
2.25.1
[PATCH v2 7/9] phy: phy-mtk-hdmi: convert to devm_platform_ioremap_resource
Use devm_platform_ioremap_resource to simplify code
Acked-by: Chun-Kuang Hu
Signed-off-by: Chunfeng Yun
---
v2: add acked-by CK
---
drivers/phy/mediatek/phy-mtk-hdmi.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.c
b/drivers/phy/mediatek/phy-mtk-hdmi.c
index 8ad8f717ef43..5fb4217fb8e0 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
@@ -100,7 +100,6 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct mtk_hdmi_phy *hdmi_phy;
- struct resource *mem;
struct clk *ref_clk;
const char *ref_clk_name;
struct clk_init_data clk_init = {
@@ -116,11 +115,9 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
if (!hdmi_phy)
return -ENOMEM;
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- hdmi_phy->regs = devm_ioremap_resource(dev, mem);
- if (IS_ERR(hdmi_phy->regs)) {
+ hdmi_phy->regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(hdmi_phy->regs))
return PTR_ERR(hdmi_phy->regs);
- }
ref_clk = devm_clk_get(dev, "pll_ref");
if (IS_ERR(ref_clk)) {
--
2.25.1
[PATCH v2 2/9] phy: phy-mtk-tphy: use clock bulk to get clocks
Use clock bulk helpers to get/enable/disable clocks
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
drivers/phy/mediatek/phy-mtk-tphy.c | 43 +
1 file changed, 13 insertions(+), 30 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c
b/drivers/phy/mediatek/phy-mtk-tphy.c
index 33000b38fd1b..3259210f08a1 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -280,6 +280,8 @@
#define RG_CDR_BIRLTD0_GEN3_MSKGENMASK(4, 0)
#define RG_CDR_BIRLTD0_GEN3_VAL(x) (0x1f & (x))
+#define TPHY_CLKS_CNT 2
+
enum mtk_phy_version {
MTK_PHY_V1 = 1,
MTK_PHY_V2,
@@ -318,8 +320,7 @@ struct mtk_phy_instance {
struct u2phy_banks u2_banks;
struct u3phy_banks u3_banks;
};
- struct clk *ref_clk;/* reference clock of (digital) phy */
- struct clk *da_ref_clk; /* reference clock of analog phy */
+ struct clk_bulk_data clks[TPHY_CLKS_CNT];
u32 index;
u8 type;
int eye_src;
@@ -974,18 +975,9 @@ static int mtk_phy_init(struct phy *phy)
struct mtk_tphy *tphy = dev_get_drvdata(phy->dev.parent);
int ret;
- ret = clk_prepare_enable(instance->ref_clk);
- if (ret) {
- dev_err(tphy->dev, "failed to enable ref_clk\n");
+ ret = clk_bulk_prepare_enable(TPHY_CLKS_CNT, instance->clks);
+ if (ret)
return ret;
- }
-
- ret = clk_prepare_enable(instance->da_ref_clk);
- if (ret) {
- dev_err(tphy->dev, "failed to enable da_ref\n");
- clk_disable_unprepare(instance->ref_clk);
- return ret;
- }
switch (instance->type) {
case PHY_TYPE_USB2:
@@ -1003,8 +995,7 @@ static int mtk_phy_init(struct phy *phy)
break;
default:
dev_err(tphy->dev, "incompatible PHY type\n");
- clk_disable_unprepare(instance->ref_clk);
- clk_disable_unprepare(instance->da_ref_clk);
+ clk_bulk_disable_unprepare(TPHY_CLKS_CNT, instance->clks);
return -EINVAL;
}
@@ -1047,8 +1038,7 @@ static int mtk_phy_exit(struct phy *phy)
if (instance->type == PHY_TYPE_USB2)
u2_phy_instance_exit(tphy, instance);
- clk_disable_unprepare(instance->ref_clk);
- clk_disable_unprepare(instance->da_ref_clk);
+ clk_bulk_disable_unprepare(TPHY_CLKS_CNT, instance->clks);
return 0;
}
@@ -1211,6 +1201,7 @@ static int mtk_tphy_probe(struct platform_device *pdev)
port = 0;
for_each_child_of_node(np, child_np) {
struct mtk_phy_instance *instance;
+ struct clk_bulk_data *clks;
struct phy *phy;
instance = devm_kzalloc(dev, sizeof(*instance), GFP_KERNEL);
@@ -1247,20 +1238,12 @@ static int mtk_tphy_probe(struct platform_device *pdev)
phy_set_drvdata(phy, instance);
port++;
- instance->ref_clk = devm_clk_get_optional(&phy->dev, "ref");
- if (IS_ERR(instance->ref_clk)) {
- dev_err(dev, "failed to get ref_clk(id-%d)\n", port);
- retval = PTR_ERR(instance->ref_clk);
+ clks = instance->clks;
+ clks[0].id = "ref"; /* digital (& analog) clock */
+ clks[1].id = "da_ref"; /* analog clock */
+ retval = devm_clk_bulk_get_optional(&phy->dev, TPHY_CLKS_CNT,
clks);
+ if (retval)
goto put_child;
- }
-
- instance->da_ref_clk =
- devm_clk_get_optional(&phy->dev, "da_ref");
- if (IS_ERR(instance->da_ref_clk)) {
- dev_err(dev, "failed to get da_ref_clk(id-%d)\n", port);
- retval = PTR_ERR(instance->da_ref_clk);
- goto put_child;
- }
}
provider = devm_of_phy_provider_register(dev, mtk_phy_xlate);
--
2.25.1
[PATCH v2 8/9] phy: phy-mtk-mipi-dsi: remove dummy assignment of error number
Return the error number directly without assignment
Acked-by: Chun-Kuang Hu
Signed-off-by: Chunfeng Yun
---
v2: add acked-by CK
---
drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
index 01cf31633019..61c942fbf4a1 100644
--- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
@@ -203,10 +203,8 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
phy_set_drvdata(phy, mipi_tx);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
- if (IS_ERR(phy_provider)) {
- ret = PTR_ERR(phy_provider);
- return ret;
- }
+ if (IS_ERR(phy_provider))
+ return PTR_ERR(phy_provider);
mipi_tx->dev = dev;
--
2.25.1
[PATCH v2 4/9] phy: phy-mtk-tphy: print error log using child device
Print error log using child devices instead of parent device.
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
drivers/phy/mediatek/phy-mtk-tphy.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c
b/drivers/phy/mediatek/phy-mtk-tphy.c
index a6502058a1a5..9d4b34298137 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -1278,6 +1278,7 @@ static int mtk_tphy_probe(struct platform_device *pdev)
for_each_child_of_node(np, child_np) {
struct mtk_phy_instance *instance;
struct clk_bulk_data *clks;
+ struct device *subdev;
struct phy *phy;
instance = devm_kzalloc(dev, sizeof(*instance), GFP_KERNEL);
@@ -1295,16 +1296,17 @@ static int mtk_tphy_probe(struct platform_device *pdev)
goto put_child;
}
+ subdev = &phy->dev;
retval = of_address_to_resource(child_np, 0, &res);
if (retval) {
- dev_err(dev, "failed to get address resource(id-%d)\n",
+ dev_err(subdev, "failed to get address
resource(id-%d)\n",
port);
goto put_child;
}
- instance->port_base = devm_ioremap_resource(&phy->dev, &res);
+ instance->port_base = devm_ioremap_resource(subdev, &res);
if (IS_ERR(instance->port_base)) {
- dev_err(dev, "failed to remap phy regs\n");
+ dev_err(subdev, "failed to remap phy regs\n");
retval = PTR_ERR(instance->port_base);
goto put_child;
}
@@ -1317,7 +1319,7 @@ static int mtk_tphy_probe(struct platform_device *pdev)
clks = instance->clks;
clks[0].id = "ref"; /* digital (& analog) clock */
clks[1].id = "da_ref"; /* analog clock */
- retval = devm_clk_bulk_get_optional(&phy->dev, TPHY_CLKS_CNT,
clks);
+ retval = devm_clk_bulk_get_optional(subdev, TPHY_CLKS_CNT,
clks);
if (retval)
goto put_child;
--
2.25.1
Re: [PATCH 1/1] drm: ttm: Don't bail from ttm_global_init if debugfs_create_dir fails
Tested-by: Huacai Chen
On Wed, Aug 11, 2021 at 6:42 AM Dan Moulding wrote:
>
> In 69de4421bb4c ("drm/ttm: Initialize debugfs from
> ttm_global_init()"), ttm_global_init was changed so that if creation
> of the debugfs global root directory fails, ttm_global_init will bail
> out early and return an error, leading to initialization failure of
> DRM drivers. However, not every system will be using debugfs. On such
> a system, debugfs directory creation can be expected to fail, but DRM
> drivers must still be usable. This changes it so that if creation of
> TTM's debugfs root directory fails, then no biggie: keep calm and
> carry on.
>
> Fixes: 69de4421bb4c ("drm/ttm: Initialize debugfs from ttm_global_init()")
> Signed-off-by: Dan Moulding
> ---
> drivers/gpu/drm/ttm/ttm_device.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_device.c
> b/drivers/gpu/drm/ttm/ttm_device.c
> index 74e3b460132b..2df59b3c2ea1 100644
> --- a/drivers/gpu/drm/ttm/ttm_device.c
> +++ b/drivers/gpu/drm/ttm/ttm_device.c
> @@ -78,9 +78,7 @@ static int ttm_global_init(void)
>
> ttm_debugfs_root = debugfs_create_dir("ttm", NULL);
> if (IS_ERR(ttm_debugfs_root)) {
> - ret = PTR_ERR(ttm_debugfs_root);
> ttm_debugfs_root = NULL;
> - goto out;
> }
>
> /* Limit the number of pages in the pool to about 50% of the total
> --
> 2.31.1
>
Re: [PATCH v4 08/14] vfio/pci: Move to the device set infrastructure
On Thu, Aug 05 2021, Jason Gunthorpe wrote: > From: Yishai Hadas > > PCI wants to have the usual open/close_device() logic with the slight > twist that the open/close_device() must be done under a singelton lock > shared by all of the vfio_devices that are in the PCI "reset group". > > The reset group, and thus the device set, is determined by what devices > pci_reset_bus() touches, which is either the entire bus or only the slot. > > Rely on the core code to do everything reflck was doing and delete reflck > entirely. > > Signed-off-by: Yishai Hadas > Reviewed-by: Christoph Hellwig > Signed-off-by: Jason Gunthorpe > --- > drivers/vfio/pci/vfio_pci.c | 162 +++- > drivers/vfio/pci/vfio_pci_private.h | 7 -- > 2 files changed, 37 insertions(+), 132 deletions(-) Reviewed-by: Cornelia Huck
Re: How to obtain a drm lease from X for overlay planes as well as a primary plane?
On Tue, Aug 10, 2021 at 05:57:31PM +0100, John Cox wrote: > Hi all > > I am on a Raspberry Pi, I want to display fullscreen video and have a > couple of overlay planes to display controls / subtitles etc. The h/w > can certainly do this. I need to be able to do this from a starting > point where X is running. > > I can successfully find X's output & crtc and grab that using > xcb_randr_create_lease and use that handle to display video. So far so > good. But I also want to have overlay planes for subtitles etc. The > handle I've got from the lease only seems to have a PRIMARY & a CURSOR > plane attached so I can't get anything there. I think X just gives you a legacy lease for the crtc, and the kernel automatically adds the primary plane and cursor plane (if they exist) to that lease. Unless X is patched to enable plane support and add those all explicitly to the lease I don't think there's a way for that. For wayland this is still in the works, so might be good if you check there that your use-case is properly supported. Protocol MR is here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/67 > How should I be going about getting some more planes to use for > overlays? Pointers to documentation / examples gratefully received - so > far my google-foo has failed to find anything that works. > > I'm sorry if this is the wrong place to ask, but if there is a better > place please say and I'll go there. > > Many thanks > > John Cox -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel tree
On Wed, Aug 11, 2021 at 10:16:41AM +0300, Jani Nikula wrote:
> On Tue, 10 Aug 2021, Daniel Vetter wrote:
> > On Mon, Aug 09, 2021 at 09:19:39AM -0700, Matt Roper wrote:
> >> On Mon, Aug 09, 2021 at 04:05:59PM +0200, Daniel Vetter wrote:
> >> > On Fri, Aug 06, 2021 at 09:36:56AM +0300, Joonas Lahtinen wrote:
> >> > > Hi Matt,
> >> > >
> >> > > Always use the dim tooling when applying patches, it will do the right
> >> > > thing with regards to adding the S-o-b.
> >> >
> >> > fd.o server rejects any pushes that haven't been done by dim, so how did
> >> > this get through?
> >>
> >> I definitely used dim for all of these patches, but I'm not sure how I
> >> lost my s-o-b on this one. Maybe when I edited the commit message after
> >> 'dim extract-tags' I accidentally deleted an extra line when I removed
> >> the extract-tags marker? It's the only patch where the line is missing,
> >> so it's almost certainly human error on my part rather than something
> >> dim did wrong.
> >
> > Yeah that's an expected failure model, and dim is supposed to catch that
> > by rechecking for sobs when you push. See dim_push_branch ->
> > checkpatch_commit_push_range in dim. So you can hand-edit stuff however
> > you want, dim /should/ catch it when pushing. That it didn't is kinda
> > confusing and I'd like to know why that slipped through.
>
> One of the failures that happened here was that the commit was part of a
> topic branch that was merged and pushed directly. All merges should
> happen via pull requests on the list, and applied (preferrably by
> maintainers or at least with their acks recorded on the merge) using dim
> apply-pull which should also have the checks.
Ah yes if the merge is applied directly instead of using apply-pull then
that's not good. I guess that's why we have the rule that only maintainers
should handle topic branches ...
Not sure how we can fix this in dim? Maybe a check whether the patches
your pushing contain a merge commit, which prompts an additional query
like
"Merge commits should only be done by repo maintainers, not committers.
Confirm that you are a maintainer of $repo?"
It's not the first time this slipped through and caused some fun. Similar
to how we have the confirmation check if you push a lot of patches.
Thoughts?
-Daniel
>
>
> BR,
> Jani.
>
> >
> >> > Matt, can you pls figure out and type up the patch to
> >> > plug that hole?
> >>
> >> Are you referring to a patch for dim here? The i915 patch has already
> >> landed, so we can't change its commit message now.
> >
> > Yeah dim, not drm-intel, that can't be fixed anymore because it's all
> > baked in.
> > -Daniel
> >
> >>
> >>
> >> Matt
> >>
> >> >
> >> > Thanks, Daniel
> >> >
> >> > >
> >> > > Regards, Joonas
> >> > >
> >> > > Quoting Stephen Rothwell (2021-07-15 07:18:54)
> >> > > > Hi all,
> >> > > >
> >> > > > Commit
> >> > > >
> >> > > > db47fe727e1f ("drm/i915/step:
> >> > > > s/_revid_tbl/_revids")
> >> > > >
> >> > > > is missing a Signed-off-by from its committer.
> >> > > >
> >> > > > --
> >> > > > Cheers,
> >> > > > Stephen Rothwell
> >> >
> >> > --
> >> > Daniel Vetter
> >> > Software Engineer, Intel Corporation
> >> > http://blog.ffwll.ch
> >>
> >> --
> >> Matt Roper
> >> Graphics Software Engineer
> >> VTT-OSGC Platform Enablement
> >> Intel Corporation
> >> (916) 356-2795
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
RE: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device
[Public] > -Original Message- > From: Lyude Paul > Sent: Wednesday, August 11, 2021 4:45 AM > To: Lin, Wayne ; dri-devel@lists.freedesktop.org > Cc: Kazlauskas, Nicholas ; Wentland, Harry > ; Zuo, Jerry > ; Wu, Hersen ; Juston Li > ; Imre Deak ; > Ville Syrjälä ; Daniel Vetter > ; Sean Paul ; Maarten Lankhorst > ; Maxime Ripard ; > Thomas Zimmermann ; > David Airlie ; Daniel Vetter ; Deucher, > Alexander ; Siqueira, > Rodrigo ; Pillai, Aurabindo > ; Eryk Brol ; Bas > Nieuwenhuizen ; Cornij, Nikola > ; Jani Nikula ; Manasi > Navare ; Ankit Nautiyal > ; José Roberto de Souza ; > Sean Paul ; Ben Skeggs ; > sta...@vger.kernel.org > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end > device > > On Wed, 2021-08-04 at 07:13 +, Lin, Wayne wrote: > > [Public] > > > > > -Original Message- > > > From: Lyude Paul > > > Sent: Wednesday, August 4, 2021 8:09 AM > > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org > > > Cc: Kazlauskas, Nicholas ; Wentland, > > > Harry < harry.wentl...@amd.com>; Zuo, Jerry ; Wu, > > > Hersen ; Juston Li < juston...@intel.com>; Imre > > > Deak ; Ville Syrjälä > > > ; Wentland, Harry < > > > harry.wentl...@amd.com>; Daniel Vetter ; > > > Sean Paul ; Maarten Lankhorst < > > > maarten.lankho...@linux.intel.com>; Maxime Ripard > > > ; Thomas Zimmermann ; David > > > Airlie ; Daniel Vetter ; Deucher, > > > Alexander ; Siqueira, Rodrigo < > > > rodrigo.sique...@amd.com>; Pillai, Aurabindo > > > ; Eryk Brol ; Bas > > > Nieuwenhuizen ; Cornij, Nikola > > > ; Jani Nikula ; Manasi > > > Navare ; Ankit Nautiyal > > > ; José Roberto de Souza > > > ; Sean Paul ; Ben > > > Skeggs ; sta...@vger.kernel.org > > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for > > > connected end device > > > > > > On Tue, 2021-08-03 at 19:58 -0400, Lyude Paul wrote: > > > > On Wed, 2021-07-21 at 00:03 +0800, Wayne Lin wrote: > > > > > [Why] > > > > > Currently, we will create connectors for all output ports no > > > > > matter it's connected or not. However, in MST, we can only > > > > > determine whether an output port really stands for a "connector" > > > > > till it is connected and check its peer device type as an end device. > > > > > > > > What is this commit trying to solve exactly? e.g. is AMD currently > > > > running into issues with there being too many DRM connectors or > > > > something like that? > > > > Ideally this is behavior I'd very much like us to keep as-is > > > > unless there's good reason to change it. > > Hi Lyude, > > Really appreciate for your time to elaborate in such detail. Thanks! > > > > I come up with this commit because I observed something confusing when > > I was analyzing MST connectors' life cycle. Take the topology instance > > you mentioned below > > > > Root MSTB -> Output_Port 1 -> MSTB 1.1 ->Output_Port 1(Connected w/ > > display) > > | > > - > > >Output_Port 2 (Disconnected) > > -> Output_Port 2 -> MSTB 2.1 ->Output_Port 1 > > (Disconnected) > > > > -> Output_Port 2 (Disconnected) Which is exactly the topology of > > Startech DP 1-to-4 hub. There are 3 1-to-2 branch chips within this > > hub. With our MST implementation today, we'll create drm connectors > > for all output ports. Hence, we totally create 6 drm connectors here. > > However, Output ports of Root MSTB are not connected to a stream sink. > > They are connected with branch devices. > > Thus, creating drm connector for such port looks a bit strange to me > > and increases complexity to tracking drm connectors. My thought is we > > only need to create drm connector for those connected end device. Once > > output port is connected then we can determine whether to add on a drm > > connector for this port based on the peer device type. > > Hence, this commit doesn't try to break the locking logic but add more > > constraints when We try to add drm connector. Please correct me if I > > misunderstand anything here. Thanks! > > Sorry-I will respond to this soon, some more stuff came up at work so it > might take me a day or two No worries. Much appreciated for your time! > > > > > > > > > Some context here btw - there's a lot of subtleties with MST > > > > locking that isn't immediately obvious. It's been a while since I > > > > wrote this code, but if I recall correctly one of those subtleties > > > > is that trying to create/destroy connectors on the fly when ports > > > > change types introduces a lot of potential issues with locking and > > > > some very complicated state transitions. Note that because we > > > > maintain the topology as much as possible across suspend/resumes > > > > this means there's a lot of potential state transitions with > > > > drm_dp_mst_port and drm_dp_mst_branch we need to handle that would > > > > typically be impossible to run into otherwise. > > > > > > > > An example of this, if we were to try to prune connectors based on > > > > PDT on the fly: assume we have a simple topo
Re: [Intel-gfx] [PATCH 46/46] drm/i915/guc: Add delay before disabling scheduling on contexts
On Mon, Aug 09, 2021 at 07:32:26PM +, Matthew Brost wrote: > On Mon, Aug 09, 2021 at 07:17:27PM +0200, Daniel Vetter wrote: > > On Tue, Aug 03, 2021 at 03:29:43PM -0700, Matthew Brost wrote: > > > Some workloads use lots of contexts that continually pin / unpin > > > contexts. With GuC submission an unpin translates to a schedule disable > > > H2G which puts pressure on both the i915 and GuC. A schedule disable can > > > also block future requests from being submitted until the operation > > > completes. None of this is ideal. > > > > > > Add a configurable, via debugfs, delay period before the schedule > > > disable is issued. Default delay period is 1 second. The delay period is > > > skipped if more than 3/4 of the guc_ids are in use. > > > > > > This patch also updates the selftests to turn off this delay period as > > > this extra time would likely cause many selftests to fail. Follow up > > > patches will fix all the selftests and enable the delay period. > > > > > > Signed-off-by: Matthew Brost > > > > I think this is more evidence that we should just pin/unpin context at > > create/destruction time. The current scheme doesn't really work that well > > and causes way more pain than benefits it seems. > > > > Well that choice is above my pay grade, but for what it is worth it > would simplify the GuC backend quite a bit if we perma-pin contexts. By > quite a bit, I actually mean a lot of complexity goes away. > > In the meantime I think we probably need this code though to avoid > trashes on the scheduling enable / disable. The trouble is that you muck around with the context close state bit, which is one of these lockless trickeries where my cursory analysis (just a few days in total of randomly stumbling over it when reading other code) strongly suggests it's busted. I really don't want to build more on top, especially not without careful review and all that. Also since this is a perf claim, the commit message needs some numbers. Finally even if we decide to make contexts properly evictable, we need a different scheme anyway. As you realized the current active tracking is kinda backwards because it unpins immediately when no longer in use. -Daniel > > Matt > > > If anyone screams, and that's a big if aside of some igts, we can come up > > with a proper scheme to evict contexts without pin/unpin and layer hacks > > over that misdesign. > > -Daniel > > > > > --- > > > drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +- > > > .../i915/gem/selftests/i915_gem_coherency.c | 2 +- > > > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +- > > > .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +- > > > .../drm/i915/gem/selftests/i915_gem_object.c | 2 +- > > > drivers/gpu/drm/i915/gt/intel_context.c | 2 + > > > drivers/gpu/drm/i915/gt/intel_context.h | 9 + > > > drivers/gpu/drm/i915/gt/intel_context_types.h | 8 + > > > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 7 + > > > .../gpu/drm/i915/gt/uc/intel_guc_debugfs.c| 28 ++ > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 322 +- > > > .../i915/gt/uc/selftest_guc_flow_control.c| 19 +- > > > drivers/gpu/drm/i915/i915_selftest.h | 2 + > > > drivers/gpu/drm/i915/i915_trace.h | 10 + > > > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +- > > > drivers/gpu/drm/i915/selftests/i915_perf.c| 2 +- > > > drivers/gpu/drm/i915/selftests/i915_request.c | 2 +- > > > drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +- > > > 18 files changed, 405 insertions(+), 20 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c > > > b/drivers/gpu/drm/i915/gem/i915_gem_context.c > > > index b199d59bd2c4..1553287e5491 100644 > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c > > > @@ -1298,7 +1298,7 @@ static void engines_idle_release(struct > > > i915_gem_context *ctx, > > > int err; > > > > > > /* serialises with execbuf */ > > > - set_bit(CONTEXT_CLOSED_BIT, &ce->flags); > > > + intel_context_close(ce); > > > if (!intel_context_pin_if_active(ce)) > > > continue; > > > > > > diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c > > > b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c > > > index 13b088cc787e..a666d7e610f5 100644 > > > --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c > > > +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c > > > @@ -434,5 +434,5 @@ int i915_gem_coherency_live_selftests(struct > > > drm_i915_private *i915) > > > SUBTEST(igt_gem_coherency), > > > }; > > > > > > - return i915_subtests(tests, i915); > > > + return i915_live_subtests(tests, i915); > > > } > > > diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c > > > b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c > > > ind
Re: [PATCH 25/46] drm/i915/guc: Update debugfs for GuC multi-lrc
On Tue, Aug 10, 2021 at 05:29:46PM +, Matthew Brost wrote:
> On Tue, Aug 10, 2021 at 11:27:31AM +0200, Daniel Vetter wrote:
> > On Tue, Aug 10, 2021 at 11:23:39AM +0200, Daniel Vetter wrote:
> > > On Mon, Aug 09, 2021 at 07:13:11PM +, Matthew Brost wrote:
> > > > On Mon, Aug 09, 2021 at 06:36:44PM +0200, Daniel Vetter wrote:
> > > > > On Tue, Aug 03, 2021 at 03:29:22PM -0700, Matthew Brost wrote:
> > > > > > Display the workqueue status in debugfs for GuC contexts that are in
> > > > > > parent-child relationship.
> > > > > >
> > > > > > Signed-off-by: Matthew Brost
> > > > > > ---
> > > > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 56
> > > > > > +--
> > > > > > 1 file changed, 39 insertions(+), 17 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > > index 30df1c8db491..44a7582c9aed 100644
> > > > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > > @@ -4527,31 +4527,53 @@ void intel_guc_submission_print_info(struct
> > > > > > intel_guc *guc,
> > > > > > gse_log_submission_info(guc->gse[i], p, i);
> > > > > > }
> > > > > >
> > > > > > +static inline void guc_log_context(struct drm_printer *p,
> > > > > > + struct intel_context *ce)
> > > > > > +{
> > > > > > + drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id);
> > > > > > + drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
> > > > > > + drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
> > > > > > + ce->ring->head,
> > > > > > + ce->lrc_reg_state[CTX_RING_HEAD]);
> > > > > > + drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
> > > > > > + ce->ring->tail,
> > > > > > + ce->lrc_reg_state[CTX_RING_TAIL]);
> > > > > > + drm_printf(p, "\t\tContext Pin Count: %u\n",
> > > > > > + atomic_read(&ce->pin_count));
> > > > > > + drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
> > > > > > + atomic_read(&ce->guc_id_ref));
> > > > > > + drm_printf(p, "\t\tNumber Requests Not Ready: %u\n",
> > > > > > + atomic_read(&ce->guc_num_rq_not_ready));
> > > > > > + drm_printf(p, "\t\tSchedule State: 0x%x, 0x%x\n\n",
> > > > > > + ce->guc_state.sched_state,
> > > > > > + atomic_read(&ce->guc_sched_state_no_lock));
> > > > >
> > > > > It's all debugfs, but I think proper locking even there is good. It at
> > > > > least reduces the confusion when the locking scheme is largely
> > > > > undocumented. Also given how much we have rcu for everything would be
> > > > > good
> > > > > to double-check all pointer dererences are properly protected.
> > > > >
> > > >
> > > > Not sure if I 100% follow this but I don't think any of the pointers
> > > > dref here are RCU protected. Certainly none of the GuC ones are.
> > > >
> > > > Will double before the next respin though.
> > > >
> > > > > > +}
> > > > > > +
> > > > > > void intel_guc_submission_print_context_info(struct intel_guc *guc,
> > > > > > struct drm_printer *p)
> > > > > > {
> > > > > > struct intel_context *ce;
> > > > > > unsigned long index;
> > > > > > xa_for_each(&guc->context_lookup, index, ce) {
> > > > >
> > > > > xa_for_each doesn't provide any guarantees, so doesn't protect against
> > > > > concurrent removeal or anything like that. We need to do better than
> > > > > that.
> > > >
> > > > https://elixir.bootlin.com/linux/latest/source/include/linux/xarray.h#L498
> > > > 'It is safe to modify the array during the iteration.'
> > >
> > > The xarray. Not the thing you're dereferencing, because the xarray only
> > > stores pointers, not your data structure. So yeah correct statement is
> > > that it doesn't provide you any guarantees beyond "the iterator wont be
> > > confused if the xarray itself is modified during iteration". Which isn't
> > > what you need here, you need a lot more.
> >
> > Or spelled out: The pointer you get could become immediately meaningless,
> > before you can look at it, due to a concurrent removal/release. All the
> > xa_for_each guarantees you is that on the next round you get the next
> > pointer, until you got them all (plus/minus concurrent changes). But that
> > next pointer could have become meaningless right away too.
> >
> > So you need your own locking to make use of these pointers you got and
> > make sure they're not immediately meaningless before your loop body even
> > started.
> >
>
> Ok, I think I see your point. Likely whenever we do a xa_for_each over
> &guc->context_lookup we should just grab its lock as if it is in the
> xarray we have reference to object looked up. Also everytime we use
> xa_for_each on &guc->context_lookup it is a corner case we it is ok to
> block
Re: [PATCH v4 09/14] vfio/pci: Change vfio_pci_try_bus_reset() to use the dev_set
On Thu, Aug 05 2021, Jason Gunthorpe wrote: > vfio_pci_try_bus_reset() is triggering a reset of the entire_dev set if > any device within it has accumulated a needs_reset. This reset can only be > done once all of the drivers operating the PCI devices to be reset are in > a known safe state. > > Make this clearer by directly operating on the dev_set instead of the > vfio_pci_device. Rename the function to vfio_pci_dev_set_try_reset(). > > Use the device list inside the dev_set to check that all drivers are in a > safe state instead of working backwards from the pci_device. > > The dev_set->lock directly prevents devices from joining/leaving the set, > or changing their state, which further implies the pci_device cannot > change drivers or that the vfio_device be freed, eliminating the need for > get/put's. > > If a pci_device to be reset is not in the dev_set then the reset cannot be > used as we can't know what the state of that driver is. Directly measure > this by checking that every pci_device is in the dev_set - which > effectively proves that VFIO drivers are attached to everything. > > Remove the odd interaction around vfio_pci_set_power_state() - have the > only caller avoid its redundant vfio_pci_set_power_state() instead of > avoiding it inside vfio_pci_dev_set_try_reset(). > > This restructuring corrects a call to pci_dev_driver() without holding the > device_lock() and removes a hard wiring to &vfio_pci_driver. > > Signed-off-by: Jason Gunthorpe > --- > drivers/vfio/pci/vfio_pci.c | 182 +--- > 1 file changed, 86 insertions(+), 96 deletions(-) Reviewed-by: Cornelia Huck
Re: How to obtain a drm lease from X for overlay planes as well as a primary plane?
>On Tue, Aug 10, 2021 at 05:57:31PM +0100, John Cox wrote: >> Hi all >> >> I am on a Raspberry Pi, I want to display fullscreen video and have a >> couple of overlay planes to display controls / subtitles etc. The h/w >> can certainly do this. I need to be able to do this from a starting >> point where X is running. >> >> I can successfully find X's output & crtc and grab that using >> xcb_randr_create_lease and use that handle to display video. So far so >> good. But I also want to have overlay planes for subtitles etc. The >> handle I've got from the lease only seems to have a PRIMARY & a CURSOR >> plane attached so I can't get anything there. > >I think X just gives you a legacy lease for the crtc, and the kernel >automatically adds the primary plane and cursor plane (if they exist) to >that lease. Unless X is patched to enable plane support and add those all >explicitly to the lease I don't think there's a way for that. Bother. So near and yet so far. Thanks for the info. >For wayland this is still in the works, so might be good if you check >there that your use-case is properly supported. Protocol MR is here: > >https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/67 In overall protocol terms that doesn't seem so different from what X does and I am far too inexperienced in Wayland / DRM to understand the subtleties. That MR seems to be done so is probably an inappropriate place to ask - where would you recommend as an appropriate forum? Many thanks John Cox >> How should I be going about getting some more planes to use for >> overlays? Pointers to documentation / examples gratefully received - so >> far my google-foo has failed to find anything that works. >> >> I'm sorry if this is the wrong place to ask, but if there is a better >> place please say and I'll go there. >> >> Many thanks >> >> John Cox
Re: How to obtain a drm lease from X for overlay planes as well as a primary plane?
On Wednesday, August 11th, 2021 at 11:43, Daniel Vetter wrote: > For wayland this is still in the works, so might be good if you check > there that your use-case is properly supported. Protocol MR is here: > > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/67 The client requests a connector, and the compositor will decide which resources to lease. This may or may not include overlay planes. The connector you're interested in may or may not be available for lease. What's your use-case? Why not use an xdg_toplevel and wl_subsurface? DRM leases are not a good idea for regular applications. They don't properly integrate with the rest of the desktop, and won't get input events. Letting the compositor deal with KMS planes is the preferred approach.
Re: How to obtain a drm lease from X for overlay planes as well as a primary plane?
On Wednesday, August 11th, 2021 at 12:19, John Cox wrote: > That MR seems to be done so is probably an inappropriate > place to ask - where would you recommend as an appropriate forum? For Wayland related questions, you can ask on IRC or on the wayland-devel mailing list.
Re: [PATCH 1/9] drm/i915/guc: Fix blocked context accounting
On Wed, Aug 11, 2021 at 01:16:14AM +, Matthew Brost wrote:
> Prior to this patch the blocked context counter was cleared on
> init_sched_state (used during registering a context & resets) which is
> incorrect. This state needs to be persistent or the counter can read the
> incorrect value resulting in scheduling never getting enabled again.
>
> Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Tiny bikeshed on that commit, but for SCHED_STATE_BLOCKED_MASK you want
GENMASK. Also SCHED_STATE_BLOCKED is usually called
SCHED_STATE_BLOCKED_BIAS or similar if you put a counter into that field.
But also ... we can't afford a separate counter? Is all the bitshifting
actually worth the space savings? With a separate counter your bugfix
below would look a lot more reasonable too.
> Signed-off-by: Matthew Brost
> Cc:
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 87d8dc8f51b9..69faa39da178 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -152,7 +152,7 @@ static inline void init_sched_state(struct intel_context
> *ce)
> {
> /* Only should be called from guc_lrc_desc_pin() */
> atomic_set(&ce->guc_sched_state_no_lock, 0);
atomic_t without barriers or anything like that. tsk, tsk.
Do we really need this?
Also I looked through the callchain of init_sched_state and I couldn't
find any locking, nor any description about ownership that would explain
why there's no locking.
E.g. scrub_guc_desc_for_outstanding_g2h has an xa_for_each with no
protection. No idea how that one works. I also couldn't figure out how
anything else in there is protected (no spinlocks to be seen anywhere at
least).
And then there's stuff like this:
/* Flush context */
spin_lock_irqsave(&ce->guc_state.lock, flags);
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
This pattern seems very common, and it freaks me out.
Finally none of the locking or consistency rules are explained in the
kerneldoc (or even comments) in the relevant datastructures, which is not
great.
> - ce->guc_state.sched_state = 0;
> + ce->guc_state.sched_state &= SCHED_STATE_BLOCKED_MASK;
The patch itself matches the commit message and makes sense. But like I
said, would be cleaner I think if it's just a separate counter.
Reviewed-by: Daniel Vetter
> }
>
> static inline bool
> --
> 2.32.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v4 10/14] vfio/pci: Reorganize VFIO_DEVICE_PCI_HOT_RESET to use the device set
On Thu, Aug 05 2021, Jason Gunthorpe wrote: > Like vfio_pci_dev_set_try_reset() this code wants to reset all of the > devices in the "reset group" which is the same membership as the device > set. > > Instead of trying to reconstruct the device set from the PCI list go > directly from the device set's device list to execute the reset. > > The same basic structure as vfio_pci_dev_set_try_reset() is used. The > 'vfio_devices' struct is replaced with the device set linked list and we > simply sweep it multiple times under the lock. > > This eliminates a memory allocation and get/put traffic and another > improperly locked test of pci_dev_driver(). > > Reviewed-off-by: Christoph Hellwig > Signed-off-by: Jason Gunthorpe > --- > drivers/vfio/pci/vfio_pci.c | 213 +++- > 1 file changed, 89 insertions(+), 124 deletions(-) Reviewed-by: Cornelia Huck
Re: [PATCH v4 14/14] vfio: Remove struct vfio_device_ops open/release
On Thu, Aug 05 2021, Jason Gunthorpe wrote: > Nothing uses this anymore, delete it. > > Signed-off-by: Yishai Hadas > Reviewed-by: Christoph Hellwig > Signed-off-by: Jason Gunthorpe > --- > drivers/vfio/mdev/vfio_mdev.c | 22 -- > drivers/vfio/vfio.c | 14 +- > include/linux/mdev.h | 7 --- > include/linux/vfio.h | 4 > 4 files changed, 1 insertion(+), 46 deletions(-) Reviewed-by: Cornelia Huck
Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel tree
On Wed, 11 Aug 2021, Daniel Vetter wrote:
> On Wed, Aug 11, 2021 at 10:16:41AM +0300, Jani Nikula wrote:
>> On Tue, 10 Aug 2021, Daniel Vetter wrote:
>> > On Mon, Aug 09, 2021 at 09:19:39AM -0700, Matt Roper wrote:
>> >> On Mon, Aug 09, 2021 at 04:05:59PM +0200, Daniel Vetter wrote:
>> >> > On Fri, Aug 06, 2021 at 09:36:56AM +0300, Joonas Lahtinen wrote:
>> >> > > Hi Matt,
>> >> > >
>> >> > > Always use the dim tooling when applying patches, it will do the right
>> >> > > thing with regards to adding the S-o-b.
>> >> >
>> >> > fd.o server rejects any pushes that haven't been done by dim, so how did
>> >> > this get through?
>> >>
>> >> I definitely used dim for all of these patches, but I'm not sure how I
>> >> lost my s-o-b on this one. Maybe when I edited the commit message after
>> >> 'dim extract-tags' I accidentally deleted an extra line when I removed
>> >> the extract-tags marker? It's the only patch where the line is missing,
>> >> so it's almost certainly human error on my part rather than something
>> >> dim did wrong.
>> >
>> > Yeah that's an expected failure model, and dim is supposed to catch that
>> > by rechecking for sobs when you push. See dim_push_branch ->
>> > checkpatch_commit_push_range in dim. So you can hand-edit stuff however
>> > you want, dim /should/ catch it when pushing. That it didn't is kinda
>> > confusing and I'd like to know why that slipped through.
>>
>> One of the failures that happened here was that the commit was part of a
>> topic branch that was merged and pushed directly. All merges should
>> happen via pull requests on the list, and applied (preferrably by
>> maintainers or at least with their acks recorded on the merge) using dim
>> apply-pull which should also have the checks.
>
> Ah yes if the merge is applied directly instead of using apply-pull then
> that's not good. I guess that's why we have the rule that only maintainers
> should handle topic branches ...
>
> Not sure how we can fix this in dim? Maybe a check whether the patches
> your pushing contain a merge commit, which prompts an additional query
> like
>
> "Merge commits should only be done by repo maintainers, not committers.
> Confirm that you are a maintainer of $repo?"
>
> It's not the first time this slipped through and caused some fun. Similar
> to how we have the confirmation check if you push a lot of patches.
I sent an untested patch to this effect. It's a start. I guess there
could be more detailed automated checks, but frankly dim is getting
pretty complicated for a bash script. Or because it's a bash script.
BR,
Jani.
>
> Thoughts?
> -Daniel
>
>
>>
>>
>> BR,
>> Jani.
>>
>> >
>> >> > Matt, can you pls figure out and type up the patch to
>> >> > plug that hole?
>> >>
>> >> Are you referring to a patch for dim here? The i915 patch has already
>> >> landed, so we can't change its commit message now.
>> >
>> > Yeah dim, not drm-intel, that can't be fixed anymore because it's all
>> > baked in.
>> > -Daniel
>> >
>> >>
>> >>
>> >> Matt
>> >>
>> >> >
>> >> > Thanks, Daniel
>> >> >
>> >> > >
>> >> > > Regards, Joonas
>> >> > >
>> >> > > Quoting Stephen Rothwell (2021-07-15 07:18:54)
>> >> > > > Hi all,
>> >> > > >
>> >> > > > Commit
>> >> > > >
>> >> > > > db47fe727e1f ("drm/i915/step:
>> >> > > > s/_revid_tbl/_revids")
>> >> > > >
>> >> > > > is missing a Signed-off-by from its committer.
>> >> > > >
>> >> > > > --
>> >> > > > Cheers,
>> >> > > > Stephen Rothwell
>> >> >
>> >> > --
>> >> > Daniel Vetter
>> >> > Software Engineer, Intel Corporation
>> >> > http://blog.ffwll.ch
>> >>
>> >> --
>> >> Matt Roper
>> >> Graphics Software Engineer
>> >> VTT-OSGC Platform Enablement
>> >> Intel Corporation
>> >> (916) 356-2795
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
[PATCH] gpu: drm: amd: amdgpu: amdgpu_i2c: fix possible uninitialized-variable access in amdgpu_i2c_router_select_ddc_port()
The variable val is declared without initialization, and its address is
passed to amdgpu_i2c_get_byte(). In this function, the value of val is
accessed in:
DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n",
addr, *val);
Also, when amdgpu_i2c_get_byte() returns, val may remain uninitialized,
but it is accessed in:
val &= ~amdgpu_connector->router.ddc_mux_control_pin;
To fix this possible uninitialized-variable access, initialize val to 0 in
amdgpu_i2c_router_select_ddc_port().
Reported-by: TOTE Robot
Signed-off-by: Tuo Li
---
drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
index bca45a15..82608df43396 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
@@ -339,7 +339,7 @@ static void amdgpu_i2c_put_byte(struct amdgpu_i2c_chan
*i2c_bus,
void
amdgpu_i2c_router_select_ddc_port(const struct amdgpu_connector
*amdgpu_connector)
{
- u8 val;
+ u8 val = 0;
if (!amdgpu_connector->router.ddc_valid)
return;
--
2.25.1
Re: How to obtain a drm lease from X for overlay planes as well as a primary plane?
Hi >On Wednesday, August 11th, 2021 at 11:43, Daniel Vetter >wrote: > >> For wayland this is still in the works, so might be good if you check >> there that your use-case is properly supported. Protocol MR is here: >> >> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/67 > >The client requests a connector, and the compositor will decide which >resources to lease. This may or may not include overlay planes. The >connector you're interested in may or may not be available for lease. Fair point >What's your use-case? Raspberry Pi displaying video with subtitles or other controls. I was thinking of the fullscreen case but if zero copy video can be made to work to the main desktop then that would even better. If displaying 4k video the Pi does not have enough bandwidth left for a single frame copy, convert or merge so I need hardware scaling, composition & display taking the raw video frame (its in a dmabuf). The raw video is in a somewhat unique format, I'd expect the other layers to be ARGB. The Pi h/w can do this and I believe I can make it work via DRM if I own the screen so that was where I started. >Why not use an xdg_toplevel and wl_subsurface? Probably because I am woefully underinformed about how I should be doing stuff properly. Please feel free to point me in the correct direction - any example that takes NV12 video (it isn't NV12 but if NV12 works then SAND can probably be made to too) would be a great start. Also Wayland hasn't yet come to the Pi though it will shortly be using mutter. >DRM leases are not a good idea for regular applications. They don't >properly integrate with the rest of the desktop, and won't get input >events. Letting the compositor deal with KMS planes is the preferred >approach. If that can be made to work then I agree I would like to do it like that. Many thanks for the response. John Cox
Re: [PATCH v2 4/6] drm/bridge: ti-sn65dsi86: Wrap panel with panel-bridge
Hi Stephen, On Tue, Aug 10, 2021 at 10:26:33PM -0700, Stephen Boyd wrote: > Quoting Laurent Pinchart (2021-06-23 17:03:02) > > To simplify interfacing with the panel, wrap it in a panel-bridge and > > let the DRM bridge helpers handle chaining of operations. > > > > This also prepares for support of DRM_BRIDGE_ATTACH_NO_CONNECTOR, which > > requires all components in the display pipeline to be represented by > > bridges. > > > > Signed-off-by: Laurent Pinchart > > Reviewed-by: Jagan Teki > > --- > > With this patch applied I get two eDP devices on Lazor sc7180 (it is the > arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor*.dts files if you're > looking for more info). As far as I can tell, we should only have one > eDP device on the board, for the bridge. > > localhost ~ # ls -l /sys/class/drm/card1-eDP* > lrwxrwxrwx. 1 root root 0 Aug 10 22:24 /sys/class/drm/card1-eDP-1 -> > ../../devices/platform/soc@0/ae0.mdss/drm/card1/card1-eDP-1 > lrwxrwxrwx. 1 root root 0 Aug 10 22:24 /sys/class/drm/card1-eDP-2 -> > ../../devices/platform/soc@0/ae0.mdss/drm/card1/card1-eDP-2 Indeed. Does the display driver use the DRM connector bridge helper and DRM_BRIDGE_ATTACH_NO_CONNECTOR on that platform ? -- Regards, Laurent Pinchart
Re: [PATCH 07/11] treewide: Replace the use of mem_encrypt_active() with prot_guest_has()
On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote:
> On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote:
> >
> >
> > On 7/27/21 3:26 PM, Tom Lendacky wrote:
> >> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
> >> index de01903c3735..cafed6456d45 100644
> >> --- a/arch/x86/kernel/head64.c
> >> +++ b/arch/x86/kernel/head64.c
> >> @@ -19,7 +19,7 @@
> >> #include
> >> #include
> >> #include
> >> -#include
> >> +#include
> >> #include
> >> #include
> >> @@ -285,7 +285,7 @@ unsigned long __head __startup_64(unsigned long
> >> physaddr,
> >> * there is no need to zero it after changing the memory encryption
> >> * attribute.
> >> */
> >> - if (mem_encrypt_active()) {
> >> + if (prot_guest_has(PATTR_MEM_ENCRYPT)) {
> >> vaddr = (unsigned long)__start_bss_decrypted;
> >> vaddr_end = (unsigned long)__end_bss_decrypted;
> >
> >
> > Since this change is specific to AMD, can you replace PATTR_MEM_ENCRYPT with
> > prot_guest_has(PATTR_SME) || prot_guest_has(PATTR_SEV). It is not used in
> > TDX.
>
> This is a direct replacement for now.
With current implementation of prot_guest_has() for TDX it breaks boot for
me.
Looking at code agains, now I *think* the reason is accessing a global
variable from __startup_64() inside TDX version of prot_guest_has().
__startup_64() is special. If you access any global variable you need to
use fixup_pointer(). See comment before __startup_64().
I'm not sure how you get away with accessing sme_me_mask directly from
there. Any clues? Maybe just a luck and complier generates code just right
for your case, I donno.
A separate point is that TDX version of prot_guest_has() relies on
cpu_feature_enabled() which is not ready at this point.
I think __bss_decrypted fixup has to be done if sme_me_mask is non-zero.
Or just do it uncoditionally because it's NOP for sme_me_mask == 0.
> I think the change you're requesting
> should be done as part of the TDX support patches so it's clear why it is
> being changed.
>
> But, wouldn't TDX still need to do something with this shared/unencrypted
> area, though? Or since it is shared, there's actually nothing you need to
> do (the bss decrpyted section exists even if CONFIG_AMD_MEM_ENCRYPT is not
> configured)?
AFAICS, only kvmclock uses __bss_decrypted. We don't enable kvmclock in
TDX at the moment. It may change in the future.
--
Kirill A. Shutemov
Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel tree
On Wed, Aug 11, 2021 at 10:16:41AM +0300, Jani Nikula wrote:
> On Tue, 10 Aug 2021, Daniel Vetter wrote:
> > On Mon, Aug 09, 2021 at 09:19:39AM -0700, Matt Roper wrote:
> >> On Mon, Aug 09, 2021 at 04:05:59PM +0200, Daniel Vetter wrote:
> >> > On Fri, Aug 06, 2021 at 09:36:56AM +0300, Joonas Lahtinen wrote:
> >> > > Hi Matt,
> >> > >
> >> > > Always use the dim tooling when applying patches, it will do the right
> >> > > thing with regards to adding the S-o-b.
> >> >
> >> > fd.o server rejects any pushes that haven't been done by dim, so how did
> >> > this get through?
> >>
> >> I definitely used dim for all of these patches, but I'm not sure how I
> >> lost my s-o-b on this one. Maybe when I edited the commit message after
> >> 'dim extract-tags' I accidentally deleted an extra line when I removed
> >> the extract-tags marker? It's the only patch where the line is missing,
> >> so it's almost certainly human error on my part rather than something
> >> dim did wrong.
> >
> > Yeah that's an expected failure model, and dim is supposed to catch that
> > by rechecking for sobs when you push. See dim_push_branch ->
> > checkpatch_commit_push_range in dim. So you can hand-edit stuff however
> > you want, dim /should/ catch it when pushing. That it didn't is kinda
> > confusing and I'd like to know why that slipped through.
>
> One of the failures that happened here was that the commit was part of a
> topic branch that was merged and pushed directly. All merges should
> happen via pull requests on the list, and applied (preferrably by
> maintainers or at least with their acks recorded on the merge) using dim
> apply-pull which should also have the checks.
My bad. I have asked Matt to go ahead with the topic branch.
So it is an ack, which didn't get recorded.
But I didn't expect this case of missing dim checks with this flow.
Sorry,
Rodrigo.
>
>
> BR,
> Jani.
>
> >
> >> > Matt, can you pls figure out and type up the patch to
> >> > plug that hole?
> >>
> >> Are you referring to a patch for dim here? The i915 patch has already
> >> landed, so we can't change its commit message now.
> >
> > Yeah dim, not drm-intel, that can't be fixed anymore because it's all
> > baked in.
> > -Daniel
> >
> >>
> >>
> >> Matt
> >>
> >> >
> >> > Thanks, Daniel
> >> >
> >> > >
> >> > > Regards, Joonas
> >> > >
> >> > > Quoting Stephen Rothwell (2021-07-15 07:18:54)
> >> > > > Hi all,
> >> > > >
> >> > > > Commit
> >> > > >
> >> > > > db47fe727e1f ("drm/i915/step:
> >> > > > s/_revid_tbl/_revids")
> >> > > >
> >> > > > is missing a Signed-off-by from its committer.
> >> > > >
> >> > > > --
> >> > > > Cheers,
> >> > > > Stephen Rothwell
> >> >
> >> > --
> >> > Daniel Vetter
> >> > Software Engineer, Intel Corporation
> >> > http://blog.ffwll.ch
> >>
> >> --
> >> Matt Roper
> >> Graphics Software Engineer
> >> VTT-OSGC Platform Enablement
> >> Intel Corporation
> >> (916) 356-2795
>
> --
> Jani Nikula, Intel Open Source Graphics Center
[PATCH v4 2/2] arm64: dts: qcom: sc7280: Add gpu thermal zone cooling support
From: Manaf Meethalavalappu Pallikunhi
Add cooling-cells property and the cooling maps for the gpu thermal
zones to support GPU thermal cooling.
Signed-off-by: Manaf Meethalavalappu Pallikunhi
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
arch/arm64/boot/dts/qcom/sc7280.dtsi | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index b9006d8..cd2bbf0 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -592,7 +592,7 @@
qcom,bcm-voters = <&apps_bcm_voter>;
};
- gpu@3d0 {
+ gpu: gpu@3d0 {
compatible = "qcom,adreno-635.0", "qcom,adreno";
#stream-id-cells = <16>;
reg = <0 0x03d0 0 0x4>,
@@ -607,6 +607,7 @@
qcom,gmu = <&gmu>;
interconnects = <&gem_noc MASTER_GFX3D 0 &mc_virt
SLAVE_EBI1 0>;
interconnect-names = "gfx-mem";
+ #cooling-cells = <2>;
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
@@ -2523,16 +2524,16 @@
};
gpuss0-thermal {
- polling-delay-passive = <0>;
+ polling-delay-passive = <100>;
polling-delay = <0>;
thermal-sensors = <&tsens1 1>;
trips {
gpuss0_alert0: trip-point0 {
- temperature = <9>;
+ temperature = <95000>;
hysteresis = <2000>;
- type = "hot";
+ type = "passive";
};
gpuss0_crit: gpuss0-crit {
@@ -2541,19 +2542,26 @@
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss0_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss1-thermal {
- polling-delay-passive = <0>;
+ polling-delay-passive = <100>;
polling-delay = <0>;
thermal-sensors = <&tsens1 2>;
trips {
gpuss1_alert0: trip-point0 {
- temperature = <9>;
+ temperature = <95000>;
hysteresis = <2000>;
- type = "hot";
+ type = "passive";
};
gpuss1_crit: gpuss1-crit {
@@ -2562,6 +2570,13 @@
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss1_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>;
+ };
+ };
};
nspss0-thermal {
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
[PATCH v4 1/2] arm64: dts: qcom: sc7280: Add gpu support
Add the necessary dt nodes for gpu support in sc7280.
Signed-off-by: Akhil P Oommen
---
Changes in v4:
- Removed the dependency on gpucc bindings (Stephen)
- Reordered GPU's opp table
Changes in v3:
- Re-ordered the nodes based on address (Stephen)
- Added the patch for gpu cooling to the stack.
Changes in v2:
- formatting update and removed a duplicate header (Stephen)
arch/arm64/boot/dts/qcom/sc7280.dtsi | 115 +++
1 file changed, 115 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 029723a..b9006d8 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -592,6 +592,85 @@
qcom,bcm-voters = <&apps_bcm_voter>;
};
+ gpu@3d0 {
+ compatible = "qcom,adreno-635.0", "qcom,adreno";
+ #stream-id-cells = <16>;
+ reg = <0 0x03d0 0 0x4>,
+ <0 0x03d9e000 0 0x1000>,
+ <0 0x03d61000 0 0x800>;
+ reg-names = "kgsl_3d0_reg_memory",
+ "cx_mem",
+ "cx_dbgc";
+ interrupts = ;
+ iommus = <&adreno_smmu 0 0x401>;
+ operating-points-v2 = <&gpu_opp_table>;
+ qcom,gmu = <&gmu>;
+ interconnects = <&gem_noc MASTER_GFX3D 0 &mc_virt
SLAVE_EBI1 0>;
+ interconnect-names = "gfx-mem";
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-31500 {
+ opp-hz = /bits/ 64 <31500>;
+ opp-level =
;
+ opp-peak-kBps = <1804000>;
+ };
+
+ opp-45000 {
+ opp-hz = /bits/ 64 <45000>;
+ opp-level = ;
+ opp-peak-kBps = <4068000>;
+ };
+
+ opp-55000 {
+ opp-hz = /bits/ 64 <55000>;
+ opp-level =
;
+ opp-peak-kBps = <6832000>;
+ };
+ };
+ };
+
+ gmu: gmu@3d69000 {
+ compatible="qcom,adreno-gmu-635.0", "qcom,adreno-gmu";
+ reg = <0 0x03d6a000 0 0x34000>,
+ <0 0x3de 0 0x1>,
+ <0 0x0b29 0 0x1>;
+ reg-names = "gmu", "rscc", "gmu_pdc";
+ interrupts = ,
+ ;
+ interrupt-names = "hfi", "gmu";
+ clocks = <&gpucc 5>,
+ <&gpucc 8>,
+ <&gcc GCC_DDRSS_GPU_AXI_CLK>,
+ <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
+ <&gpucc 2>,
+ <&gpucc 15>,
+ <&gpucc 11>;
+ clock-names = "gmu",
+ "cxo",
+ "axi",
+ "memnoc",
+ "ahb",
+ "hub",
+ "smmu_vote";
+ power-domains = <&gpucc 0>,
+ <&gpucc 1>;
+ power-domain-names = "cx",
+"gx";
+ iommus = <&adreno_smmu 5 0x400>;
+ operating-points-v2 = <&gmu_opp_table>;
+
+ gmu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-level =
;
+ };
+ };
+ };
+
gpucc: clock-controller@3d9 {
compatible = "qcom,sc7280-gpucc";
reg = <0 0x03d9 0 0x9000>;
@@ -606,6 +685,42 @@
#power-domain-cells = <1>;
};
+ adreno_smmu: iommu@3da {
+ compatible = "qcom,sc7280-smmu-500",
"qcom,adreno-smmu", "arm,mmu-500";
+ reg = <0 0x03da 0 0x2>;
+
[PATCH v5 1/2] arm64: dts: qcom: sc7280: Add gpu support
Add the necessary dt nodes for gpu support in sc7280.
Signed-off-by: Akhil P Oommen
---
Changes in v5:
- Added Stephen's reviewed-by tag to patch-2
Changes in v4:
- Removed the dependency on gpucc bindings (Stephen)
- Reordered GPU's opp table
Changes in v3:
- Re-ordered the nodes based on address (Stephen)
- Added the patch for gpu cooling to the stack.
Changes in v2:
- formatting update and removed a duplicate header (Stephen)
arch/arm64/boot/dts/qcom/sc7280.dtsi | 115 +++
1 file changed, 115 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 029723a..b9006d8 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -592,6 +592,85 @@
qcom,bcm-voters = <&apps_bcm_voter>;
};
+ gpu@3d0 {
+ compatible = "qcom,adreno-635.0", "qcom,adreno";
+ #stream-id-cells = <16>;
+ reg = <0 0x03d0 0 0x4>,
+ <0 0x03d9e000 0 0x1000>,
+ <0 0x03d61000 0 0x800>;
+ reg-names = "kgsl_3d0_reg_memory",
+ "cx_mem",
+ "cx_dbgc";
+ interrupts = ;
+ iommus = <&adreno_smmu 0 0x401>;
+ operating-points-v2 = <&gpu_opp_table>;
+ qcom,gmu = <&gmu>;
+ interconnects = <&gem_noc MASTER_GFX3D 0 &mc_virt
SLAVE_EBI1 0>;
+ interconnect-names = "gfx-mem";
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-31500 {
+ opp-hz = /bits/ 64 <31500>;
+ opp-level =
;
+ opp-peak-kBps = <1804000>;
+ };
+
+ opp-45000 {
+ opp-hz = /bits/ 64 <45000>;
+ opp-level = ;
+ opp-peak-kBps = <4068000>;
+ };
+
+ opp-55000 {
+ opp-hz = /bits/ 64 <55000>;
+ opp-level =
;
+ opp-peak-kBps = <6832000>;
+ };
+ };
+ };
+
+ gmu: gmu@3d69000 {
+ compatible="qcom,adreno-gmu-635.0", "qcom,adreno-gmu";
+ reg = <0 0x03d6a000 0 0x34000>,
+ <0 0x3de 0 0x1>,
+ <0 0x0b29 0 0x1>;
+ reg-names = "gmu", "rscc", "gmu_pdc";
+ interrupts = ,
+ ;
+ interrupt-names = "hfi", "gmu";
+ clocks = <&gpucc 5>,
+ <&gpucc 8>,
+ <&gcc GCC_DDRSS_GPU_AXI_CLK>,
+ <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
+ <&gpucc 2>,
+ <&gpucc 15>,
+ <&gpucc 11>;
+ clock-names = "gmu",
+ "cxo",
+ "axi",
+ "memnoc",
+ "ahb",
+ "hub",
+ "smmu_vote";
+ power-domains = <&gpucc 0>,
+ <&gpucc 1>;
+ power-domain-names = "cx",
+"gx";
+ iommus = <&adreno_smmu 5 0x400>;
+ operating-points-v2 = <&gmu_opp_table>;
+
+ gmu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-level =
;
+ };
+ };
+ };
+
gpucc: clock-controller@3d9 {
compatible = "qcom,sc7280-gpucc";
reg = <0 0x03d9 0 0x9000>;
@@ -606,6 +685,42 @@
#power-domain-cells = <1>;
};
+ adreno_smmu: iommu@3da {
+ compatible = "qcom,sc7280-smmu-500",
"qcom,adreno-smmu", "arm,mmu-500";
+
[PATCH v5 2/2] arm64: dts: qcom: sc7280: Add gpu thermal zone cooling support
From: Manaf Meethalavalappu Pallikunhi
Add cooling-cells property and the cooling maps for the gpu thermal
zones to support GPU thermal cooling.
Signed-off-by: Manaf Meethalavalappu Pallikunhi
Signed-off-by: Akhil P Oommen
Reviewed-by: Stephen Boyd
---
(no changes since v1)
arch/arm64/boot/dts/qcom/sc7280.dtsi | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index b9006d8..cd2bbf0 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -592,7 +592,7 @@
qcom,bcm-voters = <&apps_bcm_voter>;
};
- gpu@3d0 {
+ gpu: gpu@3d0 {
compatible = "qcom,adreno-635.0", "qcom,adreno";
#stream-id-cells = <16>;
reg = <0 0x03d0 0 0x4>,
@@ -607,6 +607,7 @@
qcom,gmu = <&gmu>;
interconnects = <&gem_noc MASTER_GFX3D 0 &mc_virt
SLAVE_EBI1 0>;
interconnect-names = "gfx-mem";
+ #cooling-cells = <2>;
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
@@ -2523,16 +2524,16 @@
};
gpuss0-thermal {
- polling-delay-passive = <0>;
+ polling-delay-passive = <100>;
polling-delay = <0>;
thermal-sensors = <&tsens1 1>;
trips {
gpuss0_alert0: trip-point0 {
- temperature = <9>;
+ temperature = <95000>;
hysteresis = <2000>;
- type = "hot";
+ type = "passive";
};
gpuss0_crit: gpuss0-crit {
@@ -2541,19 +2542,26 @@
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss0_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss1-thermal {
- polling-delay-passive = <0>;
+ polling-delay-passive = <100>;
polling-delay = <0>;
thermal-sensors = <&tsens1 2>;
trips {
gpuss1_alert0: trip-point0 {
- temperature = <9>;
+ temperature = <95000>;
hysteresis = <2000>;
- type = "hot";
+ type = "passive";
};
gpuss1_crit: gpuss1-crit {
@@ -2562,6 +2570,13 @@
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss1_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>;
+ };
+ };
};
nspss0-thermal {
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
[PATCH v3 3/3] drm/tegra: Add NVDEC driver
Add support for booting and using NVDEC on Tegra210, Tegra186
and Tegra194 to the Host1x and TegraDRM drivers. Booting in
secure mode is not currently supported.
Signed-off-by: Mikko Perttunen
---
v3:
* Change num_instances to unsigned int
* Remove unnecessary '= 0' initializer
* Populate num_instances data
* Fix instance number check
v2:
* Use devm_platform_get_and_ioremap_resource
* Remove reset handling, done by power domain code
* Assume runtime PM is enabled
---
drivers/gpu/drm/tegra/Makefile | 3 +-
drivers/gpu/drm/tegra/drm.c| 4 +
drivers/gpu/drm/tegra/drm.h| 1 +
drivers/gpu/drm/tegra/nvdec.c | 474 +
drivers/gpu/host1x/dev.c | 18 ++
include/linux/host1x.h | 2 +
6 files changed, 501 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/tegra/nvdec.c
diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index 5d2039f0c734..b248c631f790 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -24,7 +24,8 @@ tegra-drm-y := \
gr2d.o \
gr3d.o \
falcon.o \
- vic.o
+ vic.o \
+ nvdec.o
tegra-drm-y += trace.o
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index b20fd0833661..5f5afd7ba37e 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1337,15 +1337,18 @@ static const struct of_device_id host1x_drm_subdevs[] =
{
{ .compatible = "nvidia,tegra210-sor", },
{ .compatible = "nvidia,tegra210-sor1", },
{ .compatible = "nvidia,tegra210-vic", },
+ { .compatible = "nvidia,tegra210-nvdec", },
{ .compatible = "nvidia,tegra186-display", },
{ .compatible = "nvidia,tegra186-dc", },
{ .compatible = "nvidia,tegra186-sor", },
{ .compatible = "nvidia,tegra186-sor1", },
{ .compatible = "nvidia,tegra186-vic", },
+ { .compatible = "nvidia,tegra186-nvdec", },
{ .compatible = "nvidia,tegra194-display", },
{ .compatible = "nvidia,tegra194-dc", },
{ .compatible = "nvidia,tegra194-sor", },
{ .compatible = "nvidia,tegra194-vic", },
+ { .compatible = "nvidia,tegra194-nvdec", },
{ /* sentinel */ }
};
@@ -1369,6 +1372,7 @@ static struct platform_driver * const drivers[] = {
&tegra_gr2d_driver,
&tegra_gr3d_driver,
&tegra_vic_driver,
+ &tegra_nvdec_driver,
};
static int __init host1x_drm_init(void)
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 8b28327c931c..fc0a19554eac 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -202,5 +202,6 @@ extern struct platform_driver tegra_sor_driver;
extern struct platform_driver tegra_gr2d_driver;
extern struct platform_driver tegra_gr3d_driver;
extern struct platform_driver tegra_vic_driver;
+extern struct platform_driver tegra_nvdec_driver;
#endif /* HOST1X_DRM_H */
diff --git a/drivers/gpu/drm/tegra/nvdec.c b/drivers/gpu/drm/tegra/nvdec.c
new file mode 100644
index ..e8e7ebbea53e
--- /dev/null
+++ b/drivers/gpu/drm/tegra/nvdec.c
@@ -0,0 +1,474 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2015-2021, NVIDIA Corporation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "drm.h"
+#include "falcon.h"
+#include "vic.h"
+
+struct nvdec_config {
+ const char *firmware;
+ unsigned int version;
+ bool supports_sid;
+ unsigned int num_instances;
+};
+
+struct nvdec {
+ struct falcon falcon;
+
+ void __iomem *regs;
+ struct tegra_drm_client client;
+ struct host1x_channel *channel;
+ struct device *dev;
+ struct clk *clk;
+
+ /* Platform configuration */
+ const struct nvdec_config *config;
+};
+
+static inline struct nvdec *to_nvdec(struct tegra_drm_client *client)
+{
+ return container_of(client, struct nvdec, client);
+}
+
+static void nvdec_writel(struct nvdec *nvdec, u32 value, unsigned int offset)
+{
+ writel(value, nvdec->regs + offset);
+}
+
+static int nvdec_boot(struct nvdec *nvdec)
+{
+#ifdef CONFIG_IOMMU_API
+ struct iommu_fwspec *spec = dev_iommu_fwspec_get(nvdec->dev);
+#endif
+ int err;
+
+#ifdef CONFIG_IOMMU_API
+ if (nvdec->config->supports_sid && spec) {
+ u32 value;
+
+ value = TRANSCFG_ATT(1, TRANSCFG_SID_FALCON) | TRANSCFG_ATT(0,
TRANSCFG_SID_HW);
+ nvdec_writel(nvdec, value, VIC_TFBIF_TRANSCFG);
+
+ if (spec->num_ids > 0) {
+ value = spec->ids[0] & 0x;
+
+ nvdec_writel(nvdec, value, VIC_THI_STREAMID0);
+ nvdec_writel(nvdec, value, VIC_THI_STREAMID1);
+ }
+ }
+#endif
+
+ err = falcon_boot(&nvdec->falcon);
+ if (err < 0)
+ return err;
+
+
[PATCH v3 1/3] dt-bindings: Add YAML bindings for NVDEC
Add YAML device tree bindings for NVDEC, now in a more appropriate
place compared to the old textual Host1x bindings.
Signed-off-by: Mikko Perttunen
---
v3:
* Drop host1x bindings
* Change read2 to read-1 in interconnect names
v2:
* Fix issues pointed out in v1
* Add T194 nvidia,instance property
---
.../gpu/host1x/nvidia,tegra210-nvdec.yaml | 109 ++
MAINTAINERS | 1 +
2 files changed, 110 insertions(+)
create mode 100644
Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
diff --git
a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
new file mode 100644
index ..571849625da8
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvdec.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Device tree binding for NVIDIA Tegra NVDEC
+
+description: |
+ NVDEC is the hardware video decoder present on NVIDIA Tegra210
+ and newer chips. It is located on the Host1x bus and typically
+ programmed through Host1x channels.
+
+maintainers:
+ - Thierry Reding
+ - Mikko Perttunen
+
+properties:
+ $nodename:
+pattern: "^nvdec@[0-9a-f]*$"
+
+ compatible:
+enum:
+ - nvidia,tegra210-nvdec
+ - nvidia,tegra186-nvdec
+ - nvidia,tegra194-nvdec
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+items:
+ - const: nvdec
+
+ resets:
+maxItems: 1
+
+ reset-names:
+items:
+ - const: nvdec
+
+ power-domains:
+maxItems: 1
+
+ iommus:
+maxItems: 1
+
+ interconnects:
+items:
+ - description: DMA read memory client
+ - description: DMA read 2 memory client
+ - description: DMA write memory client
+
+ interconnect-names:
+items:
+ - const: dma-mem
+ - const: read-1
+ - const: write
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - power-domains
+
+if:
+ properties:
+compatible:
+ contains:
+const: nvidia,tegra194-host1x
+then:
+ properties:
+nvidia,instance:
+ items:
+- description: 0 for NVDEC0, or 1 for NVDEC1
+
+additionalProperties: true
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+#include
+
+nvdec@1548 {
+compatible = "nvidia,tegra186-nvdec";
+reg = <0x1548 0x4>;
+clocks = <&bpmp TEGRA186_CLK_NVDEC>;
+clock-names = "nvdec";
+resets = <&bpmp TEGRA186_RESET_NVDEC>;
+reset-names = "nvdec";
+
+power-domains = <&bpmp TEGRA186_POWER_DOMAIN_NVDEC>;
+interconnects = <&mc TEGRA186_MEMORY_CLIENT_NVDECSRD &emc>,
+<&mc TEGRA186_MEMORY_CLIENT_NVDECSRD1 &emc>,
+<&mc TEGRA186_MEMORY_CLIENT_NVDECSWR &emc>;
+interconnect-names = "dma-mem", "read-1", "write";
+iommus = <&smmu TEGRA186_SID_NVDEC>;
+};
+
+
diff --git a/MAINTAINERS b/MAINTAINERS
index 69932194e1ba..ce9e360639d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6230,6 +6230,7 @@ L:linux-te...@vger.kernel.org
S: Supported
T: git git://anongit.freedesktop.org/tegra/linux.git
F:
Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
+F: Documentation/devicetree/bindings/gpu/host1x/
F: drivers/gpu/drm/tegra/
F: drivers/gpu/host1x/
F: include/linux/host1x.h
--
2.32.0
[PATCH v3 0/3] NVIDIA Tegra NVDEC support
Here's the v3 of the NVDEC support series, containing minor fixes compared to v2. NVDEC hardware documentation can be found at https://github.com/NVIDIA/open-gpu-doc/tree/master/classes/video and example userspace can be found at https://github.com/cyndis/vaapi-tegra-driver Thanks, Mikko Mikko Perttunen (3): dt-bindings: Add YAML bindings for NVDEC arm64: tegra: Add NVDEC to Tegra186/194 device trees drm/tegra: Add NVDEC driver .../gpu/host1x/nvidia,tegra210-nvdec.yaml | 109 MAINTAINERS | 1 + arch/arm64/boot/dts/nvidia/tegra186.dtsi | 16 + arch/arm64/boot/dts/nvidia/tegra194.dtsi | 36 ++ drivers/gpu/drm/tegra/Makefile| 3 +- drivers/gpu/drm/tegra/drm.c | 4 + drivers/gpu/drm/tegra/drm.h | 1 + drivers/gpu/drm/tegra/nvdec.c | 474 ++ drivers/gpu/host1x/dev.c | 18 + include/linux/host1x.h| 2 + 10 files changed, 663 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml create mode 100644 drivers/gpu/drm/tegra/nvdec.c -- 2.32.0
[PATCH v3 2/3] arm64: tegra: Add NVDEC to Tegra186/194 device trees
Add a device tree node for NVDEC on Tegra186, and
device tree nodes for NVDEC and NVDEC1 on Tegra194.
Signed-off-by: Mikko Perttunen
---
v3:
* Change read2 to read-1
v2:
* Add NVDECSRD1 memory client
* Add also to T194 (both NVDEC0/1)
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 16 +++
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 36
2 files changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index d02f6bf3e2ca..4f2f21242b2c 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1342,6 +1342,22 @@ dsib: dsi@1540 {
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
};
+ nvdec@1548 {
+ compatible = "nvidia,tegra186-nvdec";
+ reg = <0x1548 0x4>;
+ clocks = <&bpmp TEGRA186_CLK_NVDEC>;
+ clock-names = "nvdec";
+ resets = <&bpmp TEGRA186_RESET_NVDEC>;
+ reset-names = "nvdec";
+
+ power-domains = <&bpmp TEGRA186_POWER_DOMAIN_NVDEC>;
+ interconnects = <&mc TEGRA186_MEMORY_CLIENT_NVDECSRD
&emc>,
+ <&mc TEGRA186_MEMORY_CLIENT_NVDECSRD1
&emc>,
+ <&mc TEGRA186_MEMORY_CLIENT_NVDECSWR
&emc>;
+ interconnect-names = "dma-mem", "read-1", "write";
+ iommus = <&smmu TEGRA186_SID_NVDEC>;
+ };
+
sor0: sor@1554 {
compatible = "nvidia,tegra186-sor";
reg = <0x1554 0x1>;
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 5ba7a4519b95..9119aa4f28c1 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1412,6 +1412,24 @@ host1x@13e0 {
interconnect-names = "dma-mem";
iommus = <&smmu TEGRA194_SID_HOST1X>;
+ nvdec@1514 {
+ compatible = "nvidia,tegra194-nvdec";
+ reg = <0x1514 0x0004>;
+ clocks = <&bpmp TEGRA194_CLK_NVDEC1>;
+ clock-names = "nvdec";
+ resets = <&bpmp TEGRA194_RESET_NVDEC1>;
+ reset-names = "nvdec";
+
+ power-domains = <&bpmp
TEGRA194_POWER_DOMAIN_NVDECB>;
+ interconnects = <&mc
TEGRA194_MEMORY_CLIENT_NVDEC1SRD &emc>,
+ <&mc
TEGRA194_MEMORY_CLIENT_NVDEC1SRD1 &emc>,
+ <&mc
TEGRA194_MEMORY_CLIENT_NVDEC1SWR &emc>;
+ interconnect-names = "dma-mem", "read-1",
"write";
+ iommus = <&smmu TEGRA194_SID_NVDEC1>;
+
+ nvidia,instance = <1>;
+ };
+
display-hub@1520 {
compatible = "nvidia,tegra194-display";
reg = <0x1520 0x0004>;
@@ -1525,6 +1543,24 @@ vic@1534 {
iommus = <&smmu TEGRA194_SID_VIC>;
};
+ nvdec@1548 {
+ compatible = "nvidia,tegra194-nvdec";
+ reg = <0x1548 0x0004>;
+ clocks = <&bpmp TEGRA194_CLK_NVDEC>;
+ clock-names = "nvdec";
+ resets = <&bpmp TEGRA194_RESET_NVDEC>;
+ reset-names = "nvdec";
+
+ power-domains = <&bpmp
TEGRA194_POWER_DOMAIN_NVDECA>;
+ interconnects = <&mc
TEGRA194_MEMORY_CLIENT_NVDECSRD &emc>,
+ <&mc
TEGRA194_MEMORY_CLIENT_NVDECSRD1 &emc>,
+ <&mc
TEGRA194_MEMORY_CLIENT_NVDECSWR &emc>;
+ interconnect-names = "dma-mem", "read-1",
"write";
+ iommus = <&smmu TEGRA194_SID_NVDEC>;
+
+ nvidia,instance = <0>;
+ };
+
dpaux0: dpaux@155c {
compatible = "nvidia,tegra194-dpaux";
reg = <0x155c 0x1>;
--
2.32.0
Re: [PATCH 01/11] mm: Introduce a function to check for virtualization protection features
On 7/27/21 3:26 PM, Tom Lendacky wrote:
diff --git a/include/linux/protected_guest.h b/include/linux/protected_guest.h
new file mode 100644
index ..f8ed7b72967b
--- /dev/null
+++ b/include/linux/protected_guest.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Protected Guest (and Host) Capability checks
+ *
+ * Copyright (C) 2021 Advanced Micro Devices, Inc.
+ *
+ * Author: Tom Lendacky
+ */
+
+#ifndef _PROTECTED_GUEST_H
+#define _PROTECTED_GUEST_H
+
+#ifndef __ASSEMBLY__
Can you include headers for bool type and false definition?
--- a/include/linux/protected_guest.h
+++ b/include/linux/protected_guest.h
@@ -12,6 +12,9 @@
#ifndef __ASSEMBLY__
+#include
+#include
Otherwise, I see following errors in multi-config auto testing.
include/linux/protected_guest.h:40:15: error: unknown type name 'bool'
include/linux/protected_guest.h:40:63: error: 'false' undeclared (first use in
this functi
+
+#define PATTR_MEM_ENCRYPT 0 /* Encrypted memory */
+#define PATTR_HOST_MEM_ENCRYPT 1 /* Host encrypted memory */
+#define PATTR_GUEST_MEM_ENCRYPT2 /* Guest encrypted
memory */
+#define PATTR_GUEST_PROT_STATE 3 /* Guest encrypted state */
+
+#ifdef CONFIG_ARCH_HAS_PROTECTED_GUEST
+
+#include
+
+#else /* !CONFIG_ARCH_HAS_PROTECTED_GUEST */
+
+static inline bool prot_guest_has(unsigned int attr) { return false; }
+
+#endif /* CONFIG_ARCH_HAS_PROTECTED_GUEST */
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* _PROTECTED_GUEST_H */
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
[PATCH] drm/tegra: vic: Use autosuspend
When going idle, it's not unlikely that more work will follow. As such, use autosuspend with a 500ms suspend delay. Signed-off-by: Mikko Perttunen --- drivers/gpu/drm/tegra/vic.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c index c02010ff2b7f..0204cfbe6694 100644 --- a/drivers/gpu/drm/tegra/vic.c +++ b/drivers/gpu/drm/tegra/vic.c @@ -482,6 +482,8 @@ static int vic_probe(struct platform_device *pdev) if (err < 0) goto unregister_client; } + pm_runtime_set_autosuspend_delay(&pdev->dev, 500); + pm_runtime_use_autosuspend(&pdev->dev); return 0; -- 2.32.0
Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel tree
On Wed, Aug 11, 2021 at 11:48:00AM +0200, Daniel Vetter wrote:
> On Wed, Aug 11, 2021 at 10:16:41AM +0300, Jani Nikula wrote:
> > On Tue, 10 Aug 2021, Daniel Vetter wrote:
> > > On Mon, Aug 09, 2021 at 09:19:39AM -0700, Matt Roper wrote:
> > >> On Mon, Aug 09, 2021 at 04:05:59PM +0200, Daniel Vetter wrote:
> > >> > On Fri, Aug 06, 2021 at 09:36:56AM +0300, Joonas Lahtinen wrote:
> > >> > > Hi Matt,
> > >> > >
> > >> > > Always use the dim tooling when applying patches, it will do the
> > >> > > right
> > >> > > thing with regards to adding the S-o-b.
> > >> >
> > >> > fd.o server rejects any pushes that haven't been done by dim, so how
> > >> > did
> > >> > this get through?
> > >>
> > >> I definitely used dim for all of these patches, but I'm not sure how I
> > >> lost my s-o-b on this one. Maybe when I edited the commit message after
> > >> 'dim extract-tags' I accidentally deleted an extra line when I removed
> > >> the extract-tags marker? It's the only patch where the line is missing,
> > >> so it's almost certainly human error on my part rather than something
> > >> dim did wrong.
> > >
> > > Yeah that's an expected failure model, and dim is supposed to catch that
> > > by rechecking for sobs when you push. See dim_push_branch ->
> > > checkpatch_commit_push_range in dim. So you can hand-edit stuff however
> > > you want, dim /should/ catch it when pushing. That it didn't is kinda
> > > confusing and I'd like to know why that slipped through.
> >
> > One of the failures that happened here was that the commit was part of a
> > topic branch that was merged and pushed directly. All merges should
> > happen via pull requests on the list, and applied (preferrably by
> > maintainers or at least with their acks recorded on the merge) using dim
> > apply-pull which should also have the checks.
>
> Ah yes if the merge is applied directly instead of using apply-pull then
> that's not good. I guess that's why we have the rule that only maintainers
> should handle topic branches ...
Hmm, I wasn't aware of this rule. I double checked with Rodrigo before
doing so and he thought merging a branch directly to intel-next and
gt-next with the foundational definitions and tables should be an okay
approach here (and he did an extra backmerge in preparation to make sure
it went smoothly).
Anyway, definitely my fault; I'll keep this in mind for the future.
Matt
>
> Not sure how we can fix this in dim? Maybe a check whether the patches
> your pushing contain a merge commit, which prompts an additional query
> like
>
> "Merge commits should only be done by repo maintainers, not committers.
> Confirm that you are a maintainer of $repo?"
>
> It's not the first time this slipped through and caused some fun. Similar
> to how we have the confirmation check if you push a lot of patches.
>
> Thoughts?
> -Daniel
>
>
> >
> >
> > BR,
> > Jani.
> >
> > >
> > >> > Matt, can you pls figure out and type up the patch to
> > >> > plug that hole?
> > >>
> > >> Are you referring to a patch for dim here? The i915 patch has already
> > >> landed, so we can't change its commit message now.
> > >
> > > Yeah dim, not drm-intel, that can't be fixed anymore because it's all
> > > baked in.
> > > -Daniel
> > >
> > >>
> > >>
> > >> Matt
> > >>
> > >> >
> > >> > Thanks, Daniel
> > >> >
> > >> > >
> > >> > > Regards, Joonas
> > >> > >
> > >> > > Quoting Stephen Rothwell (2021-07-15 07:18:54)
> > >> > > > Hi all,
> > >> > > >
> > >> > > > Commit
> > >> > > >
> > >> > > > db47fe727e1f ("drm/i915/step:
> > >> > > > s/_revid_tbl/_revids")
> > >> > > >
> > >> > > > is missing a Signed-off-by from its committer.
> > >> > > >
> > >> > > > --
> > >> > > > Cheers,
> > >> > > > Stephen Rothwell
> > >> >
> > >> > --
> > >> > Daniel Vetter
> > >> > Software Engineer, Intel Corporation
> > >> > http://blog.ffwll.ch
> > >>
> > >> --
> > >> Matt Roper
> > >> Graphics Software Engineer
> > >> VTT-OSGC Platform Enablement
> > >> Intel Corporation
> > >> (916) 356-2795
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [PATCH 01/11] mm: Introduce a function to check for virtualization protection features
On 8/11/21 9:53 AM, Kuppuswamy, Sathyanarayanan wrote: > On 7/27/21 3:26 PM, Tom Lendacky wrote: >> diff --git a/include/linux/protected_guest.h >> b/include/linux/protected_guest.h >> new file mode 100644 >> index ..f8ed7b72967b >> --- /dev/null >> +++ b/include/linux/protected_guest.h >> @@ -0,0 +1,32 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> +/* >> + * Protected Guest (and Host) Capability checks >> + * >> + * Copyright (C) 2021 Advanced Micro Devices, Inc. >> + * >> + * Author: Tom Lendacky >> + */ >> + >> +#ifndef _PROTECTED_GUEST_H >> +#define _PROTECTED_GUEST_H >> + >> +#ifndef __ASSEMBLY__ > > Can you include headers for bool type and false definition? Can do. Thanks, Tom > > --- a/include/linux/protected_guest.h > +++ b/include/linux/protected_guest.h > @@ -12,6 +12,9 @@ > > #ifndef __ASSEMBLY__ > > +#include > +#include > > Otherwise, I see following errors in multi-config auto testing. > > include/linux/protected_guest.h:40:15: error: unknown type name 'bool' > include/linux/protected_guest.h:40:63: error: 'false' undeclared (first > use in this functi >
Re: [PATCH 07/11] treewide: Replace the use of mem_encrypt_active() with prot_guest_has()
On 8/11/21 7:19 AM, Kirill A. Shutemov wrote:
> On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote:
>> On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote:
>>>
>>>
>>> On 7/27/21 3:26 PM, Tom Lendacky wrote:
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index de01903c3735..cafed6456d45 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -19,7 +19,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -285,7 +285,7 @@ unsigned long __head __startup_64(unsigned long
physaddr,
* there is no need to zero it after changing the memory encryption
* attribute.
*/
- if (mem_encrypt_active()) {
+ if (prot_guest_has(PATTR_MEM_ENCRYPT)) {
vaddr = (unsigned long)__start_bss_decrypted;
vaddr_end = (unsigned long)__end_bss_decrypted;
>>>
>>>
>>> Since this change is specific to AMD, can you replace PATTR_MEM_ENCRYPT with
>>> prot_guest_has(PATTR_SME) || prot_guest_has(PATTR_SEV). It is not used in
>>> TDX.
>>
>> This is a direct replacement for now.
>
> With current implementation of prot_guest_has() for TDX it breaks boot for
> me.
>
> Looking at code agains, now I *think* the reason is accessing a global
> variable from __startup_64() inside TDX version of prot_guest_has().
>
> __startup_64() is special. If you access any global variable you need to
> use fixup_pointer(). See comment before __startup_64().
>
> I'm not sure how you get away with accessing sme_me_mask directly from
> there. Any clues? Maybe just a luck and complier generates code just right
> for your case, I donno.
Hmm... yeah, could be that the compiler is using rip-relative addressing
for it because it lives in the .data section?
For the static variables in mem_encrypt_identity.c I did an assembler rip
relative LEA, but probably could have passed physaddr to sme_enable() and
used a fixup_pointer() style function, instead.
>
> A separate point is that TDX version of prot_guest_has() relies on
> cpu_feature_enabled() which is not ready at this point.
Does TDX have to do anything special to make memory able to be shared with
the hypervisor? You might have to use something that is available earlier
than cpu_feature_enabled() in that case (should you eventually support
kvmclock).
>
> I think __bss_decrypted fixup has to be done if sme_me_mask is non-zero.
> Or just do it uncoditionally because it's NOP for sme_me_mask == 0.
For SNP, we'll have to additionally call the HV to update the RMP to make
the memory shared. But that could also be done unconditionally since the
early_snp_set_memory_shared() routine will check for SNP before doing
anything.
Thanks,
Tom
>
>> I think the change you're requesting
>> should be done as part of the TDX support patches so it's clear why it is
>> being changed.
>>
>> But, wouldn't TDX still need to do something with this shared/unencrypted
>> area, though? Or since it is shared, there's actually nothing you need to
>> do (the bss decrpyted section exists even if CONFIG_AMD_MEM_ENCRYPT is not
>> configured)?
>
> AFAICS, only kvmclock uses __bss_decrypted. We don't enable kvmclock in
> TDX at the moment. It may change in the future.
>
Re: [PATCH v6 2/7] soc: mediatek: add mtk-mmsys support for mt8195 vdosys0
Hi Matthias, On Fri, 2021-08-06 at 13:28 +0200, Matthias Brugger wrote: > Hi Jason, > > On 05/08/2021 22:52, jason-jh.lin wrote: > > Add mt8195 vdosys0 clock driver name and routing table to > > the driver data of mtk-mmsys. > > > > I'd like to see the implementation of vdosys1 as well, to better > understand why > we need two compatibles. Do you mean I have to merge this patch and [1] into the same patch? or just add [1] at the same series? or just include [1] at commit message? [1] https://patchwork.kernel.org/project/linux-mediatek/patch/20210722094551.15255-10-nancy@mediatek.com/ > > > Signed-off-by: jason-jh.lin > > --- > > This patch is base on [1] > > > > [1] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20210805171346.24249-2-jason-jh@mediatek.com/__;!!CTRNKA9wMg0ARbw!21Mclcdx-qMIpoqPQOZd_-TuzoUfzzJ8UBC_RDzmvz5ISZQjfJIAhhJDKYBClDfOZb71$ > > > > Please add the binding description to this series. OK, I'll add the binding patch into this series. > > > --- > > drivers/soc/mediatek/mt8195-mmsys.h| 96 > > ++ > > drivers/soc/mediatek/mtk-mmsys.c | 11 +++ > > include/linux/soc/mediatek/mtk-mmsys.h | 9 +++ > > 3 files changed, 116 insertions(+) > > create mode 100644 drivers/soc/mediatek/mt8195-mmsys.h > > > > diff --git a/drivers/soc/mediatek/mt8195-mmsys.h > > b/drivers/soc/mediatek/mt8195-mmsys.h > > new file mode 100644 > > index ..9339a786ec5d > > --- /dev/null > > +++ b/drivers/soc/mediatek/mt8195-mmsys.h > > @@ -0,0 +1,96 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > + > > +#ifndef __SOC_MEDIATEK_MT8195_MMSYS_H > > +#define __SOC_MEDIATEK_MT8195_MMSYS_H > > + > > +#define MT8195_VDO0_OVL_MOUT_EN > > 0xf14 > > +#define MT8195_MOUT_DISP_OVL0_TO_DISP_RDMA0 > > BIT(0) > > +#define MT8195_MOUT_DISP_OVL0_TO_DISP_WDMA0 > > BIT(1) > > +#define MT8195_MOUT_DISP_OVL0_TO_DISP_OVL1 BIT(2) > > +#define MT8195_MOUT_DISP_OVL1_TO_DISP_RDMA1 > > BIT(4) > > +#define MT8195_MOUT_DISP_OVL1_TO_DISP_WDMA1 > > BIT(5) > > +#define MT8195_MOUT_DISP_OVL1_TO_DISP_OVL0 BIT(6) > > + > > +#define MT8195_VDO0_SEL_IN 0xf34 > > +#define MT8195_SEL_IN_VPP_MERGE_FROM_DSC_WRAP0_OUT (0 << > > 0) > > +#define MT8195_SEL_IN_VPP_MERGE_FROM_DISP_DITHER1 (1 << > > 0) > > +#define MT8195_SEL_IN_VPP_MERGE_FROM_VDO1_VIRTUAL0 (2 << > > 0) > > +#define MT8195_SEL_IN_DSC_WRAP0_IN_FROM_DISP_DITHER0 > > (0 << 4) > > +#define MT8195_SEL_IN_DSC_WRAP0_IN_FROM_VPP_MERGE (1 << > > 4) > > +#define MT8195_SEL_IN_DSC_WRAP1_IN_FROM_DISP_DITHER1 > > (0 << 5) > > +#define MT8195_SEL_IN_DSC_WRAP1_IN_FROM_VPP_MERGE (1 << > > 5) > > +#define MT8195_SEL_IN_SINA_VIRTUAL0_FROM_VPP_MERGE (0 << > > 8) > > +#define MT8195_SEL_IN_SINA_VIRTUAL0_FROM_DSC_WRAP1_OUT > > (1 << 8) > > +#define MT8195_SEL_IN_SINB_VIRTUAL0_FROM_DSC_WRAP0_OUT > > (0 << 9) > > +#define MT8195_SEL_IN_DP_INTF0_FROM_DSC_WRAP1_OUT (0 << > > 12) > > +#define MT8195_SEL_IN_DP_INTF0_FROM_VPP_MERGE > > (1 << 12) > > +#define MT8195_SEL_IN_DP_INTF0_FROM_VDO1_VIRTUAL0 (2 << > > 12) > > +#define MT8195_SEL_IN_DSI0_FROM_DSC_WRAP0_OUT > > (0 << 16) > > +#define MT8195_SEL_IN_DSI0_FROM_DISP_DITHER0 > > (1 << 16) > > +#define MT8195_SEL_IN_DSI1_FROM_DSC_WRAP1_OUT > > (0 << 17) > > +#define MT8195_SEL_IN_DSI1_FROM_VPP_MERGE (1 << > > 17) > > +#define MT8195_SEL_IN_DISP_WDMA1_FROM_DISP_OVL1 > > (0 << 20) > > +#define MT8195_SEL_IN_DISP_WDMA1_FROM_VPP_MERGE > > (1 << 20) > > +#define MT8195_SEL_IN_DSC_WRAP1_OUT_FROM_DSC_WRAP1_IN > > (0 << 21) > > +#define MT8195_SEL_IN_DSC_WRAP1_OUT_FROM_DISP_DITHER1 > > (1 << 21) > > +#define MT8195_SEL_IN_DISP_WDMA0_FROM_DISP_OVL0 > > (0 << 22) > > +#define MT8195_SEL_IN_DISP_WDMA0_FROM_VPP_MERGE > > (1 << 22) > > + > > +#define MT8195_VDO0_SEL_OUT > > 0xf38 > > +#define MT8195_SOUT_DISP_DITHER0_TO_DSC_WRAP0_IN (0 << > > 0) > > +#define MT8195_SOUT_DISP_DITHER0_TO_DSI0 (1 << > > 0) > > +#define MT8195_SOUT_DISP_DITHER1_TO_DSC_WRAP1_IN (0 << > > 1) > > +#define MT8195_SOUT_DISP_DITHER1_TO_VPP_MERGE > > (1 << 1) > > +#define MT8195_SOUT_DISP_DITHER1_TO_DSC_WRAP1_OUT (2 << > > 1) > > +#define MT8195_SOUT_VDO1_VIRTUAL0_TO_VPP_MERGE > > (0 << 4) > > +#define MT8195_SOUT_VDO1_VIRTUAL0_TO_DP_INTF0 > > (1 << 4) > > +#define M
Re: [PATCH v6 6/7] drm/mediatek: add MERGE support for mediatek-drm
On Sat, 2021-08-07 at 01:10 +0800, Chun-Kuang Hu wrote: > Hi, Jason: > > jason-jh.lin 於 2021年8月6日 週五 上午4:52寫道： > > > > Add MERGE engine file: > > MERGE module is used to merge two slice-per-line inputs > > into one side-by-side output. > > > > Signed-off-by: jason-jh.lin > > --- > > This patch is base on [1] > > > > [1] dt-bindings: mediatek: display: add mt8195 SoC binding > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20210805171346.24249-5-jason-jh@mediatek.com/__;!!CTRNKA9wMg0ARbw!yUTG6rzENI8VUIZjGy5JTWKNX2TyyJn_wn66Wnx2J2GxzFaIhl21IuF8ZlfTqAyj6ahi$ > > > > --- > > drivers/gpu/drm/mediatek/Makefile | 1 + > > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 8 + > > drivers/gpu/drm/mediatek/mtk_disp_merge.c | 263 > > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 + > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +- > > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 + > > 6 files changed, 277 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_merge.c > > > > diff --git a/drivers/gpu/drm/mediatek/Makefile > > b/drivers/gpu/drm/mediatek/Makefile > > index dc54a7a69005..538e0087a44c 100644 > > --- a/drivers/gpu/drm/mediatek/Makefile > > +++ b/drivers/gpu/drm/mediatek/Makefile > > @@ -3,6 +3,7 @@ > > mediatek-drm-y := mtk_disp_ccorr.o \ > > mtk_disp_color.o \ > > mtk_disp_gamma.o \ > > + mtk_disp_merge.o \ > > mtk_disp_ovl.o \ > > mtk_disp_rdma.o \ > > mtk_drm_crtc.o \ > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h > > b/drivers/gpu/drm/mediatek/mtk_disp_drv.h > > index cafd9df2d63b..f407cd9d873e 100644 > > --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h > > @@ -46,6 +46,14 @@ void mtk_gamma_set_common(void __iomem *regs, > > struct drm_crtc_state *state); > > void mtk_gamma_start(struct device *dev); > > void mtk_gamma_stop(struct device *dev); > > > > +int mtk_merge_clk_enable(struct device *dev); > > +void mtk_merge_clk_disable(struct device *dev); > > +void mtk_merge_config(struct device *dev, unsigned int width, > > + unsigned int height, unsigned int vrefresh, > > + unsigned int bpc, struct cmdq_pkt *cmdq_pkt); > > +void mtk_merge_start(struct device *dev); > > +void mtk_merge_stop(struct device *dev); > > + > > void mtk_ovl_bgclr_in_on(struct device *dev); > > void mtk_ovl_bgclr_in_off(struct device *dev); > > void mtk_ovl_bypass_shadow(struct device *dev); > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_merge.c > > b/drivers/gpu/drm/mediatek/mtk_disp_merge.c > > new file mode 100644 > > index ..f3d262792054 > > --- /dev/null > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_merge.c > > @@ -0,0 +1,263 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (c) 2021 MediaTek Inc. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "mtk_drm_ddp_comp.h" > > +#include "mtk_drm_drv.h" > > +#include "mtk_disp_drv.h" > > + > > +#define DISP_REG_MERGE_CTRL0x000 > > +#define MERGE_EN 1 > > One more indent for the bitwise value. OK, I'll fix this. > > > +#define DISP_REG_MERGE_CFG_0 0x010 > > +#define DISP_REG_MERGE_CFG_4 0x020 > > +#define DISP_REG_MERGE_CFG_10 0x038 > > +/* no swap */ > > +#define SWAP_MODE 0 > > +#define FLD_SWAP_MODE GENMASK(4, 0) > > +#define DISP_REG_MERGE_CFG_12 0x040 > > +#define CFG_10_10_1PI_2PO_BUF_MODE 6 > > +#define CFG_10_10_2PI_2PO_BUF_MODE 8 > > +#define FLD_CFG_MERGE_MODE GENMASK(4, 0) > > +#define DISP_REG_MERGE_CFG_24 0x070 > > +#define DISP_REG_MERGE_CFG_25 0x074 > > +#define DISP_REG_MERGE_CFG_36 0x0a0 > > +#define ULTRA_EN 1 > > +#define PREULTRA_EN1 > > +#define HALT_FOR_DVFS_EN 0 > > +#define FLD_ULTRA_EN GENMASK(0, 0) > > +#define FLD_PREULTRA_ENGENMASK(4, 4) > > +#define FLD_HALT_FOR_DVFS_EN GENMASK(8, 8) > > +#define DISP_REG_MERGE_CFG_37 0x0a4 > > +/* 0: Off, 1: SRAM0, 2: SRAM1, 3: SRAM0 + SRAM1 */ > > +#define BUFFER_MODE3 > > +#define FLD_BUFFER_MODEGENMASK(1, 0) > > +#define DISP_REG_MERGE_CFG_38 0x0a8 > > +#define FLD_VDE_BLOCK_ULTRAGENMASK(0, 0) > > +#define FLD_VALID_TH_BLOCK_ULTRA GENMASK(4, 4) > > +#define FLD_ULTRA_FIFO_VALID_THGENMASK(31, 16) > > +#define DISP_REG_MERGE_CFG_39 0x0ac > > +#define FLD_NVDE_FORCE_PREULTRAGENMASK(8, 8) > > +#define FLD_NVALID_TH_FORCE_PREULTRA GENMASK(12, 12) > > +#define FLD_PREULTRA_FIFO_VALID_T
Re: [PATCH v2 4/6] drm/bridge: ti-sn65dsi86: Wrap panel with panel-bridge
On Wed, Aug 11, 2021 at 5:15 AM Laurent Pinchart wrote: > > Hi Stephen, > > On Tue, Aug 10, 2021 at 10:26:33PM -0700, Stephen Boyd wrote: > > Quoting Laurent Pinchart (2021-06-23 17:03:02) > > > To simplify interfacing with the panel, wrap it in a panel-bridge and > > > let the DRM bridge helpers handle chaining of operations. > > > > > > This also prepares for support of DRM_BRIDGE_ATTACH_NO_CONNECTOR, which > > > requires all components in the display pipeline to be represented by > > > bridges. > > > > > > Signed-off-by: Laurent Pinchart > > > > > > Reviewed-by: Jagan Teki > > > --- > > > > With this patch applied I get two eDP devices on Lazor sc7180 (it is the > > arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor*.dts files if you're > > looking for more info). As far as I can tell, we should only have one > > eDP device on the board, for the bridge. > > > > localhost ~ # ls -l /sys/class/drm/card1-eDP* > > lrwxrwxrwx. 1 root root 0 Aug 10 22:24 /sys/class/drm/card1-eDP-1 -> > > ../../devices/platform/soc@0/ae0.mdss/drm/card1/card1-eDP-1 > > lrwxrwxrwx. 1 root root 0 Aug 10 22:24 /sys/class/drm/card1-eDP-2 -> > > ../../devices/platform/soc@0/ae0.mdss/drm/card1/card1-eDP-2 > > Indeed. > > Does the display driver use the DRM connector bridge helper and > DRM_BRIDGE_ATTACH_NO_CONNECTOR on that platform ? > There haven't been any recent changes about how we attach the bridge, it doesn't pass DRM_BRIDGE_ATTACH_NO_CONNECTOR.. tbh I've not been having time to follow too closely the recent changes with bridge stuff myself. But now with this patch we have both the ti bridge and the panel bridge creating a connector.. removing the connector created by the ti bridge "fixes" things, but not sure if that would break something on other platforms. I guess there should now always be a panel bridge, so removing ti_sn_bridge_connector_init() would be a sane thing to do? BR, -R
Re: [PATCH v6 5/7] drm/mediatek: add DSC support for mediatek-drm
Hi CK,
On Sat, 2021-08-07 at 00:44 +0800, Chun-Kuang Hu wrote:
> Hi, Jason:
>
> jason-jh.lin 於 2021年8月6日 週五 上午4:52寫道：
> >
> > DSC is designed for real-time systems with real-time compression,
> > transmission, decompression and display.
> > The DSC standard is a specification of the algorithms used for
> > compressing and decompressing image display streams, including
> > the specification of the syntax and semantics of the compressed
> > video bit stream.
> >
> > Signed-off-by: jason-jh.lin
> > ---
> > This patch is base on [1]
> >
> > [1] dt-bindings: mediatek: add mediatek, dsc.yaml for mt8195 SoC
> > binding
> >
https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20210805171346.24249-4-jason-jh@mediatek.com/__;!!CTRNKA9wMg0ARbw!z1RWCIbQoMLarG_-uxUAQS__rpGyCB2Xk7IFVb_Vbo-RoXrWDE4cLvcERABbW11zbL1o$
> >
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 62
> > +
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> > 2 files changed, 63 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index 328ee19f931e..24c7b004fe4d 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -43,6 +43,12 @@
> > #define DITHER_LSB_ERR_SHIFT_G(x) (((x) & 0x7) << 12)
> > #define DITHER_ADD_LSHIFT_G(x) (((x) & 0x7) << 4)
> >
> > +#define DISP_REG_DSC_CON 0x
> > +#define DSC_EN BIT(0)
> > +#define DSC_DUAL_INOUT BIT(2)
> > +#define DSC_BYPASS BIT(4)
> > +#define DSC_UFOE_SEL BIT(16)
> > +
> > #define DISP_REG_OD_EN 0x
> > #define DISP_REG_OD_CFG0x0020
> > #define OD_RELAYMODE BIT(0)
> > @@ -209,6 +215,35 @@ static void mtk_dither_set(struct device *dev,
> > unsigned int bpc,
> > DISP_DITHERING, cmdq_pkt);
> > }
> >
> > +static void mtk_dsc_config(struct device *dev, unsigned int w,
> > + unsigned int h, unsigned int vrefresh,
> > + unsigned int bpc, struct cmdq_pkt
> > *cmdq_pkt)
> > +{
> > + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> > +
> > + /* dsc bypass mode */
> > + mtk_ddp_write_mask(cmdq_pkt, DSC_BYPASS, &priv->cmdq_reg,
> > priv->regs,
> > + DISP_REG_DSC_CON, DSC_BYPASS);
> > + mtk_ddp_write_mask(cmdq_pkt, DSC_UFOE_SEL, &priv->cmdq_reg,
> > priv->regs,
> > + DISP_REG_DSC_CON, DSC_UFOE_SEL);
> > + mtk_ddp_write_mask(cmdq_pkt, DSC_DUAL_INOUT, &priv-
> > >cmdq_reg, priv->regs,
> > + DISP_REG_DSC_CON, DSC_DUAL_INOUT);
> > +}
> > +
> > +static void mtk_dsc_start(struct device *dev)
> > +{
> > + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> > +
> > + writel_relaxed(DSC_EN, &priv->regs + DISP_REG_DSC_CON);
> > +}
> > +
> > +static void mtk_dsc_stop(struct device *dev)
> > +{
> > + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> > +
> > + writel_relaxed(0x0, priv->regs + DISP_REG_DSC_CON);
> > +}
> > +
> > static void mtk_od_config(struct device *dev, unsigned int w,
> > unsigned int h, unsigned int vrefresh,
> > unsigned int bpc, struct cmdq_pkt
> > *cmdq_pkt)
> > @@ -272,6 +307,14 @@ static const struct mtk_ddp_comp_funcs ddp_dpi
> > = {
> > .stop = mtk_dpi_stop,
> > };
> >
> > +static const struct mtk_ddp_comp_funcs ddp_dsc = {
> > + .clk_enable = mtk_ddp_clk_enable,
> > + .clk_disable = mtk_ddp_clk_disable,
> > + .config = mtk_dsc_config,
> > + .start = mtk_dsc_start,
> > + .stop = mtk_dsc_stop,
> > +};
> > +
> > static const struct mtk_ddp_comp_funcs ddp_dsi = {
> > .start = mtk_dsi_ddp_start,
> > .stop = mtk_dsi_ddp_stop,
> > @@ -286,6 +329,14 @@ static const struct mtk_ddp_comp_funcs
> > ddp_gamma = {
> > .stop = mtk_gamma_stop,
> > };
> >
> > +static const struct mtk_ddp_comp_funcs ddp_merge = {
> > + .clk_enable = mtk_merge_clk_enable,
> > + .clk_disable = mtk_merge_clk_disable,
> > + .start = mtk_merge_start,
> > + .stop = mtk_merge_stop,
> > + .config = mtk_merge_config,
> > +};
>
> Move the merge modification to the patch of merge.
> > +
> > static const struct mtk_ddp_comp_funcs ddp_od = {
> > .clk_enable = mtk_ddp_clk_enable,
> > .clk_disable = mtk_ddp_clk_disable,
> > @@ -333,7 +384,9 @@ static const char * const
> > mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
> > [MTK_DISP_CCORR] = "ccorr",
> > [MTK_DISP_COLOR] = "color",
> > [MTK_DISP_DITHER] = "dither",
> > + [MTK_DISP_DSC] = "dsc",
> > [MT
Re: [PATCH v6 4/7] drm/mediatek: adjust to the alphabetic order for mediatek-drm
Hi CK,
On Mon, 2021-08-09 at 22:34 +0800, Chun-Kuang Hu wrote:
> Hi, Jason:
>
> jason-jh.lin 於 2021年8月6日 週五 上午4:52寫道：
> >
> > 1. Adjust to the alphabetic order for the define, function, struct
> >and array in mediatek-drm driver
> > 2. Remove the unsed define in mtk_drm_ddp_comp.c
>
> Separate the 2nd part to another patch.
OK, I'll separate them.
>
> >
> > Signed-off-by: jason-jh.lin
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 180 +---
> >
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 22 +--
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 76 -
> > 3 files changed, 133 insertions(+), 145 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index 75bc00e17fc4..328ee19f931e 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -20,50 +20,36 @@
> > #include "mtk_drm_ddp_comp.h"
> > #include "mtk_drm_crtc.h"
> >
> > -#define DISP_OD_EN 0x
> > -#define DISP_OD_INTEN 0x0008
> > -#define DISP_OD_INTSTA 0x000c
> > -#define DISP_OD_CFG0x0020
> > -#define DISP_OD_SIZE 0x0030
> > -#define DISP_DITHER_5 0x0114
> > -#define DISP_DITHER_7 0x011c
> > -#define DISP_DITHER_15 0x013c
> > -#define DISP_DITHER_16 0x0140
> > -
> > -#define DISP_REG_UFO_START 0x
> > -
> > -#define DISP_AAL_EN0x
> > -#define DISP_AAL_SIZE 0x0030
> > +#define DISP_REG_AAL_EN0x
> > +#define AAL_EN BIT(0)
> > +#define DISP_REG_AAL_SIZE 0x0030
> >
> > -#define DISP_DITHER_EN 0x
> > +#define DISP_REG_DITHER_EN 0x
>
> I think we should not change the register name just for alphabetic
> order. We list the register in the order of its address.
> If you have another reason to change register name, add another patch
> to do this.
>
> Regards,
> Chun-Kuang.
I think using DISP_REG prifix can identify the macro of register offset
and register value.
So I'll revert the changing of register name in this alphabetic order
patch and send this into another patch.
Regards,
Jason-JH.Lin
>
> > #define DITHER_EN BIT(0)
> > -#define DISP_DITHER_CFG0x0020
> > +#define DISP_REG_DITHER_CFG0x0020
> > #define DITHER_RELAY_MODE BIT(0)
> > #define DITHER_ENGINE_EN BIT(1)
> > -#define DISP_DITHER_SIZE 0x0030
> > -
> > -#define LUT_10BIT_MASK 0x03ff
> > -
> > -#define OD_RELAYMODE BIT(0)
> > -
> > -#define UFO_BYPASS BIT(2)
> > -
> > -#define AAL_EN BIT(0)
> > -
> > #define DISP_DITHERING BIT(2)
> > +#define DISP_REG_DITHER_SIZE 0x0030
> > +#define DISP_REG_DITHER_5 0x0114
> > +#define DISP_REG_DITHER_7 0x011c
> > +#define DISP_REG_DITHER_15 0x013c
> > #define DITHER_LSB_ERR_SHIFT_R(x) (((x) & 0x7) << 28)
> > -#define DITHER_OVFLW_BIT_R(x) (((x) & 0x7) << 24)
> > #define DITHER_ADD_LSHIFT_R(x) (((x) & 0x7) << 20)
> > -#define DITHER_ADD_RSHIFT_R(x) (((x) & 0x7) << 16)
> > #define DITHER_NEW_BIT_MODEBIT(0)
> > +#define DISP_REG_DITHER_16 0x0140
> > #define DITHER_LSB_ERR_SHIFT_B(x) (((x) & 0x7) << 28)
> > -#define DITHER_OVFLW_BIT_B(x) (((x) & 0x7) << 24)
> > #define DITHER_ADD_LSHIFT_B(x) (((x) & 0x7) << 20)
> > -#define DITHER_ADD_RSHIFT_B(x) (((x) & 0x7) << 16)
> > #define DITHER_LSB_ERR_SHIFT_G(x) (((x) & 0x7) << 12)
> > -#define DITHER_OVFLW_BIT_G(x) (((x) & 0x7) << 8)
> > #define DITHER_ADD_LSHIFT_G(x) (((x) & 0x7) << 4)
> > -#define DITHER_ADD_RSHIFT_G(x) (((x) & 0x7) << 0)
> > +
> > +#define DISP_REG_OD_EN 0x
> > +#define DISP_REG_OD_CFG0x0020
> > +#define OD_RELAYMODE BIT(0)
> > +#define DISP_REG_OD_SIZE 0x0030
> > +
> > +#define DISP_REG_UFO_START 0x
> > +#define UFO_BYPASS BIT(2)
> >
> > struct mtk_ddp_comp_dev {
> > struct clk *clk;
> > @@ -116,20 +102,6 @@ void mtk_ddp_write_mask(struct cmdq_pkt
> > *cmdq_pkt, unsigned int value,
> > #endif
> > }
[PATCH v4 4/6] drm/msm/dp: replug event is converted into an unplug followed by an plug events
Remove special handling of replug interrupt and instead treat replug event
as a sequential unplug followed by a plugin event. This is needed to meet
the requirements of DP Link Layer CTS test case 4.2.1.3.
Changes in V2:
-- add fixes statement
Changes in V3:
-- delete EV_HPD_REPLUG_INT
Fixes: f21c8a276c2d ("drm/msm/dp: handle irq_hpd with sink_count = 0 correctly")
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_display.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 78c5301..aa96272 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -55,7 +55,6 @@ enum {
EV_HPD_INIT_SETUP,
EV_HPD_PLUG_INT,
EV_IRQ_HPD_INT,
- EV_HPD_REPLUG_INT,
EV_HPD_UNPLUG_INT,
EV_USER_NOTIFICATION,
EV_CONNECT_PENDING_TIMEOUT,
@@ -1146,9 +1145,6 @@ static int hpd_event_thread(void *data)
case EV_IRQ_HPD_INT:
dp_irq_hpd_handle(dp_priv, todo->data);
break;
- case EV_HPD_REPLUG_INT:
- /* do nothing */
- break;
case EV_USER_NOTIFICATION:
dp_display_send_hpd_notification(dp_priv,
todo->data);
@@ -1192,10 +1188,8 @@ static irqreturn_t dp_display_irq_handler(int irq, void
*dev_id)
if (hpd_isr_status & 0x0F) {
/* hpd related interrupts */
- if (hpd_isr_status & DP_DP_HPD_PLUG_INT_MASK ||
- hpd_isr_status & DP_DP_HPD_REPLUG_INT_MASK) {
+ if (hpd_isr_status & DP_DP_HPD_PLUG_INT_MASK)
dp_add_event(dp, EV_HPD_PLUG_INT, 0, 0);
- }
if (hpd_isr_status & DP_DP_IRQ_HPD_INT_MASK) {
/* stop sentinel connect pending checking */
@@ -1203,8 +1197,10 @@ static irqreturn_t dp_display_irq_handler(int irq, void
*dev_id)
dp_add_event(dp, EV_IRQ_HPD_INT, 0, 0);
}
- if (hpd_isr_status & DP_DP_HPD_REPLUG_INT_MASK)
- dp_add_event(dp, EV_HPD_REPLUG_INT, 0, 0);
+ if (hpd_isr_status & DP_DP_HPD_REPLUG_INT_MASK) {
+ dp_add_event(dp, EV_HPD_UNPLUG_INT, 0, 0);
+ dp_add_event(dp, EV_HPD_PLUG_INT, 0, 3);
+ }
if (hpd_isr_status & DP_DP_HPD_UNPLUG_INT_MASK)
dp_add_event(dp, EV_HPD_UNPLUG_INT, 0, 0);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v4 0/6] add fixes to pass DP Link Layer compliance test cases
drm/msm/dp: add fixes to pass DP Link Layer compliance test cases Kuogee Hsieh (6): drm/msm/dp: use dp_ctrl_off_link_stream during PHY compliance test run drm/msm/dp: reduce link rate if failed at link training 1 drm/msm/dp: reset aux controller after dp_aux_cmd_fifo_tx() failed. drm/msm/dp: replug event is converted into an unplug followed by an plug events drm/msm/dp: return correct edid checksum after corrupted edid checksum read drm/msm/dp: do not end dp link training until video is ready drivers/gpu/drm/msm/dp/dp_aux.c | 3 + drivers/gpu/drm/msm/dp/dp_ctrl.c| 137 +++- drivers/gpu/drm/msm/dp/dp_display.c | 14 ++-- drivers/gpu/drm/msm/dp/dp_panel.c | 9 ++- 4 files changed, 102 insertions(+), 61 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v4 3/6] drm/msm/dp: reset aux controller after dp_aux_cmd_fifo_tx() failed.
Aux hardware calibration sequence requires resetting the aux controller
in order for the new setting to take effect. However resetting the AUX
controller will also clear HPD interrupt status which may accidentally
cause pending unplug interrupt to get lost. Therefore reset aux
controller only when link is in connection state when dp_aux_cmd_fifo_tx()
fail. This fixes Link Layer CTS cases 4.2.1.1 and 4.2.1.2.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_aux.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 4a3293b..eb40d84 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -353,6 +353,9 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
if (!(aux->retry_cnt % MAX_AUX_RETRIES))
dp_catalog_aux_update_cfg(aux->catalog);
}
+ /* reset aux if link is in connected state */
+ if (dp_catalog_link_is_connected(aux->catalog))
+ dp_catalog_aux_reset(aux->catalog);
} else {
aux->retry_cnt = 0;
switch (aux->aux_error_num) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v4 1/6] drm/msm/dp: use dp_ctrl_off_link_stream during PHY compliance test run
DP cable should always connect to DPU during the entire PHY compliance
testing run. Since DP PHY compliance test is executed at irq_hpd event
context, dp_ctrl_off_link_stream() should be used instead of dp_ctrl_off().
dp_ctrl_off() is used for unplug event which is triggered when DP cable is
dis connected.
Changes in V2:
-- add fixes statement
Fixes: f21c8a276c2d ("drm/msm/dp: handle irq_hpd with sink_count = 0 correctly")
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index caf71fa..27fb0f0 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1530,7 +1530,7 @@ static int dp_ctrl_process_phy_test_request(struct
dp_ctrl_private *ctrl)
* running. Add the global reset just before disabling the
* link clocks and core clocks.
*/
- ret = dp_ctrl_off(&ctrl->dp_ctrl);
+ ret = dp_ctrl_off_link_stream(&ctrl->dp_ctrl);
if (ret) {
DRM_ERROR("failed to disable DP controller\n");
return ret;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v4 6/6] drm/msm/dp: do not end dp link training until video is ready
Initialize both pre-emphasis and voltage swing level to 0 before
start link training and do not end link training until video is
ready to reduce the period between end of link training and video
start to meet Link Layer CTS requirement. Some dongle main link
symbol may become unlocked again if host did not end link training
soon enough after completion of link training 2. Host have to re
train main link if loss of symbol locked detected before end link
training so that the coming video stream can be transmitted to sink
properly. This fixes Link Layer CTS cases 4.3.2.1, 4.3.2.2, 4.3.2.3
and 4.3.2.4.
Changes in v3:
-- merge retrain link if loss of symbol locked happen into this patch
-- replace dp_ctrl_loss_symbol_lock() with dp_ctrl_channel_eq_ok()
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 56 +---
1 file changed, 41 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 0002805..ffed523 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1484,6 +1484,9 @@ static int dp_ctrl_link_maintenance(struct
dp_ctrl_private *ctrl)
dp_ctrl_push_idle(&ctrl->dp_ctrl);
+ ctrl->link->phy_params.p_level = 0;
+ ctrl->link->phy_params.v_level = 0;
+
ctrl->dp_ctrl.pixel_rate = ctrl->panel->dp_mode.drm_mode.clock;
ret = dp_ctrl_setup_main_link(ctrl, &training_step);
@@ -1636,6 +1639,16 @@ static bool dp_ctrl_clock_recovery_any_ok(
return drm_dp_clock_recovery_ok(link_status, reduced_cnt);
}
+static bool dp_ctrl_channel_eq_ok(struct dp_ctrl_private *ctrl)
+{
+ u8 link_status[DP_LINK_STATUS_SIZE];
+ int num_lanes = ctrl->link->link_params.num_lanes;
+
+ dp_ctrl_read_link_status(ctrl, link_status);
+
+ return drm_dp_channel_eq_ok(link_status, num_lanes);
+}
+
int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
{
int rc = 0;
@@ -1671,6 +1684,9 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
ctrl->link->link_params.rate,
ctrl->link->link_params.num_lanes, ctrl->dp_ctrl.pixel_rate);
+ ctrl->link->phy_params.p_level = 0;
+ ctrl->link->phy_params.v_level = 0;
+
rc = dp_ctrl_enable_mainlink_clocks(ctrl);
if (rc)
return rc;
@@ -1736,17 +1752,19 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
if (ctrl->link->sink_request & DP_TEST_LINK_PHY_TEST_PATTERN)
return rc;
- /* stop txing train pattern */
- dp_ctrl_clear_training_pattern(ctrl);
+ if (rc == 0) { /* link train successfully */
+ /*
+* do not stop train pattern here
+* stop link training at on_stream
+* to pass compliance test
+*/
+ } else {
+ /*
+* link training failed
+* end txing train pattern here
+*/
+ dp_ctrl_clear_training_pattern(ctrl);
- /*
-* keep transmitting idle pattern until video ready
-* to avoid main link from loss of sync
-*/
- if (rc == 0) /* link train successfully */
- dp_ctrl_push_idle(dp_ctrl);
- else {
- /* link training failed */
dp_ctrl_deinitialize_mainlink(ctrl);
rc = -ECONNRESET;
}
@@ -1754,9 +1772,15 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
return rc;
}
+static int dp_ctrl_link_retrain(struct dp_ctrl_private *ctrl)
+{
+ int training_step = DP_TRAINING_NONE;
+
+ return dp_ctrl_setup_main_link(ctrl, &training_step);
+}
+
int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl)
{
- u32 rate = 0;
int ret = 0;
bool mainlink_ready = false;
struct dp_ctrl_private *ctrl;
@@ -1766,10 +1790,6 @@ int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl)
ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
- rate = ctrl->panel->link_info.rate;
-
- ctrl->link->link_params.rate = rate;
- ctrl->link->link_params.num_lanes = ctrl->panel->link_info.num_lanes;
ctrl->dp_ctrl.pixel_rate = ctrl->panel->dp_mode.drm_mode.clock;
DRM_DEBUG_DP("rate=%d, num_lanes=%d, pixel_rate=%d\n",
@@ -1784,6 +1804,12 @@ int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl)
}
}
+ if (!dp_ctrl_channel_eq_ok(ctrl))
+ dp_ctrl_link_retrain(ctrl);
+
+ /* stop txing train pattern to end link training */
+ dp_ctrl_clear_training_pattern(ctrl);
+
ret = dp_ctrl_enable_stream_clocks(ctrl);
if (ret) {
DRM_ERROR("Failed to start pixel clocks. ret=%d\n", ret);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v4 5/6] drm/msm/dp: return correct edid checksum after corrupted edid checksum read
Response with correct edid checksum saved at connector after corrupted edid
checksum read. This fixes Link Layer CTS cases 4.2.2.3, 4.2.2.6.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_panel.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 88196f7..0fdb551 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -271,7 +271,7 @@ static u8 dp_panel_get_edid_checksum(struct edid *edid)
{
struct edid *last_block;
u8 *raw_edid;
- bool is_edid_corrupt;
+ bool is_edid_corrupt = false;
if (!edid) {
DRM_ERROR("invalid edid input\n");
@@ -303,7 +303,12 @@ void dp_panel_handle_sink_request(struct dp_panel
*dp_panel)
panel = container_of(dp_panel, struct dp_panel_private, dp_panel);
if (panel->link->sink_request & DP_TEST_LINK_EDID_READ) {
- u8 checksum = dp_panel_get_edid_checksum(dp_panel->edid);
+ u8 checksum;
+
+ if (dp_panel->edid)
+ checksum = dp_panel_get_edid_checksum(dp_panel->edid);
+ else
+ checksum = dp_panel->connector->real_edid_checksum;
dp_link_send_edid_checksum(panel->link, checksum);
dp_link_send_test_response(panel->link);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v4 2/6] drm/msm/dp: reduce link rate if failed at link training 1
Reduce link rate and re start link training if link training 1
failed due to loss of clock recovery done to fix Link Layer
CTS case 4.3.1.7. Also only update voltage and pre-emphasis
swing level after link training started to fix Link Layer CTS
case 4.3.1.6.
Changes in V2:
-- replaced cr_status with link_status[DP_LINK_STATUS_SIZE]
-- replaced dp_ctrl_any_lane_cr_done() with dp_ctrl_colco_recovery_any_ok()
-- replaced dp_ctrl_any_ane_cr_lose() with !drm_dp_clock_recovery_ok()
Changes in V3:
-- return failed if lane_count <= 1
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 79 +++-
1 file changed, 45 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 27fb0f0..0002805 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -83,13 +83,6 @@ struct dp_ctrl_private {
struct completion video_comp;
};
-struct dp_cr_status {
- u8 lane_0_1;
- u8 lane_2_3;
-};
-
-#define DP_LANE0_1_CR_DONE 0x11
-
static int dp_aux_link_configure(struct drm_dp_aux *aux,
struct dp_link_info *link)
{
@@ -1080,7 +1073,7 @@ static int dp_ctrl_read_link_status(struct
dp_ctrl_private *ctrl,
}
static int dp_ctrl_link_train_1(struct dp_ctrl_private *ctrl,
- struct dp_cr_status *cr, int *training_step)
+ int *training_step)
{
int tries, old_v_level, ret = 0;
u8 link_status[DP_LINK_STATUS_SIZE];
@@ -1109,9 +1102,6 @@ static int dp_ctrl_link_train_1(struct dp_ctrl_private
*ctrl,
if (ret)
return ret;
- cr->lane_0_1 = link_status[0];
- cr->lane_2_3 = link_status[1];
-
if (drm_dp_clock_recovery_ok(link_status,
ctrl->link->link_params.num_lanes)) {
return 0;
@@ -1188,7 +1178,7 @@ static void dp_ctrl_clear_training_pattern(struct
dp_ctrl_private *ctrl)
}
static int dp_ctrl_link_train_2(struct dp_ctrl_private *ctrl,
- struct dp_cr_status *cr, int *training_step)
+ int *training_step)
{
int tries = 0, ret = 0;
char pattern;
@@ -1204,10 +1194,6 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private
*ctrl,
else
pattern = DP_TRAINING_PATTERN_2;
- ret = dp_ctrl_update_vx_px(ctrl);
- if (ret)
- return ret;
-
ret = dp_catalog_ctrl_set_pattern(ctrl->catalog, pattern);
if (ret)
return ret;
@@ -1220,8 +1206,6 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private
*ctrl,
ret = dp_ctrl_read_link_status(ctrl, link_status);
if (ret)
return ret;
- cr->lane_0_1 = link_status[0];
- cr->lane_2_3 = link_status[1];
if (drm_dp_channel_eq_ok(link_status,
ctrl->link->link_params.num_lanes)) {
@@ -1241,7 +1225,7 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private
*ctrl,
static int dp_ctrl_reinitialize_mainlink(struct dp_ctrl_private *ctrl);
static int dp_ctrl_link_train(struct dp_ctrl_private *ctrl,
- struct dp_cr_status *cr, int *training_step)
+ int *training_step)
{
int ret = 0;
u8 encoding = DP_SET_ANSI_8B10B;
@@ -1257,7 +1241,7 @@ static int dp_ctrl_link_train(struct dp_ctrl_private
*ctrl,
drm_dp_dpcd_write(ctrl->aux, DP_MAIN_LINK_CHANNEL_CODING_SET,
&encoding, 1);
- ret = dp_ctrl_link_train_1(ctrl, cr, training_step);
+ ret = dp_ctrl_link_train_1(ctrl, training_step);
if (ret) {
DRM_ERROR("link training #1 failed. ret=%d\n", ret);
goto end;
@@ -1266,7 +1250,7 @@ static int dp_ctrl_link_train(struct dp_ctrl_private
*ctrl,
/* print success info as this is a result of user initiated action */
DRM_DEBUG_DP("link training #1 successful\n");
- ret = dp_ctrl_link_train_2(ctrl, cr, training_step);
+ ret = dp_ctrl_link_train_2(ctrl, training_step);
if (ret) {
DRM_ERROR("link training #2 failed. ret=%d\n", ret);
goto end;
@@ -1282,7 +1266,7 @@ static int dp_ctrl_link_train(struct dp_ctrl_private
*ctrl,
}
static int dp_ctrl_setup_main_link(struct dp_ctrl_private *ctrl,
- struct dp_cr_status *cr, int *training_step)
+ int *training_step)
{
int ret = 0;
@@ -1297,7 +1281,7 @@ static int dp_ctrl_setup_main_link(struct dp_ctrl_private
*ctrl,
* a link training pattern, we have to first do soft reset.
*/
- ret = dp_ctrl_link_train(ctrl, cr, training_step);
+ ret = dp_ctrl_link_train(ctrl, training_step);
return ret;
}
@@ -1496,14 +1480,13 @@ static int d
[PATCH 1/2] drm/amdgpu: Use mod_delayed_work in amdgpu_gfx_off_ctrl
From: Michel Dänzer
In contrast to schedule_delayed_work, this pushes back the work if it
was already scheduled before. Specific behaviour change:
Before:
amdgpu_device_delay_enable_gfx_off ran ~100 ms after the first time
GFXOFF was disabled and re-enabled, even if GFXOFF was disabled and
re-enabled again during those 100 ms.
After:
amdgpu_device_delay_enable_gfx_off runs ~100 ms after the last time
GFXOFF is disabled and re-enabled.
The former resulted in frame drops / stutter with the upcoming mutter
41 release on Navi 14, due to constantly enabling GFXOFF in the HW and
disabling it again (for getting the GPU clock counter).
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index a0be0772c8b3..9cfef56b2aee 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -569,7 +569,7 @@ void amdgpu_gfx_off_ctrl(struct amdgpu_device *adev, bool
enable)
adev->gfx.gfx_off_req_count--;
if (enable && !adev->gfx.gfx_off_state && !adev->gfx.gfx_off_req_count)
{
- schedule_delayed_work(&adev->gfx.gfx_off_delay_work,
GFX_OFF_DELAY_ENABLE);
+ mod_delayed_work(system_wq, &adev->gfx.gfx_off_delay_work,
GFX_OFF_DELAY_ENABLE);
} else if (!enable && adev->gfx.gfx_off_state) {
if (!amdgpu_dpm_set_powergating_by_smu(adev,
AMD_IP_BLOCK_TYPE_GFX, false)) {
adev->gfx.gfx_off_state = false;
--
2.32.0
[PATCH 2/2] drm/amdgpu: Use mod_delayed_work in JPEG/UVD/VCE/VCN ring_end_use hooks
From: Michel Dänzer
In contrast to schedule_delayed_work, this pushes back the work if it
was already scheduled before. Specific behaviour change:
Before:
The scheduled work ran ~1 second after the first time ring_end_use was
called, even if the ring was used again during that second.
After:
The scheduled work runs ~1 second after the last time ring_end_use is
called.
Inspired by the corresponding change in amdgpu_gfx_off_ctrl. While I
haven't run into specific issues in this case, the new behaviour makes
more sense to me.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 2 +-
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c| 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
index 8996cb4ed57a..2c0040153f6c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
@@ -110,7 +110,7 @@ void amdgpu_jpeg_ring_begin_use(struct amdgpu_ring *ring)
void amdgpu_jpeg_ring_end_use(struct amdgpu_ring *ring)
{
atomic_dec(&ring->adev->jpeg.total_submission_cnt);
- schedule_delayed_work(&ring->adev->jpeg.idle_work, JPEG_IDLE_TIMEOUT);
+ mod_delayed_work(system_wq, &ring->adev->jpeg.idle_work,
JPEG_IDLE_TIMEOUT);
}
int amdgpu_jpeg_dec_ring_test_ring(struct amdgpu_ring *ring)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index 0f576f294d8a..b6b1d7eeb8e5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -1283,7 +1283,7 @@ void amdgpu_uvd_ring_begin_use(struct amdgpu_ring *ring)
void amdgpu_uvd_ring_end_use(struct amdgpu_ring *ring)
{
if (!amdgpu_sriov_vf(ring->adev))
- schedule_delayed_work(&ring->adev->uvd.idle_work,
UVD_IDLE_TIMEOUT);
+ mod_delayed_work(system_wq, &ring->adev->uvd.idle_work,
UVD_IDLE_TIMEOUT);
}
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index 1ae7f824adc7..2253c18a6688 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -401,7 +401,7 @@ void amdgpu_vce_ring_begin_use(struct amdgpu_ring *ring)
void amdgpu_vce_ring_end_use(struct amdgpu_ring *ring)
{
if (!amdgpu_sriov_vf(ring->adev))
- schedule_delayed_work(&ring->adev->vce.idle_work,
VCE_IDLE_TIMEOUT);
+ mod_delayed_work(system_wq, &ring->adev->vce.idle_work,
VCE_IDLE_TIMEOUT);
}
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index 284bb42d6c86..d5937ab5ac80 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -1874,7 +1874,7 @@ void vcn_v1_0_set_pg_for_begin_use(struct amdgpu_ring
*ring, bool set_clocks)
void vcn_v1_0_ring_end_use(struct amdgpu_ring *ring)
{
- schedule_delayed_work(&ring->adev->vcn.idle_work, VCN_IDLE_TIMEOUT);
+ mod_delayed_work(system_wq, &ring->adev->vcn.idle_work,
VCN_IDLE_TIMEOUT);
mutex_unlock(&ring->adev->vcn.vcn1_jpeg1_workaround);
}
--
2.32.0
[PATCH v2 0/6] drm/ingenic: Various improvements v2
Hi, A V2 of my patchset for the ingenic-drm driver. The patches "drm/ingenic: Remove dead code" and "drm/ingenic: Use standard drm_atomic_helper_commit_tail" that were present in V1 have been merged in drm-misc-next, so they are not in this V2. Changelog: [PATCH 1/6]: dma_hwdesc_addr() extended to support palette hwdesc. The palette hwdesc is now hwdesc[3] to simplify things. Add ingenic_drm_configure_hwdesc*() functions to factorize code. Cheers, -Paul Paul Cercueil (6): drm/ingenic: Simplify code by using hwdescs array drm/ingenic: Add support for private objects drm/ingenic: Move IPU scale settings to private state drm/ingenic: Set DMA descriptor chain register when starting CRTC drm/ingenic: Upload palette before frame drm/ingenic: Attach bridge chain to encoders drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 278 +- drivers/gpu/drm/ingenic/ingenic-ipu.c | 127 -- 2 files changed, 333 insertions(+), 72 deletions(-) -- 2.30.2
[PATCH v2 1/6] drm/ingenic: Simplify code by using hwdescs array
Instead of having one 'hwdesc' variable for the plane #0, one for the
plane #1 and one for the palette, use a 'hwdesc[3]' array, where the
DMA hardware descriptors are indexed by the plane's number.
v2: dma_hwdesc_addr() extended to support palette hwdesc. The palette
hwdesc is now hwdesc[3] to simplify things. Add
ingenic_drm_configure_hwdesc*() functions to factorize code.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 78 ++-
1 file changed, 48 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index a5df1c8d34cd..95c12c2aba14 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -41,6 +41,8 @@
#include
#include
+#define HWDESC_PALETTE 2
+
struct ingenic_dma_hwdesc {
u32 next;
u32 addr;
@@ -49,9 +51,7 @@ struct ingenic_dma_hwdesc {
} __aligned(16);
struct ingenic_dma_hwdescs {
- struct ingenic_dma_hwdesc hwdesc_f0;
- struct ingenic_dma_hwdesc hwdesc_f1;
- struct ingenic_dma_hwdesc hwdesc_pal;
+ struct ingenic_dma_hwdesc hwdesc[3];
u16 palette[256] __aligned(16);
};
@@ -141,6 +141,14 @@ static inline struct ingenic_drm *drm_nb_get_priv(struct
notifier_block *nb)
return container_of(nb, struct ingenic_drm, clock_nb);
}
+static inline dma_addr_t dma_hwdesc_addr(const struct ingenic_drm *priv,
+unsigned int idx)
+{
+ u32 offset = offsetof(struct ingenic_dma_hwdescs, hwdesc[idx]);
+
+ return priv->dma_hwdescs_phys + offset;
+}
+
static int ingenic_drm_update_pixclk(struct notifier_block *nb,
unsigned long action,
void *data)
@@ -558,9 +566,9 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
struct ingenic_drm *priv = drm_device_get_priv(plane->dev);
struct drm_plane_state *newstate =
drm_atomic_get_new_plane_state(state, plane);
struct drm_plane_state *oldstate =
drm_atomic_get_old_plane_state(state, plane);
+ unsigned int width, height, cpp, next_id, plane_id;
struct drm_crtc_state *crtc_state;
struct ingenic_dma_hwdesc *hwdesc;
- unsigned int width, height, cpp, offset;
dma_addr_t addr;
u32 fourcc;
@@ -569,16 +577,14 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
drm_fb_cma_sync_non_coherent(&priv->drm, oldstate,
newstate);
crtc_state = newstate->crtc->state;
+ plane_id = !!(priv->soc_info->has_osd && plane != &priv->f0);
addr = drm_fb_cma_get_gem_addr(newstate->fb, newstate, 0);
width = newstate->src_w >> 16;
height = newstate->src_h >> 16;
cpp = newstate->fb->format->cpp[0];
- if (!priv->soc_info->has_osd || plane == &priv->f0)
- hwdesc = &priv->dma_hwdescs->hwdesc_f0;
- else
- hwdesc = &priv->dma_hwdescs->hwdesc_f1;
+ hwdesc = &priv->dma_hwdescs->hwdesc[plane_id];
hwdesc->addr = addr;
hwdesc->cmd = JZ_LCD_CMD_EOF_IRQ | (width * height * cpp / 4);
@@ -588,12 +594,8 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
ingenic_drm_plane_config(priv->dev, plane, fourcc);
- if (fourcc == DRM_FORMAT_C8)
- offset = offsetof(struct ingenic_dma_hwdescs,
hwdesc_pal);
- else
- offset = offsetof(struct ingenic_dma_hwdescs,
hwdesc_f0);
-
- priv->dma_hwdescs->hwdesc_f0.next =
priv->dma_hwdescs_phys + offset;
+ next_id = fourcc == DRM_FORMAT_C8 ? HWDESC_PALETTE : 0;
+ priv->dma_hwdescs->hwdesc[0].next =
dma_hwdesc_addr(priv, next_id);
crtc_state->color_mgmt_changed = fourcc ==
DRM_FORMAT_C8;
}
@@ -846,6 +848,35 @@ static void __maybe_unused ingenic_drm_release_rmem(void
*d)
of_reserved_mem_device_release(d);
}
+static void ingenic_drm_configure_hwdesc(struct ingenic_drm *priv,
+unsigned int hwdesc,
+unsigned int next_hwdesc, u32 id)
+{
+ struct ingenic_dma_hwdesc *desc = &priv->dma_hwdescs->hwdesc[hwdesc];
+
+ desc->next = dma_hwdesc_addr(priv, next_hwdesc);
+ desc->id = id;
+}
+
+static void ingenic_drm_configure_hwdesc_palette(struct ingenic_drm *priv)
+{
+ struct ingenic_dma_hwdesc *desc;
+
+ ingenic_drm_configure_hwdesc(priv, HWDESC_PALETTE, 0, 0xc0);
+
+ desc = &priv->dma_hwdescs->hwdesc[HWDESC_PALETTE];
+ desc->addr = priv->dma_hwdescs_phys
+ + offsetof(struct
[PATCH v2 2/6] drm/ingenic: Add support for private objects
Until now, the ingenic-drm as well as the ingenic-ipu drivers used to
put state-specific information in their respective private structure.
Add boilerplate code to support private objects in the two drivers, so
that state-specific information can be put in the state-specific private
structure.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 61 +++
drivers/gpu/drm/ingenic/ingenic-ipu.c | 54
2 files changed, 115 insertions(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 95c12c2aba14..5dbeca0f8f37 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -64,6 +64,10 @@ struct jz_soc_info {
unsigned int num_formats_f0, num_formats_f1;
};
+struct ingenic_drm_private_state {
+ struct drm_private_state base;
+};
+
struct ingenic_drm {
struct drm_device drm;
/*
@@ -99,8 +103,16 @@ struct ingenic_drm {
struct mutex clk_mutex;
bool update_clk_rate;
struct notifier_block clock_nb;
+
+ struct drm_private_obj private_obj;
};
+static inline struct ingenic_drm_private_state *
+to_ingenic_drm_priv_state(struct drm_private_state *state)
+{
+ return container_of(state, struct ingenic_drm_private_state, base);
+}
+
static bool ingenic_drm_writeable_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
@@ -766,6 +778,28 @@ ingenic_drm_gem_create_object(struct drm_device *drm,
size_t size)
return &obj->base;
}
+static struct drm_private_state *
+ingenic_drm_duplicate_state(struct drm_private_obj *obj)
+{
+ struct ingenic_drm_private_state *state =
to_ingenic_drm_priv_state(obj->state);
+
+ state = kmemdup(state, sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return NULL;
+
+ __drm_atomic_helper_private_obj_duplicate_state(obj, &state->base);
+
+ return &state->base;
+}
+
+static void ingenic_drm_destroy_state(struct drm_private_obj *obj,
+ struct drm_private_state *state)
+{
+ struct ingenic_drm_private_state *priv_state =
to_ingenic_drm_priv_state(state);
+
+ kfree(priv_state);
+}
+
DEFINE_DRM_GEM_CMA_FOPS(ingenic_drm_fops);
static const struct drm_driver ingenic_drm_driver_data = {
@@ -836,6 +870,11 @@ static struct drm_mode_config_helper_funcs
ingenic_drm_mode_config_helpers = {
.atomic_commit_tail = drm_atomic_helper_commit_tail,
};
+static const struct drm_private_state_funcs ingenic_drm_private_state_funcs = {
+ .atomic_duplicate_state = ingenic_drm_duplicate_state,
+ .atomic_destroy_state = ingenic_drm_destroy_state,
+};
+
static void ingenic_drm_unbind_all(void *d)
{
struct ingenic_drm *priv = d;
@@ -877,9 +916,15 @@ static void ingenic_drm_configure_hwdesc_plane(struct
ingenic_drm *priv,
ingenic_drm_configure_hwdesc(priv, plane, plane, 0xf0 | plane);
}
+static void ingenic_drm_atomic_private_obj_fini(struct drm_device *drm, void
*private_obj)
+{
+ drm_atomic_private_obj_fini(private_obj);
+}
+
static int ingenic_drm_bind(struct device *dev, bool has_components)
{
struct platform_device *pdev = to_platform_device(dev);
+ struct ingenic_drm_private_state *private_state;
const struct jz_soc_info *soc_info;
struct ingenic_drm *priv;
struct clk *parent_clk;
@@ -1148,6 +1193,20 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
goto err_devclk_disable;
}
+ private_state = kzalloc(sizeof(*private_state), GFP_KERNEL);
+ if (!private_state) {
+ ret = -ENOMEM;
+ goto err_clk_notifier_unregister;
+ }
+
+ drm_atomic_private_obj_init(drm, &priv->private_obj,
&private_state->base,
+ &ingenic_drm_private_state_funcs);
+
+ ret = drmm_add_action_or_reset(drm, ingenic_drm_atomic_private_obj_fini,
+ &priv->private_obj);
+ if (ret)
+ goto err_private_state_free;
+
ret = drm_dev_register(drm, 0);
if (ret) {
dev_err(dev, "Failed to register DRM driver\n");
@@ -1158,6 +1217,8 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
return 0;
+err_private_state_free:
+ kfree(private_state);
err_clk_notifier_unregister:
clk_notifier_unregister(parent_clk, &priv->clock_nb);
err_devclk_disable:
diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c
b/drivers/gpu/drm/ingenic/ingenic-ipu.c
index aeb8a757d213..c819293b8317 100644
--- a/drivers/gpu/drm/ingenic/ingenic-ipu.c
+++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c
@@ -45,6 +45,10 @@ struct soc_info {
unsigned int weight, unsigned int offset);
};
+struct ingenic_ipu_private_state {
+ struct drm_private_state base;
+};
+
stru
[PATCH v2 3/6] drm/ingenic: Move IPU scale settings to private state
The IPU scaling information is computed in the plane's ".atomic_check"
callback, and used in the ".atomic_update" callback. As such, it is
state-specific, and should be moved to a private state structure.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-ipu.c | 73 ---
1 file changed, 54 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c
b/drivers/gpu/drm/ingenic/ingenic-ipu.c
index c819293b8317..2737fc521e15 100644
--- a/drivers/gpu/drm/ingenic/ingenic-ipu.c
+++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c
@@ -47,6 +47,8 @@ struct soc_info {
struct ingenic_ipu_private_state {
struct drm_private_state base;
+
+ unsigned int num_w, num_h, denom_w, denom_h;
};
struct ingenic_ipu {
@@ -58,8 +60,6 @@ struct ingenic_ipu {
const struct soc_info *soc_info;
bool clk_enabled;
- unsigned int num_w, num_h, denom_w, denom_h;
-
dma_addr_t addr_y, addr_u, addr_v;
struct drm_property *sharpness_prop;
@@ -85,6 +85,30 @@ to_ingenic_ipu_priv_state(struct drm_private_state *state)
return container_of(state, struct ingenic_ipu_private_state, base);
}
+static struct ingenic_ipu_private_state *
+ingenic_ipu_get_priv_state(struct ingenic_ipu *priv, struct drm_atomic_state
*state)
+{
+ struct drm_private_state *priv_state;
+
+ priv_state = drm_atomic_get_private_obj_state(state,
&priv->private_obj);
+ if (IS_ERR(priv_state))
+ return ERR_CAST(priv_state);
+
+ return to_ingenic_ipu_priv_state(priv_state);
+}
+
+static struct ingenic_ipu_private_state *
+ingenic_ipu_get_new_priv_state(struct ingenic_ipu *priv, struct
drm_atomic_state *state)
+{
+ struct drm_private_state *priv_state;
+
+ priv_state = drm_atomic_get_new_private_obj_state(state,
&priv->private_obj);
+ if (!priv_state)
+ return NULL;
+
+ return to_ingenic_ipu_priv_state(priv_state);
+}
+
/*
* Apply conventional cubic convolution kernel. Both parameters
* and return value are 15.16 signed fixed-point.
@@ -305,11 +329,16 @@ static void ingenic_ipu_plane_atomic_update(struct
drm_plane *plane,
const struct drm_format_info *finfo;
u32 ctrl, stride = 0, coef_index = 0, format = 0;
bool needs_modeset, upscaling_w, upscaling_h;
+ struct ingenic_ipu_private_state *ipu_state;
int err;
if (!newstate || !newstate->fb)
return;
+ ipu_state = ingenic_ipu_get_new_priv_state(ipu, state);
+ if (WARN_ON(!ipu_state))
+ return;
+
finfo = drm_format_info(newstate->fb->format->format);
if (!ipu->clk_enabled) {
@@ -482,27 +511,27 @@ static void ingenic_ipu_plane_atomic_update(struct
drm_plane *plane,
if (ipu->soc_info->has_bicubic)
ctrl |= JZ_IPU_CTRL_ZOOM_SEL;
- upscaling_w = ipu->num_w > ipu->denom_w;
+ upscaling_w = ipu_state->num_w > ipu_state->denom_w;
if (upscaling_w)
ctrl |= JZ_IPU_CTRL_HSCALE;
- if (ipu->num_w != 1 || ipu->denom_w != 1) {
+ if (ipu_state->num_w != 1 || ipu_state->denom_w != 1) {
if (!ipu->soc_info->has_bicubic && !upscaling_w)
- coef_index |= (ipu->denom_w - 1) << 16;
+ coef_index |= (ipu_state->denom_w - 1) << 16;
else
- coef_index |= (ipu->num_w - 1) << 16;
+ coef_index |= (ipu_state->num_w - 1) << 16;
ctrl |= JZ_IPU_CTRL_HRSZ_EN;
}
- upscaling_h = ipu->num_h > ipu->denom_h;
+ upscaling_h = ipu_state->num_h > ipu_state->denom_h;
if (upscaling_h)
ctrl |= JZ_IPU_CTRL_VSCALE;
- if (ipu->num_h != 1 || ipu->denom_h != 1) {
+ if (ipu_state->num_h != 1 || ipu_state->denom_h != 1) {
if (!ipu->soc_info->has_bicubic && !upscaling_h)
- coef_index |= ipu->denom_h - 1;
+ coef_index |= ipu_state->denom_h - 1;
else
- coef_index |= ipu->num_h - 1;
+ coef_index |= ipu_state->num_h - 1;
ctrl |= JZ_IPU_CTRL_VRSZ_EN;
}
@@ -513,13 +542,13 @@ static void ingenic_ipu_plane_atomic_update(struct
drm_plane *plane,
/* Set the LUT index register */
regmap_write(ipu->map, JZ_REG_IPU_RSZ_COEF_INDEX, coef_index);
- if (ipu->num_w != 1 || ipu->denom_w != 1)
+ if (ipu_state->num_w != 1 || ipu_state->denom_w != 1)
ingenic_ipu_set_coefs(ipu, JZ_REG_IPU_HRSZ_COEF_LUT,
- ipu->num_w, ipu->denom_w);
+ ipu_state->num_w, ipu_state->denom_w);
- if (ipu->num_h != 1 || ipu->denom_h != 1)
+ if (ipu_state->num_h != 1 || ipu_state->denom_h != 1)
ingenic_ipu_set_coefs(ipu, JZ_REG_IPU_VRSZ_COEF_LUT,
-
[PATCH v2 4/6] drm/ingenic: Set DMA descriptor chain register when starting CRTC
Setting the DMA descriptor chain register in the probe function has been fine until now, because we only ever had one descriptor per foreground. As the driver will soon have real descriptor chains, and the DMA descriptor chain register updates itself to point to the current descriptor being processed, this register needs to be reset after a full modeset to point to the first descriptor of the chain. Signed-off-by: Paul Cercueil --- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c index 5dbeca0f8f37..cbc76cede99e 100644 --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c @@ -186,6 +186,10 @@ static void ingenic_drm_crtc_atomic_enable(struct drm_crtc *crtc, regmap_write(priv->map, JZ_REG_LCD_STATE, 0); + /* Set address of our DMA descriptor chain */ + regmap_write(priv->map, JZ_REG_LCD_DA0, dma_hwdesc_addr(priv, 0)); + regmap_write(priv->map, JZ_REG_LCD_DA1, dma_hwdesc_addr(priv, 1)); + regmap_update_bits(priv->map, JZ_REG_LCD_CTRL, JZ_LCD_CTRL_ENABLE | JZ_LCD_CTRL_DISABLE, JZ_LCD_CTRL_ENABLE); -- 2.30.2
[PATCH v2 5/6] drm/ingenic: Upload palette before frame
When using C8 color mode, make sure that the palette is always uploaded
before a frame; otherwise the very first frame will have wrong colors.
Do that by changing the link order of the DMA descriptors.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 53 ---
1 file changed, 47 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index cbc76cede99e..6f860f2e11c4 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -66,6 +66,7 @@ struct jz_soc_info {
struct ingenic_drm_private_state {
struct drm_private_state base;
+ bool use_palette;
};
struct ingenic_drm {
@@ -113,6 +114,30 @@ to_ingenic_drm_priv_state(struct drm_private_state *state)
return container_of(state, struct ingenic_drm_private_state, base);
}
+static struct ingenic_drm_private_state *
+ingenic_drm_get_priv_state(struct ingenic_drm *priv, struct drm_atomic_state
*state)
+{
+ struct drm_private_state *priv_state;
+
+ priv_state = drm_atomic_get_private_obj_state(state,
&priv->private_obj);
+ if (IS_ERR(priv_state))
+ return ERR_CAST(priv_state);
+
+ return to_ingenic_drm_priv_state(priv_state);
+}
+
+static struct ingenic_drm_private_state *
+ingenic_drm_get_new_priv_state(struct ingenic_drm *priv, struct
drm_atomic_state *state)
+{
+ struct drm_private_state *priv_state;
+
+ priv_state = drm_atomic_get_new_private_obj_state(state,
&priv->private_obj);
+ if (!priv_state)
+ return NULL;
+
+ return to_ingenic_drm_priv_state(priv_state);
+}
+
static bool ingenic_drm_writeable_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
@@ -183,11 +208,18 @@ static void ingenic_drm_crtc_atomic_enable(struct
drm_crtc *crtc,
struct drm_atomic_state *state)
{
struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
+ struct ingenic_drm_private_state *priv_state;
+ unsigned int next_id;
+
+ priv_state = ingenic_drm_get_new_priv_state(priv, state);
+ if (WARN_ON(!priv_state))
+ return;
regmap_write(priv->map, JZ_REG_LCD_STATE, 0);
- /* Set address of our DMA descriptor chain */
- regmap_write(priv->map, JZ_REG_LCD_DA0, dma_hwdesc_addr(priv, 0));
+ /* Set addresses of our DMA descriptor chains */
+ next_id = priv_state->use_palette ? HWDESC_PALETTE : 0;
+ regmap_write(priv->map, JZ_REG_LCD_DA0, dma_hwdesc_addr(priv, next_id));
regmap_write(priv->map, JZ_REG_LCD_DA1, dma_hwdesc_addr(priv, 1));
regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
@@ -393,6 +425,7 @@ static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
struct drm_plane_state *new_plane_state =
drm_atomic_get_new_plane_state(state,
plane);
struct ingenic_drm *priv = drm_device_get_priv(plane->dev);
+ struct ingenic_drm_private_state *priv_state;
struct drm_crtc_state *crtc_state;
struct drm_crtc *crtc = new_plane_state->crtc ?: old_plane_state->crtc;
int ret;
@@ -405,6 +438,10 @@ static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
if (WARN_ON(!crtc_state))
return -EINVAL;
+ priv_state = ingenic_drm_get_priv_state(priv, state);
+ if (IS_ERR(priv_state))
+ return PTR_ERR(priv_state);
+
ret = drm_atomic_helper_check_plane_state(new_plane_state, crtc_state,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
@@ -423,6 +460,9 @@ static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
(new_plane_state->src_h >> 16) != new_plane_state->crtc_h))
return -EINVAL;
+ priv_state->use_palette = new_plane_state->fb &&
+ new_plane_state->fb->format->format == DRM_FORMAT_C8;
+
/*
* Require full modeset if enabling or disabling a plane, or changing
* its position, size or depth.
@@ -583,6 +623,7 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
struct drm_plane_state *newstate =
drm_atomic_get_new_plane_state(state, plane);
struct drm_plane_state *oldstate =
drm_atomic_get_old_plane_state(state, plane);
unsigned int width, height, cpp, next_id, plane_id;
+ struct ingenic_drm_private_state *priv_state;
struct drm_crtc_state *crtc_state;
struct ingenic_dma_hwdesc *hwdesc;
dma_addr_t addr;
@@ -600,19 +641,19 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
height = newstate->src_h >> 16;
cpp = newstate->fb->format->cpp[0];
-
[PATCH v2 6/6] drm/ingenic: Attach bridge chain to encoders
Attach a top-level bridge to each encoder, which will be used for
negociating the bus format and flags.
All the bridges are now attached with DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 92 +--
1 file changed, 70 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 6f860f2e11c4..cdbdc4d5cc96 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -108,6 +109,19 @@ struct ingenic_drm {
struct drm_private_obj private_obj;
};
+struct ingenic_drm_bridge {
+ struct drm_encoder encoder;
+ struct drm_bridge bridge, *next_bridge;
+
+ struct drm_bus_cfg bus_cfg;
+};
+
+static inline struct ingenic_drm_bridge *
+to_ingenic_drm_bridge(struct drm_encoder *encoder)
+{
+ return container_of(encoder, struct ingenic_drm_bridge, encoder);
+}
+
static inline struct ingenic_drm_private_state *
to_ingenic_drm_priv_state(struct drm_private_state *state)
{
@@ -668,11 +682,10 @@ static void ingenic_drm_encoder_atomic_mode_set(struct
drm_encoder *encoder,
{
struct ingenic_drm *priv = drm_device_get_priv(encoder->dev);
struct drm_display_mode *mode = &crtc_state->adjusted_mode;
- struct drm_connector *conn = conn_state->connector;
- struct drm_display_info *info = &conn->display_info;
+ struct ingenic_drm_bridge *bridge = to_ingenic_drm_bridge(encoder);
unsigned int cfg, rgbcfg = 0;
- priv->panel_is_sharp = info->bus_flags & DRM_BUS_FLAG_SHARP_SIGNALS;
+ priv->panel_is_sharp = bridge->bus_cfg.flags &
DRM_BUS_FLAG_SHARP_SIGNALS;
if (priv->panel_is_sharp) {
cfg = JZ_LCD_CFG_MODE_SPECIAL_TFT_1 | JZ_LCD_CFG_REV_POLARITY;
@@ -685,19 +698,19 @@ static void ingenic_drm_encoder_atomic_mode_set(struct
drm_encoder *encoder,
cfg |= JZ_LCD_CFG_HSYNC_ACTIVE_LOW;
if (mode->flags & DRM_MODE_FLAG_NVSYNC)
cfg |= JZ_LCD_CFG_VSYNC_ACTIVE_LOW;
- if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
+ if (bridge->bus_cfg.flags & DRM_BUS_FLAG_DE_LOW)
cfg |= JZ_LCD_CFG_DE_ACTIVE_LOW;
- if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
+ if (bridge->bus_cfg.flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
cfg |= JZ_LCD_CFG_PCLK_FALLING_EDGE;
if (!priv->panel_is_sharp) {
- if (conn->connector_type == DRM_MODE_CONNECTOR_TV) {
+ if (conn_state->connector->connector_type ==
DRM_MODE_CONNECTOR_TV) {
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
cfg |= JZ_LCD_CFG_MODE_TV_OUT_I;
else
cfg |= JZ_LCD_CFG_MODE_TV_OUT_P;
} else {
- switch (*info->bus_formats) {
+ switch (bridge->bus_cfg.format) {
case MEDIA_BUS_FMT_RGB565_1X16:
cfg |= JZ_LCD_CFG_MODE_GENERIC_16BIT;
break;
@@ -723,20 +736,29 @@ static void ingenic_drm_encoder_atomic_mode_set(struct
drm_encoder *encoder,
regmap_write(priv->map, JZ_REG_LCD_RGBC, rgbcfg);
}
-static int ingenic_drm_encoder_atomic_check(struct drm_encoder *encoder,
- struct drm_crtc_state *crtc_state,
- struct drm_connector_state
*conn_state)
+static int ingenic_drm_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+ struct ingenic_drm_bridge *ib = to_ingenic_drm_bridge(bridge->encoder);
+
+ return drm_bridge_attach(bridge->encoder, ib->next_bridge,
+&ib->bridge, flags);
+}
+
+static int ingenic_drm_bridge_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state
*bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state
*conn_state)
{
- struct drm_display_info *info = &conn_state->connector->display_info;
struct drm_display_mode *mode = &crtc_state->adjusted_mode;
+ struct ingenic_drm_bridge *ib = to_ingenic_drm_bridge(bridge->encoder);
- if (info->num_bus_formats != 1)
- return -EINVAL;
+ ib->bus_cfg = bridge_state->output_bus_cfg;
if (conn_state->connector->connector_type == DRM_MODE_CONNECTOR_TV)
return 0;
- switch (*info->bus_formats) {
+ switch (bridge_state->output_bus_cfg.format) {
case MEDIA_BUS_FMT_RGB888_3X8:
case MEDIA_BUS_FMT_RGB888_3X8_DELTA:
Re: [PATCH 1/9] drm/i915/guc: Fix blocked context accounting
On Wed, Aug 11, 2021 at 12:30:52PM +0200, Daniel Vetter wrote:
> On Wed, Aug 11, 2021 at 01:16:14AM +, Matthew Brost wrote:
> > Prior to this patch the blocked context counter was cleared on
> > init_sched_state (used during registering a context & resets) which is
> > incorrect. This state needs to be persistent or the counter can read the
> > incorrect value resulting in scheduling never getting enabled again.
> >
> > Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
>
Ah, relized I sent this series to the wrong list, let's stop replying to
rev of series after this patch.
> Tiny bikeshed on that commit, but for SCHED_STATE_BLOCKED_MASK you want
> GENMASK. Also SCHED_STATE_BLOCKED is usually called
> SCHED_STATE_BLOCKED_BIAS or similar if you put a counter into that field.
>
> But also ... we can't afford a separate counter? Is all the bitshifting
> actually worth the space savings? With a separate counter your bugfix
> below would look a lot more reasonable too.
>
Could add a counter I suppose. A lot of this clean up can be done over
time.
>
> > Signed-off-by: Matthew Brost
> > Cc:
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 87d8dc8f51b9..69faa39da178 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -152,7 +152,7 @@ static inline void init_sched_state(struct
> > intel_context *ce)
> > {
> > /* Only should be called from guc_lrc_desc_pin() */
> > atomic_set(&ce->guc_sched_state_no_lock, 0);
>
> atomic_t without barriers or anything like that. tsk, tsk.
>
> Do we really need this?
>
> Also I looked through the callchain of init_sched_state and I couldn't
> find any locking, nor any description about ownership that would explain
> why there's no locking.
>
> E.g. scrub_guc_desc_for_outstanding_g2h has an xa_for_each with no
> protection. No idea how that one works. I also couldn't figure out how
In both the reset and context registration cases it is guaranteed no one
else can be touching this context. We can get a lock inversion if use
this lock while registering the context, thus we don't use it there.
All this locking complexity is going to be greatly reduced when we move
to the DRM scheduler + have a task to clean up the locking then.
> anything else in there is protected (no spinlocks to be seen anywhere at
> least).
>
> And then there's stuff like this:
>
> /* Flush context */
> spin_lock_irqsave(&ce->guc_state.lock, flags);
> spin_unlock_irqrestore(&ce->guc_state.lock, flags);
>
> This pattern seems very common, and it freaks me out.
>
I wrote some doc up on this in one of my initial posts. It is basically
seal a bunch of races flying around related to resets. Cycling the lock
guarantees that contexts can see that reset is in flight and not send
out a H2G that requires a G2H response. Losing a G2H is fatal as we
depend on that response to take further action (e.g. release a fence, do
a put, etc...).
> Finally none of the locking or consistency rules are explained in the
> kerneldoc (or even comments) in the relevant datastructures, which is not
> great.
Like I said, I have a patch for documentation but it hasn't made it into
the kernel yet. I'll include the doc patch in my next spin of the parallel
submission code.
>
> > - ce->guc_state.sched_state = 0;
> > + ce->guc_state.sched_state &= SCHED_STATE_BLOCKED_MASK;
>
> The patch itself matches the commit message and makes sense. But like I
> said, would be cleaner I think if it's just a separate counter.
>
Can clean this in the future.
Matt
> Reviewed-by: Daniel Vetter
>
> > }
> >
> > static inline bool
> > --
> > 2.32.0
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Re: [PATCH 25/46] drm/i915/guc: Update debugfs for GuC multi-lrc
On Wed, Aug 11, 2021 at 12:04:04PM +0200, Daniel Vetter wrote:
> On Tue, Aug 10, 2021 at 05:29:46PM +, Matthew Brost wrote:
> > On Tue, Aug 10, 2021 at 11:27:31AM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 10, 2021 at 11:23:39AM +0200, Daniel Vetter wrote:
> > > > On Mon, Aug 09, 2021 at 07:13:11PM +, Matthew Brost wrote:
> > > > > On Mon, Aug 09, 2021 at 06:36:44PM +0200, Daniel Vetter wrote:
> > > > > > On Tue, Aug 03, 2021 at 03:29:22PM -0700, Matthew Brost wrote:
> > > > > > > Display the workqueue status in debugfs for GuC contexts that are
> > > > > > > in
> > > > > > > parent-child relationship.
> > > > > > >
> > > > > > > Signed-off-by: Matthew Brost
> > > > > > > ---
> > > > > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 56
> > > > > > > +--
> > > > > > > 1 file changed, 39 insertions(+), 17 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > > > index 30df1c8db491..44a7582c9aed 100644
> > > > > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > > > @@ -4527,31 +4527,53 @@ void
> > > > > > > intel_guc_submission_print_info(struct intel_guc *guc,
> > > > > > > gse_log_submission_info(guc->gse[i], p, i);
> > > > > > > }
> > > > > > >
> > > > > > > +static inline void guc_log_context(struct drm_printer *p,
> > > > > > > +struct intel_context *ce)
> > > > > > > +{
> > > > > > > + drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id);
> > > > > > > + drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
> > > > > > > + drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
> > > > > > > +ce->ring->head,
> > > > > > > +ce->lrc_reg_state[CTX_RING_HEAD]);
> > > > > > > + drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
> > > > > > > +ce->ring->tail,
> > > > > > > +ce->lrc_reg_state[CTX_RING_TAIL]);
> > > > > > > + drm_printf(p, "\t\tContext Pin Count: %u\n",
> > > > > > > +atomic_read(&ce->pin_count));
> > > > > > > + drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
> > > > > > > +atomic_read(&ce->guc_id_ref));
> > > > > > > + drm_printf(p, "\t\tNumber Requests Not Ready: %u\n",
> > > > > > > +atomic_read(&ce->guc_num_rq_not_ready));
> > > > > > > + drm_printf(p, "\t\tSchedule State: 0x%x, 0x%x\n\n",
> > > > > > > +ce->guc_state.sched_state,
> > > > > > > +atomic_read(&ce->guc_sched_state_no_lock));
> > > > > >
> > > > > > It's all debugfs, but I think proper locking even there is good. It
> > > > > > at
> > > > > > least reduces the confusion when the locking scheme is largely
> > > > > > undocumented. Also given how much we have rcu for everything would
> > > > > > be good
> > > > > > to double-check all pointer dererences are properly protected.
> > > > > >
> > > > >
> > > > > Not sure if I 100% follow this but I don't think any of the pointers
> > > > > dref here are RCU protected. Certainly none of the GuC ones are.
> > > > >
> > > > > Will double before the next respin though.
> > > > >
> > > > > > > +}
> > > > > > > +
> > > > > > > void intel_guc_submission_print_context_info(struct intel_guc
> > > > > > > *guc,
> > > > > > >struct drm_printer *p)
> > > > > > > {
> > > > > > > struct intel_context *ce;
> > > > > > > unsigned long index;
> > > > > > > xa_for_each(&guc->context_lookup, index, ce) {
> > > > > >
> > > > > > xa_for_each doesn't provide any guarantees, so doesn't protect
> > > > > > against
> > > > > > concurrent removeal or anything like that. We need to do better
> > > > > > than that.
> > > > >
> > > > > https://elixir.bootlin.com/linux/latest/source/include/linux/xarray.h#L498
> > > > > 'It is safe to modify the array during the iteration.'
> > > >
> > > > The xarray. Not the thing you're dereferencing, because the xarray only
> > > > stores pointers, not your data structure. So yeah correct statement is
> > > > that it doesn't provide you any guarantees beyond "the iterator wont be
> > > > confused if the xarray itself is modified during iteration". Which isn't
> > > > what you need here, you need a lot more.
> > >
> > > Or spelled out: The pointer you get could become immediately meaningless,
> > > before you can look at it, due to a concurrent removal/release. All the
> > > xa_for_each guarantees you is that on the next round you get the next
> > > pointer, until you got them all (plus/minus concurrent changes). But that
> > > next pointer could have become meaningless right away too.
> > >
> > > So you need your own locking to make use of these pointers you got and
> > > make sure they're not immediately meaningless before your loop body even
> > > started.
> > >
> >
> > Ok, I think I see your point. Likely
Re: [Intel-gfx] [PATCH 46/46] drm/i915/guc: Add delay before disabling scheduling on contexts
On Wed, Aug 11, 2021 at 11:55:48AM +0200, Daniel Vetter wrote: > On Mon, Aug 09, 2021 at 07:32:26PM +, Matthew Brost wrote: > > On Mon, Aug 09, 2021 at 07:17:27PM +0200, Daniel Vetter wrote: > > > On Tue, Aug 03, 2021 at 03:29:43PM -0700, Matthew Brost wrote: > > > > Some workloads use lots of contexts that continually pin / unpin > > > > contexts. With GuC submission an unpin translates to a schedule disable > > > > H2G which puts pressure on both the i915 and GuC. A schedule disable can > > > > also block future requests from being submitted until the operation > > > > completes. None of this is ideal. > > > > > > > > Add a configurable, via debugfs, delay period before the schedule > > > > disable is issued. Default delay period is 1 second. The delay period is > > > > skipped if more than 3/4 of the guc_ids are in use. > > > > > > > > This patch also updates the selftests to turn off this delay period as > > > > this extra time would likely cause many selftests to fail. Follow up > > > > patches will fix all the selftests and enable the delay period. > > > > > > > > Signed-off-by: Matthew Brost > > > > > > I think this is more evidence that we should just pin/unpin context at > > > create/destruction time. The current scheme doesn't really work that well > > > and causes way more pain than benefits it seems. > > > > > > > Well that choice is above my pay grade, but for what it is worth it > > would simplify the GuC backend quite a bit if we perma-pin contexts. By > > quite a bit, I actually mean a lot of complexity goes away. > > > > In the meantime I think we probably need this code though to avoid > > trashes on the scheduling enable / disable. > > The trouble is that you muck around with the context close state bit, This really doesn't mess this bit anymore that what is there, it just adds callback to the backend. > which is one of these lockless trickeries where my cursory analysis (just > a few days in total of randomly stumbling over it when reading other code) > strongly suggests it's busted. > > I really don't want to build more on top, especially not without careful > review and all that. > > Also since this is a perf claim, the commit message needs some numbers. > This was basically just visual inspection of ftrace of a media workload that uses lots of contexts. The contexts were repeatedly pinned / unpinned. Disabling / enabling scheduling is a rather expensive operation so we really shouldn't be doing it all the time. We visually observed an ftrace after this change and all this unnecessary traffic went away. > Finally even if we decide to make contexts properly evictable, we need a > different scheme anyway. As you realized the current active tracking is > kinda backwards because it unpins immediately when no longer in use. Right, this basically just works around the fact that contexts are immediately unpinned when not in use. As stated before if we perma-pin contexts all this goes away. Matt > -Daniel > > > > > Matt > > > > > If anyone screams, and that's a big if aside of some igts, we can come up > > > with a proper scheme to evict contexts without pin/unpin and layer hacks > > > over that misdesign. > > > -Daniel > > > > > > > --- > > > > drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +- > > > > .../i915/gem/selftests/i915_gem_coherency.c | 2 +- > > > > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +- > > > > .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +- > > > > .../drm/i915/gem/selftests/i915_gem_object.c | 2 +- > > > > drivers/gpu/drm/i915/gt/intel_context.c | 2 + > > > > drivers/gpu/drm/i915/gt/intel_context.h | 9 + > > > > drivers/gpu/drm/i915/gt/intel_context_types.h | 8 + > > > > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 7 + > > > > .../gpu/drm/i915/gt/uc/intel_guc_debugfs.c| 28 ++ > > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 322 +- > > > > .../i915/gt/uc/selftest_guc_flow_control.c| 19 +- > > > > drivers/gpu/drm/i915/i915_selftest.h | 2 + > > > > drivers/gpu/drm/i915/i915_trace.h | 10 + > > > > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +- > > > > drivers/gpu/drm/i915/selftests/i915_perf.c| 2 +- > > > > drivers/gpu/drm/i915/selftests/i915_request.c | 2 +- > > > > drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +- > > > > 18 files changed, 405 insertions(+), 20 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c > > > > b/drivers/gpu/drm/i915/gem/i915_gem_context.c > > > > index b199d59bd2c4..1553287e5491 100644 > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c > > > > @@ -1298,7 +1298,7 @@ static void engines_idle_release(struct > > > > i915_gem_context *ctx, > > > > int err; > > > > > > > > /* serialises with execbuf */ > > > > - set_bit(CONTEXT_CLOSED_
Re: [Intel-gfx] [PATCH 11/46] drm/i915/guc: Don't call switch_to_kernel_context with GuC submission
On Tue, Aug 10, 2021 at 08:47:10AM +0200, Daniel Vetter wrote: > On Mon, Aug 09, 2021 at 06:20:51PM +, Matthew Brost wrote: > > On Mon, Aug 09, 2021 at 04:27:01PM +0200, Daniel Vetter wrote: > > > On Tue, Aug 03, 2021 at 03:29:08PM -0700, Matthew Brost wrote: > > > > Calling switch_to_kernel_context isn't needed if the engine PM reference > > > > is taken while all contexts are pinned. By not calling > > > > switch_to_kernel_context we save on issuing a request to the engine. > > > > > > > > Signed-off-by: Matthew Brost > > > > --- > > > > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c > > > > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c > > > > index 1f07ac4e0672..58099de6bf07 100644 > > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c > > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c > > > > @@ -162,6 +162,10 @@ static bool switch_to_kernel_context(struct > > > > intel_engine_cs *engine) > > > > unsigned long flags; > > > > bool result = true; > > > > > > > > + /* No need to switch_to_kernel_context if GuC submission */ > > > > > > Maybe whack a big FIXME on here that we should unravel this properly. > > > > Sure, can add a FIXME here. > > > > > Currently the execlist backend assumptions are leaked all over the place, > > > leading to stuff like this. Which means extremely fragile code. > > > > > > > Yes, this something required for execlists implemented in what should be > > generic code. > > > > > I currently don't have a great idea on how exactly we should do that, but > > > oh well. > > > > Me either, it will be a process. > > > > > > > > btw just in case we ever want to make guc lrc properly evictable (which as > > > the og use-case for this function, way, way back), would we need to fully > > > > Can you explain what you mean by fully evictable? Not getting what you > > mean in this context. > > > > > unregister them from guc? At least I'm assuming there's no other trick > > > > If scheduling is disabled on the context (currently done on unpin) you are > > free move anything around as the GuC is guaranteed not to touch the > > context state. If on re-pin something has moved (e.g. the LRC vaddr is > > different), you need to unregister and re-register the context with the > > GuC. > > So at that point GuC also guarantees that it's not left in the hw engine? > Execlist has this barrier request to fully unload the ctx from the hw, and > that's also why I cam on the topic of OA. > > > > like the below one. > > > > > > Another aside: How does the perf/OA patching work on GuC? > > > > > > > Not my area of expertise but perf somewhat a WIP. The plan is for the > > GuC to write out some stats to HWSP I think? John Harrison is working to > > get this fully implemented. > > > > OA is working afaik, with Umesh Nerlige Ramappa being the expert here. > > I think it's OA that I'm thinking of here: We have code in i915_perf.c to > patch all the ctx currently in the system, so that they have a consistent > OA config. That's also relying on this barrier stuff, and I was wondering > how that will work with GuC. > -Daniel > Not an OA expert at all but glanced at the code I don't see anything in there that prevents it working with GuC submission. We certainly have this working internally. If you have questions about this I'd reach out to Umesh Nerlige Ramappa as he likely has the answers. Matt > > > > Matt > > > > > Anyway, patch looks legit: > > > > > > Reviewed-by: Daniel Vetter > > > > > > > > > > + if (intel_engine_uses_guc(engine)) > > > > + return true; > > > > + > > > > /* GPU is pointing to the void, as good as in the kernel > > > > context. */ > > > > if (intel_gt_is_wedged(engine->gt)) > > > > return true; > > > > -- > > > > 2.28.0 > > > > > > > > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
Re: [PATCH v5 1/2] arm64: dts: qcom: sc7280: Add gpu support
Quoting Akhil P Oommen (2021-08-11 07:23:54) > Add the necessary dt nodes for gpu support in sc7280. > > Signed-off-by: Akhil P Oommen > --- Reviewed-by: Stephen Boyd
[PATCH] drm: Copy drm_wait_vblank request and copy_to_user before return.
From: Mark Yacoub [Why] Userspace should get back a copy of the request that's been modified even when drm_wait_vblank_ioctl returns a failure. Rationale: drm_wait_vblank_ioctl modifies the request and expects the user to read back. When the type is RELATIVE, it modifies it to ABSOLUTE and updates the sequence to become current_vblank_count + sequence (which was relative), not it becomes absolute. drmWaitVBlank (in libdrm), expects this to be the case as it modifies the request to be Absolute as it expects the sequence to would have been updated. The change is in compat_drm_wait_vblank, which is called by drm_compat_ioctl. This change of copying the data back regardless of the return number makes it en par with drm_ioctl, which always copies the data before returning. [How] Copy the drm_wait_vblank request. Return from the function after everything has been copied to user. Fixes: IGT:kms_flip::modeset-vs-vblank-race-interruptible Tested on ChromeOS Trogdor(msm) Signed-off-by: Mark Yacoub --- drivers/gpu/drm/drm_ioc32.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c index d29907955ff79..275b860df8fbe 100644 --- a/drivers/gpu/drm/drm_ioc32.c +++ b/drivers/gpu/drm/drm_ioc32.c @@ -855,17 +855,19 @@ static int compat_drm_wait_vblank(struct file *file, unsigned int cmd, req.request.sequence = req32.request.sequence; req.request.signal = req32.request.signal; err = drm_ioctl_kernel(file, drm_wait_vblank_ioctl, &req, DRM_UNLOCKED); - if (err) - return err; req32.reply.type = req.reply.type; req32.reply.sequence = req.reply.sequence; req32.reply.tval_sec = req.reply.tval_sec; req32.reply.tval_usec = req.reply.tval_usec; + /* drm_wait_vblank_ioctl modifies Request, update their values here as well. */ + req32.request.type = req.request.type; + req32.request.sequence = req.request.sequence; + req32.request.signal = req.request.signal; if (copy_to_user(argp, &req32, sizeof(req32))) return -EFAULT; - return 0; + return err; } #if defined(CONFIG_X86) -- 2.33.0.rc1.237.g0d66db33f3-goog
Re: [PATCH 14/46] drm/i915: Expose logical engine instance to user
On Tue, Aug 10, 2021 at 08:53:16AM +0200, Daniel Vetter wrote:
> On Mon, Aug 09, 2021 at 06:37:01PM +, Matthew Brost wrote:
> > On Mon, Aug 09, 2021 at 04:30:06PM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 03, 2021 at 03:29:11PM -0700, Matthew Brost wrote:
> > > > Expose logical engine instance to user via query engine info IOCTL. This
> > > > is required for split-frame workloads as these needs to be placed on
> > > > engines in a logically contiguous order. The logical mapping can change
> > > > based on fusing. Rather than having user have knowledge of the fusing we
> > > > simply just expose the logical mapping with the existing query engine
> > > > info IOCTL.
> > > >
> > > > Cc: Tvrtko Ursulin
> > > > Signed-off-by: Matthew Brost
> > >
> > > Uapi must have a link to the userspace MR/patch set using this, and to the
> > > igt patch set validating it.
> > >
> >
> > Have an IGT:
> > https://patchwork.freedesktop.org/patch/447008/?series=93071&rev=1
> >
> > Not sure when the media UMD is going to be updated upstream to use this.
> > Does that mean I can't merge this until the media UMD is ready? Seems
> > like it but isn't that a circular dependency? How can the media team
> > develop for a new uAPI that isn't in the kernel yet?
>
> Yes and no. Full explainer here:
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
>
> In the drm subsystem this is pretty much the only rule where if you break
> it the book will be thrown at you with extreme prejudice.
>
Well I don't want a book thrown at, new here and trying to play by the
rules.
> Also wrt circular: If the umd aren't set up to test their branches against
> kernel branches they need to fix their stuff. I know that internally
> that's not been done, and its a disaster, but in upstream there's no room
> for excuses. Both kernel and userspace needs to be in branches until it's
> ready for merging.
>
Ok, looks like a have a few things to learn. I'll coordinate with the
media team on this. Likely won't have links to the UMD in the next spin
but I'll have a branch for them to prep their patches on.
Matt
> > For what it is worth the downstream release is already using this.
>
> Yeah which is another problem, shipping new uapi in downstream before it's
> in upstream is decidedly not great.
> -Daniel
>
> >
> > Matt
> >
> > > Ideally in each patch, since it's way too hard to unfortunately find the
> > > cover letter late on.
> > >
> > > Jason even went as far as making this a hard requirement because he wasted
> > > a bit too much time trying to find the userspace for new uapi:
> > >
> > > https://lore.kernel.org/dri-devel/20210804185704.624883-1-ja...@jlekstrand.net/
> > >
> > > Cheers, Daniel
> > >
> > > >---
> > > > drivers/gpu/drm/i915/i915_query.c | 2 ++
> > > > include/uapi/drm/i915_drm.h | 8 +++-
> > > > 2 files changed, 9 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_query.c
> > > > b/drivers/gpu/drm/i915/i915_query.c
> > > > index e49da36c62fb..8a72923fbdba 100644
> > > > --- a/drivers/gpu/drm/i915/i915_query.c
> > > > +++ b/drivers/gpu/drm/i915/i915_query.c
> > > > @@ -124,7 +124,9 @@ query_engine_info(struct drm_i915_private *i915,
> > > > for_each_uabi_engine(engine, i915) {
> > > > info.engine.engine_class = engine->uabi_class;
> > > > info.engine.engine_instance = engine->uabi_instance;
> > > > + info.flags = I915_ENGINE_INFO_HAS_LOGICAL_INSTANCE;
> > > > info.capabilities = engine->uabi_capabilities;
> > > > + info.logical_instance = ilog2(engine->logical_mask);
> > > >
> > > > if (copy_to_user(info_ptr, &info, sizeof(info)))
> > > > return -EFAULT;
> > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > > index 7f13d241417f..ef72e07fe08c 100644
> > > > --- a/include/uapi/drm/i915_drm.h
> > > > +++ b/include/uapi/drm/i915_drm.h
> > > > @@ -2706,14 +2706,20 @@ struct drm_i915_engine_info {
> > > >
> > > > /** @flags: Engine flags. */
> > > > __u64 flags;
> > > > +#define I915_ENGINE_INFO_HAS_LOGICAL_INSTANCE (1 << 0)
> > > >
> > > > /** @capabilities: Capabilities of this engine. */
> > > > __u64 capabilities;
> > > > #define I915_VIDEO_CLASS_CAPABILITY_HEVC (1 << 0)
> > > > #define I915_VIDEO_AND_ENHANCE_CLASS_CAPABILITY_SFC(1 << 1)
> > > >
> > > > + /** @logical_instance: Logical instance of engine */
> > > > + __u16 logical_instance;
> > > > +
> > > > /** @rsvd1: Reserved fields. */
> > > > - __u64 rsvd1[4];
> > > > + __u16 rsvd1[3];
> > > > + /** @rsvd2: Reserved fields. */
> > > > + __u64 rsvd2[3];
> > > > };
> > > >
> > > > /**
> > > > --
> > > > 2.28.0
> > > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://b
Consistently reproduce-able warning
Hello, I have nightly tests that run on VM's against our btrfs devel tree, and I'm getting this warning every day [15522.437976] [ cut here ] [15522.438356] WARNING: CPU: 0 PID: 2334448 at drivers/gpu/drm/ttm/ttm_bo.c:512 ttm_bo_release+0x4f9/0x5c0 [ttm] [15522.439322] Modules linked in: dm_thin_pool dm_persistent_data dm_bio_prison dm_log_writes dm_dust dm_flakey loop nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6_tables nft_compat ip_set rfkill nf_tables nfnetlink joydev iTCO_wdt iTCO_vendor_support intel_rapl_msr virtio_balloon intel_rapl_common snd_hda_codec_generic lpc_ich snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd soundcore i2c_i801 i2c_smbus zram ip_tables xfs crct10dif_pclmul crc32_pclmul crc32c_intel qxl drm_ttm_helper ttm drm_kms_helper ghash_clmulni_intel cec serio_raw virtio_blk qemu_fw_cfg drm [15522.445295] CPU: 0 PID: 2334448 Comm: kworker/0:6 Tainted: GW 5.12.0-rc1+ #155 [15522.446187] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 [15522.447066] Workqueue: events qxl_gc_work [qxl] [15522.447546] RIP: 0010:ttm_bo_release+0x4f9/0x5c0 [ttm] [15522.448093] Code: ff 48 8b bd e8 fe ff ff b9 30 75 00 00 31 d2 be 01 00 00 00 e8 a8 98 5b c9 48 8b 45 e0 e9 fb fe ff ff 4c 89 e8 e9 f3 fe ff ff <0f> 0b c7 85 94 00 00 00 00 00 00 00 48 8b 3c 24 48 8d 75 08 31 d2 [15522.450625] RSP: 0018:aaf6c14d3d80 EFLAGS: 00010202 [15522.451134] RAX: 0001 RBX: 0002 RCX: [15522.451896] RDX: 0001 RSI: RDI: c039d168 [15522.452641] RBP: 9a028335f648 R08: R09: [15522.453387] R10: R11: 9a0282367488 R12: 9a02920b4c00 [15522.454233] R13: 9a0292208d90 R14: 9a028335f6b0 R15: 9a02920b4700 [15522.454936] FS: () GS:9a02fbc0() knlGS: [15522.455938] CS: 0010 DS: ES: CR0: 80050033 [15522.456508] CR2: 7f2c2fe34000 CR3: 0001112be001 CR4: 00370ef0 [15522.456910] Call Trace: [15522.457055] qxl_bo_unref+0x31/0x50 [qxl] [15522.457293] qxl_release_free_list+0x52/0xa0 [qxl] [15522.457563] qxl_release_free+0x76/0xe0 [qxl] [15522.457821] qxl_garbage_collect+0xbd/0x170 [qxl] [15522.458086] process_one_work+0x26e/0x570 [15522.458320] worker_thread+0x55/0x3c0 [15522.458526] ? process_one_work+0x570/0x570 [15522.458776] kthread+0x137/0x150 [15522.458961] ? __kthread_bind_mask+0x60/0x60 [15522.459199] ret_from_fork+0x1f/0x30 [15522.459407] irq event stamp: 0 [15522.459580] hardirqs last enabled at (0): [<>] 0x0 [15522.459935] hardirqs last disabled at (0): [] copy_process+0x8c4/0x1ca0 [15522.460385] softirqs last enabled at (0): [] copy_process+0x8c4/0x1ca0 [15522.460835] softirqs last disabled at (0): [<>] 0x0 [15522.461179] ---[ end trace d46763407dcdfb0a ]--- You can find the full dmesg here http://toxicpanda.com/results/josefbacik/xfstests2/btrfs_compression/08-11-2021-06:56:57/btrfs/022.dmesg.html I had hit this before and just turned off drm because it was going almost constantly, but I accidentally turned it back on when messing with my config. Can you guys get this fixed, it messes with my test results as kernel warnings show up as failures. I can run whatever debug stuff you want me to run, like I said these run every night and it reproduces all the time. Thanks, Josef
[PATCH] video: fbdev: w100fb: Reset global state
w100fb_probe() did not reset the global state to its initial state. This
can result in invocation of iounmap() even when there was not the
appropriate successful call of ioremap(). For instance, this may be the
case if first probe fails after two successful ioremap() while second
probe fails when first ioremap() fails. The similar issue is with
w100fb_remove(). The patch fixes both bugs.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
Co-developed-by: Kirill Shilimanov
Signed-off-by: Kirill Shilimanov
---
drivers/video/fbdev/w100fb.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/w100fb.c b/drivers/video/fbdev/w100fb.c
index d96ab28f8ce4..4e641a780726 100644
--- a/drivers/video/fbdev/w100fb.c
+++ b/drivers/video/fbdev/w100fb.c
@@ -770,12 +770,18 @@ static int w100fb_probe(struct platform_device *pdev)
fb_dealloc_cmap(&info->cmap);
kfree(info->pseudo_palette);
}
- if (remapped_fbuf != NULL)
+ if (remapped_fbuf != NULL) {
iounmap(remapped_fbuf);
- if (remapped_regs != NULL)
+ remapped_fbuf = NULL;
+ }
+ if (remapped_regs != NULL) {
iounmap(remapped_regs);
- if (remapped_base != NULL)
+ remapped_regs = NULL;
+ }
+ if (remapped_base != NULL) {
iounmap(remapped_base);
+ remapped_base = NULL;
+ }
if (info)
framebuffer_release(info);
return err;
@@ -795,8 +801,11 @@ static int w100fb_remove(struct platform_device *pdev)
fb_dealloc_cmap(&info->cmap);
iounmap(remapped_base);
+ remapped_base = NULL;
iounmap(remapped_regs);
+ remapped_regs = NULL;
iounmap(remapped_fbuf);
+ remapped_fbuf = NULL;
framebuffer_release(info);
--
2.26.2
Re: [Intel-gfx] [PATCH 16/46] drm/i915/guc: Implement GuC parent-child context pin / unpin functions
On Tue, Aug 10, 2021 at 11:07:55AM +0200, Daniel Vetter wrote:
> On Tue, Aug 10, 2021 at 10:53:37AM +0200, Daniel Vetter wrote:
> > On Mon, Aug 09, 2021 at 06:58:23PM +, Matthew Brost wrote:
> > > On Mon, Aug 09, 2021 at 05:17:34PM +0200, Daniel Vetter wrote:
> > > > On Tue, Aug 03, 2021 at 03:29:13PM -0700, Matthew Brost wrote:
> > > > > Implement GuC parent-child context pin / unpin functions in which in
> > > > > any
> > > > > contexts in the relationship are pinned all the contexts are pinned.
> > > > > The
> > > > > parent owns most of the pinning / unpinning process and the children
> > > > > direct any pins / unpins to the parent.
> > > > >
> > > > > Patch implements a number of unused functions that will be connected
> > > > > later in the series.
> > > > >
> > > > > Signed-off-by: Matthew Brost
> > > > > ---
> > > > > drivers/gpu/drm/i915/gt/intel_context.c | 187
> > > > > --
> > > > > drivers/gpu/drm/i915/gt/intel_context.h | 43 +---
> > > > > drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
> > > > > .../drm/i915/gt/intel_execlists_submission.c | 25 ++-
> > > > > drivers/gpu/drm/i915/gt/intel_lrc.c | 26 +--
> > > > > drivers/gpu/drm/i915/gt/intel_lrc.h | 6 +-
> > > > > .../gpu/drm/i915/gt/intel_ring_submission.c | 5 +-
> > > > > drivers/gpu/drm/i915/gt/mock_engine.c | 4 +-
> > > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 183 +++--
> > > > > 9 files changed, 371 insertions(+), 112 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > > b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > > index 8cb92b10b547..bb4c14656067 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > > @@ -158,8 +158,8 @@ static void __ring_retire(struct intel_ring *ring)
> > > > > intel_ring_unpin(ring);
> > > > > }
> > > > >
> > > > > -static int intel_context_pre_pin(struct intel_context *ce,
> > > > > - struct i915_gem_ww_ctx *ww)
> > > > > +static int __intel_context_pre_pin(struct intel_context *ce,
> > > > > +struct i915_gem_ww_ctx *ww)
> > > > > {
> > > > > int err;
> > > > >
> > > > > @@ -190,7 +190,7 @@ static int intel_context_pre_pin(struct
> > > > > intel_context *ce,
> > > > > return err;
> > > > > }
> > > > >
> > > > > -static void intel_context_post_unpin(struct intel_context *ce)
> > > > > +static void __intel_context_post_unpin(struct intel_context *ce)
> > > > > {
> > > > > if (ce->state)
> > > > > __context_unpin_state(ce->state);
> > > > > @@ -199,13 +199,85 @@ static void intel_context_post_unpin(struct
> > > > > intel_context *ce)
> > > > > __ring_retire(ce->ring);
> > > > > }
> > > > >
> > > > > -int __intel_context_do_pin_ww(struct intel_context *ce,
> > > > > - struct i915_gem_ww_ctx *ww)
> > > > > +static int intel_context_pre_pin(struct intel_context *ce,
> > > > > + struct i915_gem_ww_ctx *ww)
> > > > > {
> > > > > - bool handoff = false;
> > > > > - void *vaddr;
> > > > > + struct intel_context *child;
> > > > > + int err, i = 0;
> > > > > +
> > > > > + GEM_BUG_ON(intel_context_is_child(ce));
> > > > > +
> > > > > + for_each_child(ce, child) {
> > > > > + err = __intel_context_pre_pin(child, ww);
> > > > > + if (unlikely(err))
> > > > > + goto unwind;
> > > > > + ++i;
> > > > > + }
> > > > > +
> > > > > + err = __intel_context_pre_pin(ce, ww);
> > > > > + if (unlikely(err))
> > > > > + goto unwind;
> > > > > +
> > > > > + return 0;
> > > > > +
> > > > > +unwind:
> > > > > + for_each_child(ce, child) {
> > > > > + if (!i--)
> > > > > + break;
> > > > > + __intel_context_post_unpin(ce);
> > > > > + }
> > > > > +
> > > > > + return err;
> > > > > +}
> > > > > +
> > > > > +static void intel_context_post_unpin(struct intel_context *ce)
> > > > > +{
> > > > > + struct intel_context *child;
> > > > > +
> > > > > + GEM_BUG_ON(intel_context_is_child(ce));
> > > > > +
> > > > > + for_each_child(ce, child)
> > > > > + __intel_context_post_unpin(child);
> > > > > +
> > > > > + __intel_context_post_unpin(ce);
> > > > > +}
> > > > > +
> > > > > +static int __do_ww_lock(struct intel_context *ce,
> > > > > + struct i915_gem_ww_ctx *ww)
> > > > > +{
> > > > > + int err = i915_gem_object_lock(ce->timeline->hwsp_ggtt->obj,
> > > > > ww);
> > > > > +
> > > > > + if (!err && ce->ring->vma->obj)
> > > > > + err = i915_gem_object_lock(ce->ring->vma->obj, ww);
> > > > > + if (!err && ce->state)
> > > > > + err = i915_gem_object_lock(ce->state->obj, ww);
> > > > > +
> > > > > +
Re: [Intel-gfx] [PATCH 16/46] drm/i915/guc: Implement GuC parent-child context pin / unpin functions
On Tue, Aug 10, 2021 at 10:53:37AM +0200, Daniel Vetter wrote:
> On Mon, Aug 09, 2021 at 06:58:23PM +, Matthew Brost wrote:
> > On Mon, Aug 09, 2021 at 05:17:34PM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 03, 2021 at 03:29:13PM -0700, Matthew Brost wrote:
> > > > Implement GuC parent-child context pin / unpin functions in which in any
> > > > contexts in the relationship are pinned all the contexts are pinned. The
> > > > parent owns most of the pinning / unpinning process and the children
> > > > direct any pins / unpins to the parent.
> > > >
> > > > Patch implements a number of unused functions that will be connected
> > > > later in the series.
> > > >
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > > drivers/gpu/drm/i915/gt/intel_context.c | 187 --
> > > > drivers/gpu/drm/i915/gt/intel_context.h | 43 +---
> > > > drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
> > > > .../drm/i915/gt/intel_execlists_submission.c | 25 ++-
> > > > drivers/gpu/drm/i915/gt/intel_lrc.c | 26 +--
> > > > drivers/gpu/drm/i915/gt/intel_lrc.h | 6 +-
> > > > .../gpu/drm/i915/gt/intel_ring_submission.c | 5 +-
> > > > drivers/gpu/drm/i915/gt/mock_engine.c | 4 +-
> > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 183 +++--
> > > > 9 files changed, 371 insertions(+), 112 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > index 8cb92b10b547..bb4c14656067 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > @@ -158,8 +158,8 @@ static void __ring_retire(struct intel_ring *ring)
> > > > intel_ring_unpin(ring);
> > > > }
> > > >
> > > > -static int intel_context_pre_pin(struct intel_context *ce,
> > > > -struct i915_gem_ww_ctx *ww)
> > > > +static int __intel_context_pre_pin(struct intel_context *ce,
> > > > + struct i915_gem_ww_ctx *ww)
> > > > {
> > > > int err;
> > > >
> > > > @@ -190,7 +190,7 @@ static int intel_context_pre_pin(struct
> > > > intel_context *ce,
> > > > return err;
> > > > }
> > > >
> > > > -static void intel_context_post_unpin(struct intel_context *ce)
> > > > +static void __intel_context_post_unpin(struct intel_context *ce)
> > > > {
> > > > if (ce->state)
> > > > __context_unpin_state(ce->state);
> > > > @@ -199,13 +199,85 @@ static void intel_context_post_unpin(struct
> > > > intel_context *ce)
> > > > __ring_retire(ce->ring);
> > > > }
> > > >
> > > > -int __intel_context_do_pin_ww(struct intel_context *ce,
> > > > - struct i915_gem_ww_ctx *ww)
> > > > +static int intel_context_pre_pin(struct intel_context *ce,
> > > > +struct i915_gem_ww_ctx *ww)
> > > > {
> > > > - bool handoff = false;
> > > > - void *vaddr;
> > > > + struct intel_context *child;
> > > > + int err, i = 0;
> > > > +
> > > > + GEM_BUG_ON(intel_context_is_child(ce));
> > > > +
> > > > + for_each_child(ce, child) {
> > > > + err = __intel_context_pre_pin(child, ww);
> > > > + if (unlikely(err))
> > > > + goto unwind;
> > > > + ++i;
> > > > + }
> > > > +
> > > > + err = __intel_context_pre_pin(ce, ww);
> > > > + if (unlikely(err))
> > > > + goto unwind;
> > > > +
> > > > + return 0;
> > > > +
> > > > +unwind:
> > > > + for_each_child(ce, child) {
> > > > + if (!i--)
> > > > + break;
> > > > + __intel_context_post_unpin(ce);
> > > > + }
> > > > +
> > > > + return err;
> > > > +}
> > > > +
> > > > +static void intel_context_post_unpin(struct intel_context *ce)
> > > > +{
> > > > + struct intel_context *child;
> > > > +
> > > > + GEM_BUG_ON(intel_context_is_child(ce));
> > > > +
> > > > + for_each_child(ce, child)
> > > > + __intel_context_post_unpin(child);
> > > > +
> > > > + __intel_context_post_unpin(ce);
> > > > +}
> > > > +
> > > > +static int __do_ww_lock(struct intel_context *ce,
> > > > + struct i915_gem_ww_ctx *ww)
> > > > +{
> > > > + int err = i915_gem_object_lock(ce->timeline->hwsp_ggtt->obj,
> > > > ww);
> > > > +
> > > > + if (!err && ce->ring->vma->obj)
> > > > + err = i915_gem_object_lock(ce->ring->vma->obj, ww);
> > > > + if (!err && ce->state)
> > > > + err = i915_gem_object_lock(ce->state->obj, ww);
> > > > +
> > > > + return err;
> > > > +}
> > > > +
> > > > +static int do_ww_lock(struct intel_context *ce,
> > > > + struct i915_gem_ww_ctx *ww)
> > > > +{
> > > > + struct intel_context *child;
> > > > int err = 0;
>
Re: [PATCH v4 1/3] dt-bindings: vendor-prefixes: Add an entry for SKOV A/S
On Wed, 04 Aug 2021 06:34:37 +0200, Oleksij Rempel wrote: > Add "skov" entry for the SKOV A/S: https://www.skov.com/en/ > > Signed-off-by: Oleksij Rempel > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v4 2/3] dt-bindings: arm: fsl: add SKOV imx6q and imx6dl based boards
On Wed, 04 Aug 2021 06:34:38 +0200, Oleksij Rempel wrote: > Add SKOV imx6q/dl LT2, LT6 and mi1010ait-1cp1 boards. > > Signed-off-by: Oleksij Rempel > --- > Documentation/devicetree/bindings/arm/fsl.yaml | 5 + > 1 file changed, 5 insertions(+) > Acked-by: Rob Herring
Re: [PATCH 1/2] dt-bindings: display: panel: Add Truly NT35521 panel support
On Wed, Aug 04, 2021 at 04:13:51PM +0800, Shawn Guo wrote:
> The Truly NT35521 is a 5.24" 1280x720 DSI panel, and the backlight is
> managed through DSI link.
>
> Signed-off-by: Shawn Guo
> ---
> .../bindings/display/panel/truly,nt35521.yaml | 62 +++
> 1 file changed, 62 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/truly,nt35521.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/truly,nt35521.yaml
> b/Documentation/devicetree/bindings/display/panel/truly,nt35521.yaml
> new file mode 100644
> index ..4727c3df6eb8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/truly,nt35521.yaml
> @@ -0,0 +1,62 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/truly,nt35521.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Truly NT35521 5.24" 1280x720 MIPI-DSI Panel
> +
> +maintainers:
> + - Shawn Guo
> +
> +description: |
> + The Truly NT35521 is a 5.24" 1280x720 MIPI-DSI panel. The panel backlight
> + is managed through DSI link.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +const: truly,nt35521
> +
> + reg: true
> +
> + reset-gpios: true
> +
> + enable-gpios: true
> +
> + pwr-positive5-gpios:
> +maxItems: 1
> +
> + pwr-negative5-gpios:
> +maxItems: 1
Are these +/-5V supplies? If so, they should be modeled with
gpio-regulator perhaps unless the panel connection could only ever be
GPIOs.
> +
> +required:
> + - compatible
> + - reg
> + - reset-gpios
> + - enable-gpios
> + - pwr-positive5-gpios
> + - pwr-negative5-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +panel@0 {
> +compatible = "truly,nt35521";
> +reg = <0>;
> +reset-gpios = <&msmgpio 25 GPIO_ACTIVE_LOW>;
> +pwr-positive5-gpios = <&msmgpio 114 GPIO_ACTIVE_HIGH>;
> +pwr-negative5-gpios = <&msmgpio 17 GPIO_ACTIVE_HIGH>;
> +enable-gpios = <&msmgpio 10 GPIO_ACTIVE_HIGH>;
> +};
> +};
> +...
> --
> 2.17.1
>
>
[PATCH] Whitelist AMD host bridge device(s) to enable P2P DMA
Current implementation will disallow P2P DMA if the participating
devices belong to different root complexes. Implementation allows
this default behavior to be overridden for whitelisted devices. The
patch adds an AMD host bridge to be whitelisted
Signed-off-by: Ramesh Errabolu
---
drivers/pci/p2pdma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index 196382630363..7003bb9faf23 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -305,6 +305,8 @@ static const struct pci_p2pdma_whitelist_entry {
{PCI_VENDOR_ID_INTEL, 0x2032, 0},
{PCI_VENDOR_ID_INTEL, 0x2033, 0},
{PCI_VENDOR_ID_INTEL, 0x2020, 0},
+ /* AMD Host Bridge Devices */
+ {PCI_VENDOR_ID_AMD, 0x1480, 0},
{}
};
--
2.31.1
Re: [PATCH] Whitelist AMD host bridge device(s) to enable P2P DMA
On Wed, Aug 11, 2021 at 3:11 PM Ramesh Errabolu wrote:
>
> Current implementation will disallow P2P DMA if the participating
> devices belong to different root complexes. Implementation allows
> this default behavior to be overridden for whitelisted devices. The
> patch adds an AMD host bridge to be whitelisted
Why do we need this? cpu_supports_p2pdma() should return true for all
AMD Zen CPUs.
Alex
>
> Signed-off-by: Ramesh Errabolu
> ---
> drivers/pci/p2pdma.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index 196382630363..7003bb9faf23 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -305,6 +305,8 @@ static const struct pci_p2pdma_whitelist_entry {
> {PCI_VENDOR_ID_INTEL, 0x2032, 0},
> {PCI_VENDOR_ID_INTEL, 0x2033, 0},
> {PCI_VENDOR_ID_INTEL, 0x2020, 0},
> + /* AMD Host Bridge Devices */
> + {PCI_VENDOR_ID_AMD, 0x1480, 0},
> {}
> };
>
> --
> 2.31.1
>
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List
On Tue, Aug 10, 2021 at 04:52:11PM -0700, Juston Li wrote:
> When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by itself
> once to retrieve the DEVICE_COUNT to calculate the size of the
> ReceiverID list then read a second time as a part of reading ReceiverID
> list.
>
> On some MST docking stations, RxInfo can only be read after the RxStatus
> READY bit is set otherwise the read will return -EIO. The spec states that
> the READY bit should be cleared as soon as RxInfo has been read.
>
> In this case, the first RxInfo read succeeds but after the READY bit is
> cleared, the second read fails.
>
> Fix it by reading RxInfo once and storing it before reading the rest of
> RepeaterAuth_Send_ReceiverID_List once we know the size.
>
> Modify get_receiver_id_list_size() to read and store RxInfo in the
> message buffer and also parse DEVICE_COUNT so we know the size of
> RepeaterAuth_Send_ReceiverID_List.
>
> Afterwards, retrieve the rest of the message at the offset for
> seq_num_V.
>
> Changes in v4:
> - rebase and edit commit message
>
> Changes in v3:
> - remove comment
>
> Changes in v2:
> - remove unnecessary moving of drm_i915_private from patch 1
>
> Signed-off-by: Juston Li
> Acked-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 30 ++--
> include/drm/drm_dp_helper.h | 2 +-
> 2 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index 1d0096654776..526fd58b9b51 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -496,11 +496,10 @@ get_rxinfo_hdcp_1_dev_downstream(struct
> intel_digital_port *dig_port, bool *hdcp
> }
>
> static
> -ssize_t get_receiver_id_list_size(struct intel_digital_port *dig_port)
> +ssize_t get_receiver_id_list_rx_info(struct intel_digital_port *dig_port,
> u32 *dev_cnt, u8 *byte)
> {
> - u8 rx_info[HDCP_2_2_RXINFO_LEN];
> - u32 dev_cnt;
> ssize_t ret;
> + u8 *rx_info = byte;
>
> ret = drm_dp_dpcd_read(&dig_port->dp.aux,
> DP_HDCP_2_2_REG_RXINFO_OFFSET,
> @@ -508,15 +507,11 @@ ssize_t get_receiver_id_list_size(struct
> intel_digital_port *dig_port)
> if (ret != HDCP_2_2_RXINFO_LEN)
> return ret >= 0 ? -EIO : ret;
>
> - dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
> + *dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
> HDCP_2_2_DEV_COUNT_LO(rx_info[1]));
>
> - if (dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
> - dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
> -
> - ret = sizeof(struct hdcp2_rep_send_receiverid_list) -
> - HDCP_2_2_RECEIVER_IDS_MAX_LEN +
> - (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
> + if (*dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
> + *dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
>
> return ret;
> }
> @@ -534,6 +529,7 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
> *dig_port,
> const struct hdcp2_dp_msg_data *hdcp2_msg_data;
> ktime_t msg_end = ktime_set(0, 0);
> bool msg_expired;
> + u32 dev_cnt;
>
> hdcp2_msg_data = get_hdcp2_dp_msg_data(msg_id);
> if (!hdcp2_msg_data)
> @@ -546,17 +542,21 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
> *dig_port,
>
> hdcp->cp_irq_count_cached = atomic_read(&hdcp->cp_irq_count);
>
> + /* DP adaptation msgs has no msg_id */
> + byte++;
> +
> if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {
> - ret = get_receiver_id_list_size(dig_port);
> + ret = get_receiver_id_list_rx_info(dig_port, &dev_cnt, byte);
> if (ret < 0)
> return ret;
>
> - size = ret;
> + byte += ret;
> + size = sizeof(struct hdcp2_rep_send_receiverid_list) -
> + HDCP_2_2_RXINFO_LEN - HDCP_2_2_RECEIVER_IDS_MAX_LEN +
> + (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
> }
> - bytes_to_recv = size - 1;
>
> - /* DP adaptation msgs has no msg_id */
> - byte++;
> + bytes_to_recv = size - 1;
>
> while (bytes_to_recv) {
> len = bytes_to_recv > DP_AUX_MAX_PAYLOAD_BYTES ?
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
I was about to merge to drm-intel-next but then I noticed this..
So we need to cc Dave and Daniel here to get an ack from them.
> index 3f2715eb965f..7476e7c6d0be 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1413,7 +1413,7 @@ enum drm_dp_phy {
> #define DP_HDCP_2_2_LC_INIT_OFFSET DP_HDCP_2_2_REG_RN_OFFSET
> #define DP_HDCP_2_2_LC_SEND_LPRIME_OFFSETDP_HDCP_2_2_REG_LPRIME_OFFSET
> #define DP_HDCP_2_2_SKE_SEND_EKS_OFFSET
> DP_HDCP_2_2_REG_EDKEY_KS_OFFSET
> -#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET
> DP_HDCP_2_2_R
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List
On Wed, 2021-08-11 at 15:34 -0400, Rodrigo Vivi wrote:
> On Tue, Aug 10, 2021 at 04:52:11PM -0700, Juston Li wrote:
> > When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by
> > itself
> > once to retrieve the DEVICE_COUNT to calculate the size of the
> > ReceiverID list then read a second time as a part of reading
> > ReceiverID
> > list.
> >
> > On some MST docking stations, RxInfo can only be read after the
> > RxStatus
> > READY bit is set otherwise the read will return -EIO. The spec
> > states that
> > the READY bit should be cleared as soon as RxInfo has been read.
> >
> > In this case, the first RxInfo read succeeds but after the READY
> > bit is
> > cleared, the second read fails.
> >
> > Fix it by reading RxInfo once and storing it before reading the
> > rest of
> > RepeaterAuth_Send_ReceiverID_List once we know the size.
> >
> > Modify get_receiver_id_list_size() to read and store RxInfo in the
> > message buffer and also parse DEVICE_COUNT so we know the size of
> > RepeaterAuth_Send_ReceiverID_List.
> >
> > Afterwards, retrieve the rest of the message at the offset for
> > seq_num_V.
> >
> > Changes in v4:
> > - rebase and edit commit message
> >
> > Changes in v3:
> > - remove comment
> >
> > Changes in v2:
> > - remove unnecessary moving of drm_i915_private from patch 1
> >
> > Signed-off-by: Juston Li
> > Acked-by: Anshuman Gupta
> > ---
> > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 30 ++--
> >
> > include/drm/drm_dp_helper.h | 2 +-
> > 2 files changed, 16 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > index 1d0096654776..526fd58b9b51 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > @@ -496,11 +496,10 @@ get_rxinfo_hdcp_1_dev_downstream(struct
> > intel_digital_port *dig_port, bool *hdcp
> > }
> >
> > static
> > -ssize_t get_receiver_id_list_size(struct intel_digital_port
> > *dig_port)
> > +ssize_t get_receiver_id_list_rx_info(struct intel_digital_port
> > *dig_port, u32 *dev_cnt, u8 *byte)
> > {
> > - u8 rx_info[HDCP_2_2_RXINFO_LEN];
> > - u32 dev_cnt;
> > ssize_t ret;
> > + u8 *rx_info = byte;
> >
> > ret = drm_dp_dpcd_read(&dig_port->dp.aux,
> > DP_HDCP_2_2_REG_RXINFO_OFFSET,
> > @@ -508,15 +507,11 @@ ssize_t get_receiver_id_list_size(struct
> > intel_digital_port *dig_port)
> > if (ret != HDCP_2_2_RXINFO_LEN)
> > return ret >= 0 ? -EIO : ret;
> >
> > - dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
> > + *dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
> > HDCP_2_2_DEV_COUNT_LO(rx_info[1]));
> >
> > - if (dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
> > - dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
> > -
> > - ret = sizeof(struct hdcp2_rep_send_receiverid_list) -
> > - HDCP_2_2_RECEIVER_IDS_MAX_LEN +
> > - (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
> > + if (*dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
> > + *dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
> >
> > return ret;
> > }
> > @@ -534,6 +529,7 @@ int intel_dp_hdcp2_read_msg(struct
> > intel_digital_port *dig_port,
> > const struct hdcp2_dp_msg_data *hdcp2_msg_data;
> > ktime_t msg_end = ktime_set(0, 0);
> > bool msg_expired;
> > + u32 dev_cnt;
> >
> > hdcp2_msg_data = get_hdcp2_dp_msg_data(msg_id);
> > if (!hdcp2_msg_data)
> > @@ -546,17 +542,21 @@ int intel_dp_hdcp2_read_msg(struct
> > intel_digital_port *dig_port,
> >
> > hdcp->cp_irq_count_cached = atomic_read(&hdcp-
> > >cp_irq_count);
> >
> > + /* DP adaptation msgs has no msg_id */
> > + byte++;
> > +
> > if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {
> > - ret = get_receiver_id_list_size(dig_port);
> > + ret = get_receiver_id_list_rx_info(dig_port,
> > &dev_cnt, byte);
> > if (ret < 0)
> > return ret;
> >
> > - size = ret;
> > + byte += ret;
> > + size = sizeof(struct
> > hdcp2_rep_send_receiverid_list) -
> > + HDCP_2_2_RXINFO_LEN - HDCP_2_2_RECEIVER_IDS_MAX_LEN
> > +
> > + (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
> > }
> > - bytes_to_recv = size - 1;
> >
> > - /* DP adaptation msgs has no msg_id */
> > - byte++;
> > + bytes_to_recv = size - 1;
> >
> > while (bytes_to_recv) {
> > len = bytes_to_recv > DP_AUX_MAX_PAYLOAD_BYTES ?
> > diff --git a/include/drm/drm_dp_helper.h
> > b/include/drm/drm_dp_helper.h
>
> I was about to merge to drm-intel-next but then I noticed this..
>
> So we need to cc Dave and Daniel here to get an ack from them.
>
> > index 3f2715eb965f..7476e7c6
Re: [PATCH] gpu: drm: amd: amdgpu: amdgpu_i2c: fix possible uninitialized-variable access in amdgpu_i2c_router_select_ddc_port()
Applied. Thanks!
Alex
On Wed, Aug 11, 2021 at 7:35 AM Tuo Li wrote:
>
> The variable val is declared without initialization, and its address is
> passed to amdgpu_i2c_get_byte(). In this function, the value of val is
> accessed in:
> DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n",
>addr, *val);
>
> Also, when amdgpu_i2c_get_byte() returns, val may remain uninitialized,
> but it is accessed in:
> val &= ~amdgpu_connector->router.ddc_mux_control_pin;
>
> To fix this possible uninitialized-variable access, initialize val to 0 in
> amdgpu_i2c_router_select_ddc_port().
>
> Reported-by: TOTE Robot
> Signed-off-by: Tuo Li
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> index bca45a15..82608df43396 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> @@ -339,7 +339,7 @@ static void amdgpu_i2c_put_byte(struct amdgpu_i2c_chan
> *i2c_bus,
> void
> amdgpu_i2c_router_select_ddc_port(const struct amdgpu_connector
> *amdgpu_connector)
> {
> - u8 val;
> + u8 val = 0;
>
> if (!amdgpu_connector->router.ddc_valid)
> return;
> --
> 2.25.1
>
Re: [PATCH 2/2] drm/amdgpu: Use mod_delayed_work in JPEG/UVD/VCE/VCN ring_end_use hooks
On Wed, Aug 11, 2021 at 12:52 PM Michel Dänzer wrote:
>
> From: Michel Dänzer
>
> In contrast to schedule_delayed_work, this pushes back the work if it
> was already scheduled before. Specific behaviour change:
>
> Before:
>
> The scheduled work ran ~1 second after the first time ring_end_use was
> called, even if the ring was used again during that second.
>
> After:
>
> The scheduled work runs ~1 second after the last time ring_end_use is
> called.
>
> Inspired by the corresponding change in amdgpu_gfx_off_ctrl. While I
> haven't run into specific issues in this case, the new behaviour makes
> more sense to me.
>
> Signed-off-by: Michel Dänzer
Makes sense to me. Applied the series.
Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c| 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
> index 8996cb4ed57a..2c0040153f6c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
> @@ -110,7 +110,7 @@ void amdgpu_jpeg_ring_begin_use(struct amdgpu_ring *ring)
> void amdgpu_jpeg_ring_end_use(struct amdgpu_ring *ring)
> {
> atomic_dec(&ring->adev->jpeg.total_submission_cnt);
> - schedule_delayed_work(&ring->adev->jpeg.idle_work, JPEG_IDLE_TIMEOUT);
> + mod_delayed_work(system_wq, &ring->adev->jpeg.idle_work,
> JPEG_IDLE_TIMEOUT);
> }
>
> int amdgpu_jpeg_dec_ring_test_ring(struct amdgpu_ring *ring)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> index 0f576f294d8a..b6b1d7eeb8e5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> @@ -1283,7 +1283,7 @@ void amdgpu_uvd_ring_begin_use(struct amdgpu_ring *ring)
> void amdgpu_uvd_ring_end_use(struct amdgpu_ring *ring)
> {
> if (!amdgpu_sriov_vf(ring->adev))
> - schedule_delayed_work(&ring->adev->uvd.idle_work,
> UVD_IDLE_TIMEOUT);
> + mod_delayed_work(system_wq, &ring->adev->uvd.idle_work,
> UVD_IDLE_TIMEOUT);
> }
>
> /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> index 1ae7f824adc7..2253c18a6688 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> @@ -401,7 +401,7 @@ void amdgpu_vce_ring_begin_use(struct amdgpu_ring *ring)
> void amdgpu_vce_ring_end_use(struct amdgpu_ring *ring)
> {
> if (!amdgpu_sriov_vf(ring->adev))
> - schedule_delayed_work(&ring->adev->vce.idle_work,
> VCE_IDLE_TIMEOUT);
> + mod_delayed_work(system_wq, &ring->adev->vce.idle_work,
> VCE_IDLE_TIMEOUT);
> }
>
> /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
> b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
> index 284bb42d6c86..d5937ab5ac80 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
> @@ -1874,7 +1874,7 @@ void vcn_v1_0_set_pg_for_begin_use(struct amdgpu_ring
> *ring, bool set_clocks)
>
> void vcn_v1_0_ring_end_use(struct amdgpu_ring *ring)
> {
> - schedule_delayed_work(&ring->adev->vcn.idle_work, VCN_IDLE_TIMEOUT);
> + mod_delayed_work(system_wq, &ring->adev->vcn.idle_work,
> VCN_IDLE_TIMEOUT);
> mutex_unlock(&ring->adev->vcn.vcn1_jpeg1_workaround);
> }
>
> --
> 2.32.0
>
Re: [PATCH v2 4/6] drm/bridge: ti-sn65dsi86: Wrap panel with panel-bridge
Quoting Rob Clark (2021-08-11 09:20:30) > On Wed, Aug 11, 2021 at 5:15 AM Laurent Pinchart > wrote: > > > > Hi Stephen, > > > > On Tue, Aug 10, 2021 at 10:26:33PM -0700, Stephen Boyd wrote: > > > Quoting Laurent Pinchart (2021-06-23 17:03:02) > > > > To simplify interfacing with the panel, wrap it in a panel-bridge and > > > > let the DRM bridge helpers handle chaining of operations. > > > > > > > > This also prepares for support of DRM_BRIDGE_ATTACH_NO_CONNECTOR, which > > > > requires all components in the display pipeline to be represented by > > > > bridges. > > > > > > > > Signed-off-by: Laurent Pinchart > > > > > > > > Reviewed-by: Jagan Teki > > > > --- > > > > > > With this patch applied I get two eDP devices on Lazor sc7180 (it is the > > > arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor*.dts files if you're > > > looking for more info). As far as I can tell, we should only have one > > > eDP device on the board, for the bridge. > > > > > > localhost ~ # ls -l /sys/class/drm/card1-eDP* > > > lrwxrwxrwx. 1 root root 0 Aug 10 22:24 /sys/class/drm/card1-eDP-1 -> > > > ../../devices/platform/soc@0/ae0.mdss/drm/card1/card1-eDP-1 > > > lrwxrwxrwx. 1 root root 0 Aug 10 22:24 /sys/class/drm/card1-eDP-2 -> > > > ../../devices/platform/soc@0/ae0.mdss/drm/card1/card1-eDP-2 > > > > Indeed. > > > > Does the display driver use the DRM connector bridge helper and > > DRM_BRIDGE_ATTACH_NO_CONNECTOR on that platform ? > > > > There haven't been any recent changes about how we attach the bridge, > it doesn't pass DRM_BRIDGE_ATTACH_NO_CONNECTOR.. tbh I've not been > having time to follow too closely the recent changes with bridge stuff > myself. > > But now with this patch we have both the ti bridge and the panel > bridge creating a connector.. removing the connector created by the > ti bridge "fixes" things, but not sure if that would break something > on other platforms. I guess there should now always be a panel > bridge, so removing ti_sn_bridge_connector_init() would be a sane > thing to do? > So this patch works. We don't want to make the connector in this driver for the next bridge because this driver is making the connector. I guess eventually we'll drop this flag when this driver stops making the connector here? ---8<--- diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index cd0fccdd8dfd..a8d4818484aa 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -741,7 +741,7 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge, /* Attach the next bridge */ ret = drm_bridge_attach(bridge->encoder, pdata->next_bridge, - &pdata->bridge, flags); + &pdata->bridge, flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR); if (ret < 0) goto err_dsi_detach;
Re: [PATCH v2 4/6] drm/bridge: ti-sn65dsi86: Wrap panel with panel-bridge
On Wed, Aug 11, 2021 at 1:39 PM Stephen Boyd wrote: > > Quoting Rob Clark (2021-08-11 09:20:30) > > On Wed, Aug 11, 2021 at 5:15 AM Laurent Pinchart > > wrote: > > > > > > Hi Stephen, > > > > > > On Tue, Aug 10, 2021 at 10:26:33PM -0700, Stephen Boyd wrote: > > > > Quoting Laurent Pinchart (2021-06-23 17:03:02) > > > > > To simplify interfacing with the panel, wrap it in a panel-bridge and > > > > > let the DRM bridge helpers handle chaining of operations. > > > > > > > > > > This also prepares for support of DRM_BRIDGE_ATTACH_NO_CONNECTOR, > > > > > which > > > > > requires all components in the display pipeline to be represented by > > > > > bridges. > > > > > > > > > > Signed-off-by: Laurent Pinchart > > > > > > > > > > Reviewed-by: Jagan Teki > > > > > --- > > > > > > > > With this patch applied I get two eDP devices on Lazor sc7180 (it is the > > > > arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor*.dts files if you're > > > > looking for more info). As far as I can tell, we should only have one > > > > eDP device on the board, for the bridge. > > > > > > > > localhost ~ # ls -l /sys/class/drm/card1-eDP* > > > > lrwxrwxrwx. 1 root root 0 Aug 10 22:24 /sys/class/drm/card1-eDP-1 -> > > > > ../../devices/platform/soc@0/ae0.mdss/drm/card1/card1-eDP-1 > > > > lrwxrwxrwx. 1 root root 0 Aug 10 22:24 /sys/class/drm/card1-eDP-2 -> > > > > ../../devices/platform/soc@0/ae0.mdss/drm/card1/card1-eDP-2 > > > > > > Indeed. > > > > > > Does the display driver use the DRM connector bridge helper and > > > DRM_BRIDGE_ATTACH_NO_CONNECTOR on that platform ? > > > > > > > There haven't been any recent changes about how we attach the bridge, > > it doesn't pass DRM_BRIDGE_ATTACH_NO_CONNECTOR.. tbh I've not been > > having time to follow too closely the recent changes with bridge stuff > > myself. > > > > But now with this patch we have both the ti bridge and the panel > > bridge creating a connector.. removing the connector created by the > > ti bridge "fixes" things, but not sure if that would break something > > on other platforms. I guess there should now always be a panel > > bridge, so removing ti_sn_bridge_connector_init() would be a sane > > thing to do? > > > > So this patch works. We don't want to make the connector in this driver > for the next bridge because this driver is making the connector. I guess > eventually we'll drop this flag when this driver stops making the > connector here? > > ---8<--- > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index cd0fccdd8dfd..a8d4818484aa 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -741,7 +741,7 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge, > > /* Attach the next bridge */ > ret = drm_bridge_attach(bridge->encoder, pdata->next_bridge, > - &pdata->bridge, flags); > + &pdata->bridge, flags | > DRM_BRIDGE_ATTACH_NO_CONNECTOR); > if (ret < 0) > goto err_dsi_detach; I kinda think *all* bridges that create a connector (whether optional or not) should OR in NO_CONNECTOR when attaching the next downstream bridge.. since you never want multiple connectors BR, -R
Re: [PATCH] Whitelist AMD host bridge device(s) to enable P2P DMA
Am 2021-08-11 um 3:29 p.m. schrieb Alex Deucher:
> On Wed, Aug 11, 2021 at 3:11 PM Ramesh Errabolu
> wrote:
>> Current implementation will disallow P2P DMA if the participating
>> devices belong to different root complexes. Implementation allows
>> this default behavior to be overridden for whitelisted devices. The
>> patch adds an AMD host bridge to be whitelisted
> Why do we need this? cpu_supports_p2pdma() should return true for all
> AMD Zen CPUs.
This is part of our on-going work to get P2P support upstream. We want
to use pci_p2pdma_distance_many to determine whether P2P is possible
between a pair of devices. This whitelist is used in this function. This
will affect the P2P links reported in the topology and it will be
double-checked in the BO mapping function to ensure a peer mapping is legal.
I think this change is a bit free of context at the moment, as we're
still working on a few other loose ends for P2P support in our internal
branch. I'm hoping we'll have a bigger patch series for upstreamable KFD
P2P support ready in a few weeks. I also think we'll probably want to
add a few more PCI IDs for other supported AMD root complexes.
Regards,
Felix
>
> Alex
>
>> Signed-off-by: Ramesh Errabolu
>> ---
>> drivers/pci/p2pdma.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
>> index 196382630363..7003bb9faf23 100644
>> --- a/drivers/pci/p2pdma.c
>> +++ b/drivers/pci/p2pdma.c
>> @@ -305,6 +305,8 @@ static const struct pci_p2pdma_whitelist_entry {
>> {PCI_VENDOR_ID_INTEL, 0x2032, 0},
>> {PCI_VENDOR_ID_INTEL, 0x2033, 0},
>> {PCI_VENDOR_ID_INTEL, 0x2020, 0},
>> + /* AMD Host Bridge Devices */
>> + {PCI_VENDOR_ID_AMD, 0x1480, 0},
>> {}
>> };
>>
>> --
>> 2.31.1
>>
[PATCH] drm/edid: fix edid field name
Byte 26 in a edid struct is supposed to be "Blue and white
least-significant 2 bits", not "black and white". Rename the field
accordingly. This field is not used anywhere, so just renaming it here
for correctness.
Signed-off-by: Lucas De Marchi
---
include/drm/drm_edid.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 759328a5eeb2..deccfd39e6db 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -336,7 +336,7 @@ struct edid {
u8 features;
/* Color characteristics */
u8 red_green_lo;
- u8 black_white_lo;
+ u8 blue_white_lo;
u8 red_x;
u8 red_y;
u8 green_x;
--
2.31.1
Re: [PATCH 2/2] drm/amdgpu: Use mod_delayed_work in JPEG/UVD/VCE/VCN ring_end_use hooks
[AMD Official Use Only]
This patch is Reviewed-by: James Zhu
Thanks & Best Regards!
James Zhu
From: Alex Deucher
Sent: Wednesday, August 11, 2021 4:34 PM
To: Michel Dänzer
Cc: Deucher, Alexander ; Koenig, Christian
; Liu, Leo ; Zhu, James
; amd-gfx list ; Maling list
- DRI developers
Subject: Re: [PATCH 2/2] drm/amdgpu: Use mod_delayed_work in JPEG/UVD/VCE/VCN
ring_end_use hooks
On Wed, Aug 11, 2021 at 12:52 PM Michel Dänzer wrote:
>
> From: Michel Dänzer
>
> In contrast to schedule_delayed_work, this pushes back the work if it
> was already scheduled before. Specific behaviour change:
>
> Before:
>
> The scheduled work ran ~1 second after the first time ring_end_use was
> called, even if the ring was used again during that second.
>
> After:
>
> The scheduled work runs ~1 second after the last time ring_end_use is
> called.
>
> Inspired by the corresponding change in amdgpu_gfx_off_ctrl. While I
> haven't run into specific issues in this case, the new behaviour makes
> more sense to me.
>
> Signed-off-by: Michel Dänzer
Makes sense to me. Applied the series.
Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c| 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
> index 8996cb4ed57a..2c0040153f6c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
> @@ -110,7 +110,7 @@ void amdgpu_jpeg_ring_begin_use(struct amdgpu_ring *ring)
> void amdgpu_jpeg_ring_end_use(struct amdgpu_ring *ring)
> {
> atomic_dec(&ring->adev->jpeg.total_submission_cnt);
> - schedule_delayed_work(&ring->adev->jpeg.idle_work, JPEG_IDLE_TIMEOUT);
> + mod_delayed_work(system_wq, &ring->adev->jpeg.idle_work,
> JPEG_IDLE_TIMEOUT);
> }
>
> int amdgpu_jpeg_dec_ring_test_ring(struct amdgpu_ring *ring)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> index 0f576f294d8a..b6b1d7eeb8e5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> @@ -1283,7 +1283,7 @@ void amdgpu_uvd_ring_begin_use(struct amdgpu_ring *ring)
> void amdgpu_uvd_ring_end_use(struct amdgpu_ring *ring)
> {
> if (!amdgpu_sriov_vf(ring->adev))
> - schedule_delayed_work(&ring->adev->uvd.idle_work,
> UVD_IDLE_TIMEOUT);
> + mod_delayed_work(system_wq, &ring->adev->uvd.idle_work,
> UVD_IDLE_TIMEOUT);
> }
>
> /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> index 1ae7f824adc7..2253c18a6688 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> @@ -401,7 +401,7 @@ void amdgpu_vce_ring_begin_use(struct amdgpu_ring *ring)
> void amdgpu_vce_ring_end_use(struct amdgpu_ring *ring)
> {
> if (!amdgpu_sriov_vf(ring->adev))
> - schedule_delayed_work(&ring->adev->vce.idle_work,
> VCE_IDLE_TIMEOUT);
> + mod_delayed_work(system_wq, &ring->adev->vce.idle_work,
> VCE_IDLE_TIMEOUT);
> }
>
> /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
> b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
> index 284bb42d6c86..d5937ab5ac80 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
> @@ -1874,7 +1874,7 @@ void vcn_v1_0_set_pg_for_begin_use(struct amdgpu_ring
> *ring, bool set_clocks)
>
> void vcn_v1_0_ring_end_use(struct amdgpu_ring *ring)
> {
> - schedule_delayed_work(&ring->adev->vcn.idle_work, VCN_IDLE_TIMEOUT);
> + mod_delayed_work(system_wq, &ring->adev->vcn.idle_work,
> VCN_IDLE_TIMEOUT);
> mutex_unlock(&ring->adev->vcn.vcn1_jpeg1_workaround);
> }
>
> --
> 2.32.0
>
Re: [PATCH] Whitelist AMD host bridge device(s) to enable P2P DMA
On Wed, Aug 11, 2021 at 4:50 PM Felix Kuehling wrote:
>
>
> Am 2021-08-11 um 3:29 p.m. schrieb Alex Deucher:
> > On Wed, Aug 11, 2021 at 3:11 PM Ramesh Errabolu
> > wrote:
> >> Current implementation will disallow P2P DMA if the participating
> >> devices belong to different root complexes. Implementation allows
> >> this default behavior to be overridden for whitelisted devices. The
> >> patch adds an AMD host bridge to be whitelisted
> > Why do we need this? cpu_supports_p2pdma() should return true for all
> > AMD Zen CPUs.
>
> This is part of our on-going work to get P2P support upstream. We want
> to use pci_p2pdma_distance_many to determine whether P2P is possible
> between a pair of devices. This whitelist is used in this function. This
> will affect the P2P links reported in the topology and it will be
> double-checked in the BO mapping function to ensure a peer mapping is legal.
>
> I think this change is a bit free of context at the moment, as we're
> still working on a few other loose ends for P2P support in our internal
> branch. I'm hoping we'll have a bigger patch series for upstreamable KFD
> P2P support ready in a few weeks. I also think we'll probably want to
> add a few more PCI IDs for other supported AMD root complexes.
We don't need to keep adding AMD root complexes. You must be using an
older kernel or something. All root complexes on all Zen platforms
support P2P DMA. See:
commit dea286bb71baded7d2fb4f090e3b9fd2c1ccac58
Author: Logan Gunthorpe
Date: Wed Jul 29 17:18:44 2020 -0600
PCI/P2PDMA: Allow P2PDMA on AMD Zen and newer CPUs
Allow P2PDMA if the CPU vendor is AMD and family is 0x17 (Zen) or greater.
[bhelgaas: commit log, simplify #if/#else/#endif]
Link: https://lore.kernel.org/r/20200729231844.4653-1-log...@deltatee.com
Signed-off-by: Logan Gunthorpe
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
Cc: Christian König
Cc: Huang Rui
Alex
>
> Regards,
> Felix
>
>
> >
> > Alex
> >
> >> Signed-off-by: Ramesh Errabolu
> >> ---
> >> drivers/pci/p2pdma.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> >> index 196382630363..7003bb9faf23 100644
> >> --- a/drivers/pci/p2pdma.c
> >> +++ b/drivers/pci/p2pdma.c
> >> @@ -305,6 +305,8 @@ static const struct pci_p2pdma_whitelist_entry {
> >> {PCI_VENDOR_ID_INTEL, 0x2032, 0},
> >> {PCI_VENDOR_ID_INTEL, 0x2033, 0},
> >> {PCI_VENDOR_ID_INTEL, 0x2020, 0},
> >> + /* AMD Host Bridge Devices */
> >> + {PCI_VENDOR_ID_AMD, 0x1480, 0},
> >> {}
> >> };
> >>
> >> --
> >> 2.31.1
> >>
Re: [PATCH] drm/edid: fix edid field name
Reviewed-by: Simon Ser Do you need me to push this?
