Re: [PATCH v3 1/3] usb: gadget: add Aspeed ast2600 udc driver
On Fri, May 20, 2022 at 02:29:36AM +, Neal Liu wrote: > > -Original Message- > > From: Greg Kroah-Hartman > > Sent: Thursday, May 19, 2022 11:56 PM > > To: Neal Liu > > Cc: Rob Herring ; Krzysztof Kozlowski > > ; Joel Stanley ; Andrew > > Jeffery ; Felipe Balbi ; Sumit Semwal > > ; Christian König ; > > Geert Uytterhoeven ; Li Yang ; > > linux-asp...@lists.ozlabs.org; linux-...@vger.kernel.org; > > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > > linux-ker...@vger.kernel.org; linux-me...@vger.kernel.org; > > dri-devel@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; kernel test > > robot > > Subject: Re: [PATCH v3 1/3] usb: gadget: add Aspeed ast2600 udc driver > > > > On Wed, May 18, 2022 at 02:20:41PM +0800, Neal Liu wrote: > > > Aspeed udc is compliant with USB2.0, supports USB High Speed and Full > > > Speed, backward compatible with USB1.1. > > > > > > Supports independent DMA channel for each generic endpoint. > > > Supports 32/256 stages descriptor mode for all generic endpoints. > > > > > > This driver supports full functionality including single/multiple > > > stages descriptor mode, and exposes 1 UDC gadget driver. > > > > > > Signed-off-by: Neal Liu > > > Reported-by: kernel test robot > > > > The kernel test robot did not report that you needed to add a new driver :( > > I had received auto build test WARNING on usb/usb-testing reported from > kernel test robot. > It still mentioned that if the issue is fixed, I can kindly add this tag. > Would you prefer not to add this tag for the first coming driver? Please do not add tags that do not make sense to. thanks, greg k-h
[PULL] drm-intel-fixes
Hi Dave & Daniel, Here's the previous PR + additional fix for regression #5806: GPU hangs and display artifacts on 5.18-rc3 on Intel GM45. Was also discussed here: https://lore.kernel.org/all/CAHk-=wj0ghsg6iw3d8ufptm9a_dvtsqrrofy9wopobbybyu...@mail.gmail.com/ Regards, Joonas *** drm-intel-fixes-2022-05-20: - Previous PR + fix for #5806: GPU hangs and display artifacts on 5.18-rc3 on Intel GM45 The following changes since commit 42226c989789d8da4af1de0c31070c96726d990c: Linux 5.18-rc7 (2022-05-15 18:08:58 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-05-20 for you to fetch changes up to 7b1d6924f27ba24b9e47abb9bd53d0bbc430a835: drm/i915: Use i915_gem_object_ggtt_pin_ww for reloc_iomap (2022-05-19 12:49:49 +0300) - Previous PR + fix for #5806: GPU hangs and display artifacts on 5.18-rc3 on Intel GM45 Anusha Srivatsa (1): drm/i915/dmc: Add MMIO range restrictions Maarten Lankhorst (1): drm/i915: Use i915_gem_object_ggtt_pin_ww for reloc_iomap Umesh Nerlige Ramappa (1): i915/guc/reset: Make __guc_reset_context aware of guilty engines drivers/gpu/drm/i915/display/intel_dmc.c | 44 +++ drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 6 ++-- drivers/gpu/drm/i915/gt/intel_reset.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 16 - drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 +- drivers/gpu/drm/i915/i915_reg.h | 16 + 8 files changed, 74 insertions(+), 16 deletions(-)
Re: [PATCH 1/2] MAINTAINERS: Broaden scope of simpledrm entry
Hello Thomas, On 5/18/22 20:30, Thomas Zimmermann wrote: > There will be more DRM drivers for firmware-provided framebuffers. Use > the existing entry for simpledrm instead of adding a new one for each > driver. Also add DRM's aperture helpers, which are part of the driver's > infrastructure. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas I think you could push this without waiting for 2/2 to be ready. > MAINTAINERS | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 5c1fd93d9050..43d833273ae9 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6388,13 +6388,15 @@ S:Orphan / Obsolete > F: drivers/gpu/drm/savage/ > F: include/uapi/drm/savage_drm.h > > -DRM DRIVER FOR SIMPLE FRAMEBUFFERS > +DRM DRIVER FOR FIRMWARE FRAMEBUFFERS > M: Thomas Zimmermann > M: Javier Martinez Canillas > L: dri-devel@lists.freedesktop.org > S: Maintained > T: git git://anongit.freedesktop.org/drm/drm-misc > +F: drivers/gpu/drm/drm_aperture.c > F: drivers/gpu/drm/tiny/simpledrm.c > +F: include/drm/drm_aperture.h I wonder if we could add drivers/firmware/sysfb* as well, it certainly is related since is the place where different platforms register the device. But it's not in drivers/gpu, hence the question if we could include it (and possibly merge it through drm-misc as well, etc). Dave, Daniel, what do you think ? -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [RFC PATCH] procfs: Add file path and size to /proc//fdinfo
On Thu, May 19, 2022 at 02:40:15PM -0700, Kalesh Singh wrote: > [...] > + seq_file_path(m, file, "\n"); > + seq_putc(m, '\n'); > > /* show_fd_locks() never deferences files so a stale value is safe */ > show_fd_locks(m, file, files); This comment implies "file" might be stale? Does that mean anything for the above seq_file_path()? -- Kees Cook
Re: [PATCH] staging: fbtft: fix checkpatch.pl struct should normally be const
Hi Uri, Thank you for the patch! Yet something to improve: [auto build test ERROR on staging/staging-testing] url: https://github.com/intel-lab-lkp/linux/commits/Uri-Arev/staging-fbtft-fix-checkpatch-pl-struct-should-normally-be-const/20220520-012948 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 4d0cc9e0e53e9946d7b8dc58279c62dfa7a2191b config: x86_64-randconfig-a013 (https://download.01.org/0day-ci/archive/20220520/202205200955.wbcgkxij-...@intel.com/config) compiler: gcc-11 (Debian 11.3.0-1) 11.3.0 reproduce (this is a W=1 build): # https://github.com/intel-lab-lkp/linux/commit/d26e139bfc29011b0a147df71f0b91485189c66e git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Uri-Arev/staging-fbtft-fix-checkpatch-pl-struct-should-normally-be-const/20220520-012948 git checkout d26e139bfc29011b0a147df71f0b91485189c66e # save the config file mkdir build_dir && cp config build_dir/.config make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): drivers/staging/fbtft/fbtft-core.c: In function 'fbtft_framebuffer_alloc': >> drivers/staging/fbtft/fbtft-core.c:617:15: error: type defaults to 'int' in >> declaration of 'fbops' [-Werror=implicit-int] 617 | const fbops = devm_kzalloc(dev, sizeof(struct fb_ops), GFP_KERNEL); | ^ >> drivers/staging/fbtft/fbtft-core.c:617:15: error: conflicting type >> qualifiers for 'fbops' drivers/staging/fbtft/fbtft-core.c:542:30: note: previous definition of 'fbops' with type 'const struct fb_ops *' 542 | const struct fb_ops *fbops = NULL; | ^ drivers/staging/fbtft/fbtft-core.c:617:23: warning: initialization of 'int' from 'void *' makes integer from pointer without a cast [-Wint-conversion] 617 | const fbops = devm_kzalloc(dev, sizeof(struct fb_ops), GFP_KERNEL); | ^~~~ drivers/staging/fbtft/fbtft-core.c:617:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 617 | const fbops = devm_kzalloc(dev, sizeof(struct fb_ops), GFP_KERNEL); | ^ drivers/staging/fbtft/fbtft-core.c:644:21: warning: assignment to 'const struct fb_ops *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 644 | info->fbops = fbops; | ^ >> drivers/staging/fbtft/fbtft-core.c:647:14: error: invalid type argument of >> '->' (have 'int') 647 | fbops->owner= dev->driver->owner; | ^~ drivers/staging/fbtft/fbtft-core.c:648:14: error: invalid type argument of '->' (have 'int') 648 | fbops->fb_read = fb_sys_read; | ^~ drivers/staging/fbtft/fbtft-core.c:649:14: error: invalid type argument of '->' (have 'int') 649 | fbops->fb_write = fbtft_fb_write; | ^~ drivers/staging/fbtft/fbtft-core.c:650:14: error: invalid type argument of '->' (have 'int') 650 | fbops->fb_fillrect = fbtft_fb_fillrect; | ^~ drivers/staging/fbtft/fbtft-core.c:651:14: error: invalid type argument of '->' (have 'int') 651 | fbops->fb_copyarea = fbtft_fb_copyarea; | ^~ drivers/staging/fbtft/fbtft-core.c:652:14: error: invalid type argument of '->' (have 'int') 652 | fbops->fb_imageblit = fbtft_fb_imageblit; | ^~ drivers/staging/fbtft/fbtft-core.c:653:14: error: invalid type argument of '->' (have 'int') 653 | fbops->fb_setcolreg = fbtft_fb_setcolreg; | ^~ drivers/staging/fbtft/fbtft-core.c:654:14: error: invalid type argument of '->' (have 'int') 654 | fbops->fb_blank = fbtft_fb_blank; | ^~ cc1: some warnings being treated as errors vim +617 drivers/staging/fbtft/fbtft-core.c 516 517 /** 518 * fbtft_framebuffer_alloc - creates a new frame buffer info structure 519 * 520 * @display: pointer to structure describing the display 521 * @dev: pointer to the device for this fb, this can be NULL 522 * @pdata: platform data for the display in use 523 * 524 * Creates a new frame buffer info structure. 525 * 526 * Also creates and populates the following structures: 527 * info->fbops 528 * info->fbdefio 529 * info->pseudo_palette 530 * par->fbtftops 531 * par->txbuf 532 * 533 * Returns the new structure, or NULL if an error occurred. 534 * 535 */ 536 struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display, 537
Re: [PATCH] staging: fbtft: fix checkpatch.pl struct should normally be const
Hi Uri, Thank you for the patch! Yet something to improve: [auto build test ERROR on staging/staging-testing] url: https://github.com/intel-lab-lkp/linux/commits/Uri-Arev/staging-fbtft-fix-checkpatch-pl-struct-should-normally-be-const/20220520-012948 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 4d0cc9e0e53e9946d7b8dc58279c62dfa7a2191b config: arm64-randconfig-r011-20220519 (https://download.01.org/0day-ci/archive/20220520/202205200821.njq0ifft-...@intel.com/config) compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project e00cbbec06c08dc616a0d52a20f678b8fbd4e304) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://github.com/intel-lab-lkp/linux/commit/d26e139bfc29011b0a147df71f0b91485189c66e git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Uri-Arev/staging-fbtft-fix-checkpatch-pl-struct-should-normally-be-const/20220520-012948 git checkout d26e139bfc29011b0a147df71f0b91485189c66e # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm64 SHELL=/bin/bash drivers/staging/fbtft/ If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All error/warnings (new ones prefixed by >>): drivers/staging/fbtft/fbtft-core.c:332:6: warning: variable 'count' set but not used [-Wunused-but-set-variable] int count = 0; ^ >> drivers/staging/fbtft/fbtft-core.c:617:8: error: type specifier missing, >> defaults to 'int'; ISO C99 and later do not support implicit int >> [-Wimplicit-int] const fbops = devm_kzalloc(dev, sizeof(struct fb_ops), GFP_KERNEL); ~ ^ int >> drivers/staging/fbtft/fbtft-core.c:617:8: error: redefinition of 'fbops' >> with a different type: 'const int' vs 'const struct fb_ops *' drivers/staging/fbtft/fbtft-core.c:542:23: note: previous definition is here const struct fb_ops *fbops = NULL; ^ >> drivers/staging/fbtft/fbtft-core.c:647:22: error: cannot assign to variable >> 'fbops' with const-qualified type 'const struct fb_ops *' fbops->owner= dev->driver->owner; ^ drivers/staging/fbtft/fbtft-core.c:542:23: note: variable 'fbops' declared const here const struct fb_ops *fbops = NULL; ~^~~~ drivers/staging/fbtft/fbtft-core.c:648:22: error: cannot assign to variable 'fbops' with const-qualified type 'const struct fb_ops *' fbops->fb_read = fb_sys_read; ~~ ^ drivers/staging/fbtft/fbtft-core.c:542:23: note: variable 'fbops' declared const here const struct fb_ops *fbops = NULL; ~^~~~ drivers/staging/fbtft/fbtft-core.c:649:22: error: cannot assign to variable 'fbops' with const-qualified type 'const struct fb_ops *' fbops->fb_write = fbtft_fb_write; ~~~ ^ drivers/staging/fbtft/fbtft-core.c:542:23: note: variable 'fbops' declared const here const struct fb_ops *fbops = NULL; ~^~~~ drivers/staging/fbtft/fbtft-core.c:650:22: error: cannot assign to variable 'fbops' with const-qualified type 'const struct fb_ops *' fbops->fb_fillrect = fbtft_fb_fillrect; ~~ ^ drivers/staging/fbtft/fbtft-core.c:542:23: note: variable 'fbops' declared const here const struct fb_ops *fbops = NULL; ~^~~~ drivers/staging/fbtft/fbtft-core.c:651:22: error: cannot assign to variable 'fbops' with const-qualified type 'const struct fb_ops *' fbops->fb_copyarea = fbtft_fb_copyarea; ~~ ^ drivers/staging/fbtft/fbtft-core.c:542:23: note: variable 'fbops' declared const here const struct fb_ops *fbops = NULL; ~^~~~ drivers/staging/fbtft/fbtft-core.c:652:22: error: cannot assign to variable 'fbops' with const-qualified type 'const struct fb_ops *' fbops->fb_imageblit = fbtft_fb_imageblit; ~~~ ^ drivers/staging/fbtft/fbtft-core.c:542:23: note: variable 'fbops' declared const here const struct fb_ops *fbops = NULL; ~^~~~ drivers/staging/fbtft/fbtft-core.c:653:22: error: cannot assign to variable 'fbops'
Re: [PATCH v3 1/4] drm/dp: Add wait_hpd_asserted() callback to struct drm_dp_aux
Quoting Doug Anderson (2022-05-12 16:24:13)
> On Wed, May 11, 2022 at 6:58 PM Stephen Boyd wrote:
> > Quoting Douglas Anderson (2022-04-18 10:17:54)
> > > diff --git a/include/drm/dp/drm_dp_helper.h
> > > b/include/drm/dp/drm_dp_helper.h
> > > index 53d1e722f4de..0940c415db8c 100644
> > > --- a/include/drm/dp/drm_dp_helper.h
> > > +++ b/include/drm/dp/drm_dp_helper.h
> > > @@ -2035,6 +2035,32 @@ struct drm_dp_aux {
> > > ssize_t (*transfer)(struct drm_dp_aux *aux,
> > > struct drm_dp_aux_msg *msg);
> > >
> > > + /**
> > > +* @wait_hpd_asserted: wait for HPD to be asserted
> > > +*
> > > +* This is mainly useful for eDP panels drivers to wait for an eDP
> > > +* panel to finish powering on. This is an optional function.
> >
> > Is there any use for the opposite direction? For example, does anything
> > care that HPD is deasserted?
>
> Not that I'm aware of. Originally I was planning to have it so that a
> timeout of "0" meant to just poll without sleeping at all, but it
> ended up making the code a lot more complicated because everywhere
> else we had the "readx" semantics where 0 meant wait forever. It
> didn't seem worth it. I can go back to that behavior if need be.
>
Got it.
>
> > > +*
> > > +* This function will efficiently wait for up to `wait_us`
> > > microseconds
> > > +* for HPD to be asserted and might sleep.
> > > +*
> > > +* This function returns 0 if HPD was asserted or -ETIMEDOUT if
> > > time
> > > +* expired and HPD wasn't asserted. This function should not print
> > > +* timeout errors to the log.
> > > +*
> > > +* The semantics of this function are designed to match the
> > > +* readx_poll_timeout() function. That means a `wait_us` of 0
> > > means
> > > +* to wait forever. If you want to do a quick poll you could pass
> > > 1
> > > +* for `wait_us`.
> >
> > It would also make sense to have a drm_dp_wait_hpd_asserted() API
> >
> > int drm_dp_wait_hpd_asserted(struct drm_dp_aux *aux, unsigned long
> > wait_us);
> >
> > and then this aux function could be implemented in various ways. The API
> > could poll if the aux can only read immediate state of HPD, or it could
> > sleep (is sleeping allowed? that isn't clear) and wake up the process
> > once HPD goes high. Or if this op isn't implemented maybe there's a
> > fixed timeout member that is non-zero which means "sleep this long".
> > Either way, making each drm_dp_aux implement that logic seems error
> > prone vs. having the drm_dp_aux implement some function for
> >
> > get_immediate_hpd(struct drm_dp_aux *aux)
>
> There's a reason why I changed the API to "wait" from "get". If you
> can think of a good place to document this, I'm all ears.
>
> The basic problem is ps8640 (my nemesis, apparently). On ps8640,
> because of the black box firmware blob that's on it, we have a crazy
> long delay in its runtime resume (300ms). So what happens with ps8640
> is that if we make the API "get_immediate_hpd()" it wasn't so
> immediate. Even with autosuspend, that first "get" could take 300 ms,
> which really screwed with everyone else who was waiting with a 200 ms
> timeout.
>
> Now, in theory, one could argue that the fact that ps8640 had a 300 ms
> sleep would mean that the very first "get" of the panel would already
> show HPD high. I don't know why that wasn't the case, but ps8640 is an
> annoying black box.
>
> In general, though, the DP controller might need some amount of time
> to power itself back up and configure itself. Even though the ps8640
> case is extreme, it wouldn't be totally extreme to assume that an AUX
> controller might take 20 ms or 50 ms to power up. That could still
> throw timings off. Implementing the API as a "wait" style API gets
> around this problem. Now the DP controller can take as long as it
> needs to power itself up and it can then wait with the requested
> timeout.
To clarify, are you saying that the 'wait' passed in will be added to
whatever time it takes for the driver to runtime resume to check HPD
status? Or is the driver supposed to subtract any time to power up from the
'wait' passed in and then poll or wait for an irq about HPD?
Would it be incorrect to somehow have the pm_runtime_get_sync() call in
the mythical wrapper API with a ktime_get() before and after and then
subtract that from the 'wait' time and call "get_immediate_hpd()"?
It would help me understand further if the 'wait' is described as a
maximum time we're willing to wait or a minimum time we're willing to
wait for hpd to be asserted. Usually a timeout is the maximum we're
willing to wait so I think you're saying the wait is the maximum time
after we know the drm_dp_aux is fully powered up and ready to check the
state.
Re: [PATCH v2] drm: Document the power requirements for DP AUX transfers
Hi,
On Mon, May 9, 2022 at 4:18 PM Douglas Anderson wrote:
>
> When doing DP AUX transfers there are two actors that need to be
> powered in order for the DP AUX transfer to work: the DP source and
> the DP sink. Commit bacbab58f09d ("drm: Mention the power state
> requirement on side-channel operations") added some documentation
> saying that the DP source is required to power itself up (if needed)
> to do AUX transfers. However, that commit doesn't talk anything about
> the DP sink.
>
> For full fledged DP the sink isn't really a problem. It's expected
> that if an external DP monitor isn't plugged in that attempting to do
> AUX transfers won't work. It's also expected that if a DP monitor is
> plugged in (and thus asserting HPD) then AUX transfers will work.
>
> When we're looking at eDP, however, things are less obvious. Let's add
> some documentation about expectations. Here's what we'll say:
>
> 1. We don't expect the DP AUX transfer function to power on an eDP
> panel. If an eDP panel is physically connected but powered off then it
> makes sense for the transfer to fail.
>
> 2. We'll document that the official way to power on a panel is via the
> bridge chain, specifically by making sure that the panel's prepare
> function has been called (which is called by
> panel_bridge_pre_enable()). It's already specified in the kernel doc
> of drm_panel_prepare() that this is the way to power the panel on and
> also that after this call "it is possible to communicate with any
> integrated circuitry via a command bus."
>
> 3. We'll also document that for code running in the panel driver
> itself that it is legal for the panel driver to power itself up
> however it wants (it doesn't need to officially call
> drm_panel_pre_enable()) and then it can do AUX bus transfers. This is
> currently the way that edp-panel works when it's running atop the DP
> AUX bus.
>
> NOTE: there was much discussion of all of this in response to v1 [1]
> of this patch. A summary of that is:
> * With the Intel i195 driver, apparently eDP panels do get powered
> up. We won't forbid this but it is expected that code that wants to
> run on a variety of platforms should ensure that the drm_panel's
> prepare() function has been called.
> * There is at least a reasonable amount of agreement that the
> transfer() functions itself shouldn't be responsible for powering
> the panel. It's proposed that if we need the DP AUX dev nodes to be
> robust for eDP that the code handling the DP AUX dev nodes could
> handle powering the panel by ensuring that the panel's prepare()
> call was made. Potentially drm_dp_aux_dev_get_by_minor() could be a
> good place to do this. This is left as a future exercise. Until
> that's fixed the DP AUX dev nodes for eDP are probably best just
> used for debugging.
> * If a panel could be in PSR and DP AUX via the dev node needs to be
> reliable then we need to be able to pull the panel out of PSR. On
> i915 this is also apparently handled as part of the transfer()
> function.
>
> [1]
> https://lore.kernel.org/r/20220503162033.1.Ia8651894026707e4fa61267da944ff739610d180@changeid
>
> Signed-off-by: Douglas Anderson
> Reviewed-by: Dmitry Baryshkov
> Reviewed-by: Lyude Paul
> ---
> Hopefully I've resolved everything here to everyone's
> satisfaction. There's no crazy hurry here. I'll give this a week or so
> and then land it on drm-misc if there is no additional discussion.
>
> Changes in v2:
> - Updated wording as per discussion on v1.
> - Updated commit message as per discussion on v1.
> - Add pointer to v1 discussion for future reference.
>
> include/drm/display/drm_dp_helper.h | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
Pushed to drm-misc-next:
69ef4a192bba drm: Document the power requirements for DP AUX transfers
Re: [PATCH v3 2/2] drm/probe-helper: For DP, add 640x480 if all other modes are bad
Hi,
On Wed, May 11, 2022 at 3:58 PM Douglas Anderson wrote:
>
> As per Displayport spec section 5.2.1.2 ("Video Timing Format") says
> that all detachable sinks shall support 640x480 @60Hz as a fail safe
> mode.
>
> A DP compliance test expected us to utilize the above fact when all
> modes it presented to the DP source were not achievable. It presented
> only modes that would be achievable with more lanes and/or higher
> speeds than we had available and expected that when we couldn't do
> that then we'd fall back to 640x480 even though it didn't advertise
> this size.
>
> In order to pass the compliance test (and also support any users who
> might fall into a similar situation with their display), we need to
> add 640x480 into the list of modes. However, we don't want to add
> 640x480 all the time. Despite the fact that the DP spec says all sinks
> _shall support_ 640x480, they're not guaranteed to support it
> _well_. Continuing to read the spec you can see that the display is
> not required to really treat 640x480 equal to all the other modes. It
> doesn't need to scale or anything--just display the pixels somehow for
> failsafe purposes. It should also be noted that it's not hard to find
> a display hooked up via DisplayPort that _doesn't_ support 640x480 at
> all. The HP ZR30w screen I'm sitting in front of has a native DP port
> and doesn't work at 640x480. I also plugged in a tiny 800x480 HDMI
> display via a DP to HDMI adapter and that screen definitely doesn't
> support 640x480.
>
> As a compromise solution, let's only add the 640x480 mode if:
> * We're on DP.
> * All other modes have been pruned.
>
> This acknowledges that 640x480 might not be the best mode to use but,
> since sinks are _supposed_ to support it, we will at least fall back
> to it if there's nothing else.
>
> Note that we _don't_ add higher resolution modes like 1024x768 in this
> case. We only add those modes for a failed EDID read where we have no
> idea what's going on. In the case where we've pruned all modes then
> instead we only want 640x480 which is the only defined "Fail Safe"
> resolution.
>
> This patch originated in response to Kuogee Hsieh's patch [1].
>
> [1]
> https://lore.kernel.org/r/1650671124-14030-1-git-send-email-quic_khs...@quicinc.com
>
> Signed-off-by: Douglas Anderson
> Tested-by: Kuogee Hsieh
> Reviewed-by: Abhinav Kumar
> Reviewed-by: Dmitry Baryshkov
> ---
>
> Changes in v3:
> - Removed WARN_ON
>
> Changes in v2:
> - Two underscores for __drm_helper_update_and_validate().
> - Return err and use WARN_ON instead of returning a bool.
>
> drivers/gpu/drm/drm_probe_helper.c | 27 ++-
> 1 file changed, 22 insertions(+), 5 deletions(-)
Pushed to drm-misc-next:
e7c254d75d16 drm/probe-helper: For DP, add 640x480 if all other modes are bad
Re: [PATCH v3 1/2] drm/probe-helper: Add helper for drm_helper_probe_single_connector_modes()
Hi, On Wed, May 11, 2022 at 3:58 PM Douglas Anderson wrote: > > The drm_helper_probe_single_connector_modes() is a bit long. Let's > break a chunk off to update and validate modes. This helps avoid one > goto and also will allow us to more easily call the helper a second > time in a future patch without adding looping or another goto. > > This change is intended to be a no-op change--just code movement. > > Signed-off-by: Douglas Anderson > Reviewed-by: Abhinav Kumar > Reviewed-by: Thomas Zimmermann > --- > > Changes in v3: > - Removed WARN_ON > > Changes in v2: > - Two underscores for __drm_helper_update_and_validate(). > - Return err and use WARN_ON instead of returning a bool. > > drivers/gpu/drm/drm_probe_helper.c | 106 - > 1 file changed, 60 insertions(+), 46 deletions(-) Pushed to drm-misc-next: 4a2a13a57b60 drm/probe-helper: Add helper for drm_helper_probe_single_connector_modes()
Re: [PATCH v6 1/3] phy: qcom-edp: add regulator_set_load to edp phy
Quoting Kuogee Hsieh (2022-05-19 16:11:40)
> diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
> b/drivers/phy/qualcomm/phy-qcom-edp.c
> index cacd32f..78b7306 100644
> --- a/drivers/phy/qualcomm/phy-qcom-edp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
> @@ -87,14 +87,19 @@ struct qcom_edp {
>
> struct clk_bulk_data clks[2];
> struct regulator_bulk_data supplies[2];
> + int enable_load[2];
> };
>
> static int qcom_edp_phy_init(struct phy *phy)
> {
> struct qcom_edp *edp = phy_get_drvdata(phy);
> int ret;
> + int i;
>
> - ret = regulator_bulk_enable(ARRAY_SIZE(edp->supplies), edp->supplies);
> + for (i = 0; i < 2; i++)
Use ARRAY_SIZE(edp->supplies)?
> + regulator_set_load(edp->supplies[i].consumer,
> edp->enable_load[i]);
> +
> + ret = regulator_bulk_enable(2, edp->supplies);
Why is ARRAY_SIZE() usage removed?
> if (ret)
> return ret;
>
Re: [PATCH v8 02/16] clk: Provide new devm_clk helpers for prepared and enabled clocks
The Cc list is huge. Here it goes!
Quoting Uwe Kleine-König (2022-03-14 07:16:29)
> When a driver keeps a clock prepared (or enabled) during the whole
> lifetime of the driver, these helpers allow to simplify the drivers.
>
> Reviewed-by: Jonathan Cameron
> Reviewed-by: Alexandru Ardelean
> Signed-off-by: Uwe Kleine-König
> ---
I'm ready to merge it! I'm largely waiting for Russell to ack the clk.h
change, but if that doesn't happen then I think we'll have to merge it
anyway. Can you resend with collected acks, maybe just the ones you want
me to merge through clk tree? Then I'll go ahead and stage it. Some
nitpicks below.
> drivers/clk/clk-devres.c | 31 ++
> include/linux/clk.h | 90 +++-
> 2 files changed, 120 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
> index fb7761888b30..4707fe718f0b 100644
> --- a/drivers/clk/clk-devres.c
> +++ b/drivers/clk/clk-devres.c
> @@ -67,12 +67,43 @@ struct clk *devm_clk_get(struct device *dev, const char
> *id)
> }
> EXPORT_SYMBOL(devm_clk_get);
>
> +struct clk *devm_clk_get_prepared(struct device *dev, const char *id)
> +{
> + return __devm_clk_get(dev, id, clk_get, clk_prepare, clk_unprepare);
> +
Nitpick: Remove newline
> +}
> +EXPORT_SYMBOL(devm_clk_get_prepared);
> +
> +struct clk *devm_clk_get_enabled(struct device *dev, const char *id)
> +{
> + return __devm_clk_get(dev, id, clk_get,
> + clk_prepare_enable, clk_disable_unprepare);
> +
Nitpick: Remove newline
> +}
> +EXPORT_SYMBOL(devm_clk_get_enabled);
> +
> struct clk *devm_clk_get_optional(struct device *dev, const char *id)
> {
> return __devm_clk_get(dev, id, clk_get_optional, NULL, NULL);
> }
> EXPORT_SYMBOL(devm_clk_get_optional);
>
> +struct clk *devm_clk_get_optional_prepared(struct device *dev, const char
> *id)
> +{
> + return __devm_clk_get(dev, id, clk_get_optional,
> + clk_prepare, clk_unprepare);
> +
Nitpick: Remove newline
> +}
> +EXPORT_SYMBOL(devm_clk_get_optional_prepared);
> +
> +struct clk *devm_clk_get_optional_enabled(struct device *dev, const char *id)
> +{
> + return __devm_clk_get(dev, id, clk_get_optional,
> + clk_prepare_enable, clk_disable_unprepare);
> +
Nitpick: Remove newline
> +}
> +EXPORT_SYMBOL(devm_clk_get_optional_enabled);
EXPORT_SYMBOL_GPL for all of these? Or make them macros and cut down on
the number of symbols.
> +
> struct clk_bulk_devres {
> struct clk_bulk_data *clks;
> int num_clks;
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 266e8de3cb51..b011dbba7109 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -449,7 +449,7 @@ int __must_check devm_clk_bulk_get_all(struct device *dev,
> * the clock producer. (IOW, @id may be identical strings, but
> * clk_get may return different clock producers depending on @dev.)
> *
> - * Drivers must assume that the clock source is not enabled.
> + * Drivers must assume that the clock source is neither prepared nor enabled.
> *
> * devm_clk_get should not be called from within interrupt context.
> *
Can you split this off to another patch? It's updating the doc to
clarify the assumed state of a clk returned from this API.
> @@ -458,6 +458,47 @@ int __must_check devm_clk_bulk_get_all(struct device
> *dev,
> */
> struct clk *devm_clk_get(struct device *dev, const char *id);
>
> +/**
> + * devm_clk_get_prepared - devm_clk_get() + clk_prepare()
> + * @dev: device for clock "consumer"
> + * @id: clock consumer ID
> + *
> + * Returns a struct clk corresponding to the clock producer, or
> + * valid IS_ERR() condition containing errno. The implementation
> + * uses @dev and @id to determine the clock consumer, and thereby
> + * the clock producer. (IOW, @id may be identical strings, but
> + * clk_get may return different clock producers depending on @dev.)
> + *
> + * The returned clk (if valid) is prepared. Drivers must however assume that
> the
> + * clock is not enabled.
> + *
> + * devm_clk_get_prepared should not be called from within interrupt context.
There's 'Context:' for this. Please use it.
> + *
> + * The clock will automatically be unprepared and freed when the
> + * device is unbound from the bus.
> + */
> +struct clk *devm_clk_get_prepared(struct device *dev, const char *id);
> +
> +/**
> + * devm_clk_get_enabled - devm_clk_get() + clk_prepare_enable()
> + * @dev: device for clock "consumer"
> + * @id: clock consumer ID
> + *
> + * Returns a struct clk corresponding to the clock producer, or valid
> IS_ERR()
There's 'Return:' for this. Please use it.
> + * condition containing errno. The implementation uses @dev and @id to
> + * determine the clock consumer, and thereby the clock producer. (IOW, @id
> may
> + * be identical strings, but clk_get may return different clock producers
> + * depending on
[PATCH v6 3/3] drm/msm/dp: delete vdda regulator related functions from eDP/DP controller
Vdda regulators are related to both eDP and DP phy so that it should be
managed at eDP and DP phy driver instead of controller. This patch removes
vdda regulators related functions out of eDP/DP controller.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_parser.c | 14 --
drivers/gpu/drm/msm/dp/dp_parser.h | 6 ---
drivers/gpu/drm/msm/dp/dp_power.c | 95 +-
3 files changed, 2 insertions(+), 113 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c
b/drivers/gpu/drm/msm/dp/dp_parser.c
index 8f9fed9..4ef2130 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -22,14 +22,6 @@
#define DP_DEFAULT_P0_OFFSET 0x1000
#define DP_DEFAULT_P0_SIZE 0x0400
-static const struct dp_regulator_cfg sdm845_dp_reg_cfg = {
- .num = 2,
- .regs = {
- {"vdda-1p2", 21800, 4 },/* 1.2 V */
- {"vdda-0p9", 36000, 32 }, /* 0.9 V */
- },
-};
-
static void __iomem *dp_ioremap(struct platform_device *pdev, int idx, size_t
*len)
{
struct resource *res;
@@ -298,12 +290,6 @@ static int dp_parser_parse(struct dp_parser *parser)
if (rc)
return rc;
- /* Map the corresponding regulator information according to
-* version. Currently, since we only have one supported platform,
-* mapping the regulator directly.
-*/
- parser->regulator_cfg = _dp_reg_cfg;
-
return 0;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h
b/drivers/gpu/drm/msm/dp/dp_parser.h
index 3a4d797..b56b4d7 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -101,11 +101,6 @@ struct dp_reg_entry {
int disable_load;
};
-struct dp_regulator_cfg {
- int num;
- struct dp_reg_entry regs[DP_DEV_REGULATOR_MAX];
-};
-
/**
* struct dp_parser - DP parser's data exposed to clients
*
@@ -121,7 +116,6 @@ struct dp_parser {
struct dp_pinctrl pinctrl;
struct dp_io io;
struct dp_display_data disp_data;
- const struct dp_regulator_cfg *regulator_cfg;
u32 max_dp_lanes;
struct drm_bridge *next_bridge;
diff --git a/drivers/gpu/drm/msm/dp/dp_power.c
b/drivers/gpu/drm/msm/dp/dp_power.c
index d9e0117..b52ac1d 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.c
+++ b/drivers/gpu/drm/msm/dp/dp_power.c
@@ -20,82 +20,10 @@ struct dp_power_private {
struct clk *link_clk_src;
struct clk *pixel_provider;
struct clk *link_provider;
- struct regulator_bulk_data supplies[DP_DEV_REGULATOR_MAX];
struct dp_power dp_power;
};
-static void dp_power_regulator_disable(struct dp_power_private *power)
-{
- struct regulator_bulk_data *s = power->supplies;
- const struct dp_reg_entry *regs = power->parser->regulator_cfg->regs;
- int num = power->parser->regulator_cfg->num;
- int i;
-
- DBG("");
- for (i = num - 1; i >= 0; i--)
- if (regs[i].disable_load >= 0)
- regulator_set_load(s[i].consumer,
- regs[i].disable_load);
-
- regulator_bulk_disable(num, s);
-}
-
-static int dp_power_regulator_enable(struct dp_power_private *power)
-{
- struct regulator_bulk_data *s = power->supplies;
- const struct dp_reg_entry *regs = power->parser->regulator_cfg->regs;
- int num = power->parser->regulator_cfg->num;
- int ret, i;
-
- DBG("");
- for (i = 0; i < num; i++) {
- if (regs[i].enable_load >= 0) {
- ret = regulator_set_load(s[i].consumer,
-regs[i].enable_load);
- if (ret < 0) {
- pr_err("regulator %d set op mode failed, %d\n",
- i, ret);
- goto fail;
- }
- }
- }
-
- ret = regulator_bulk_enable(num, s);
- if (ret < 0) {
- pr_err("regulator enable failed, %d\n", ret);
- goto fail;
- }
-
- return 0;
-
-fail:
- for (i--; i >= 0; i--)
- regulator_set_load(s[i].consumer, regs[i].disable_load);
- return ret;
-}
-
-static int dp_power_regulator_init(struct dp_power_private *power)
-{
- struct regulator_bulk_data *s = power->supplies;
- const struct dp_reg_entry *regs = power->parser->regulator_cfg->regs;
- struct platform_device *pdev = power->pdev;
- int num = power->parser->regulator_cfg->num;
- int i, ret;
-
- for (i = 0; i < num; i++)
- s[i].supply = regs[i].name;
-
- ret = devm_regulator_bulk_get(>dev, num, s);
- if (ret < 0) {
- pr_err("%s: failed to init regulator, ret=%d\n",
-
[PATCH v6 2/3] phy: qcom-qmp: add regulator_set_load to dp phy
This patch add regulator_set_load() before enable regulator at
DP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index b144ae1..fcf87ae 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -3130,6 +3130,7 @@ struct qmp_phy_cfg {
int num_resets;
/* regulators to be requested */
const char * const *vreg_list;
+ const unsigned int *vreg_enable_load;
int num_vregs;
/* array of registers with different offsets */
@@ -3346,6 +3347,10 @@ static const char * const qmp_phy_vreg_l[] = {
"vdda-phy", "vdda-pll",
};
+static const unsigned int qmp_phy_vreg_enable_load[] = {
+ 21800, 36000
+};
+
static const struct qmp_phy_cfg ipq8074_usb3phy_cfg = {
.type = PHY_TYPE_USB3,
.nlanes = 1,
@@ -3711,6 +3716,7 @@ static const struct qmp_phy_cfg sc7180_usb3phy_cfg = {
.reset_list = sc7180_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(sc7180_usb3phy_reset_l),
.vreg_list = qmp_phy_vreg_l,
+ .vreg_enable_load = qmp_phy_vreg_enable_load,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = qmp_v3_usb3phy_regs_layout,
@@ -3749,6 +3755,7 @@ static const struct qmp_phy_cfg sc7180_dpphy_cfg = {
.reset_list = sc7180_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(sc7180_usb3phy_reset_l),
.vreg_list = qmp_phy_vreg_l,
+ .vreg_enable_load = qmp_phy_vreg_enable_load,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = qmp_v3_usb3phy_regs_layout,
@@ -3940,6 +3947,7 @@ static const struct qmp_phy_cfg sm8150_usb3phy_cfg = {
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
.vreg_list = qmp_phy_vreg_l,
+ .vreg_enable_load = qmp_phy_vreg_enable_load,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = qmp_v4_usb3phy_regs_layout,
@@ -4009,6 +4017,7 @@ static const struct qmp_phy_cfg sc8180x_dpphy_cfg = {
.reset_list = sc7180_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(sc7180_usb3phy_reset_l),
.vreg_list = qmp_phy_vreg_l,
+ .vreg_enable_load = qmp_phy_vreg_enable_load,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = qmp_v3_usb3phy_regs_layout,
@@ -4072,6 +4081,7 @@ static const struct qmp_phy_cfg sm8250_usb3phy_cfg = {
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
.vreg_list = qmp_phy_vreg_l,
+ .vreg_enable_load = qmp_phy_vreg_enable_load,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = qmp_v4_usb3phy_regs_layout,
@@ -4139,6 +4149,7 @@ static const struct qmp_phy_cfg sm8250_dpphy_cfg = {
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
.vreg_list = qmp_phy_vreg_l,
+ .vreg_enable_load = qmp_phy_vreg_enable_load,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = qmp_v4_usb3phy_regs_layout,
@@ -5008,6 +5019,11 @@ static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
return 0;
}
+ if (cfg->vreg_enable_load) {
+ for (i = 0; i < cfg->num_vregs; i++)
+ regulator_set_load(qmp->vregs[i].consumer,
cfg->vreg_enable_load[i]);
+ }
+
/* turn on regulator supplies */
ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs);
if (ret) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v6 1/3] phy: qcom-edp: add regulator_set_load to edp phy
This patch add regulator_set_load() before enable regulator at
eDP phy driver.
Signed-off-by: Kuogee Hsieh
---
drivers/phy/qualcomm/phy-qcom-edp.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
b/drivers/phy/qualcomm/phy-qcom-edp.c
index cacd32f..78b7306 100644
--- a/drivers/phy/qualcomm/phy-qcom-edp.c
+++ b/drivers/phy/qualcomm/phy-qcom-edp.c
@@ -87,14 +87,19 @@ struct qcom_edp {
struct clk_bulk_data clks[2];
struct regulator_bulk_data supplies[2];
+ int enable_load[2];
};
static int qcom_edp_phy_init(struct phy *phy)
{
struct qcom_edp *edp = phy_get_drvdata(phy);
int ret;
+ int i;
- ret = regulator_bulk_enable(ARRAY_SIZE(edp->supplies), edp->supplies);
+ for (i = 0; i < 2; i++)
+ regulator_set_load(edp->supplies[i].consumer,
edp->enable_load[i]);
+
+ ret = regulator_bulk_enable(2, edp->supplies);
if (ret)
return ret;
@@ -635,6 +640,8 @@ static int qcom_edp_phy_probe(struct platform_device *pdev)
edp->supplies[0].supply = "vdda-phy";
edp->supplies[1].supply = "vdda-pll";
+ edp->enable_load[0] = 21800;/* load for 1.2 V vdda-phy supply */
+ edp->enable_load[1] = 36000;/* load for 0.9 V vdda-pll supply */
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(edp->supplies),
edp->supplies);
if (ret)
return ret;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v6 0/3] eDP/DP Phy vdda realted function
1) add regulator_set_load() to eDP phy 2) add regulator_set_load() to DP phy 3) remove vdda related function out of eDP/DP controller Kuogee Hsieh (3): phy: qcom-edp: add regulator_set_load to edp phy phy: qcom-qmp: add regulator_set_load to dp phy drm/msm/dp: delete vdda regulator related functions from eDP/DP controller drivers/gpu/drm/msm/dp/dp_parser.c | 14 -- drivers/gpu/drm/msm/dp/dp_parser.h | 6 --- drivers/gpu/drm/msm/dp/dp_power.c | 95 + drivers/phy/qualcomm/phy-qcom-edp.c | 9 +++- drivers/phy/qualcomm/phy-qcom-qmp.c | 16 +++ 5 files changed, 26 insertions(+), 114 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [Intel-gfx] [RFC v3 3/3] drm/doc/rfc: VM_BIND uapi definition
On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote:
> VM_BIND and related uapi definitions
>
> v2: Ensure proper kernel-doc formatting with cross references.
> Also add new uapi and documentation as per review comments
> from Daniel.
>
> Signed-off-by: Niranjana Vishwanathapura
> ---
> Documentation/gpu/rfc/i915_vm_bind.h | 399 +++
> 1 file changed, 399 insertions(+)
> create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
>
> diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
> b/Documentation/gpu/rfc/i915_vm_bind.h
> new file mode 100644
> index ..589c0a009107
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> @@ -0,0 +1,399 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +/**
> + * DOC: I915_PARAM_HAS_VM_BIND
> + *
> + * VM_BIND feature availability.
> + * See typedef drm_i915_getparam_t param.
> + */
> +#define I915_PARAM_HAS_VM_BIND 57
> +
> +/**
> + * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
> + *
> + * Flag to opt-in for VM_BIND mode of binding during VM creation.
> + * See struct drm_i915_gem_vm_control flags.
> + *
> + * A VM in VM_BIND mode will not support the older execbuff mode of binding.
> + * In VM_BIND mode, execbuff ioctl will not accept any execlist (ie., the
> + * _i915_gem_execbuffer2.buffer_count must be 0).
> + * Also, _i915_gem_execbuffer2.batch_start_offset and
> + * _i915_gem_execbuffer2.batch_len must be 0.
> + * DRM_I915_GEM_EXECBUFFER_EXT_BATCH_ADDRESSES extension must be provided
> + * to pass in the batch buffer addresses.
> + *
> + * Additionally, I915_EXEC_NO_RELOC, I915_EXEC_HANDLE_LUT and
> + * I915_EXEC_BATCH_FIRST of _i915_gem_execbuffer2.flags must be 0
> + * (not used) in VM_BIND mode. I915_EXEC_USE_EXTENSIONS flag must always be
> + * set (See struct drm_i915_gem_execbuffer_ext_batch_addresses).
> + * The buffers_ptr, buffer_count, batch_start_offset and batch_len fields
> + * of struct drm_i915_gem_execbuffer2 are also not used and must be 0.
> + */
From that description, it seems we have:
struct drm_i915_gem_execbuffer2 {
__u64 buffers_ptr; -> must be 0 (new)
__u32 buffer_count; -> must be 0 (new)
__u32 batch_start_offset; -> must be 0 (new)
__u32 batch_len;-> must be 0 (new)
__u32 DR1; -> must be 0 (old)
__u32 DR4; -> must be 0 (old)
__u32 num_cliprects; (fences) -> must be 0 since using extensions
__u64 cliprects_ptr; (fences, extensions) -> contains an actual pointer!
__u64 flags;-> some flags must be 0 (new)
__u64 rsvd1; (context info) -> repurposed field (old)
__u64 rsvd2;-> unused
};
Based on that, why can't we just get drm_i915_gem_execbuffer3 instead
of adding even more complexity to an already abused interface? While
the Vulkan-like extension thing is really nice, I don't think what
we're doing here is extending the ioctl usage, we're completely
changing how the base struct should be interpreted based on how the VM
was created (which is an entirely different ioctl).
From Rusty Russel's API Design grading, drm_i915_gem_execbuffer2 is
already at -6 without these changes. I think after vm_bind we'll need
to create a -11 entry just to deal with this ioctl.
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they complete in reasonable amount of time.
+ * Compute on the other hand can be long running. Hence it is not appropriate
+ * for compute contexts to export request completion dma-fence to user.
+ * The dma-fence usage will be limited to in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_OUT (See _i915_gem_execbuffer2.flags and
+ * I915_EXEC_FENCE_SIGNAL (See _i915_gem_exec_fence.flags) are expected
+ * to be not used.
+ *
+ * DRM_I915_GEM_WAIT ioctl call is also not supported for objects mapped
+ * to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_WAIT_USER_FENCE 0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT_USER_FENCE, struct drm_i915_gem_wait_user_fence)
+
+/**
+ * struct
Re: [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote: > VM_BIND design document with description of intended use cases. > > v2: Add more documentation and format as per review comments > from Daniel. > > Signed-off-by: Niranjana Vishwanathapura > --- > > diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst > b/Documentation/gpu/rfc/i915_vm_bind.rst > new file mode 100644 > index ..f1be560d313c > --- /dev/null > +++ b/Documentation/gpu/rfc/i915_vm_bind.rst > @@ -0,0 +1,304 @@ > +== > +I915 VM_BIND feature design and use cases > +== > + > +VM_BIND feature > + > +DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer > +objects (BOs) or sections of a BOs at specified GPU virtual addresses on a > +specified address space (VM). These mappings (also referred to as persistent > +mappings) will be persistent across multiple GPU submissions (execbuff calls) > +issued by the UMD, without user having to provide a list of all required > +mappings during each submission (as required by older execbuff mode). > + > +VM_BIND/UNBIND ioctls will support 'in' and 'out' fences to allow userpace > +to specify how the binding/unbinding should sync with other operations > +like the GPU job submission. These fences will be timeline 'drm_syncobj's > +for non-Compute contexts (See struct drm_i915_vm_bind_ext_timeline_fences). > +For Compute contexts, they will be user/memory fences (See struct > +drm_i915_vm_bind_ext_user_fence). > + > +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND. > +User has to opt-in for VM_BIND mode of binding for an address space (VM) > +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. > + > +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping in > an > +async worker. The binding and unbinding will work like a special GPU engine. > +The binding and unbinding operations are serialized and will wait on > specified > +input fences before the operation and will signal the output fences upon the > +completion of the operation. Due to serialization, completion of an operation > +will also indicate that all previous operations are also complete. > + > +VM_BIND features include: > + > +* Multiple Virtual Address (VA) mappings can map to the same physical pages > + of an object (aliasing). > +* VA mapping can map to a partial section of the BO (partial binding). > +* Support capture of persistent mappings in the dump upon GPU error. > +* TLB is flushed upon unbind completion. Batching of TLB flushes in some > + use cases will be helpful. > +* Asynchronous vm_bind and vm_unbind support with 'in' and 'out' fences. > +* Support for userptr gem objects (no special uapi is required for this). > + > +Execbuff ioctl in VM_BIND mode > +--- > +The execbuff ioctl handling in VM_BIND mode differs significantly from the > +older method. A VM in VM_BIND mode will not support older execbuff mode of > +binding. In VM_BIND mode, execbuff ioctl will not accept any execlist. Hence, > +no support for implicit sync. It is expected that the below work will be able > +to support requirements of object dependency setting in all use cases: > + > +"dma-buf: Add an API for exporting sync files" > +(https://lwn.net/Articles/859290/) I would really like to have more details here. The link provided points to new ioctls and we're not very familiar with those yet, so I think you should really clarify the interaction between the new additions here. Having some sample code would be really nice too. For Mesa at least (and I believe for the other drivers too) we always have a few exported buffers in every execbuf call, and we rely on the implicit synchronization provided by execbuf to make sure everything works. The execbuf ioctl also has some code to flush caches during implicit synchronization AFAIR, so I would guess we rely on it too and whatever else the Kernel does. Is that covered by the new ioctls? In addition, as far as I remember, one of the big improvements of vm_bind was that it would help reduce ioctl latency and cpu overhead. But if making execbuf faster comes at the cost of requiring additional ioctls calls for implicit synchronization, which is required on ever execbuf call, then I wonder if we'll even get any faster at all. Comparing old execbuf vs plain new execbuf without the new required ioctls won't make sense. But maybe I'm wrong and we won't need to call these new ioctls around every single execbuf ioctl we submit? Again, more clarification and some code examples here would be really nice. This is a big change on an important part of the API, we should clarify the new expected usage. > + > +This also means, we need an execbuff extension to pass in the batch > +buffer addresses (See struct drm_i915_gem_execbuffer_ext_batch_addresses). > + > +If at all execlist support in execbuff ioctl
Re: [PATCH v5 1/3] phy: qcom-edp: add regulator_set_load to edp phy
Quoting Kuogee Hsieh (2022-05-19 10:45:37)
> diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
> b/drivers/phy/qualcomm/phy-qcom-edp.c
> index cacd32f..90093cd 100644
> --- a/drivers/phy/qualcomm/phy-qcom-edp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
> @@ -87,14 +87,19 @@ struct qcom_edp {
>
> struct clk_bulk_data clks[2];
> struct regulator_bulk_data supplies[2];
> + int enable_load[2];
> };
>
> static int qcom_edp_phy_init(struct phy *phy)
> {
> struct qcom_edp *edp = phy_get_drvdata(phy);
> int ret;
> + int i;
>
> - ret = regulator_bulk_enable(ARRAY_SIZE(edp->supplies), edp->supplies);
> + for (i = 0; i < 2; i++)
> + regulator_set_load(edp->supplies[i].consumer,
> edp->enable_load[i]);
> +
> + ret = regulator_bulk_enable(num_consumers, edp->supplies);
Where is num_consumers coming from?
> if (ret)
> return ret;
>
Re: [PATCH v5 2/3] phy: qcom-qmp: add regulator_set_load to dp phy
Quoting Kuogee Hsieh (2022-05-19 10:45:38)
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index b144ae1..24f39ee 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -5008,6 +5019,11 @@ static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
> return 0;
> }
>
> + if (cfg->vreg_enable_load) {
> + for (i = 0; i <= cfg->num_vregs; i++)
Just less than (<) cfg->num_vregs, not less than or equal to (<=)
> + regulator_set_load(qmp->vregs[i].consumer,
> cfg->vreg_enable_load[i]);
> + }
>
[PATCH RESEND v6] drm/i915/display: disable HPD workers before display driver unregister
Handling HPD during driver removal is pointless, and can cause different use-after-free/concurrency issues: 1. Setup of deferred fbdev after fbdev unregistration. 2. Access to DP-AUX after DP-AUX removal. Below stacktraces of both cases observed on CI: [272.634530] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: [#1] PREEMPT SMP NOPTI [272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U 5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1 [272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021 [272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60 ... [272.634582] Call Trace: [272.634583] [272.634585] do_remove_conflicting_framebuffers+0x59/0xa0 [272.634589] remove_conflicting_framebuffers+0x2d/0xc0 [272.634592] remove_conflicting_pci_framebuffers+0xc8/0x110 [272.634595] drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70 [272.634604] i915_driver_probe+0x63a/0xdd0 [i915] [283.405824] cpu_latency_qos_update_request called for unknown object [283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 cpu_latency_qos_update_request+0x2d/0x100 [283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1 [283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021 [283.405916] Workqueue: i915-dp i915_digport_work_func [i915] [283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100 ... [283.406040] Call Trace: [283.406041] [283.406044] intel_dp_aux_xfer+0x60e/0x8e0 [i915] [283.406131] ? finish_swait+0x80/0x80 [283.406139] intel_dp_aux_transfer+0xc5/0x2b0 [i915] [283.406218] drm_dp_dpcd_access+0x79/0x130 [drm_display_helper] [283.406227] drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper] [283.406233] intel_dp_hpd_pulse+0x134/0x570 [i915] [283.406308] ? __down_killable+0x70/0x140 [283.406313] i915_digport_work_func+0xba/0x150 [i915] Signed-off-by: Andrzej Hajda --- Hi all, This is resend of [1]. For unknown reason CC-ing ppl did not work, so I've decided to resend. I hope this time it will work. The patch was already succesfully tested by CI (rev6, rev7 of [1]). [1]: https://patchwork.freedesktop.org/series/103811/ Regards Andrzej --- drivers/gpu/drm/i915/display/intel_display.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 806d50b302ab92..007bc6daef7d31 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -10486,13 +10486,6 @@ void intel_modeset_driver_remove_noirq(struct drm_i915_private *i915) */ intel_hpd_poll_fini(i915); - /* -* MST topology needs to be suspended so we don't have any calls to -* fbdev after it's finalized. MST will be destroyed later as part of -* drm_mode_config_cleanup() -*/ - intel_dp_mst_suspend(i915); - /* poll work can call into fbdev, hence clean that up afterwards */ intel_fbdev_fini(i915); @@ -10584,6 +10577,10 @@ void intel_display_driver_unregister(struct drm_i915_private *i915) if (!HAS_DISPLAY(i915)) return; + intel_dp_mst_suspend(i915); + intel_hpd_cancel_work(i915); + drm_kms_helper_poll_disable(>drm); + intel_fbdev_unregister(i915); intel_audio_deinit(i915); -- 2.25.1
Re: [PATCH v7 3/7] drm/i915: Prepare for multiple GTs
Hi Daniele, > > > @@ -909,6 +903,8 @@ int i915_driver_probe(struct pci_dev *pdev, > > > const struct pci_device_id *ent) > > > i915_ggtt_driver_late_release(i915); > > > out_cleanup_mmio: > > > i915_driver_mmio_release(i915); > > > +out_tiles_cleanup: > > > + intel_gt_release_all(i915); > > > > We don't seem to call intel_gt_release_all() from driver_release(), so > > we might be leaking something there. I wanted to send a patch to add the > > call at the same place in the flow as in this error path, but then I > > noticed that i915_driver_late_release(), which we call a few lines > > below, calls intel_gt_driver_late_release_all(), which seems to expect > > that the GTs are still allocated, so we probably need to flip the order > > those are called in, or move the cleanup code from late_release() to > > late_release_all() (or vice versa). > > Andi, can you have a look at this? well spotted! I will check it. > Ping! :) Sorry for taking so long for replying. I'm on it, now. Thank you, Andi
Re: [RFC PATCH] procfs: Add file path and size to /proc//fdinfo
Hi-- On 5/19/22 14:40, Kalesh Singh wrote: > diff --git a/Documentation/filesystems/proc.rst > b/Documentation/filesystems/proc.rst > index 061744c436d9..ad66d78aca51 100644 > --- a/Documentation/filesystems/proc.rst > +++ b/Documentation/filesystems/proc.rst > @@ -1922,13 +1922,16 @@ if precise results are needed. > 3.8 /proc//fdinfo/ - Information about opened file > --- > This file provides information associated with an opened file. The regular > -files have at least four fields -- 'pos', 'flags', 'mnt_id' and 'ino'. > +files have at least six fields -- 'pos', 'flags', 'mnt_id', 'ino', 'size', > +and 'path'. > + > The 'pos' represents the current offset of the opened file in decimal > form [see lseek(2) for details], 'flags' denotes the octal O_xxx mask the > file has been created with [see open(2) for details] and 'mnt_id' represents > mount ID of the file system containing the opened file [see 3.5 > /proc//mountinfo for details]. 'ino' represents the inode number of > -the file. > +the file, 'size' represents the size of the file in bytes, and 'path' > +represents the file path. > > A typical output is:: > > @@ -1936,6 +1939,8 @@ A typical output is:: > flags: 012 > mnt_id: 19 > ino:63107 > +size: 0 > +path: /dev/null > > All locks associated with a file descriptor are shown in its fdinfo too:: > > @@ -1953,6 +1958,8 @@ Eventfd files > flags: 04002 > mnt_id: 9 > ino:63107 > +size: 0 > +path: anon_inode:[eventfd] > eventfd-count: 5a > > where 'eventfd-count' is hex value of a counter. > @@ -1966,6 +1973,8 @@ Signalfd files > flags: 04002 > mnt_id: 9 > ino:63107 > +size: 0 > +path: anon_inode:[signalfd] > sigmask:0200 > > where 'sigmask' is hex value of the signal mask associated > @@ -1980,6 +1989,8 @@ Epoll files > flags: 02 > mnt_id: 9 > ino:63107 > +size: 0 > +path: anon_inode:[eventpoll] > tfd:5 events: 1d data: pos:0 ino:61af > sdev:7 > > where 'tfd' is a target file descriptor number in decimal form, > @@ -1998,6 +2009,8 @@ For inotify files the format is the following:: > flags: 0200 > mnt_id: 9 > ino:63107 > +size: 0 > +path: anon_inode:inotify > inotify wd:3 ino:9e7e sdev:800013 mask:800afce ignored_mask:0 > fhandle-bytes:8 fhandle-type:1 f_handle:7e9e640d1b6d > > where 'wd' is a watch descriptor in decimal form, i.e. a target file > @@ -2021,6 +2034,8 @@ For fanotify files the format is:: > flags: 02 > mnt_id: 9 > ino:63107 > +size: 0 > +path: anon_inode:[fanotify] > fanotify flags:10 event-flags:0 > fanotify mnt_id:12 mflags:40 mask:38 ignored_mask:4003 > fanotify ino:4f969 sdev:800013 mflags:0 mask:3b ignored_mask:4000 > fhandle-bytes:8 fhandle-type:1 f_handle:69f90400c275b5b4 > @@ -2046,6 +2061,8 @@ Timerfd files > flags: 02 > mnt_id: 9 > ino:63107 > +size: 0 > +path: anon_inode:[timerfd] > clockid: 0 > ticks: 0 > settime flags: 01 > @@ -2070,6 +2087,7 @@ DMA Buffer files > mnt_id: 9 > ino:63107 > size: 32768 > +path: /dmabuf: > count: 2 > exp_name: system-heap All of these added lines should be indented with a tab instead of spaces. thanks. -- ~Randy
Re: [Intel-gfx] [PATCH] drm/i915: Fix vm use-after-free in vma destruction
Hi Thomas,
On Thu, May 12, 2022 at 11:40:45AM +0200, Thomas Hellström wrote:
> In vma destruction, the following race may occur:
>
> Thread 1: Thread 2:
> i915_vma_destroy();
>
> ...
> list_del_init(vma->vm_link);
> ...
> mutex_unlock(vma->vm->mutex);
> __i915_vm_release();
> release_references();
>
> And in release_reference() we dereference vma->vm to get to the
> vm gt pointer, leadin go a use-after free.
leading to
[...]
> -static void release_references(struct i915_vma *vma, bool vm_ddestroy)
> +static void release_references(struct i915_vma *vma, struct intel_gt *gt,
> +bool vm_ddestroy)
> {
> struct drm_i915_gem_object *obj = vma->obj;
> - struct intel_gt *gt = vma->vm->gt;
>
> GEM_BUG_ON(i915_vma_is_active(vma));
but then we have
if (vm_ddestroy)
i915_vm_resv_put(vma->vm);
were we reference to a freed vm, right? Do we need to check it
here, as well?
Andi
Re: [PATCH] staging: fbtft: fix checkpatch.pl struct should normally be const
Hi Uri, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on staging/staging-testing] url: https://github.com/intel-lab-lkp/linux/commits/Uri-Arev/staging-fbtft-fix-checkpatch-pl-struct-should-normally-be-const/20220520-012948 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 4d0cc9e0e53e9946d7b8dc58279c62dfa7a2191b config: alpha-allyesconfig (https://download.01.org/0day-ci/archive/20220520/202205200517.bcemgrh4-...@intel.com/config) compiler: alpha-linux-gcc (GCC) 11.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/d26e139bfc29011b0a147df71f0b91485189c66e git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Uri-Arev/staging-fbtft-fix-checkpatch-pl-struct-should-normally-be-const/20220520-012948 git checkout d26e139bfc29011b0a147df71f0b91485189c66e # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1 O=build_dir ARCH=alpha SHELL=/bin/bash drivers/staging/fbtft/ If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): drivers/staging/fbtft/fbtft-core.c: In function 'fbtft_framebuffer_alloc': drivers/staging/fbtft/fbtft-core.c:617:15: error: type defaults to 'int' in declaration of 'fbops' [-Werror=implicit-int] 617 | const fbops = devm_kzalloc(dev, sizeof(struct fb_ops), GFP_KERNEL); | ^ drivers/staging/fbtft/fbtft-core.c:617:15: error: conflicting type qualifiers for 'fbops' drivers/staging/fbtft/fbtft-core.c:542:30: note: previous definition of 'fbops' with type 'const struct fb_ops *' 542 | const struct fb_ops *fbops = NULL; | ^ >> drivers/staging/fbtft/fbtft-core.c:617:23: warning: initialization of 'int' >> from 'void *' makes integer from pointer without a cast [-Wint-conversion] 617 | const fbops = devm_kzalloc(dev, sizeof(struct fb_ops), GFP_KERNEL); | ^~~~ >> drivers/staging/fbtft/fbtft-core.c:617:9: warning: ISO C90 forbids mixed >> declarations and code [-Wdeclaration-after-statement] 617 | const fbops = devm_kzalloc(dev, sizeof(struct fb_ops), GFP_KERNEL); | ^ >> drivers/staging/fbtft/fbtft-core.c:644:21: warning: assignment to 'const >> struct fb_ops *' from 'int' makes pointer from integer without a cast >> [-Wint-conversion] 644 | info->fbops = fbops; | ^ drivers/staging/fbtft/fbtft-core.c:647:14: error: invalid type argument of '->' (have 'int') 647 | fbops->owner= dev->driver->owner; | ^~ drivers/staging/fbtft/fbtft-core.c:648:14: error: invalid type argument of '->' (have 'int') 648 | fbops->fb_read = fb_sys_read; | ^~ drivers/staging/fbtft/fbtft-core.c:649:14: error: invalid type argument of '->' (have 'int') 649 | fbops->fb_write = fbtft_fb_write; | ^~ drivers/staging/fbtft/fbtft-core.c:650:14: error: invalid type argument of '->' (have 'int') 650 | fbops->fb_fillrect = fbtft_fb_fillrect; | ^~ drivers/staging/fbtft/fbtft-core.c:651:14: error: invalid type argument of '->' (have 'int') 651 | fbops->fb_copyarea = fbtft_fb_copyarea; | ^~ drivers/staging/fbtft/fbtft-core.c:652:14: error: invalid type argument of '->' (have 'int') 652 | fbops->fb_imageblit = fbtft_fb_imageblit; | ^~ drivers/staging/fbtft/fbtft-core.c:653:14: error: invalid type argument of '->' (have 'int') 653 | fbops->fb_setcolreg = fbtft_fb_setcolreg; | ^~ drivers/staging/fbtft/fbtft-core.c:654:14: error: invalid type argument of '->' (have 'int') 654 | fbops->fb_blank = fbtft_fb_blank; | ^~ cc1: some warnings being treated as errors vim +617 drivers/staging/fbtft/fbtft-core.c 516 517 /** 518 * fbtft_framebuffer_alloc - creates a new frame buffer info structure 519 * 520 * @display: pointer to structure describing the display 521 * @dev: pointer to the device for this fb, this can be NULL 522 * @pdata: platform data for the display in use 523 * 524 * Creates a new frame buffer info structure. 525 * 526 * Also creates and populates the following structures: 527 * info->fbops 528 * info->fbdefio 529 * info->pseudo_palette 530 *
Re: [PATCH] dt-bindings: Fix properties without any type
On Thu, May 19, 2022 at 04:14:11PM -0500, Rob Herring wrote: > Now that the schema tools can extract type information for all > properties (in order to decode dtb files), finding properties missing > any type definition is fairly trivial though not yet automated. > > Fix the various property schemas which are missing a type. Most of these > tend to be device specific properties which don't have a vendor prefix. > A vendor prefix is how we normally ensure a type is defined. Acked-by: Mark Brown signature.asc Description: PGP signature
[PATCH] dt-bindings: Fix properties without any type
Now that the schema tools can extract type information for all properties (in order to decode dtb files), finding properties missing any type definition is fairly trivial though not yet automated. Fix the various property schemas which are missing a type. Most of these tend to be device specific properties which don't have a vendor prefix. A vendor prefix is how we normally ensure a type is defined. Signed-off-by: Rob Herring --- .../arm/hisilicon/controller/hip04-bootwrapper.yaml | 5 +++-- .../bindings/display/bridge/toshiba,tc358768.yaml | 1 + .../devicetree/bindings/display/panel/panel-timing.yaml | 5 + .../bindings/display/panel/raydium,rm67191.yaml | 1 + .../bindings/display/panel/samsung,s6e8aa0.yaml | 1 + .../devicetree/bindings/gpio/fairchild,74hc595.yaml | 1 + .../devicetree/bindings/input/google,cros-ec-keyb.yaml| 1 + .../devicetree/bindings/input/matrix-keymap.yaml | 4 Documentation/devicetree/bindings/media/i2c/adv7604.yaml | 3 ++- Documentation/devicetree/bindings/mux/reg-mux.yaml| 8 ++-- Documentation/devicetree/bindings/net/cdns,macb.yaml | 1 + Documentation/devicetree/bindings/net/ingenic,mac.yaml| 1 + .../devicetree/bindings/net/ti,davinci-mdio.yaml | 1 + .../devicetree/bindings/net/wireless/ti,wlcore.yaml | 2 ++ .../devicetree/bindings/pci/snps,dw-pcie-ep.yaml | 6 -- Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml | 2 ++ .../devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml| 2 ++ Documentation/devicetree/bindings/power/avs/qcom,cpr.yaml | 1 + .../devicetree/bindings/power/supply/battery.yaml | 7 ++- .../devicetree/bindings/power/supply/charger-manager.yaml | 1 + Documentation/devicetree/bindings/rng/st,stm32-rng.yaml | 1 + Documentation/devicetree/bindings/serial/8250.yaml| 1 + .../devicetree/bindings/sound/audio-graph-card2.yaml | 3 +++ .../devicetree/bindings/sound/imx-audio-hdmi.yaml | 3 +++ Documentation/devicetree/bindings/usb/smsc,usb3503.yaml | 1 + 25 files changed, 55 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/hisilicon/controller/hip04-bootwrapper.yaml b/Documentation/devicetree/bindings/arm/hisilicon/controller/hip04-bootwrapper.yaml index 7378159e61df..483caf0ce25b 100644 --- a/Documentation/devicetree/bindings/arm/hisilicon/controller/hip04-bootwrapper.yaml +++ b/Documentation/devicetree/bindings/arm/hisilicon/controller/hip04-bootwrapper.yaml @@ -17,14 +17,15 @@ properties: - const: hisilicon,hip04-bootwrapper boot-method: +$ref: /schemas/types.yaml#/definitions/uint32-array description: | Address and size of boot method. [0]: bootwrapper physical address [1]: bootwrapper size [2]: relocation physical address [3]: relocation size -minItems: 1 -maxItems: 2 +minItems: 2 +maxItems: 4 required: - compatible diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml index 3bd670b8e5cd..0b6f5bef120f 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml @@ -58,6 +58,7 @@ properties: properties: data-lines: +$ref: /schemas/types.yaml#/definitions/uint32 enum: [ 16, 18, 24 ] port@1: diff --git a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml index 7749de95ee40..229e3b36ee29 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml @@ -146,6 +146,7 @@ properties: Horizontal sync pulse. 0 selects active low, 1 selects active high. If omitted then it is not used by the hardware +$ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1] vsync-active: @@ -153,6 +154,7 @@ properties: Vertical sync pulse. 0 selects active low, 1 selects active high. If omitted then it is not used by the hardware +$ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1] de-active: @@ -160,6 +162,7 @@ properties: Data enable. 0 selects active low, 1 selects active high. If omitted then it is not used by the hardware +$ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1] pixelclk-active: @@ -169,6 +172,7 @@ properties: sample data on rising edge. Use 1 to drive pixel data on rising edge and sample data on falling edge +$ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1] syncclk-active: @@ -179,6 +183,7 @@ properties: sample sync on rising edge of pixel clock. Use 1 to drive sync on
Re: [PATCH] staging: fbtft: fix checkpatch.pl struct should normally be const
On Thu, May 19, 2022 at 08:25:01PM +0300, Uri Arev wrote: > This simple patch fixes a checkpatch.pl warning in `fbtft/fbtft-core.c`. > > Reported by Checkpatch: > WARNING: struct fb_ops should normally be const ... > - fbops = devm_kzalloc(dev, sizeof(struct fb_ops), GFP_KERNEL); > + const fbops = devm_kzalloc(dev, sizeof(struct fb_ops), GFP_KERNEL); Why? -- With Best Regards, Andy Shevchenko
Re: [linux-next:master] BUILD REGRESSION 736ee37e2e8eed7fe48d0a37ee5a709514d478b3
On Wed, 18 May 2022 20:41:27 -0700 Guenter Roeck wrote: > On 5/18/22 17:55, kernel test robot wrote: > > tree/branch: > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > > branch HEAD: 736ee37e2e8eed7fe48d0a37ee5a709514d478b3 Add linux-next > > specific files for 20220518 > > > > Error/Warning reports: > > > > https://lore.kernel.org/linux-mm/202204291924.vtgzmeri-...@intel.com > > https://lore.kernel.org/linux-mm/202205041248.wgcwpcev-...@intel.com > > https://lore.kernel.org/linux-mm/202205122113.ulkzd3sz-...@intel.com > > https://lore.kernel.org/linux-mm/202205172344.3gfeaum1-...@intel.com > > https://lore.kernel.org/linux-mm/202205190527.o9wvevhi-...@intel.com > > > > Error/Warning: (recently discovered and may have been fixed) > > > [ .. ] > > drivers/hwmon/nct6775-platform.c:199:9: sparse:unsigned char > > drivers/hwmon/nct6775-platform.c:199:9: sparse:void > > This is getting tiresome. Every driver using outb() on m68k will > experience that "problem". As far as I can see, it is caused by > > #define out_8(addr,b) (void)((*(__force volatile u8 *) (unsigned long)(addr)) > = (b)) > > in arch/m68k/include/asm/raw_io.h. I have no idea what the > "(void)" is for, but removing it "fixes" the problem. > Either case, this is not a problem with the nct6775 driver, > nor is it a new problem. (cc Geert)
Re: [PATCH v7] drm/msm/dp: Always clear mask bits to disable interrupts at dp_ctrl_reset_irq_ctrl()
On 5/17/2022 9:21 AM, Kuogee Hsieh wrote:
Is anyone has comments on this patch?
dp_catalog_ctrl_reset() will software reset DP controller. But it will
not reset programmable registers to default value. DP driver still have
to clear mask bits to interrupt status registers to disable interrupts
after software reset of controller.
At current implementation, dp_ctrl_reset_irq_ctrl() will software reset dp
controller but did not call dp_catalog_ctrl_enable_irq(false) to clear hpd
related interrupt mask bits to disable hpd related interrupts due to it
mistakenly think hpd related interrupt mask bits will be cleared by software
reset of dp controller automatically. This mistake may cause system to crash
during suspending procedure due to unexpected irq fired and trigger event
thread to access dp controller registers with controller clocks are disabled.
This patch fixes system crash during suspending problem by removing "enable"
flag condition checking at dp_ctrl_reset_irq_ctrl() so that hpd related
interrupt mask bits are cleared to prevent unexpected from happening.
Changes in v2:
-- add more details commit text
Changes in v3:
-- add synchrons_irq()
-- add atomic_t suspended
Changes in v4:
-- correct Fixes's commit ID
-- remove synchrons_irq()
Changes in v5:
-- revise commit text
Changes in v6:
-- add event_lock to protect "suspended"
Changes in v7:
-- delete "suspended" flag
Fixes: 989ebe7bc446 ("drm/msm/dp: do not initialize phy until plugin interrupt
received")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 5356856..5ddb4e8 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1380,8 +1380,13 @@ void dp_ctrl_reset_irq_ctrl(struct dp_ctrl *dp_ctrl,
bool enable)
dp_catalog_ctrl_reset(ctrl->catalog);
- if (enable)
- dp_catalog_ctrl_enable_irq(ctrl->catalog, enable);
+ /*
+* all dp controller programmable registers will not
+* be reset to default value after DP_SW_RESET
+* therefore interrupt mask bits have to be updated
+* to enable/disable interrupts
+*/
+ dp_catalog_ctrl_enable_irq(ctrl->catalog, enable);
}
void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl)
[PATCH v5 3/3] drm/msm/dp: delete vdda regulator related functions from eDP/DP controller
Vdda regulators are related to both eDP and DP phy so that it should be
managed at eDP and DP phy driver instead of controller. This patch removes
vdda regulators related functions out of eDP/DP controller.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_parser.c | 14 --
drivers/gpu/drm/msm/dp/dp_parser.h | 6 ---
drivers/gpu/drm/msm/dp/dp_power.c | 95 +-
3 files changed, 2 insertions(+), 113 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c
b/drivers/gpu/drm/msm/dp/dp_parser.c
index 8f9fed9..4ef2130 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -22,14 +22,6 @@
#define DP_DEFAULT_P0_OFFSET 0x1000
#define DP_DEFAULT_P0_SIZE 0x0400
-static const struct dp_regulator_cfg sdm845_dp_reg_cfg = {
- .num = 2,
- .regs = {
- {"vdda-1p2", 21800, 4 },/* 1.2 V */
- {"vdda-0p9", 36000, 32 }, /* 0.9 V */
- },
-};
-
static void __iomem *dp_ioremap(struct platform_device *pdev, int idx, size_t
*len)
{
struct resource *res;
@@ -298,12 +290,6 @@ static int dp_parser_parse(struct dp_parser *parser)
if (rc)
return rc;
- /* Map the corresponding regulator information according to
-* version. Currently, since we only have one supported platform,
-* mapping the regulator directly.
-*/
- parser->regulator_cfg = _dp_reg_cfg;
-
return 0;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h
b/drivers/gpu/drm/msm/dp/dp_parser.h
index 3a4d797..b56b4d7 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -101,11 +101,6 @@ struct dp_reg_entry {
int disable_load;
};
-struct dp_regulator_cfg {
- int num;
- struct dp_reg_entry regs[DP_DEV_REGULATOR_MAX];
-};
-
/**
* struct dp_parser - DP parser's data exposed to clients
*
@@ -121,7 +116,6 @@ struct dp_parser {
struct dp_pinctrl pinctrl;
struct dp_io io;
struct dp_display_data disp_data;
- const struct dp_regulator_cfg *regulator_cfg;
u32 max_dp_lanes;
struct drm_bridge *next_bridge;
diff --git a/drivers/gpu/drm/msm/dp/dp_power.c
b/drivers/gpu/drm/msm/dp/dp_power.c
index d9e0117..b52ac1d 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.c
+++ b/drivers/gpu/drm/msm/dp/dp_power.c
@@ -20,82 +20,10 @@ struct dp_power_private {
struct clk *link_clk_src;
struct clk *pixel_provider;
struct clk *link_provider;
- struct regulator_bulk_data supplies[DP_DEV_REGULATOR_MAX];
struct dp_power dp_power;
};
-static void dp_power_regulator_disable(struct dp_power_private *power)
-{
- struct regulator_bulk_data *s = power->supplies;
- const struct dp_reg_entry *regs = power->parser->regulator_cfg->regs;
- int num = power->parser->regulator_cfg->num;
- int i;
-
- DBG("");
- for (i = num - 1; i >= 0; i--)
- if (regs[i].disable_load >= 0)
- regulator_set_load(s[i].consumer,
- regs[i].disable_load);
-
- regulator_bulk_disable(num, s);
-}
-
-static int dp_power_regulator_enable(struct dp_power_private *power)
-{
- struct regulator_bulk_data *s = power->supplies;
- const struct dp_reg_entry *regs = power->parser->regulator_cfg->regs;
- int num = power->parser->regulator_cfg->num;
- int ret, i;
-
- DBG("");
- for (i = 0; i < num; i++) {
- if (regs[i].enable_load >= 0) {
- ret = regulator_set_load(s[i].consumer,
-regs[i].enable_load);
- if (ret < 0) {
- pr_err("regulator %d set op mode failed, %d\n",
- i, ret);
- goto fail;
- }
- }
- }
-
- ret = regulator_bulk_enable(num, s);
- if (ret < 0) {
- pr_err("regulator enable failed, %d\n", ret);
- goto fail;
- }
-
- return 0;
-
-fail:
- for (i--; i >= 0; i--)
- regulator_set_load(s[i].consumer, regs[i].disable_load);
- return ret;
-}
-
-static int dp_power_regulator_init(struct dp_power_private *power)
-{
- struct regulator_bulk_data *s = power->supplies;
- const struct dp_reg_entry *regs = power->parser->regulator_cfg->regs;
- struct platform_device *pdev = power->pdev;
- int num = power->parser->regulator_cfg->num;
- int i, ret;
-
- for (i = 0; i < num; i++)
- s[i].supply = regs[i].name;
-
- ret = devm_regulator_bulk_get(>dev, num, s);
- if (ret < 0) {
- pr_err("%s: failed to init regulator, ret=%d\n",
-
[PATCH v5 1/3] phy: qcom-edp: add regulator_set_load to edp phy
This patch add regulator_set_load() before enable regulator at
eDP phy driver.
Signed-off-by: Kuogee Hsieh
---
drivers/phy/qualcomm/phy-qcom-edp.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
b/drivers/phy/qualcomm/phy-qcom-edp.c
index cacd32f..90093cd 100644
--- a/drivers/phy/qualcomm/phy-qcom-edp.c
+++ b/drivers/phy/qualcomm/phy-qcom-edp.c
@@ -87,14 +87,19 @@ struct qcom_edp {
struct clk_bulk_data clks[2];
struct regulator_bulk_data supplies[2];
+ int enable_load[2];
};
static int qcom_edp_phy_init(struct phy *phy)
{
struct qcom_edp *edp = phy_get_drvdata(phy);
int ret;
+ int i;
- ret = regulator_bulk_enable(ARRAY_SIZE(edp->supplies), edp->supplies);
+ for (i = 0; i < 2; i++)
+ regulator_set_load(edp->supplies[i].consumer,
edp->enable_load[i]);
+
+ ret = regulator_bulk_enable(num_consumers, edp->supplies);
if (ret)
return ret;
@@ -635,6 +640,8 @@ static int qcom_edp_phy_probe(struct platform_device *pdev)
edp->supplies[0].supply = "vdda-phy";
edp->supplies[1].supply = "vdda-pll";
+ edp->enable_load[0] = 21800;/* load for 1.2 V vdda-phy supply */
+ edp->enable_load[1] = 36000;/* load for 0.9 V vdda-pll supply */
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(edp->supplies),
edp->supplies);
if (ret)
return ret;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v5 2/3] phy: qcom-qmp: add regulator_set_load to dp phy
This patch add regulator_set_load() before enable regulator at
DP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index b144ae1..24f39ee 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -3130,6 +3130,7 @@ struct qmp_phy_cfg {
int num_resets;
/* regulators to be requested */
const char * const *vreg_list;
+ const unsigned int *vreg_enable_load;
int num_vregs;
/* array of registers with different offsets */
@@ -3346,6 +3347,10 @@ static const char * const qmp_phy_vreg_l[] = {
"vdda-phy", "vdda-pll",
};
+static const unsigned int qmp_phy_vreg_enable_load[] = {
+ 21800, 36000
+};
+
static const struct qmp_phy_cfg ipq8074_usb3phy_cfg = {
.type = PHY_TYPE_USB3,
.nlanes = 1,
@@ -3711,6 +3716,7 @@ static const struct qmp_phy_cfg sc7180_usb3phy_cfg = {
.reset_list = sc7180_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(sc7180_usb3phy_reset_l),
.vreg_list = qmp_phy_vreg_l,
+ .vreg_enable_load = qmp_phy_vreg_enable_load,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = qmp_v3_usb3phy_regs_layout,
@@ -3749,6 +3755,7 @@ static const struct qmp_phy_cfg sc7180_dpphy_cfg = {
.reset_list = sc7180_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(sc7180_usb3phy_reset_l),
.vreg_list = qmp_phy_vreg_l,
+ .vreg_enable_load = qmp_phy_vreg_enable_load,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = qmp_v3_usb3phy_regs_layout,
@@ -3940,6 +3947,7 @@ static const struct qmp_phy_cfg sm8150_usb3phy_cfg = {
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
.vreg_list = qmp_phy_vreg_l,
+ .vreg_enable_load = qmp_phy_vreg_enable_load,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = qmp_v4_usb3phy_regs_layout,
@@ -4009,6 +4017,7 @@ static const struct qmp_phy_cfg sc8180x_dpphy_cfg = {
.reset_list = sc7180_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(sc7180_usb3phy_reset_l),
.vreg_list = qmp_phy_vreg_l,
+ .vreg_enable_load = qmp_phy_vreg_enable_load,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = qmp_v3_usb3phy_regs_layout,
@@ -4072,6 +4081,7 @@ static const struct qmp_phy_cfg sm8250_usb3phy_cfg = {
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
.vreg_list = qmp_phy_vreg_l,
+ .vreg_enable_load = qmp_phy_vreg_enable_load,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = qmp_v4_usb3phy_regs_layout,
@@ -4139,6 +4149,7 @@ static const struct qmp_phy_cfg sm8250_dpphy_cfg = {
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
.vreg_list = qmp_phy_vreg_l,
+ .vreg_enable_load = qmp_phy_vreg_enable_load,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = qmp_v4_usb3phy_regs_layout,
@@ -5008,6 +5019,11 @@ static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
return 0;
}
+ if (cfg->vreg_enable_load) {
+ for (i = 0; i <= cfg->num_vregs; i++)
+ regulator_set_load(qmp->vregs[i].consumer,
cfg->vreg_enable_load[i]);
+ }
+
/* turn on regulator supplies */
ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs);
if (ret) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v5 0/3] eDP/DP Phy vdda realted function
1) add regulator_set_load() to eDP phy 2) add regulator_set_load() to DP phy 3) remove vdda related function out of eDP/DP controller Kuogee Hsieh (3): phy: qcom-edp: add regulator_set_load to edp phy phy: qcom-qmp: add regulator_set_load to dp phy drm/msm/dp: delete vdda regulator related functions from eDP/DP controller drivers/gpu/drm/msm/dp/dp_parser.c | 14 -- drivers/gpu/drm/msm/dp/dp_parser.h | 6 --- drivers/gpu/drm/msm/dp/dp_power.c | 95 + drivers/phy/qualcomm/phy-qcom-edp.c | 9 +++- drivers/phy/qualcomm/phy-qcom-qmp.c | 16 +++ 5 files changed, 26 insertions(+), 114 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[RESEND 3/6 v2] media: uapi: add MEDIA_BUS_FMT_RGB565_1X24_CPADHI
From: Chris Morgan Add the MEDIA_BUS_FMT_RGB565_1X24_CPADHI format used by the Geekworm MZP280 panel for the Raspberry Pi. Signed-off-by: Chris Morgan --- include/uapi/linux/media-bus-format.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index 0dfc11ee2..a7b765498 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -34,13 +34,14 @@ #define MEDIA_BUS_FMT_FIXED0x0001 -/* RGB - next is 0x101e */ +/* RGB - next is 0x101f */ #define MEDIA_BUS_FMT_RGB444_1X12 0x1016 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE 0x1003 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE 0x1004 #define MEDIA_BUS_FMT_RGB565_1X16 0x1017 +#define MEDIA_BUS_FMT_RGB565_1X24_CPADHI 0x101e #define MEDIA_BUS_FMT_BGR565_2X8_BE0x1005 #define MEDIA_BUS_FMT_BGR565_2X8_LE0x1006 #define MEDIA_BUS_FMT_RGB565_2X8_BE0x1007 -- 2.25.1
[RESEND 6/6 v2] drm/vc4: dpi: Support DPI interface in mode3 for RGB565
From: Chris Morgan
Add support for the VC4 DPI driver to utilize DPI mode 3. This is
defined here as xxxRxxGGxxxB:
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#parallel-display-interface-dpi
This mode is required to use the Geekworm MZP280 DPI display.
Signed-off-by: Chris Morgan
Reviewed-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_dpi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index c180eb60b..3c58ade25 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -173,6 +173,10 @@ static void vc4_dpi_encoder_enable(struct drm_encoder
*encoder)
dpi_c |= VC4_SET_FIELD(DPI_FORMAT_16BIT_565_RGB_3,
DPI_FORMAT);
break;
+ case MEDIA_BUS_FMT_RGB565_1X24_CPADHI:
+ dpi_c |= VC4_SET_FIELD(DPI_FORMAT_16BIT_565_RGB_2,
+ DPI_FORMAT);
+ break;
default:
DRM_ERROR("Unknown media bus format %d\n", bus_format);
break;
--
2.25.1
[RESEND 4/6 v2] dt-bindings: display: simple: add Geekworm MZP280 Panel
From: Chris Morgan The Geekworm MZP280 panel is a 480x640 (portrait) panel with a capacitive touch interface and a 40 pin header meant to interface directly with the Raspberry Pi. The screen is 2.8 inches diagonally, and there appear to be at least 4 distinct versions all with the same panel timings. Timings were derived from drivers posted on the github located here: https://github.com/tianyoujian/MZDPI/tree/master/vga Additional details about this panel family can be found here: https://wiki.geekworm.com/2.8_inch_Touch_Screen_for_Pi_zero Signed-off-by: Chris Morgan --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 62f5f050c..3d03d8276 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -148,6 +148,8 @@ properties: - frida,frd350h54004 # FriendlyELEC HD702E 800x1280 LCD panel - friendlyarm,hd702e +# Geekworm MZP280 2.8" 480x640 LCD panel with capacitive touch + - geekworm,mzp280 # GiantPlus GPG48273QS5 4.3" (480x272) WQVGA TFT LCD panel - giantplus,gpg48273qs5 # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel -- 2.25.1
[RESEND 5/6 v2] drm/panel: simple: add Geekworm MZP280 Panel
From: Chris Morgan
Add support for the Geekworm MZP280 Panel
Signed-off-by: Chris Morgan
Acked-by: Maxime Ripard
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 9e46db5e3..cbc1a4fd1 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1824,6 +1824,32 @@ static const struct panel_desc friendlyarm_hd702e = {
},
};
+static const struct drm_display_mode geekworm_mzp280_mode = {
+ .clock = 32000,
+ .hdisplay = 480,
+ .hsync_start = 480 + 41,
+ .hsync_end = 480 + 41 + 20,
+ .htotal = 480 + 41 + 20 + 60,
+ .vdisplay = 640,
+ .vsync_start = 640 + 5,
+ .vsync_end = 640 + 5 + 10,
+ .vtotal = 640 + 5 + 10 + 10,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc geekworm_mzp280 = {
+ .modes = _mzp280_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 47,
+ .height = 61,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB565_1X24_CPADHI,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode giantplus_gpg482739qs5_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -3790,6 +3816,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "friendlyarm,hd702e",
.data = _hd702e,
+ }, {
+ .compatible = "geekworm,mzp280",
+ .data = _mzp280,
}, {
.compatible = "giantplus,gpg482739qs5",
.data = _gpg482739qs5
--
2.25.1
[RESEND 1/6 v2] dt-bindings: vendor-prefixes: Add Geekworm
From: Chris Morgan Add vendor prefix for Geekworm (https://geekworm.com). Signed-off-by: Chris Morgan --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 294093d45..c0c7627c6 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -455,6 +455,8 @@ patternProperties: description: General Electric Company "^geekbuying,.*": description: GeekBuying + "^geekworm,.*": +description: Geekworm "^gef,.*": description: GE Fanuc Intelligent Platforms Embedded Systems, Inc. "^GEFanuc,.*": -- 2.25.1
[RESEND 2/6 v2] media: uapi: Document format MEDIA_BUS_FMT_RGB565_1X24_CPADHI
From: Chris Morgan Add support for MEDIA_BUS_FMT_RGB565_1X24_CPADHI. This format is used by the Geekworm MZP280 panel which interfaces with the Raspberry Pi. Signed-off-by: Chris Morgan --- .../media/v4l/subdev-formats.rst | 37 +++ 1 file changed, 37 insertions(+) diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst index 0cbc045d5..e43e07634 100644 --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst @@ -624,6 +624,43 @@ The following tables list existing packed RGB formats. - b\ :sub:`2` - b\ :sub:`1` - b\ :sub:`0` +* .. _MEDIA_BUS_FMT_RGB565_1X24_CPADHI: + + - MEDIA_BUS_FMT_RGB565_1X24_CPADHI + - 0x101e + - + - + - + - + - + - + - + - + - + - 0 + - 0 + - 0 + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - 0 + - 0 + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - 0 + - 0 + - 0 + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` * .. _MEDIA-BUS-FMT-BGR565-2X8-BE: - MEDIA_BUS_FMT_BGR565_2X8_BE -- 2.25.1
[RESEND 0/6 v2] Support Geekworm MZP280 Panel for Raspberry Pi
From: Chris Morgan This patch series is to add support for the MZP280 panel for the Raspberry Pi. This panel requires adding support for Mode 3 of the Raspberry Pi DPI connector, which necessitates a new media bus format. This patch series has been tested on my Raspberry Pi 4 with version 1 of the panel in question. Changes since V1: - Added documentation for vendor string. Signed-off-by: Chris Morgan Chris Morgan (6): dt-bindings: vendor-prefixes: Add Geekworm media: uapi: Document format MEDIA_BUS_FMT_RGB565_1X24_CPADHI media: uapi: add MEDIA_BUS_FMT_RGB565_1X24_CPADHI dt-bindings: display: simple: add Geekworm MZP280 Panel drm/panel: simple: add Geekworm MZP280 Panel drm/vc4: dpi: Support DPI interface in mode3 for RGB565 .../bindings/display/panel/panel-simple.yaml | 2 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../media/v4l/subdev-formats.rst | 37 +++ drivers/gpu/drm/panel/panel-simple.c | 29 +++ drivers/gpu/drm/vc4/vc4_dpi.c | 4 ++ include/uapi/linux/media-bus-format.h | 3 +- 6 files changed, 76 insertions(+), 1 deletion(-) -- 2.25.1
Re: [PATCH v9 18/22] drm/mediatek: Add mt8195 Embedded DisplayPort driver
On Thu, 12 May 2022 09:44, Maxime Ripard wrote:
>Hi,
>
>On Wed, May 11, 2022 at 05:59:13AM -0700, Guillaume Ranquet wrote:
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +
>> >> +#include "mtk_dp_reg.h"
>> >> +
>> >> +#define MTK_DP_AUX_WAIT_REPLY_COUNT 20
>> >> +#define MTK_DP_CHECK_SINK_CAP_TIMEOUT_COUNT 3
>> >> +
>> >> +//TODO: platform/device data or dts?
>> >
>> >DTS :)
>>
>> It's probably going to be a platform_data struct for v10...
>> If I have time, I'll change it to a dts property for v10.
>
>I can't really imagine a case where we would need platform_data
>nowadays. If you have a device tree, then it should be part of the
>binding.
>
>What issue would you like to address by using a platform_data?
>
Ok, I'll migrate to dt then. I didn't realize platform_data were depreciated.
Angelo wants the MAX_LINRATE and MAX_LANES defines to be configurable.
I imagined platform_data would be more appropriate as (per my understanding) the
limitation is associated with a specific SoC.
>> >> +static enum drm_connector_status mtk_dp_bdg_detect(struct drm_bridge
>> >> *bridge)
>> >> +{
>> >> + return connector_status_connected;
>> >> +}
>> >
>> >I'm not quite sure what's going on there. You seem to have some support
>> >for HPD interrupts above, but you always report the display as
>> >connected?
>> >
>> >I'd assume that either you don't have HPD support and then always report
>> >it as connected, or you have HPD support and report the current status
>> >in detect, but that combination seems weird.
>>
>> The HPD logic needs more work, some things have been broken when I split
>> the driver into three patches eDP - DP - Audio
>> The assumption at first was that eDP didn't need any HPD handling... but it
>> seems I was wrong and the eDP driver needs to be reworked.
>
>That can be made into a patch of its own if you prefer.
>
>You first introduce the driver without status reporting (always
>returning connected or unknown), and then add the needed bits for HPD.
>
>However, that first patch shouldn't contain the interrupt plumbing and
>so on, it's just confusing.
>
After discussing a while with Mediatek, it appears that hot plug detection
needs to be handled even for eDP... (which is always connected).
So I'll revert to the split I made earlier in v8 where hot plug detection was
part of the eDP patch the addition of the External display port was a
trivial patch [1].
>> >> +static struct edid *mtk_dp_get_edid(struct drm_bridge *bridge,
>> >> + struct drm_connector *connector)
>> >> +{
>> >> + struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
>> >> + bool enabled = mtk_dp->enabled;
>> >> + struct edid *new_edid = NULL;
>> >> +
>> >> + if (!enabled)
>> >> + drm_bridge_chain_pre_enable(bridge);
>> >> +
>> >> + drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
>> >> + usleep_range(2000, 5000);
>> >> +
>> >> + if (mtk_dp_plug_state(mtk_dp))
>> >> + new_edid = drm_get_edid(connector, _dp->aux.ddc);
>> >> +
>> >> + if (!enabled)
>> >> + drm_bridge_chain_post_disable(bridge);
>> >
>> >Are you sure we can't get a mode set while get_edid is called?
>> >
>> >If we can, then you could end up disabling the device while it's being
>> >powered on.
>>
>> I'm a bit unsure, I need to spend more time in the drm stack to make sure.
>> I'll get back to you when I have a definitive answer.
>
>So, it looks like it's ok.
>
>get_edid is your implementation of get_modes, which is called by
>drm_helper_probe_single_connector_modes
>
>https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_probe_helper.c#L416
>
>This is the standard implemantion of fill_modes, which is called
>whenever the get_connector ioctl is called (or similar paths, like
>drm_client_modeset_probe)
>
>drm_helper_probe_single_connector_modes is under the assumption that the
>mode_config.mutex is held though, and that the big lock. So it should be
>serialized there.
>
>Just for future proofing though, it would be better to use refcounting
>there. Would runtime_pm work for you there?
>
Thx for looking into this for me.
Not sure runtime_pm works here as it would only refcount if compiled
with CONFIG_PM?
I'd rather use the enabled field as a refcounter instead of a boolean.
Unless I'm totally missing your point?
Thx,
Guillaume.
>> >> +static void mtk_dp_parse_drm_mode_timings(struct mtk_dp *mtk_dp,
>> >> + struct drm_display_mode *mode)
>> >> +{
>> >> + struct mtk_dp_timings *timings = _dp->info.timings;
>> >> +
>> >> + drm_display_mode_to_videomode(mode, >vm);
>> >> +
[GIT PULL] drm/msm: drm-msm-fixes-2022-05-19
Hi Rob Here is the pull request for the fixes for 5.19. Just a few more changes on top of msm-fixes-staging. Mainly it has the foll fixes: - Limiting WB modes to max sspp linewidth - Fixing the supported rotations to add 180 back for IGT - Fix to handle pm_runtime_get_sync() errors to avoid unclocked access in the bind() path for dpu driver - Fix the irq_free() without request issue which was a big-time hitter in the CI-runs. Thanks Abhinav The following changes since commit 947a844bb3ebff0f4736d244d792ce129f6700d7: drm: msm: fix possible memory leak in mdp5_crtc_cursor_set() (2022-05-18 11:05:21 -0700) are available in the git repository at: https://gitlab.freedesktop.org/abhinavk/msm.git/ tags/msm-next-5.19-fixes for you to fetch changes up to 64b22a0da12adb571c01edd671ee43634ebd7e41: drm/msm/dpu: handle pm_runtime_get_sync() errors in bind path (2022-05-18 18:32:03 -0700) 5.19 fixes for msm-next Signed-off-by: Abhinav Kumar Abhinav Kumar (3): drm/msm/dpu: limit writeback modes according to max_linewidth drm/msm/dpu: add DRM_MODE_ROTATE_180 back to supported rotations drm/msm/dpu: handle pm_runtime_get_sync() errors in bind path Dmitry Baryshkov (1): drm/msm: don't free the IRQ if it was not requested drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 +++- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 4 +++- drivers/gpu/drm/msm/msm_drv.c | 7 ++- drivers/gpu/drm/msm/msm_kms.h | 1 + 5 files changed, 14 insertions(+), 4 deletions(-)
Re: [PATCH v3 0/3] add Aspeed udc driver for ast2600
On Wed, May 18, 2022 at 02:20:40PM +0800, Neal Liu wrote: > This patch series aim to add Aspeed USB 2.0 Device Controller (udc) > driver, including driver itself, device tree node and documentation. > > Change since v2: > - Rename device tree nodes. > - Fix unusual indentation. > > Change since v1: > - Fix build test warning reported by kernel test robot. > - Rename proper name for dt-bindings document. > > *** BLURB HERE *** No blurb?
Re: [PATCH v3 1/3] usb: gadget: add Aspeed ast2600 udc driver
On Wed, May 18, 2022 at 02:20:41PM +0800, Neal Liu wrote: > Aspeed udc is compliant with USB2.0, supports USB High Speed > and Full Speed, backward compatible with USB1.1. > > Supports independent DMA channel for each generic endpoint. > Supports 32/256 stages descriptor mode for all generic endpoints. > > This driver supports full functionality including single/multiple > stages descriptor mode, and exposes 1 UDC gadget driver. > > Signed-off-by: Neal Liu > Reported-by: kernel test robot The kernel test robot did not report that you needed to add a new driver :(
[PATCH] drm/panfrost: Job should reference MMU not file_priv
For a while now it's been allowed for a MMU context to outlive it's
corresponding panfrost_priv, however the job structure still references
panfrost_priv to get hold of the MMU context. If panfrost_priv has been
freed this is a use-after-free which I've been able to trigger resulting
in a splat.
To fix this, drop the reference to panfrost_priv in the job structure
and add a direct reference to the MMU structure which is what's actually
needed.
Fixes: 7fdc48cc63a3 ("drm/panfrost: Make sure MMU context lifetime is not bound
to panfrost_priv")
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 5 +++--
drivers/gpu/drm/panfrost/panfrost_job.c | 6 +++---
drivers/gpu/drm/panfrost/panfrost_job.h | 2 +-
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 7fcbc2a5b6cd..087e69b98d06 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -233,6 +233,7 @@ static int panfrost_ioctl_submit(struct drm_device *dev,
void *data,
struct drm_file *file)
{
struct panfrost_device *pfdev = dev->dev_private;
+ struct panfrost_file_priv *file_priv = file->driver_priv;
struct drm_panfrost_submit *args = data;
struct drm_syncobj *sync_out = NULL;
struct panfrost_job *job;
@@ -262,12 +263,12 @@ static int panfrost_ioctl_submit(struct drm_device *dev,
void *data,
job->jc = args->jc;
job->requirements = args->requirements;
job->flush_id = panfrost_gpu_get_latest_flush_id(pfdev);
- job->file_priv = file->driver_priv;
+ job->mmu = file_priv->mmu;
slot = panfrost_job_get_slot(job);
ret = drm_sched_job_init(>base,
->file_priv->sched_entity[slot],
+_priv->sched_entity[slot],
NULL);
if (ret)
goto out_put_job;
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index fda5871aebe3..7c4208476fbd 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -201,7 +201,7 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
return;
}
- cfg = panfrost_mmu_as_get(pfdev, job->file_priv->mmu);
+ cfg = panfrost_mmu_as_get(pfdev, job->mmu);
job_write(pfdev, JS_HEAD_NEXT_LO(js), lower_32_bits(jc_head));
job_write(pfdev, JS_HEAD_NEXT_HI(js), upper_32_bits(jc_head));
@@ -435,7 +435,7 @@ static void panfrost_job_handle_err(struct panfrost_device
*pfdev,
job->jc = 0;
}
- panfrost_mmu_as_put(pfdev, job->file_priv->mmu);
+ panfrost_mmu_as_put(pfdev, job->mmu);
panfrost_devfreq_record_idle(>pfdevfreq);
if (signal_fence)
@@ -456,7 +456,7 @@ static void panfrost_job_handle_done(struct panfrost_device
*pfdev,
* happen when we receive the DONE interrupt while doing a GPU reset).
*/
job->jc = 0;
- panfrost_mmu_as_put(pfdev, job->file_priv->mmu);
+ panfrost_mmu_as_put(pfdev, job->mmu);
panfrost_devfreq_record_idle(>pfdevfreq);
dma_fence_signal_locked(job->done_fence);
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.h
b/drivers/gpu/drm/panfrost/panfrost_job.h
index 77e6d0e6f612..8becc1ba0eb9 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.h
+++ b/drivers/gpu/drm/panfrost/panfrost_job.h
@@ -17,7 +17,7 @@ struct panfrost_job {
struct kref refcount;
struct panfrost_device *pfdev;
- struct panfrost_file_priv *file_priv;
+ struct panfrost_mmu *mmu;
/* Fence to be signaled by IRQ handler when the job is complete. */
struct dma_fence *done_fence;
--
2.30.2
Re: [PATCH v7 3/7] drm/i915: Prepare for multiple GTs
On 5/11/2022 12:11 PM, Ceraolo Spurio, Daniele wrote:
On 3/18/2022 4:39 PM, Andi Shyti wrote:
From: Tvrtko Ursulin
On a multi-tile platform, each tile has its own registers + GGTT
space, and BAR 0 is extended to cover all of them.
Up to four GTs are supported in i915->gt[], with slot zero
shadowing the existing i915->gt0 to enable source compatibility
with legacy driver paths. A for_each_gt macro is added to iterate
over the GTs and will be used by upcoming patches that convert
various parts of the driver to be multi-gt aware.
Only the primary/root tile is initialized for now; the other
tiles will be detected and plugged in by future patches once the
necessary infrastructure is in place to handle them.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
Signed-off-by: Andi Shyti
Cc: Daniele Ceraolo Spurio
Cc: Joonas Lahtinen
Cc: Matthew Auld
Reviewed-by: Matt Roper
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/intel_gt.c | 133 --
drivers/gpu/drm/i915/gt/intel_gt.h | 17 ++-
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 9 +-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 7 +
drivers/gpu/drm/i915/i915_driver.c | 28 ++--
drivers/gpu/drm/i915/i915_drv.h | 6 +
drivers/gpu/drm/i915/intel_memory_region.h | 3 +
drivers/gpu/drm/i915/intel_uncore.c | 11 +-
drivers/gpu/drm/i915/intel_uncore.h | 3 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 13 +-
10 files changed, 184 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index ca875ba3e2a9d..cfac4a913642e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -29,7 +29,7 @@
#include "intel_uncore.h"
#include "shmem_utils.h"
-void __intel_gt_init_early(struct intel_gt *gt, struct
drm_i915_private *i915)
+static void __intel_gt_init_early(struct intel_gt *gt)
{
spin_lock_init(>irq_lock);
@@ -51,17 +51,23 @@ void __intel_gt_init_early(struct intel_gt *gt,
struct drm_i915_private *i915)
intel_rps_init_early(>rps);
}
-void intel_gt_init_early(struct intel_gt *gt, struct
drm_i915_private *i915)
+/* Preliminary initialization of Tile 0 */
+void intel_root_gt_init_early(struct drm_i915_private *i915)
{
+ struct intel_gt *gt = to_gt(i915);
+
gt->i915 = i915;
gt->uncore = >uncore;
+
+ __intel_gt_init_early(gt);
}
-int intel_gt_probe_lmem(struct intel_gt *gt)
+static int intel_gt_probe_lmem(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
+ unsigned int instance = gt->info.id;
+ int id = INTEL_REGION_LMEM_0 + instance;
struct intel_memory_region *mem;
- int id;
int err;
mem = intel_gt_setup_lmem(gt);
@@ -76,9 +82,8 @@ int intel_gt_probe_lmem(struct intel_gt *gt)
return err;
}
- id = INTEL_REGION_LMEM_0;
-
mem->id = id;
+ mem->instance = instance;
intel_memory_region_set_name(mem, "local%u", mem->instance);
@@ -807,16 +812,21 @@ void intel_gt_driver_release(struct intel_gt
*gt)
intel_gt_fini_hwconfig(gt);
}
-void intel_gt_driver_late_release(struct intel_gt *gt)
+void intel_gt_driver_late_release_all(struct drm_i915_private *i915)
{
+ struct intel_gt *gt;
+ unsigned int id;
+
/* We need to wait for inflight RCU frees to release their grip */
rcu_barrier();
- intel_uc_driver_late_release(>uc);
- intel_gt_fini_requests(gt);
- intel_gt_fini_reset(gt);
- intel_gt_fini_timelines(gt);
- intel_engines_free(gt);
+ for_each_gt(gt, i915, id) {
+ intel_uc_driver_late_release(>uc);
+ intel_gt_fini_requests(gt);
+ intel_gt_fini_reset(gt);
+ intel_gt_fini_timelines(gt);
+ intel_engines_free(gt);
+ }
}
/**
@@ -1013,6 +1023,105 @@ void intel_gt_report_steering(struct
drm_printer *p, struct intel_gt *gt,
}
}
+static int intel_gt_tile_setup(struct intel_gt *gt, phys_addr_t
phys_addr)
+{
+ int ret;
+
+ if (!gt_is_root(gt)) {
+ struct intel_uncore_mmio_debug *mmio_debug;
+ struct intel_uncore *uncore;
+
+ uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
+ if (!uncore)
+ return -ENOMEM;
+
+ mmio_debug = kzalloc(sizeof(*mmio_debug), GFP_KERNEL);
+ if (!mmio_debug) {
+ kfree(uncore);
+ return -ENOMEM;
+ }
+
+ gt->uncore = uncore;
+ gt->uncore->debug = mmio_debug;
+
+ __intel_gt_init_early(gt);
+ }
+
+ intel_uncore_init_early(gt->uncore, gt);
+
+ ret = intel_uncore_setup_mmio(gt->uncore, phys_addr);
+ if (ret)
+ return ret;
+
+ gt->phys_addr = phys_addr;
+
+ return 0;
+}
+
+static void
+intel_gt_tile_cleanup(struct intel_gt *gt)
+{
+ intel_uncore_cleanup_mmio(gt->uncore);
+
+ if
Re: [PATCH v4 11/15] drm/shmem-helper: Add generic memory shrinker
On 5/19/22 17:13, Daniel Vetter wrote: > On Thu, May 12, 2022 at 10:04:53PM +0300, Dmitry Osipenko wrote: >> On 5/12/22 20:04, Daniel Vetter wrote: >>> On Thu, 12 May 2022 at 13:36, Dmitry Osipenko >>> wrote: On 5/11/22 22:09, Daniel Vetter wrote: > On Wed, May 11, 2022 at 07:06:18PM +0300, Dmitry Osipenko wrote: >> On 5/11/22 16:09, Daniel Vetter wrote: >>> I'd like to ask you to reduce the scope of the patchset and build >>> the >>> shrinker only for virtio-gpu. I know that I first suggested to build >>> upon shmem helpers, but it seems that it's easier to do that in a >>> later >>> patchset. >> The first version of the VirtIO shrinker didn't support memory >> eviction. >> Memory eviction support requires page fault handler to be aware of >> the >> evicted pages, what should we do about it? The page fault handling >> is a >> part of memory management, hence to me drm-shmem is already kinda a >> MM. > Hm I still don't get that part, why does that also not go through the > shmem helpers? The drm_gem_shmem_vm_ops includes the page faults handling, it's a helper by itself that is used by DRM drivers. I could try to move all the shrinker logic to the VirtIO and re-invent virtio_gem_shmem_vm_ops, but what is the point of doing this for each driver if we could have it once and for all in the common drm-shmem code? Maybe I should try to factor out all the shrinker logic from drm-shmem into a new drm-shmem-shrinker that could be shared by drivers? Will you be okay with this option? >>> I think we're talking past each another a bit. I'm only bringing up the >>> purge vs eviction topic we discussed in the other subthread again. >> >> Thomas asked to move the whole shrinker code to the VirtIO driver and >> I's saying that this is not a great idea to me, or am I misunderstanding >> the Thomas' suggestion? Thomas? > > I think it was just me creating a confusion here. > > fwiw I do also think that shrinker in shmem helpers makes sense, just in > case that was also lost in confusion. Okay, good that we're on the same page now. > I'm still confused why drivers need to know the difference > between evition and purging. Or maybe I'm confused again. Example: If userspace uses IOV addresses, then these addresses must be kept reserved while buffer is evicted. If BO is purged, then we don't need to retain the IOV space allocated for the purged BO. >>> Yeah but is that actually needed by anyone? If userspace fails to >>> allocate >>> another bo because of lack of gpu address space then it's very easy to >>> handle that: >>> >>> 1. Make a rule that "out of gpu address space" gives you a special errno >>> code like ENOSPC >>> >>> 2. If userspace gets that it walks the list of all buffers it marked as >>> purgeable and nukes them (whether they have been evicted or not). Then >>> it >>> retries the bo allocation. >>> >>> Alternatively you can do step 2 also directly from the bo alloc ioctl in >>> step 1. Either way you clean up va space, and actually a lot more (you >>> potentially nuke all buffers marked as purgeable, not just the ones that >>> have been purged already) and only when va cleanup is actually needed >>> >>> Trying to solve this problem at eviction time otoh means: >>> - we have this difference between eviction and purging >>> - it's still not complete, you still need to glue step 2 above into your >>> driver somehow, and once step 2 above is glued in doing additional >>> cleanup in the purge function is just duplicated logic >>> >>> So at least in my opinion this isn't the justification we need. And we >>> should definitely not just add that complication "in case, for the >>> future", if we don't have a real need right now. Adding it later on is >>> easy, removing it later on because it just gets in the way and confuses >>> is >>> much harder. >> >> The IOVA space is only one example. >> >> In case of the VirtIO driver, we may have two memory allocation for a >> BO. One is the shmem allcation in guest and the other is in host's vram. >> If we will only release the guest's memory on purge, then the vram will >> remain allocated until BO is destroyed, which unnecessarily sub-optimal. > > Hm but why don't you just nuke the memory on the host side too when you > evict? Allowing the guest memory to be swapped out while keeping the host > memory allocation alive also doesn't make a lot of sense for me. Both can > be recreated (I guess at least?) on swap-in.
RE: [PATCH 09/11] drm/ttm: audit bo->resource usage
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, May 19, 2022 5:55 AM
>To: intel-...@lists.freedesktop.org
>Cc: matthew.william.a...@gmail.com; Christian König
>; dri-devel@lists.freedesktop.org
>Subject: [PATCH 09/11] drm/ttm: audit bo->resource usage
>
>Allow BOs to exist without backing store.
Took me a while to figure out that only the last line is related to this commit
message.
Could you add something like:
Refactor usage information.
Allow BOs to exist without backing store.
?
Would make this patch a little easier to decipher.
M
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/ttm/ttm_bo.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index 2b01cb30694a..a55564c8b57c 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -117,12 +117,13 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
> struct ttm_operation_ctx *ctx,
> struct ttm_place *hop)
> {
>- struct ttm_resource_manager *old_man, *new_man;
> struct ttm_device *bdev = bo->bdev;
>+ bool old_use_tt, new_use_tt;
> int ret;
>
>- old_man = ttm_manager_type(bdev, bo->resource->mem_type);
>- new_man = ttm_manager_type(bdev, mem->mem_type);
>+ old_use_tt = bo->resource &&
>+ ttm_manager_type(bdev, bo->resource->mem_type)-
>>use_tt;
>+ new_use_tt = ttm_manager_type(bdev, mem->mem_type)->use_tt;
>
> ttm_bo_unmap_virtual(bo);
>
>@@ -130,11 +131,11 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
>* Create and bind a ttm if required.
>*/
>
>- if (new_man->use_tt) {
>+ if (new_use_tt) {
> /* Zero init the new TTM structure if the old location should
>* have used one as well.
>*/
>- ret = ttm_tt_create(bo, old_man->use_tt);
>+ ret = ttm_tt_create(bo, old_use_tt);
> if (ret)
> goto out_err;
>
>@@ -160,8 +161,7 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
> return 0;
>
> out_err:
>- new_man = ttm_manager_type(bdev, bo->resource->mem_type);
>- if (!new_man->use_tt)
>+ if (!old_use_tt)
> ttm_bo_tt_destroy(bo);
>
> return ret;
>@@ -898,7 +898,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
> /*
>* Check whether we need to move buffer.
>*/
>- if (!ttm_resource_compat(bo->resource, placement)) {
>+ if (!bo->resource || !ttm_resource_compat(bo->resource,
>placement)) {
> ret = ttm_bo_move_buffer(bo, placement, ctx);
> if (ret)
> return ret;
>--
>2.25.1
Re: [PATCH v4 11/15] drm/shmem-helper: Add generic memory shrinker
On Thu, May 12, 2022 at 10:04:53PM +0300, Dmitry Osipenko wrote: > On 5/12/22 20:04, Daniel Vetter wrote: > > On Thu, 12 May 2022 at 13:36, Dmitry Osipenko > > wrote: > >> > >> On 5/11/22 22:09, Daniel Vetter wrote: > >>> On Wed, May 11, 2022 at 07:06:18PM +0300, Dmitry Osipenko wrote: > On 5/11/22 16:09, Daniel Vetter wrote: > > I'd like to ask you to reduce the scope of the patchset and build > > the > > shrinker only for virtio-gpu. I know that I first suggested to build > > upon shmem helpers, but it seems that it's easier to do that in a > > later > > patchset. > The first version of the VirtIO shrinker didn't support memory > eviction. > Memory eviction support requires page fault handler to be aware of > the > evicted pages, what should we do about it? The page fault handling > is a > part of memory management, hence to me drm-shmem is already kinda a > MM. > >>> Hm I still don't get that part, why does that also not go through the > >>> shmem helpers? > >> The drm_gem_shmem_vm_ops includes the page faults handling, it's a > >> helper by itself that is used by DRM drivers. > >> > >> I could try to move all the shrinker logic to the VirtIO and re-invent > >> virtio_gem_shmem_vm_ops, but what is the point of doing this for each > >> driver if we could have it once and for all in the common drm-shmem > >> code? > >> > >> Maybe I should try to factor out all the shrinker logic from drm-shmem > >> into a new drm-shmem-shrinker that could be shared by drivers? Will you > >> be okay with this option? > > I think we're talking past each another a bit. I'm only bringing up the > > purge vs eviction topic we discussed in the other subthread again. > > Thomas asked to move the whole shrinker code to the VirtIO driver and > I's saying that this is not a great idea to me, or am I misunderstanding > the Thomas' suggestion? Thomas? > >>> > >>> I think it was just me creating a confusion here. > >>> > >>> fwiw I do also think that shrinker in shmem helpers makes sense, just in > >>> case that was also lost in confusion. > >> > >> Okay, good that we're on the same page now. > >> > >>> I'm still confused why drivers need to know the difference > >>> between evition and purging. Or maybe I'm confused again. > >> Example: > >> > >> If userspace uses IOV addresses, then these addresses must be kept > >> reserved while buffer is evicted. > >> > >> If BO is purged, then we don't need to retain the IOV space allocated > >> for the purged BO. > > Yeah but is that actually needed by anyone? If userspace fails to > > allocate > > another bo because of lack of gpu address space then it's very easy to > > handle that: > > > > 1. Make a rule that "out of gpu address space" gives you a special errno > > code like ENOSPC > > > > 2. If userspace gets that it walks the list of all buffers it marked as > > purgeable and nukes them (whether they have been evicted or not). Then > > it > > retries the bo allocation. > > > > Alternatively you can do step 2 also directly from the bo alloc ioctl in > > step 1. Either way you clean up va space, and actually a lot more (you > > potentially nuke all buffers marked as purgeable, not just the ones that > > have been purged already) and only when va cleanup is actually needed > > > > Trying to solve this problem at eviction time otoh means: > > - we have this difference between eviction and purging > > - it's still not complete, you still need to glue step 2 above into your > > driver somehow, and once step 2 above is glued in doing additional > > cleanup in the purge function is just duplicated logic > > > > So at least in my opinion this isn't the justification we need. And we > > should definitely not just add that complication "in case, for the > > future", if we don't have a real need right now. Adding it later on is > > easy, removing it later on because it just gets in the way and confuses > > is > > much harder. > > The IOVA space is only one example. > > In case of the VirtIO driver, we may have two memory allocation for a > BO. One is the shmem allcation in guest and the other is in host's vram. > If we will only release the guest's memory on purge, then the vram will > remain allocated until BO is destroyed, which unnecessarily sub-optimal. > >>> > >>> Hm but why don't you just nuke the memory on the host side too when you > >>> evict? Allowing the guest memory to be swapped out while keeping the host > >>> memory allocation alive also doesn't make a lot of sense for me. Both can > >>> be recreated (I guess at least?) on swap-in. > >> > >> Shouldn't be very doable or at least
RE: [PATCH 06/11] drm/ttm: rename and cleanup ttm_bo_init_reserved
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, May 19, 2022 5:55 AM
>To: intel-...@lists.freedesktop.org
>Cc: matthew.william.a...@gmail.com; Christian König
>; dri-devel@lists.freedesktop.org
>Subject: [PATCH 06/11] drm/ttm: rename and cleanup ttm_bo_init_reserved
>
>Rename ttm_bo_init_reserved to ttm_bo_init_validate since that better
>matches what the function is actually doing.
>
>Remove the unused size parameter, move the function's kerneldoc to the
>implementation and cleanup the whole error handling.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
> drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 5 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
> drivers/gpu/drm/qxl/qxl_object.c | 2 +-
> drivers/gpu/drm/radeon/radeon_object.c | 2 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 92 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 12 ++-
> include/drm/ttm/ttm_bo_api.h | 44 +--
> 9 files changed, 75 insertions(+), 88 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>index 5444515c1476..116c8d31e646 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>@@ -590,7 +590,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
> if (!bp->destroy)
> bp->destroy = _bo_destroy;
>
>- r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, bp-
>>type,
>+ r = ttm_bo_init_validate(>mman.bdev, >tbo, bp->type,
>>placement, page_align, , NULL,
>bp->resv, bp->destroy);
> if (unlikely(r != 0))
>diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>b/drivers/gpu/drm/drm_gem_vram_helper.c
>index 7449cbc2f925..73e91baccea0 100644
>--- a/drivers/gpu/drm/drm_gem_vram_helper.c
>+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>@@ -226,7 +226,7 @@ struct drm_gem_vram_object
>*drm_gem_vram_create(struct drm_device *dev,
>* A failing ttm_bo_init will call ttm_buffer_object_destroy
>* to release gbo->bo.base and kfree gbo.
>*/
>- ret = ttm_bo_init_reserved(bdev, >bo, size,
>ttm_bo_type_device,
>+ ret = ttm_bo_init_validate(bdev, >bo, ttm_bo_type_device,
> >placement, pg_align, , NULL,
>NULL,
> ttm_buffer_object_destroy);
> if (ret)
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>index 4c25d9b2f138..253188da91eb 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>@@ -1229,9 +1229,8 @@ int __i915_gem_ttm_object_init(struct
>intel_memory_region *mem,
>* Similarly, in delayed_destroy, we can't call ttm_bo_put()
>* until successful initialization.
>*/
>- ret = ttm_bo_init_reserved(>bdev, i915_gem_to_ttm(obj),
>size,
>- bo_type, _sys_placement,
>- page_size >> PAGE_SHIFT,
>+ ret = ttm_bo_init_validate(>bdev, i915_gem_to_ttm(obj),
>bo_type,
>+ _sys_placement, page_size >>
>PAGE_SHIFT,
> , NULL, NULL, i915_ttm_bo_destroy);
> if (ret)
> return i915_ttm_err_to_gem(ret);
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 858b9382036c..666941804297 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -308,7 +308,7 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size,
>int align, u32 domain,
> nouveau_bo_placement_set(nvbo, domain, 0);
> INIT_LIST_HEAD(>io_reserve_lru);
>
>- ret = ttm_bo_init_reserved(nvbo->bo.bdev, >bo, size, type,
>+ ret = ttm_bo_init_validate(nvbo->bo.bdev, >bo, type,
> >placement, align >> PAGE_SHIFT,
>,
> sg, robj, nouveau_bo_del_ttm);
> if (ret) {
>diff --git a/drivers/gpu/drm/qxl/qxl_object.c
>b/drivers/gpu/drm/qxl/qxl_object.c
>index b42a657e4c2f..da3f76f508ea 100644
>--- a/drivers/gpu/drm/qxl/qxl_object.c
>+++ b/drivers/gpu/drm/qxl/qxl_object.c
>@@ -141,7 +141,7 @@ int qxl_bo_create(struct qxl_device *qdev, unsigned
>long size,
> qxl_ttm_placement_from_domain(bo, domain);
>
> bo->tbo.priority = priority;
>- r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
>+ r = ttm_bo_init_validate(>mman.bdev, >tbo, type,
>>placement, 0, , NULL, NULL,
>_ttm_bo_destroy);
> if (unlikely(r != 0)) {
>diff --git a/drivers/gpu/drm/radeon/radeon_object.c
>b/drivers/gpu/drm/radeon/radeon_object.c
>index 1d414ff4ab0c..550ca056b3ac 100644
>---
[PATCH v3] dt-bindings: display: bridge: sil, sii9022: Convert to json-schema
Convert the Silicon Image sii902x HDMI bridge Device Tree binding
documentation to json-schema.
Add missing sil,sii9022-cpi and sil,sii9022-tpi compatible values.
Signed-off-by: Geert Uytterhoeven
---
v3:
- Add comments clarifying CPI/TPI,
- Improve wording,
- Drop port@2,
- Add port descriptions,
- Add schema references to individual ports.
v2:
- Rework sil,i2s-data-lanes,
- Add schema reference to ports.
---
.../bindings/display/bridge/sii902x.txt | 78 ---
.../bindings/display/bridge/sil,sii9022.yaml | 131 ++
2 files changed, 131 insertions(+), 78 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/bridge/sii902x.txt
create mode 100644
Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
deleted file mode 100644
index 3bc760cc31cbbeee..
--- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-sii902x HDMI bridge bindings
-
-Required properties:
- - compatible: "sil,sii9022"
- - reg: i2c address of the bridge
-
-Optional properties:
- - interrupts: describe the interrupt line used to inform the host
- about hotplug events.
- - reset-gpios: OF device-tree gpio specification for RST_N pin.
- - iovcc-supply: I/O Supply Voltage (1.8V or 3.3V)
- - cvcc12-supply: Digital Core Supply Voltage (1.2V)
-
- HDMI audio properties:
- - #sound-dai-cells: <0> or <1>. <0> if only i2s or spdif pin
- is wired, <1> if the both are wired. HDMI audio is
- configured only if this property is found.
- - sil,i2s-data-lanes: Array of up to 4 integers with values of 0-3
- Each integer indicates which i2s pin is connected to which
- audio fifo. The first integer selects i2s audio pin for the
- first audio fifo#0 (HDMI channels 1&2), second for fifo#1
- (HDMI channels 3&4), and so on. There is 4 fifos and 4 i2s
- pins (SD0 - SD3). Any i2s pin can be connected to any fifo,
- but there can be no gaps. E.g. an i2s pin must be mapped to
- fifo#0 and fifo#1 before mapping a channel to fifo#2. Default
- value is <0>, describing SD0 pin beiging routed to hdmi audio
- fifo #0.
- - clocks: phandle and clock specifier for each clock listed in
- the clock-names property
- - clock-names: "mclk"
- Describes SII902x MCLK input. MCLK can be used to produce
- HDMI audio CTS values. This property follows
- Documentation/devicetree/bindings/clock/clock-bindings.txt
- consumer binding.
-
- If HDMI audio is configured the sii902x device becomes an I2S
- and/or spdif audio codec component (e.g a digital audio sink),
- that can be used in configuring a full audio devices with
- simple-card or audio-graph-card binding. See their binding
- documents on how to describe the way the sii902x device is
- connected to the rest of the audio system:
- Documentation/devicetree/bindings/sound/simple-card.yaml
- Documentation/devicetree/bindings/sound/audio-graph-card.yaml
- Note: In case of the audio-graph-card binding the used port
- index should be 3.
-
-Optional subnodes:
- - video input: this subnode can contain a video input port node
- to connect the bridge to a display controller output (See this
- documentation [1]).
-
-[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
-
-Example:
- hdmi-bridge@39 {
- compatible = "sil,sii9022";
- reg = <0x39>;
- reset-gpios = < 1 0>;
- iovcc-supply = <_hdmi>;
- cvcc12-supply = <_hdmi>;
-
- #sound-dai-cells = <0>;
- sil,i2s-data-lanes = < 0 1 2 >;
- clocks = <>;
- clock-names = "mclk";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- bridge_in: endpoint {
- remote-endpoint = <_out>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml
b/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml
new file mode 100644
index ..5a69547ad3d79667
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml
@@ -0,0 +1,131 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/sil,sii9022.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title:
Re: [PATCH] drm/bridge: fix anx6345 power up sequence
On Wed, 18 May 2022 09:53:58 -0700 Vasily Khoruzhick wrote: > On Thu, Apr 28, 2022 at 8:58 AM Torsten Duwe wrote: > > power on the eDP bridge? Could there be any leftovers from that > > mechanism? I use a hacked-up U-Boot with a procedure similar to the > > kernel driver as fixed by this change. I was asking because I recall an ugly hack in some ATF code to power up the chip correctly. Did you patch ATF, and maybe call functions of it at runtime? > > > > But the main question is: does this patch in any way worsen the > > situation on the pinebook? > > I don't think it worsens anything, but according to the datasheet the > change makes no sense. Could you try increasing T2 instead of changing > the power sequence? According to the datasheet, there is also T3, I realise now. The diagram talks about "System Clock", but both Teres and Pinebook have a passive resonator circuit there. Correct me if I'm wrong, but without chip power, there is little to resonate. What if that driving clock circuit is powered by Vdd25? Maybe the earlier provision of 2V5 is enough for Teres' Q4, but Pinebook X4 takes even longer? The start-up times can be in the range of milliseconds. Torsten
RE: [PATCH 04/11] drm/ttm: move default BO destructor into VMWGFX
>-Original Message- >From: dri-devel On Behalf Of >Christian König >Sent: Thursday, May 19, 2022 5:55 AM >To: intel-...@lists.freedesktop.org >Cc: matthew.william.a...@gmail.com; Christian König >; dri-devel@lists.freedesktop.org >Subject: [PATCH 04/11] drm/ttm: move default BO destructor into VMWGFX > >It's the only driver using this. > >Signed-off-by: Christian König >--- > drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 3 +++ > 1 file changed, 3 insertions(+) > >diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >index 85a66014c2b6..c4f376d5e1d0 100644 >--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >@@ -462,6 +462,9 @@ int vmw_bo_create(struct vmw_private *vmw, > return -ENOMEM; > } > >+ if (!bo_free) >+ bo_free = vmw_bo_default_destroy; >+ vmw_bo_init has a WARN_ON if this is NULL. Also, all of the callers use vmw_bo_bo_free() or vmw_gem_destroy(). Both of those unmap, release and then free the object. It doesn't look like vmw_bo_default_destroy does this work. Is this the right "default" path? Or should the WARN_ON be used to check for this? M > ret = vmw_bo_init(vmw, *p_bo, size, > placement, interruptible, pin, > bo_free); >-- >2.25.1
RE: [PATCH 02/11] drm/nouveau: switch over to ttm_bo_init_reserved
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, May 19, 2022 5:55 AM
>To: intel-...@lists.freedesktop.org
>Cc: matthew.william.a...@gmail.com; Christian König
>; dri-devel@lists.freedesktop.org
>Subject: [PATCH 02/11] drm/nouveau: switch over to ttm_bo_init_reserved
>
>Use the new interface instead.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 05076e530e7d..858b9382036c 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -302,19 +302,23 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64
>size, int align, u32 domain,
> struct sg_table *sg, struct dma_resv *robj)
> {
> int type = sg ? ttm_bo_type_sg : ttm_bo_type_device;
>+ struct ttm_operation_ctx ctx = { false, false };
> int ret;
>
> nouveau_bo_placement_set(nvbo, domain, 0);
> INIT_LIST_HEAD(>io_reserve_lru);
>
>- ret = ttm_bo_init(nvbo->bo.bdev, >bo, size, type,
>->placement, align >> PAGE_SHIFT, false, sg,
>-robj, nouveau_bo_del_ttm);
>+ ret = ttm_bo_init_reserved(nvbo->bo.bdev, >bo, size, type,
>+ >placement, align >> PAGE_SHIFT,
>,
>+ sg, robj, nouveau_bo_del_ttm);
> if (ret) {
> /* ttm will call nouveau_bo_del_ttm if it fails.. */
> return ret;
> }
>
>+ if (!robj)
>+ ttm_bo_unreserve(>bo);
>+
Ok, this implies that patch 1 does have an issue.
I see this usage in patch 1, 2, and 3. Would it make sense to move this
_unreserve to ttm_bo_init_reserved?
Mike
> return 0;
> }
>
>--
>2.25.1
Re: [PATCH 01/11] drm/radeon: switch over to ttm_bo_init_reserved
Am 19.05.22 um 14:54 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Christian König
Sent: Thursday, May 19, 2022 5:55 AM
To: intel-...@lists.freedesktop.org
Cc: matthew.william.a...@gmail.com; Christian König
; dri-devel@lists.freedesktop.org
Subject: [PATCH 01/11] drm/radeon: switch over to ttm_bo_init_reserved
Use the new interface instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_object.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 6c4a6802ca96..1d414ff4ab0c 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -133,9 +133,12 @@ int radeon_bo_create(struct radeon_device *rdev,
struct dma_resv *resv,
struct radeon_bo **bo_ptr)
{
- struct radeon_bo *bo;
- enum ttm_bo_type type;
unsigned long page_align = roundup(byte_align, PAGE_SIZE) >>
PAGE_SHIFT;
+
+ /* Kernel allocation are uninterruptible */
+ struct ttm_operation_ctx ctx = { !kernel, false };
+ enum ttm_bo_type type;
+ struct radeon_bo *bo;
int r;
size = ALIGN(size, PAGE_SIZE);
@@ -200,11 +203,13 @@ int radeon_bo_create(struct radeon_device *rdev,
#endif
radeon_ttm_placement_from_domain(bo, domain);
- /* Kernel allocation are uninterruptible */
down_read(>pm.mclk_lock);
- r = ttm_bo_init(>mman.bdev, >tbo, size, type,
- >placement, page_align, !kernel, sg, resv,
- _ttm_bo_destroy);
+ r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
+>placement, page_align, , sg, resv,
+_ttm_bo_destroy);
+if (!r)
+ ttm_bo_unreserve(>tbo);
+
Hi Christian,
I am not understanding this unreserve.
The original code path does not have it. It looks like tt_bo_init will do
this, but only if !resv.
Should this be:
if (!resv)
ttm_bo_unreserve(>tbo);
Ah, yes good point. That's a bug.
Thanks,
Christian.
?
M
up_read(>pm.mclk_lock);
if (unlikely(r != 0)) {
return r;
--
2.25.1
Re: [PATCH 04/11] drm/r128: Fix undefined behavior due to shift overflowing the constant
On Mon, Apr 25, 2022 at 11:46:53AM -0700, Randy Dunlap wrote: > > > On 4/5/22 08:15, Borislav Petkov wrote: > > From: Borislav Petkov > > > > Fix: > > > > drivers/gpu/drm/r128/r128_cce.c: In function ‘r128_do_init_cce’: > > drivers/gpu/drm/r128/r128_cce.c:417:2: error: case label does not reduce > > to an integer constant > > case R128_PM4_64BM_64VCBM_64INDBM: > > ^~~~ > > drivers/gpu/drm/r128/r128_cce.c:418:2: error: case label does not reduce > > to an integer constant > > case R128_PM4_64PIO_64VCPIO_64INDPIO: > > ^~~~ > > > > See https://lore.kernel.org/r/ykwq6%2btih8gqp...@zn.tnic for the gory > > details as to why it triggers with older gccs only. > > > > Signed-off-by: Borislav Petkov > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Alex Deucher > > Cc: dri-devel@lists.freedesktop.org > > Reviewed-by: Randy Dunlap Pushed to drm-misc-next, thanks for patch -Daniel > > Thanks. > > > --- > > drivers/gpu/drm/r128/r128_drv.h | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/r128/r128_drv.h > > b/drivers/gpu/drm/r128/r128_drv.h > > index 2e1bc01aa5c9..970e192b0d51 100644 > > --- a/drivers/gpu/drm/r128/r128_drv.h > > +++ b/drivers/gpu/drm/r128/r128_drv.h > > @@ -300,8 +300,8 @@ extern long r128_compat_ioctl(struct file *filp, > > unsigned int cmd, > > # define R128_PM4_64PIO_128INDBM (5 << 28) > > # define R128_PM4_64BM_128INDBM (6 << 28) > > # define R128_PM4_64PIO_64VCBM_64INDBM(7 << 28) > > -# define R128_PM4_64BM_64VCBM_64INDBM (8 << 28) > > -# define R128_PM4_64PIO_64VCPIO_64INDPIO (15 << 28) > > +# define R128_PM4_64BM_64VCBM_64INDBM (8U << 28) > > +# define R128_PM4_64PIO_64VCPIO_64INDPIO (15U << 28) > > # define R128_PM4_BUFFER_CNTL_NOUPDATE(1 << 27) > > > > #define R128_PM4_BUFFER_WM_CNTL0x0708 > > -- > ~Randy -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH V2 0/3] DSI host and peripheral initialisation ordering
Hi Marek and Andrzej On Wed, 18 May 2022 at 23:53, Andrzej Hajda wrote: > > > > On 18.05.2022 16:05, Marek Szyprowski wrote: > > Hi Dave, > > > > On 11.05.2022 17:47, Dave Stevenson wrote: > >> On Wed, 11 May 2022 at 15:58, Marek Szyprowski > >> wrote: > >>> On 05.04.2022 13:43, Dave Stevenson wrote: > On Fri, 18 Mar 2022 at 12:25, Dave Stevenson > wrote: > > On Fri, 4 Mar 2022 at 15:18, Dave Stevenson > > wrote: > >> Hi All > > A gentle ping on this series. Any comments on the approach? > > Thanks. > I realise the merge window has just closed and therefore folks have > been busy, but no responses on this after a month? > > Do I give up and submit a patch to document that DSI is broken and no > one cares? > >>> Thanks for pointing this patchset in the 'drm: bridge: Add Samsung MIPI > >>> DSIM bridge' thread, otherwise I would miss it since I'm not involved > >>> much in the DRM development. > >>> > >>> This resolves most of the issues in the Exynos DSI and its recent > >>> conversion to the drm bridge framework. I've added the needed > >>> prepare_upstream_first flags to the panels and everything works fine > >>> without the bridge chain order hacks. > >>> > >>> Feel free to add: > >>> > >>> Tested-by: Marek Szyprowski > >> Thanks for testing it. I was almost at the stage of abandoning the patch > >> set. > >> > >>> The only remaining thing to resolve is the moment of enabling DSI host. > >>> The proper sequence is: > >>> > >>> 1. host power on, 2. device power on, 3. host init, 4. device init, 5. > >>> video enable. > >>> > >>> #1 is done in dsi's pre_enable, #2 is done in panel's prepare. #3 was so > >>> far done in the first host transfer call, which usually happens in > >>> panel's prepare, then the #4 happens. Then video enable is done in the > >>> enable callbacks. > >> What's your definition of host power on and host init here? What state > >> are you defining the DSI interface to be in after each operation? > > Well, lets start from the point that I'm not a DSI specialist nor I'm > > not the exynos-dsi author. I just played a bit with the code trying to > > restore proper driver operation on the various Exynos based boards I have. Is there any such thing as a DSI specialist? It seems to have many nasty corners that very few can really claim to fully understand (I don't claim to be an expert in it!). > > By the host/device power on I mean enabling their power regulators. By > > host init I mean executing the samsung_dsim_init() function, which > > basically sets the lp-11 state if I understand it right. > > > > > >>> Jagan wants to move it to the dsi host pre_enable() to let it work with > >>> DSI bridges controlled over different interfaces > >>> (https://lore.kernel.org/all/20220504114021.33265-6-ja...@amarulasolutions.com/ > >>> ). > >> I think I'm in agreement with Jagan. > >> As documented in patch 4/4: > >> + * A DSI host should keep the PHY powered down until the pre_enable > >> operation is > >> + * called. All lanes are in an undefined idle state up to this point, and > >> it > >> + * must not be assumed that it is LP-11. > >> + * pre_enable should initialise the PHY, set the data lanes to LP-11, and > >> the > >> + * clock lane to either LP-11 or HS depending on the mode_flag > >> + * %MIPI_DSI_CLOCK_NON_CONTINUOUS. > > Right, this theory makes sense. > > > > However Exynos DSI for some reasons did the host initialization in the > > first call of the samsung_dsim_host_transfer(). > > It was a way to fit exynos DSI order of initialization to the frameworks > present at the time it was written: > exynos_dsi was an drm_encoder, and it was connected to drm_panel (DSI > controlled panel). > 1. In exynos_dsi_enable host was powered on then drm_panel_prepare was > called. > 2. drm_panel_prepare called .prepare callback of the panel, which > powered on the panel and then requested dsi transfers to initialize panel. > 3. 1st dsi transfer performed dsi host init (LP-11), after that all > transfers started by panel performed panel initialization. > 4. after that control goes back to exynos_dsi_enable. > 5. exynos_dsi_enable starts video transfer and notify panel about it via > drm_panel_enable. > 6. .enable callback of the panel starts displaying frames (after some > delay). > > This construction allowed to keep proper order of hw initialization: > host power on, panel power on, host init, panel init, start video > transmission, start display frames. > Almost all elements of this sequence are enforced by DSI specification > (at least for devices controlled via dsi). > The only thing which I am not sure is placement of "panel power on". It > does not seem to be a part of DSI spec, but I am not 100% sure. > It could be specific to platform (mis)configuration (regulators, level > shifters, ...), or just dsi host init sequence tries to do too much. > I wonder if dropping checking stop state in exynos_dsi wouldn't solve > the mystery
RE: [PATCH 01/11] drm/radeon: switch over to ttm_bo_init_reserved
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, May 19, 2022 5:55 AM
>To: intel-...@lists.freedesktop.org
>Cc: matthew.william.a...@gmail.com; Christian König
>; dri-devel@lists.freedesktop.org
>Subject: [PATCH 01/11] drm/radeon: switch over to ttm_bo_init_reserved
>
>Use the new interface instead.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/radeon/radeon_object.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
>diff --git a/drivers/gpu/drm/radeon/radeon_object.c
>b/drivers/gpu/drm/radeon/radeon_object.c
>index 6c4a6802ca96..1d414ff4ab0c 100644
>--- a/drivers/gpu/drm/radeon/radeon_object.c
>+++ b/drivers/gpu/drm/radeon/radeon_object.c
>@@ -133,9 +133,12 @@ int radeon_bo_create(struct radeon_device *rdev,
>struct dma_resv *resv,
>struct radeon_bo **bo_ptr)
> {
>- struct radeon_bo *bo;
>- enum ttm_bo_type type;
> unsigned long page_align = roundup(byte_align, PAGE_SIZE) >>
>PAGE_SHIFT;
>+
>+ /* Kernel allocation are uninterruptible */
>+ struct ttm_operation_ctx ctx = { !kernel, false };
>+ enum ttm_bo_type type;
>+ struct radeon_bo *bo;
> int r;
>
> size = ALIGN(size, PAGE_SIZE);
>@@ -200,11 +203,13 @@ int radeon_bo_create(struct radeon_device *rdev,
> #endif
>
> radeon_ttm_placement_from_domain(bo, domain);
>- /* Kernel allocation are uninterruptible */
> down_read(>pm.mclk_lock);
>- r = ttm_bo_init(>mman.bdev, >tbo, size, type,
>- >placement, page_align, !kernel, sg, resv,
>- _ttm_bo_destroy);
>+ r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
>+ >placement, page_align, , sg, resv,
>+ _ttm_bo_destroy);
>+if (!r)
>+ ttm_bo_unreserve(>tbo);
>+
Hi Christian,
I am not understanding this unreserve.
The original code path does not have it. It looks like tt_bo_init will do
this, but only if !resv.
Should this be:
if (!resv)
ttm_bo_unreserve(>tbo);
?
M
> up_read(>pm.mclk_lock);
> if (unlikely(r != 0)) {
> return r;
>--
>2.25.1
[PATCH v3] drm/bridge: tc358767: Make sure Refclk clock are enabled
The Refclk may be supplied by SoC clock output instead of crystal
oscillator, make sure the clock are enabled before any other action
is performed with the bridge chip, otherwise it may either fail to
operate at all, or miss reset GPIO toggle.
Reviewed-by: Lucas Stach
Fixes: 7caff0fc4296e ("drm/bridge: tc358767: Add DPI to eDP bridge driver")
Signed-off-by: Marek Vasut
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Marek Vasut
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Sam Ravnborg
---
V2: - Use devm_add_action_or_reset() to add clock disable hook instead
of wall of failpath
V3: - Swap devm_add_action_or_reset()/clk_prepare_enable() to avoid
clock disable imbalance
- Add RB from Lucas
---
drivers/gpu/drm/bridge/tc358767.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 45ea829d56601..7d4035ca26b19 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -2033,6 +2033,13 @@ static int tc_probe_bridge_endpoint(struct tc_data *tc)
return -EINVAL;
}
+static void tc_clk_disable(void *data)
+{
+ struct clk *refclk = data;
+
+ clk_disable_unprepare(refclk);
+}
+
static int tc_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
struct device *dev = >dev;
@@ -2049,6 +2056,22 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
if (ret)
return ret;
+ tc->refclk = devm_clk_get(dev, "ref");
+ if (IS_ERR(tc->refclk)) {
+ ret = PTR_ERR(tc->refclk);
+ dev_err(dev, "Failed to get refclk: %d\n", ret);
+ return ret;
+ }
+
+ clk_prepare_enable(tc->refclk);
+
+ ret = devm_add_action_or_reset(dev, tc_clk_disable, tc->refclk);
+ if (ret)
+ return ret;
+
+ /* tRSTW = 100 cycles , at 13 MHz that is ~7.69 us */
+ usleep_range(10, 15);
+
/* Shut down GPIO is optional */
tc->sd_gpio = devm_gpiod_get_optional(dev, "shutdown", GPIOD_OUT_HIGH);
if (IS_ERR(tc->sd_gpio))
@@ -2069,13 +2092,6 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
usleep_range(5000, 1);
}
- tc->refclk = devm_clk_get(dev, "ref");
- if (IS_ERR(tc->refclk)) {
- ret = PTR_ERR(tc->refclk);
- dev_err(dev, "Failed to get refclk: %d\n", ret);
- return ret;
- }
-
tc->regmap = devm_regmap_init_i2c(client, _regmap_config);
if (IS_ERR(tc->regmap)) {
ret = PTR_ERR(tc->regmap);
--
2.35.1
Re: [syzbot] WARNING in __dma_map_sg_attrs
On Tue, 8 Feb 2022 at 13:26, Daniel Vetter wrote: > > On Sat, Feb 05, 2022 at 12:18:23PM -0800, syzbot wrote: > > syzbot has found a reproducer for the following issue on: > > > > HEAD commit:0457e5153e0e Merge tag 'for-linus' of git://git.kernel.org.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=11b2637c70 > > kernel config: https://syzkaller.appspot.com/x/.config?x=6f043113811433a5 > > dashboard link: https://syzkaller.appspot.com/bug?extid=10e27961f4da37c443b2 > > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils > > for Debian) 2.35.2 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11c6554270 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1163f48070 > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+10e27961f4da37c44...@syzkaller.appspotmail.com > > Adding Gerd, since this seems to blow up in udmabuf. > > I wonder why syzbot didn't figure this out, since it seems to have > correctly added both dma-api and dma-buf people. Just not the maintainer > for the begin_cpu_udmabuf function in the middle of the backtrace? Hi Daniel, syzbot selects only 1 file to get maintainers. Do you suggest using all files in the stack trace? I think it may lead to too many developers CCed since there can be something like 20 files including something from scheduler, arch, fs, etc. > > [ cut here ] > > WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 > > __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 > > Modules linked in: > > CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted > > 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 > > Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 > > b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 > > e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 > > RSP: 0018:c90002a07d68 EFLAGS: 00010293 > > RAX: RBX: RCX: > > RDX: 88807e25e2c0 RSI: 81649e91 RDI: 88801b848408 > > RBP: 88801b848000 R08: 0002 R09: 88801d86c74f > > R10: 81649d72 R11: 0001 R12: 0002 > > R13: 88801d86c680 R14: 0001 R15: > > FS: 56e30300() GS:8880b9d0() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 20cc CR3: 1d74a000 CR4: 003506e0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > Call Trace: > > > > dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 > > get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 > > begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 > > dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 > > dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 > > vfs_ioctl fs/ioctl.c:51 [inline] > > __do_sys_ioctl fs/ioctl.c:874 [inline] > > __se_sys_ioctl fs/ioctl.c:860 [inline] > > __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > RIP: 0033:0x7f62fcf530f9 > > Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > > ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 > > RSP: 002b:7ffe3edab9b8 EFLAGS: 0246 ORIG_RAX: 0010 > > RAX: ffda RBX: RCX: 7f62fcf530f9 > > RDX: 2200 RSI: 40086200 RDI: 0006 > > RBP: 7f62fcf170e0 R08: R09: > > R10: R11: 0246 R12: 7f62fcf17170 > > R13: R14: R15: > > > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/YgJhjdAbRHdnCZ4T%40phenom.ffwll.local.
Re: [PATCH v2] drm/bridge: tc358767: Make sure Refclk clock are enabled
On Thu, May 19, 2022 at 01:47:51PM +0200, Marek Vasut wrote:
> The Refclk may be supplied by SoC clock output instead of crystal
> oscillator, make sure the clock are enabled before any other action
> is performed with the bridge chip, otherwise it may either fail to
> operate at all, or miss reset GPIO toggle.
>
> Fixes: 7caff0fc4296e ("drm/bridge: tc358767: Add DPI to eDP bridge driver")
> Signed-off-by: Marek Vasut
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Lucas Stach
> Cc: Marek Vasut
> Cc: Maxime Ripard
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Sam Ravnborg
> ---
> V2: Use devm_add_action_or_reset() to add clock disable hook instead
> of wall of failpath
> ---
> drivers/gpu/drm/bridge/tc358767.c | 30 +++---
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index 45ea829d56601..b2ef01303be23 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -2033,6 +2033,13 @@ static int tc_probe_bridge_endpoint(struct tc_data *tc)
> return -EINVAL;
> }
>
> +static void tc_clk_disable(void *data)
> +{
> + struct clk *refclk = data;
> +
> + clk_disable_unprepare(refclk);
> +}
> +
> static int tc_probe(struct i2c_client *client, const struct i2c_device_id
> *id)
> {
> struct device *dev = >dev;
> @@ -2049,6 +2056,22 @@ static int tc_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> if (ret)
> return ret;
>
> + tc->refclk = devm_clk_get(dev, "ref");
> + if (IS_ERR(tc->refclk)) {
> + ret = PTR_ERR(tc->refclk);
> + dev_err(dev, "Failed to get refclk: %d\n", ret);
> + return ret;
> + }
> +
> + ret = devm_add_action_or_reset(dev, tc_clk_disable, tc->refclk);
> + if (ret)
> + return ret;
if devm_add_action_or_reset fails, tc_clk_disable will be called
resulting in an unbalanced enable count for refclk. it should be called
after the clk_prepare_enable() call.
Maxime
Re: [PATCH 3/3] drm/bridge: tc358767: Make sure Refclk clock are enabled
On 5/19/22 09:57, Lucas Stach wrote:
Am Donnerstag, dem 19.05.2022 um 01:36 +0200 schrieb Marek Vasut:
The Refclk may be supplied by SoC clock output instead of crystal
oscillator, make sure the clock are enabled before any other action
is performed with the bridge chip, otherwise it may either fail to
operate at all, or miss reset GPIO toggle.
Fixes: 7caff0fc4296e ("drm/bridge: tc358767: Add DPI to eDP bridge driver")
Signed-off-by: Marek Vasut
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Marek Vasut
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Sam Ravnborg
---
drivers/gpu/drm/bridge/tc358767.c | 51 ---
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index a8bb6de9e600a..4b15acbc73c4e 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -2055,10 +2055,24 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
if (ret)
return ret;
+ tc->refclk = devm_clk_get(dev, "ref");
+ if (IS_ERR(tc->refclk)) {
+ ret = PTR_ERR(tc->refclk);
+ dev_err(dev, "Failed to get refclk: %d\n", ret);
+ return ret;
+ }
+
+ clk_prepare_enable(tc->refclk);
+
+ /* tRSTW = 100 cycles , at 13 MHz that is ~7.69 us */
+ usleep_range(10, 15);
+
/* Shut down GPIO is optional */
tc->sd_gpio = devm_gpiod_get_optional(dev, "shutdown", GPIOD_OUT_HIGH);
- if (IS_ERR(tc->sd_gpio))
- return PTR_ERR(tc->sd_gpio);
+ if (IS_ERR(tc->sd_gpio)) {
+ ret = PTR_ERR(tc->sd_gpio);
+ goto err_clk;
+ }
if (tc->sd_gpio) {
gpiod_set_value_cansleep(tc->sd_gpio, 0);
@@ -2067,26 +2081,21 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
/* Reset GPIO is optional */
tc->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
- if (IS_ERR(tc->reset_gpio))
- return PTR_ERR(tc->reset_gpio);
+ if (IS_ERR(tc->reset_gpio)) {
+ ret = PTR_ERR(tc->reset_gpio);
+ goto err_clk;
+ }
if (tc->reset_gpio) {
gpiod_set_value_cansleep(tc->reset_gpio, 1);
usleep_range(5000, 1);
}
- tc->refclk = devm_clk_get(dev, "ref");
- if (IS_ERR(tc->refclk)) {
- ret = PTR_ERR(tc->refclk);
- dev_err(dev, "Failed to get refclk: %d\n", ret);
- return ret;
- }
-
tc->regmap = devm_regmap_init_i2c(client, _regmap_config);
if (IS_ERR(tc->regmap)) {
ret = PTR_ERR(tc->regmap);
dev_err(dev, "Failed to initialize regmap: %d\n", ret);
- return ret;
+ goto err_clk;
}
ret = of_property_read_u32(dev->of_node, "toshiba,hpd-pin",
@@ -2096,7 +2105,7 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
} else {
if (tc->hpd_pin < 0 || tc->hpd_pin > 1) {
dev_err(dev, "failed to parse HPD number\n");
- return ret;
+ goto err_clk;
}
}
@@ -2110,7 +2119,7 @@ static int tc_probe(struct i2c_client *client, const struct i2c_device_id *id)
"tc358767-irq", tc);
if (ret) {
dev_err(dev, "failed to register dp interrupt\n");
- return ret;
+ goto err_clk;
}
tc->have_irq = true;
@@ -2119,12 +2128,13 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
ret = regmap_read(tc->regmap, TC_IDREG, >rev);
if (ret) {
dev_err(tc->dev, "can not read device ID: %d\n", ret);
- return ret;
+ goto err_clk;
}
if ((tc->rev != 0x6601) && (tc->rev != 0x6603)) {
dev_err(tc->dev, "invalid device ID: 0x%08x\n", tc->rev);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_clk;
}
tc->assr = (tc->rev == 0x6601); /* Enable ASSR for eDP panels */
@@ -2164,7 +2174,7 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
if (tc->bridge.type != DRM_MODE_CONNECTOR_DPI) { /* (e)DP output */
ret = tc_aux_link_setup(tc);
if (ret)
- return ret;
+ goto err_clk;
}
tc->bridge.of_node = dev->of_node;
@@ -2176,11 +2186,15 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
ret = tc_mipi_dsi_host_attach(tc);
if (ret) {
drm_bridge_remove(>bridge);
-
Re: [PATCH v2] drm/bridge: tc358767: Make sure Refclk clock are enabled
Am Donnerstag, dem 19.05.2022 um 13:47 +0200 schrieb Marek Vasut:
> The Refclk may be supplied by SoC clock output instead of crystal
> oscillator, make sure the clock are enabled before any other action
> is performed with the bridge chip, otherwise it may either fail to
> operate at all, or miss reset GPIO toggle.
>
> Fixes: 7caff0fc4296e ("drm/bridge: tc358767: Add DPI to eDP bridge driver")
> Signed-off-by: Marek Vasut
Reviewed-by: Lucas Stach
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Lucas Stach
> Cc: Marek Vasut
> Cc: Maxime Ripard
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Sam Ravnborg
> ---
> V2: Use devm_add_action_or_reset() to add clock disable hook instead
> of wall of failpath
> ---
> drivers/gpu/drm/bridge/tc358767.c | 30 +++---
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index 45ea829d56601..b2ef01303be23 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -2033,6 +2033,13 @@ static int tc_probe_bridge_endpoint(struct tc_data *tc)
> return -EINVAL;
> }
>
> +static void tc_clk_disable(void *data)
> +{
> + struct clk *refclk = data;
> +
> + clk_disable_unprepare(refclk);
> +}
> +
> static int tc_probe(struct i2c_client *client, const struct i2c_device_id
> *id)
> {
> struct device *dev = >dev;
> @@ -2049,6 +2056,22 @@ static int tc_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> if (ret)
> return ret;
>
> + tc->refclk = devm_clk_get(dev, "ref");
> + if (IS_ERR(tc->refclk)) {
> + ret = PTR_ERR(tc->refclk);
> + dev_err(dev, "Failed to get refclk: %d\n", ret);
> + return ret;
> + }
> +
> + ret = devm_add_action_or_reset(dev, tc_clk_disable, tc->refclk);
> + if (ret)
> + return ret;
> +
> + clk_prepare_enable(tc->refclk);
> +
> + /* tRSTW = 100 cycles , at 13 MHz that is ~7.69 us */
> + usleep_range(10, 15);
> +
> /* Shut down GPIO is optional */
> tc->sd_gpio = devm_gpiod_get_optional(dev, "shutdown", GPIOD_OUT_HIGH);
> if (IS_ERR(tc->sd_gpio))
> @@ -2069,13 +2092,6 @@ static int tc_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> usleep_range(5000, 1);
> }
>
> - tc->refclk = devm_clk_get(dev, "ref");
> - if (IS_ERR(tc->refclk)) {
> - ret = PTR_ERR(tc->refclk);
> - dev_err(dev, "Failed to get refclk: %d\n", ret);
> - return ret;
> - }
> -
> tc->regmap = devm_regmap_init_i2c(client, _regmap_config);
> if (IS_ERR(tc->regmap)) {
> ret = PTR_ERR(tc->regmap);
Re: [PATCH 10/11] drm/bridge: msm: Convert to drm_of_get_data_lanes
On 5/19/22 13:43, Dmitry Baryshkov wrote: On 19/05/2022 14:26, Marek Vasut wrote: Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by: Dmitry Baryshkov Can you please also test it, that it does not break anything ? Minor nit, if you resend this series for any reason: could you please follow the usual subject prefix for the msm driver: 'drm/msm: ' Will do
[PATCH v4 2/2] drm: lcdif: Add support for i.MX8MP LCDIF variant
Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is
completely different from the LCDIFv3 found in i.MX23 in that it has
a completely scrambled register layout compared to all previous LCDIF
variants. The new LCDIFv3 also supports 36bit address space.
Add a separate driver which is really a fork of MXSFB driver with the
i.MX8MP LCDIF variant handling filled in.
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
V2: - Drop the pitch check from lcdif_fb_create()
- Drop connector caching
- Wait for shadow load bit to be cleared in IRQ handler
- Make all clock mandatory and grab them all by name
- Wait for EN to be cleared in lcdif_disable_controller
- Rename to imx-lcdif
- Move shadow load to atomic_flush
V3: - Invert DE polarity to match MX8MPRM datasheet
- Enable CSC in RGB to YUV mode for MEDIA_BUS_FMT_UYVY8_1X16
V4: - Drop lcdif_overlay_plane_formats, it is unused
---
drivers/gpu/drm/mxsfb/Kconfig | 16 +
drivers/gpu/drm/mxsfb/Makefile | 2 +
drivers/gpu/drm/mxsfb/lcdif_drv.c | 361 +
drivers/gpu/drm/mxsfb/lcdif_drv.h | 47 +++
drivers/gpu/drm/mxsfb/lcdif_kms.c | 497 +
drivers/gpu/drm/mxsfb/lcdif_regs.h | 257 +++
6 files changed, 1180 insertions(+)
create mode 100644 drivers/gpu/drm/mxsfb/lcdif_drv.c
create mode 100644 drivers/gpu/drm/mxsfb/lcdif_drv.h
create mode 100644 drivers/gpu/drm/mxsfb/lcdif_kms.c
create mode 100644 drivers/gpu/drm/mxsfb/lcdif_regs.h
diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
index 987170e16ebd6..873551b4552f5 100644
--- a/drivers/gpu/drm/mxsfb/Kconfig
+++ b/drivers/gpu/drm/mxsfb/Kconfig
@@ -19,3 +19,19 @@ config DRM_MXSFB
i.MX28, i.MX6SX, i.MX7 and i.MX8M).
If M is selected the module will be called mxsfb.
+
+config DRM_IMX_LCDIF
+ tristate "i.MX LCDIFv3 LCD controller"
+ depends on DRM && OF
+ depends on COMMON_CLK
+ select DRM_MXS
+ select DRM_KMS_HELPER
+ select DRM_GEM_CMA_HELPER
+ select DRM_PANEL
+ select DRM_PANEL_BRIDGE
+ help
+ Choose this option if you have an LCDIFv3 LCD controller.
+ Those devices are found in various i.MX SoC (i.MX8MP,
+ i.MXRT).
+
+ If M is selected the module will be called imx-lcdif.
diff --git a/drivers/gpu/drm/mxsfb/Makefile b/drivers/gpu/drm/mxsfb/Makefile
index 26d153896d720..3fa44059b9d85 100644
--- a/drivers/gpu/drm/mxsfb/Makefile
+++ b/drivers/gpu/drm/mxsfb/Makefile
@@ -1,3 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
mxsfb-y := mxsfb_drv.o mxsfb_kms.o
obj-$(CONFIG_DRM_MXSFB)+= mxsfb.o
+imx-lcdif-y := lcdif_drv.o lcdif_kms.o
+obj-$(CONFIG_DRM_IMX_LCDIF) += imx-lcdif.o
diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c
b/drivers/gpu/drm/mxsfb/lcdif_drv.c
new file mode 100644
index 0..3e29c8a768487
--- /dev/null
+++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
@@ -0,0 +1,361 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2022 Marek Vasut
+ *
+ * This code is based on drivers/gpu/drm/mxsfb/mxsfb*
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "lcdif_drv.h"
+#include "lcdif_regs.h"
+
+static struct drm_framebuffer *
+lcdif_fb_create(struct drm_device *dev, struct drm_file *file_priv,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ const struct drm_format_info *info;
+
+ info = drm_get_format_info(dev, mode_cmd);
+ if (!info)
+ return ERR_PTR(-EINVAL);
+
+ return drm_gem_fb_create(dev, file_priv, mode_cmd);
+}
+
+static const struct drm_mode_config_funcs lcdif_mode_config_funcs = {
+ .fb_create = lcdif_fb_create,
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
+};
+
+static const struct drm_mode_config_helper_funcs lcdif_mode_config_helpers = {
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+};
+
+static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
+{
+ struct drm_device *drm = lcdif->drm;
+ struct drm_bridge *bridge;
+ struct drm_panel *panel;
+ int ret;
+
+ ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, ,
+ );
+ if (ret)
+ return ret;
+
+ if (panel) {
+ bridge = devm_drm_panel_bridge_add_typed(drm->dev, panel,
+
DRM_MODE_CONNECTOR_DPI);
+ if (IS_ERR(bridge))
+ return PTR_ERR(bridge);
+ }
+
+ if (!bridge)
+ return -ENODEV;
+
+
[PATCH v4 1/2] dt-bindings: lcdif: Add compatible for i.MX8MP
Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3 and is completely different from the LCDIFv3 found in i.MX23 in that it has a completely scrambled register layout compared to all previous LCDIF variants. The new LCDIFv3 also supports 36bit address space. However, except for the complete bit reshuffling, this is still LCDIF and it still works like one. Signed-off-by: Marek Vasut Cc: Alexander Stein Cc: Laurent Pinchart Cc: Lucas Stach Cc: Peng Fan Cc: Rob Herring Cc: Robby Cai Cc: Sam Ravnborg Cc: Stefan Agner Cc: devicet...@vger.kernel.org --- V2: No change V3: No change V4: No change --- Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index 900a56cae80e6..876015a44a1e6 100644 --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml @@ -20,6 +20,7 @@ properties: - fsl,imx23-lcdif - fsl,imx28-lcdif - fsl,imx6sx-lcdif + - fsl,imx8mp-lcdif - items: - enum: - fsl,imx6sl-lcdif -- 2.35.1
[PATCH v2] drm/bridge: tc358767: Make sure Refclk clock are enabled
The Refclk may be supplied by SoC clock output instead of crystal
oscillator, make sure the clock are enabled before any other action
is performed with the bridge chip, otherwise it may either fail to
operate at all, or miss reset GPIO toggle.
Fixes: 7caff0fc4296e ("drm/bridge: tc358767: Add DPI to eDP bridge driver")
Signed-off-by: Marek Vasut
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Marek Vasut
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Sam Ravnborg
---
V2: Use devm_add_action_or_reset() to add clock disable hook instead
of wall of failpath
---
drivers/gpu/drm/bridge/tc358767.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 45ea829d56601..b2ef01303be23 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -2033,6 +2033,13 @@ static int tc_probe_bridge_endpoint(struct tc_data *tc)
return -EINVAL;
}
+static void tc_clk_disable(void *data)
+{
+ struct clk *refclk = data;
+
+ clk_disable_unprepare(refclk);
+}
+
static int tc_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
struct device *dev = >dev;
@@ -2049,6 +2056,22 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
if (ret)
return ret;
+ tc->refclk = devm_clk_get(dev, "ref");
+ if (IS_ERR(tc->refclk)) {
+ ret = PTR_ERR(tc->refclk);
+ dev_err(dev, "Failed to get refclk: %d\n", ret);
+ return ret;
+ }
+
+ ret = devm_add_action_or_reset(dev, tc_clk_disable, tc->refclk);
+ if (ret)
+ return ret;
+
+ clk_prepare_enable(tc->refclk);
+
+ /* tRSTW = 100 cycles , at 13 MHz that is ~7.69 us */
+ usleep_range(10, 15);
+
/* Shut down GPIO is optional */
tc->sd_gpio = devm_gpiod_get_optional(dev, "shutdown", GPIOD_OUT_HIGH);
if (IS_ERR(tc->sd_gpio))
@@ -2069,13 +2092,6 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
usleep_range(5000, 1);
}
- tc->refclk = devm_clk_get(dev, "ref");
- if (IS_ERR(tc->refclk)) {
- ret = PTR_ERR(tc->refclk);
- dev_err(dev, "Failed to get refclk: %d\n", ret);
- return ret;
- }
-
tc->regmap = devm_regmap_init_i2c(client, _regmap_config);
if (IS_ERR(tc->regmap)) {
ret = PTR_ERR(tc->regmap);
--
2.35.1
Re: [PATCH 10/11] drm/bridge: msm: Convert to drm_of_get_data_lanes
On 19/05/2022 14:26, Marek Vasut wrote:
Convert driver to use this new helper to standardize
OF "data-lanes" parsing.
Reviewed-by: Dmitry Baryshkov
Minor nit, if you resend this series for any reason: could you please
follow the usual subject prefix for the msm driver: 'drm/msm: '
Signed-off-by: Marek Vasut
Cc: Abhinav Kumar
Cc: Andrzej Hajda
Cc: Dmitry Baryshkov
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Rob Clark
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: Sean Paul
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/msm/dp/dp_parser.c | 6 ++
drivers/gpu/drm/msm/dsi/dsi_host.c | 7 +++
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c
b/drivers/gpu/drm/msm/dp/dp_parser.c
index 8f9fed9fdafc4..6ef919cda0f5c 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -102,11 +102,9 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
static int dp_parser_misc(struct dp_parser *parser)
{
struct device_node *of_node = parser->pdev->dev.of_node;
- int len = 0;
- const char *data_lane_property = "data-lanes";
+ int len;
- len = of_property_count_elems_of_size(of_node,
-data_lane_property, sizeof(u32));
+ len = drm_of_get_data_lanes(of_node, 1, DP_MAX_NUM_DP_LANES);
if (len < 0) {
DRM_WARN("Invalid property %s, default max DP lanes = %d\n",
data_lane_property, DP_MAX_NUM_DP_LANES);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index a95d5df52653c..a0c7d23cd4939 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1779,11 +1779,10 @@ static int dsi_host_parse_lane_data(struct msm_dsi_host
*msm_host,
return 0;
}
- num_lanes = len / sizeof(u32);
-
- if (num_lanes < 1 || num_lanes > 4) {
+ num_lanes = drm_of_get_data_lanes(ep, 1, 4);
+ if (num_lanes < 0) {
DRM_DEV_ERROR(dev, "bad number of data lanes\n");
- return -EINVAL;
+ return num_lanes;
}
msm_host->num_data_lanes = num_lanes;
--
With best wishes
Dmitry
Re: [Intel-gfx] [PATCH v6] drm/i915/display: disable HPD workers before display driver unregister
Seems the patch correctly fixes the the issue and passes CI so added maintainers/reviewers to CC. On 13.05.2022 18:06, Andrzej Hajda wrote: Handling HPD during driver removal is pointless, and can cause different use-after-free/concurrency issues: 1. Setup of deferred fbdev after fbdev unregistration. 2. Access to DP-AUX after DP-AUX removal. Below stacktraces of both cases observed on CI: [272.634530] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: [#1] PREEMPT SMP NOPTI [272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U 5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1 [272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021 [272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60 ... [272.634582] Call Trace: [272.634583] [272.634585] do_remove_conflicting_framebuffers+0x59/0xa0 [272.634589] remove_conflicting_framebuffers+0x2d/0xc0 [272.634592] remove_conflicting_pci_framebuffers+0xc8/0x110 [272.634595] drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70 [272.634604] i915_driver_probe+0x63a/0xdd0 [i915] [283.405824] cpu_latency_qos_update_request called for unknown object [283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 cpu_latency_qos_update_request+0x2d/0x100 [283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1 [283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021 [283.405916] Workqueue: i915-dp i915_digport_work_func [i915] [283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100 ... [283.406040] Call Trace: [283.406041] [283.406044] intel_dp_aux_xfer+0x60e/0x8e0 [i915] [283.406131] ? finish_swait+0x80/0x80 [283.406139] intel_dp_aux_transfer+0xc5/0x2b0 [i915] [283.406218] drm_dp_dpcd_access+0x79/0x130 [drm_display_helper] [283.406227] drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper] [283.406233] intel_dp_hpd_pulse+0x134/0x570 [i915] [283.406308] ? __down_killable+0x70/0x140 [283.406313] i915_digport_work_func+0xba/0x150 [i915] Signed-off-by: Andrzej Hajda --- Hi all, This is my Nth attempt to solve some old CI bug[1]. v-2: caused issues in kms code [2], v-1: revealed that not only fbdev does not like HPD on removal [3], v3: lacks drm_kms_helper_poll_disable[4] v4: added dump_stack to detect late fb registration v5: added intel_dp_mst_suspend to stop late fb registration v6: removed dump_stack with hope everything is handled Moreover this is quite rare bug, but due to specific configuration of one of CI machines it appears there very frequently. Forgive me spamming the list. [1]: https://gitlab.freedesktop.org/drm/intel/-/issues/5329 [2]: https://patchwork.freedesktop.org/series/103621/ [3]: https://patchwork.freedesktop.org/series/103738/ [4]: https://patchwork.freedesktop.org/series/103811/ Regards Andrzej --- drivers/gpu/drm/i915/display/intel_display.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 806d50b302ab92..007bc6daef7d31 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -10486,13 +10486,6 @@ void intel_modeset_driver_remove_noirq(struct drm_i915_private *i915) */ intel_hpd_poll_fini(i915); - /* -* MST topology needs to be suspended so we don't have any calls to -* fbdev after it's finalized. MST will be destroyed later as part of -* drm_mode_config_cleanup() -*/ - intel_dp_mst_suspend(i915); - /* poll work can call into fbdev, hence clean that up afterwards */ intel_fbdev_fini(i915); @@ -10584,6 +10577,10 @@ void intel_display_driver_unregister(struct drm_i915_private *i915) if (!HAS_DISPLAY(i915)) return; + intel_dp_mst_suspend(i915); + intel_hpd_cancel_work(i915); + drm_kms_helper_poll_disable(>drm); + intel_fbdev_unregister(i915); intel_audio_deinit(i915);
[PATCH 05/11] drm/bridge: lt9211: Convert to drm_of_get_data_lanes
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Signed-off-by: Marek Vasut Cc: Andrzej Hajda Cc: Laurent Pinchart Cc: Lucas Stach Cc: Maxime Ripard Cc: Robert Foss Cc: Sam Ravnborg To: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/bridge/lontium-lt9211.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/lontium-lt9211.c b/drivers/gpu/drm/bridge/lontium-lt9211.c index e92821fbc6393..3e158689f6696 100644 --- a/drivers/gpu/drm/bridge/lontium-lt9211.c +++ b/drivers/gpu/drm/bridge/lontium-lt9211.c @@ -686,7 +686,7 @@ static int lt9211_host_attach(struct lt9211 *ctx) int ret; endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1); - dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes"); + dsi_lanes = drm_of_get_data_lanes(endpoint, 1, 4); host_node = of_graph_get_remote_port_parent(endpoint); host = of_find_mipi_dsi_host_by_node(host_node); of_node_put(host_node); @@ -695,8 +695,8 @@ static int lt9211_host_attach(struct lt9211 *ctx) if (!host) return -EPROBE_DEFER; - if (dsi_lanes < 0 || dsi_lanes > 4) - return -EINVAL; + if (dsi_lanes < 0) + return dsi_lanes; dsi = devm_mipi_dsi_device_register_full(dev, host, ); if (IS_ERR(dsi)) -- 2.35.1
[PATCH 11/11] drm/bridge: rcar: Convert to drm_of_get_data_lanes_ep
Convert driver to use this new helper to standardize
OF "data-lanes" parsing.
Signed-off-by: Marek Vasut
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
index 891bb956fd61b..915c74c0a37fd 100644
--- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
+++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
@@ -683,19 +683,10 @@ static int rcar_mipi_dsi_parse_dt(struct rcar_mipi_dsi
*dsi)
u32 data_lanes[4];
int ret;
- ep = of_graph_get_endpoint_by_regs(dsi->dev->of_node, 1, 0);
- if (!ep) {
- dev_dbg(dsi->dev, "unconnected port@1\n");
- return -ENODEV;
- }
-
- ret = of_property_read_variable_u32_array(ep, "data-lanes", data_lanes,
- 1, 4);
- of_node_put(ep);
-
+ ret = drm_of_get_data_lanes_ep(dsi->dev->of_node, 1, 0, 1, 4);
if (ret < 0) {
dev_err(dsi->dev, "missing or invalid data-lanes property\n");
- return -ENODEV;
+ return ret;
}
dsi->num_data_lanes = ret;
--
2.35.1
[PATCH 08/11] drm/bridge: ti-sn65dsi83: Convert to drm_of_get_data_lanes
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Signed-off-by: Marek Vasut Cc: Andrzej Hajda Cc: Laurent Pinchart Cc: Lucas Stach Cc: Maxime Ripard Cc: Robert Foss Cc: Sam Ravnborg To: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c index f5c1819857665..e3d87e5905c00 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -628,7 +628,7 @@ static int sn65dsi83_host_attach(struct sn65dsi83 *ctx) int dsi_lanes, ret; endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1); - dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes"); + dsi_lanes = drm_of_get_data_lanes(endpoint, 1, 4); host_node = of_graph_get_remote_port_parent(endpoint); host = of_find_mipi_dsi_host_by_node(host_node); of_node_put(host_node); -- 2.35.1
[PATCH 09/11] drm/bridge: ti-sn65dsi86: Convert to drm_of_get_data_lanes
Convert driver to use this new helper to standardize
OF "data-lanes" parsing.
Signed-off-by: Marek Vasut
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 8cad662de9bb5..44a330a48d385 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -1142,8 +1142,8 @@ static void ti_sn_bridge_parse_lanes(struct ti_sn65dsi86
*pdata,
* mappings that the hardware supports.
*/
endpoint = of_graph_get_endpoint_by_regs(np, 1, -1);
- dp_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
- if (dp_lanes > 0 && dp_lanes <= SN_MAX_DP_LANES) {
+ dp_lanes = drm_of_get_data_lanes(endpoint, 1, SN_MAX_DP_LANES);
+ if (dp_lanes > 0) {
of_property_read_u32_array(endpoint, "data-lanes",
lane_assignments, dp_lanes);
of_property_read_u32_array(endpoint, "lane-polarities",
--
2.35.1
[PATCH 04/11] drm/bridge: lt8912: Convert to drm_of_get_data_lanes_ep
Convert driver to use this new helper to standardize
OF "data-lanes" parsing.
Signed-off-by: Marek Vasut
Cc: Adrien Grassein
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
b/drivers/gpu/drm/bridge/lontium-lt8912b.c
index c642d1e02b2f8..b9741de70d584 100644
--- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
+++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
@@ -607,7 +607,6 @@ static int lt8912_parse_dt(struct lt8912 *lt)
int ret;
int data_lanes;
struct device_node *port_node;
- struct device_node *endpoint;
gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(gp_reset)) {
@@ -618,16 +617,12 @@ static int lt8912_parse_dt(struct lt8912 *lt)
}
lt->gp_reset = gp_reset;
- endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
- if (!endpoint)
- return -ENODEV;
-
- data_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
- of_node_put(endpoint);
+ data_lanes = drm_of_get_data_lanes_ep(dev->of_node, 0, -1, 1, 4);
if (data_lanes < 0) {
dev_err(lt->dev, "%s: Bad data-lanes property\n", __func__);
return data_lanes;
}
+
lt->data_lanes = data_lanes;
lt->host_node = of_graph_get_remote_node(dev->of_node, 0, -1);
--
2.35.1
[PATCH 07/11] drm/bridge: tc358775: Convert to drm_of_get_data_lanes_ep
Convert driver to use this new helper to standardize
OF "data-lanes" parsing.
Signed-off-by: Marek Vasut
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/bridge/tc358775.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
index 62a7ef352daa5..7abb8ae3df2ff 100644
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -530,7 +530,7 @@ static int tc358775_parse_dt(struct device_node *np, struct
tc_data *tc)
struct device_node *parent;
struct device_node *remote;
struct property *prop;
- int len = 0;
+ int dsi_lanes, len = 0;
/*
* To get the data-lanes of dsi, we need to access the dsi0_out of port1
@@ -544,25 +544,15 @@ static int tc358775_parse_dt(struct device_node *np,
struct tc_data *tc)
of_node_put(endpoint);
if (parent) {
/* dsi0 port 1 */
- endpoint = of_graph_get_endpoint_by_regs(parent, 1, -1);
+ dsi_lanes = drm_of_get_data_lanes_ep(parent, 1, -1, 1,
4);
of_node_put(parent);
- if (endpoint) {
- prop = of_find_property(endpoint, "data-lanes",
- );
- of_node_put(endpoint);
- if (!prop) {
- dev_err(tc->dev,
- "failed to find data lane\n");
- return -EPROBE_DEFER;
- }
- }
}
}
- tc->num_dsi_lanes = len / sizeof(u32);
+ if (dsi_lanes < 0)
+ return dsi_lanes;
- if (tc->num_dsi_lanes < 1 || tc->num_dsi_lanes > 4)
- return -EINVAL;
+ tc->num_dsi_lanes = dsi_lanes;
tc->host_node = of_graph_get_remote_node(np, 0, 0);
if (!tc->host_node)
--
2.35.1
[PATCH 10/11] drm/bridge: msm: Convert to drm_of_get_data_lanes
Convert driver to use this new helper to standardize
OF "data-lanes" parsing.
Signed-off-by: Marek Vasut
Cc: Abhinav Kumar
Cc: Andrzej Hajda
Cc: Dmitry Baryshkov
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Rob Clark
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: Sean Paul
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/msm/dp/dp_parser.c | 6 ++
drivers/gpu/drm/msm/dsi/dsi_host.c | 7 +++
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c
b/drivers/gpu/drm/msm/dp/dp_parser.c
index 8f9fed9fdafc4..6ef919cda0f5c 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -102,11 +102,9 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
static int dp_parser_misc(struct dp_parser *parser)
{
struct device_node *of_node = parser->pdev->dev.of_node;
- int len = 0;
- const char *data_lane_property = "data-lanes";
+ int len;
- len = of_property_count_elems_of_size(of_node,
-data_lane_property, sizeof(u32));
+ len = drm_of_get_data_lanes(of_node, 1, DP_MAX_NUM_DP_LANES);
if (len < 0) {
DRM_WARN("Invalid property %s, default max DP lanes = %d\n",
data_lane_property, DP_MAX_NUM_DP_LANES);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index a95d5df52653c..a0c7d23cd4939 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1779,11 +1779,10 @@ static int dsi_host_parse_lane_data(struct msm_dsi_host
*msm_host,
return 0;
}
- num_lanes = len / sizeof(u32);
-
- if (num_lanes < 1 || num_lanes > 4) {
+ num_lanes = drm_of_get_data_lanes(ep, 1, 4);
+ if (num_lanes < 0) {
DRM_DEV_ERROR(dev, "bad number of data lanes\n");
- return -EINVAL;
+ return num_lanes;
}
msm_host->num_data_lanes = num_lanes;
--
2.35.1
[PATCH 06/11] drm/bridge: tc358767: Convert to drm_of_get_data_lanes
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Signed-off-by: Marek Vasut Cc: Andrzej Hajda Cc: Laurent Pinchart Cc: Lucas Stach Cc: Maxime Ripard Cc: Robert Foss Cc: Sam Ravnborg To: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/bridge/tc358767.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 8e210b1176906..a6990a8c08a8b 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -1892,18 +1892,18 @@ static int tc_mipi_dsi_host_attach(struct tc_data *tc) int dsi_lanes, ret; endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1); - dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes"); + dsi_lanes = drm_of_get_data_lanes(endpoint, 1, 4); host_node = of_graph_get_remote_port_parent(endpoint); host = of_find_mipi_dsi_host_by_node(host_node); of_node_put(host_node); of_node_put(endpoint); - if (dsi_lanes <= 0 || dsi_lanes > 4) - return -EINVAL; - if (!host) return -EPROBE_DEFER; + if (dsi_lanes < 0) + return dsi_lanes; + dsi = mipi_dsi_device_register_full(host, ); if (IS_ERR(dsi)) return dev_err_probe(dev, PTR_ERR(dsi), -- 2.35.1
[PATCH 02/11] drm/bridge: anx7625: Convert to drm_of_get_data_lanes
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Signed-off-by: Marek Vasut Cc: Andrzej Hajda Cc: Laurent Pinchart Cc: Lucas Stach Cc: Maxime Ripard Cc: Robert Foss Cc: Sam Ravnborg Cc: Xin Ji To: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/bridge/analogix/anx7625.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c b/drivers/gpu/drm/bridge/analogix/anx7625.c index e92eb4a407452..87d7658b92fac 100644 --- a/drivers/gpu/drm/bridge/analogix/anx7625.c +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c @@ -1637,16 +1637,16 @@ static int anx7625_parse_dt(struct device *dev, if (of_property_read_u32(ep0, "bus-type", _type)) bus_type = 0; - mipi_lanes = of_property_count_u32_elems(ep0, "data-lanes"); + mipi_lanes = drm_of_get_data_lanes(ep0, 1, MAX_LANES_SUPPORT); of_node_put(ep0); } if (bus_type == V4L2_FWNODE_BUS_TYPE_PARALLEL) /* bus type is Parallel(DSI) */ pdata->is_dpi = 0; - pdata->mipi_lanes = mipi_lanes; - if (pdata->mipi_lanes > MAX_LANES_SUPPORT || pdata->mipi_lanes <= 0) - pdata->mipi_lanes = MAX_LANES_SUPPORT; + pdata->mipi_lanes = MAX_LANES_SUPPORT; + if (mipi_lanes > 0) + pdata->mipi_lanes = mipi_lanes; if (pdata->is_dpi) DRM_DEV_DEBUG_DRIVER(dev, "found MIPI DPI host node.\n"); -- 2.35.1
[PATCH 03/11] drm/bridge: icn6211: Convert to drm_of_get_data_lanes_ep
Convert driver to use this new helper to standardize
OF "data-lanes" parsing.
Signed-off-by: Marek Vasut
Cc: Andrzej Hajda
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/bridge/chipone-icn6211.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c
b/drivers/gpu/drm/bridge/chipone-icn6211.c
index 45bb89ac3fff7..e53a19f721c8c 100644
--- a/drivers/gpu/drm/bridge/chipone-icn6211.c
+++ b/drivers/gpu/drm/bridge/chipone-icn6211.c
@@ -496,21 +496,18 @@ static int chipone_dsi_attach(struct chipone *icn)
{
struct mipi_dsi_device *dsi = icn->dsi;
struct device *dev = icn->dev;
- struct device_node *endpoint;
int dsi_lanes, ret;
- endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
- dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
- of_node_put(endpoint);
+ dsi_lanes = drm_of_get_data_lanes_ep(dev->of_node, 0, 0, 1, 4);
/*
* If the 'data-lanes' property does not exist in DT or is invalid,
* default to previously hard-coded behavior, which was 4 data lanes.
*/
- if (dsi_lanes >= 1 && dsi_lanes <= 4)
- icn->dsi->lanes = dsi_lanes;
- else
+ if (dsi_lanes < 0)
icn->dsi->lanes = 4;
+ else
+ icn->dsi->lanes = dsi_lanes;
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
--
2.35.1
[PATCH 01/11] drm: of: Add drm_of_get_data_lanes and drm_of_get_data_lanes_ep
Add helper function to count and sanitize DT "data-lanes" property
and return either error or the data-lanes count. This is useful for
both DSI and (e)DP "data-lanes" property. The later version of the
function is an extra wrapper which handles the endpoint look up by
regs, that's what majority of the drivers duplicate too, but not all
of them.
Signed-off-by: Marek Vasut
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_of.c | 61
include/drm/drm_of.h | 20 +
2 files changed, 81 insertions(+)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 9a2cfab3a177f..2186f966d2820 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -430,3 +430,64 @@ int drm_of_lvds_get_data_mapping(const struct device_node
*port)
return -EINVAL;
}
EXPORT_SYMBOL_GPL(drm_of_lvds_get_data_mapping);
+
+/**
+ * drm_of_get_data_lanes - Get DSI/(e)DP data lane count
+ * @endpoint: DT endpoint node of the DSI/(e)DP source or sink
+ * @min: minimum supported number of data lanes
+ * @max: maximum supported number of data lanes
+ *
+ * Count DT "data-lanes" property elements and check for validity.
+ *
+ * Return:
+ * * min..max - positive integer count of "data-lanes" elements
+ * * -ve - the "data-lanes" property is missing or invalid
+ * * -EINVAL - the "data-lanes" property is unsupported
+ */
+int drm_of_get_data_lanes(const struct device_node *endpoint,
+ const unsigned int min, const unsigned int max)
+{
+ int ret;
+
+ ret = of_property_count_u32_elems(endpoint, "data-lanes");
+ if (ret < 0)
+ return ret;
+
+ if (ret < min || ret > max)
+ return -EINVAL;
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(drm_of_get_data_lanes);
+
+/**
+ * drm_of_get_data_lanes_ep - Get DSI/(e)DP data lane count by endpoint
+ * @port: DT port node of the DSI/(e)DP source or sink
+ * @port_reg: identifier (value of reg property) of the parent port node
+ * @reg: identifier (value of reg property) of the endpoint node
+ * @min: minimum supported number of data lanes
+ * @max: maximum supported number of data lanes
+ *
+ * Count DT "data-lanes" property elements and check for validity.
+ * This variant uses endpoint specifier.
+ *
+ * Return:
+ * * min..max - positive integer count of "data-lanes" elements
+ * * -EINVAL - the "data-mapping" property is unsupported
+ * * -ENODEV - the "data-mapping" property is missing
+ */
+int drm_of_get_data_lanes_ep(const struct device_node *port,
+int port_reg, int reg,
+const unsigned int min,
+const unsigned int max)
+{
+ struct device_node *endpoint;
+ int ret;
+
+ endpoint = of_graph_get_endpoint_by_regs(port, port_reg, reg);
+ ret = drm_of_get_data_lanes(endpoint, min, max);
+ of_node_put(endpoint);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(drm_of_get_data_lanes_ep);
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 99f79ac8b4cd7..b559c53756196 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -50,6 +50,12 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
int drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
const struct device_node *port2);
int drm_of_lvds_get_data_mapping(const struct device_node *port);
+int drm_of_get_data_lanes(const struct device_node *endpoint,
+ const unsigned int min, const unsigned int max);
+int drm_of_get_data_lanes_ep(const struct device_node *port,
+int port_reg, int reg,
+const unsigned int min,
+const unsigned int max);
#else
static inline uint32_t drm_of_crtc_port_mask(struct drm_device *dev,
struct device_node *port)
@@ -105,6 +111,20 @@ drm_of_lvds_get_data_mapping(const struct device_node
*port)
{
return -EINVAL;
}
+
+int drm_of_get_data_lanes(const struct device_node *endpoint,
+ const unsigned int min, const unsigned int max)
+{
+ return -EINVAL;
+}
+
+int drm_of_get_data_lanes_ep(const struct device_node *port,
+int port_reg, int reg
+const unsigned int min,
+const unsigned int max)
+{
+ return -EINVAL;
+}
#endif
/*
--
2.35.1
[PATCH] drm/bridge: ti-sn65dsi83: Do not cache dsi_lanes and host twice
The DSI lane count can be accessed via the dsi device pointer, make use
of that. The DSI host pointer is only used in sn65dsi83_host_attach(),
move the code around so that the host does not have to be cached in the
driver private data. This simplifies the code further. No functional
change.
This has the added bonus that lt9211, tc358767, sn65dsi83 now use very
similar *_mipi_dsi_host_attach() which is ripe for deduplication.
Signed-off-by: Marek Vasut
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 64 +--
1 file changed, 22 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index dc65f424e7f3c..f5c1819857665 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -141,12 +141,10 @@ struct sn65dsi83 {
struct drm_bridge bridge;
struct device *dev;
struct regmap *regmap;
- struct device_node *host_node;
struct mipi_dsi_device *dsi;
struct drm_bridge *panel_bridge;
struct gpio_desc*enable_gpio;
struct regulator*vcc;
- int dsi_lanes;
boollvds_dual_link;
boollvds_dual_link_even_odd_swap;
atomic_tenable_count;
@@ -308,7 +306,7 @@ static u8 sn65dsi83_get_dsi_range(struct sn65dsi83 *ctx,
*/
return DIV_ROUND_UP(clamp((unsigned int)mode->clock *
mipi_dsi_pixel_format_to_bpp(ctx->dsi->format) /
- ctx->dsi_lanes / 2, 4U, 50U), 5000U);
+ ctx->dsi->lanes / 2, 4U, 50U), 5000U);
}
static u8 sn65dsi83_get_dsi_div(struct sn65dsi83 *ctx)
@@ -316,7 +314,7 @@ static u8 sn65dsi83_get_dsi_div(struct sn65dsi83 *ctx)
/* The divider is (DSI_CLK / LVDS_CLK) - 1, which really is: */
unsigned int dsi_div = mipi_dsi_pixel_format_to_bpp(ctx->dsi->format);
- dsi_div /= ctx->dsi_lanes;
+ dsi_div /= ctx->dsi->lanes;
if (!ctx->lvds_dual_link)
dsi_div /= 2;
@@ -411,7 +409,7 @@ static void sn65dsi83_atomic_enable(struct drm_bridge
*bridge,
/* Set number of DSI lanes and LVDS link config. */
regmap_write(ctx->regmap, REG_DSI_LANE,
REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE |
-REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
+REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi->lanes - 1)) |
/* CHB is DSI85-only, set to default on DSI83/DSI84 */
REG_DSI_LANE_CHB_DSI_LANES(3));
/* No equalization. */
@@ -577,22 +575,6 @@ static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum
sn65dsi83_model model)
{
struct drm_bridge *panel_bridge;
struct device *dev = ctx->dev;
- struct device_node *endpoint;
- int ret;
-
- endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
- ctx->dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
- ctx->host_node = of_graph_get_remote_port_parent(endpoint);
- of_node_put(endpoint);
-
- if (ctx->dsi_lanes <= 0 || ctx->dsi_lanes > 4) {
- ret = -EINVAL;
- goto err_put_node;
- }
- if (!ctx->host_node) {
- ret = -ENODEV;
- goto err_put_node;
- }
ctx->lvds_dual_link = false;
ctx->lvds_dual_link_even_odd_swap = false;
@@ -618,10 +600,8 @@ static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum
sn65dsi83_model model)
}
panel_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 2, 0);
- if (IS_ERR(panel_bridge)) {
- ret = PTR_ERR(panel_bridge);
- goto err_put_node;
- }
+ if (IS_ERR(panel_bridge))
+ return PTR_ERR(panel_bridge);
ctx->panel_bridge = panel_bridge;
@@ -631,15 +611,13 @@ static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum
sn65dsi83_model model)
"Failed to get supply 'vcc'\n");
return 0;
-
-err_put_node:
- of_node_put(ctx->host_node);
- return ret;
}
static int sn65dsi83_host_attach(struct sn65dsi83 *ctx)
{
struct device *dev = ctx->dev;
+ struct device_node *host_node;
+ struct device_node *endpoint;
struct mipi_dsi_device *dsi;
struct mipi_dsi_host *host;
const struct mipi_dsi_device_info info = {
@@ -647,13 +625,20 @@ static int sn65dsi83_host_attach(struct sn65dsi83 *ctx)
.channel = 0,
.node = NULL,
};
- int ret;
+ int dsi_lanes, ret;
+
+ endpoint
[PATCH] drm/bridge: tc358767: Do not cache dsi_lanes twice
The DSI lane count can be accessed via the dsi device pointer,
make use of that. No functional change.
Signed-off-by: Marek Vasut
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
---
drivers/gpu/drm/bridge/tc358767.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 5e0de9974143c..8e210b1176906 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -288,7 +288,6 @@ struct tc_data {
struct drm_connectorconnector;
struct mipi_dsi_device *dsi;
- u8 dsi_lanes;
/* link settings */
struct tc_edp_link link;
@@ -1264,7 +1263,7 @@ static int tc_dsi_rx_enable(struct tc_data *tc)
regmap_write(tc->regmap, PPI_TX_RX_TA, TTA_GET | TTA_SURE);
regmap_write(tc->regmap, PPI_LPTXTIMECNT, LPX_PERIOD);
- value = ((LANEENABLE_L0EN << tc->dsi_lanes) - LANEENABLE_L0EN) |
+ value = ((LANEENABLE_L0EN << tc->dsi->lanes) - LANEENABLE_L0EN) |
LANEENABLE_CLEN;
regmap_write(tc->regmap, PPI_LANEENABLE, value);
regmap_write(tc->regmap, DSI_LANEENABLE, value);
@@ -1912,8 +1911,7 @@ static int tc_mipi_dsi_host_attach(struct tc_data *tc)
tc->dsi = dsi;
- tc->dsi_lanes = dsi_lanes;
- dsi->lanes = tc->dsi_lanes;
+ dsi->lanes = dsi_lanes;
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
--
2.35.1
[PATCH] drm/bridge: anx7625: Add missing of_node_put for endpoint
Add of_node_put call on the endpoint node after it is not needed. Signed-off-by: Marek Vasut Cc: Alex Deucher Cc: Javier Martinez Canillas Cc: Lyude Paul Cc: Thomas Zimmermann Cc: Xin Ji --- drivers/gpu/drm/bridge/analogix/anx7625.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c b/drivers/gpu/drm/bridge/analogix/anx7625.c index 53a5da6c49dd3..e92eb4a407452 100644 --- a/drivers/gpu/drm/bridge/analogix/anx7625.c +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c @@ -1638,6 +1638,7 @@ static int anx7625_parse_dt(struct device *dev, bus_type = 0; mipi_lanes = of_property_count_u32_elems(ep0, "data-lanes"); + of_node_put(ep0); } if (bus_type == V4L2_FWNODE_BUS_TYPE_PARALLEL) /* bus type is Parallel(DSI) */ -- 2.35.1
Re: [PATCH v7 2/6] cgroup: gpu: Add a cgroup controller for allocator attribution of GPU memory
From: Enric Balletbo i Serra On Tue, 10 May 2022 23:56:46 +, T.J. Mercier wrote > From: Hridya Valsaraju > > The cgroup controller provides accounting for GPU and GPU-related > memory allocations. The memory being accounted can be device memory or > memory allocated from pools dedicated to serve GPU-related tasks. > > This patch adds APIs to: > -allow a device to register for memory accounting using the GPU cgroup > controller. > -charge and uncharge allocated memory to a cgroup. > > When the cgroup controller is enabled, it would expose information about > the memory allocated by each device(registered for GPU cgroup memory > accounting) for each cgroup. > > The API/UAPI can be extended to set per-device/total allocation limits > in the future. > > The cgroup controller has been named following the discussion in [1]. > > [1]: https://lore.kernel.org/amd-gfx/YCJp%2F%2FkMC7YjVMXv@phenom.ffwll.local/ > > Signed-off-by: Hridya Valsaraju > Signed-off-by: T.J. Mercier > --- > v7 changes > Hide gpucg and gpucg_bucket struct definitions per Michal Koutný. > This means gpucg_register_bucket now returns an internally allocated > struct gpucg_bucket. > > Move all public function documentation to the cgroup_gpu.h header. > > v5 changes > Support all strings for gpucg_register_device instead of just string > literals. > > Enforce globally unique gpucg_bucket names. > > Constrain gpucg_bucket name lengths to 64 bytes. > > Obtain just a single css refcount instead of nr_pages for each > charge. > > Rename: > gpucg_try_charge -> gpucg_charge > find_cg_rpool_locked -> cg_rpool_find_locked > init_cg_rpool -> cg_rpool_init > get_cg_rpool_locked -> cg_rpool_get_locked > "gpu cgroup controller" -> "GPU controller" > gpucg_device -> gpucg_bucket > usage -> size > > v4 changes > Adjust gpucg_try_charge critical section for future charge transfer > functionality. > > v3 changes > Use more common dual author commit message format per John Stultz. > > v2 changes > Fix incorrect Kconfig help section indentation per Randy Dunlap. > --- > include/linux/cgroup_gpu.h| 122 > include/linux/cgroup_subsys.h | 4 + > init/Kconfig | 7 + > kernel/cgroup/Makefile| 1 + > kernel/cgroup/gpu.c | 339 ++ > 5 files changed, 473 insertions(+) > create mode 100644 include/linux/cgroup_gpu.h > create mode 100644 kernel/cgroup/gpu.c > > diff --git a/include/linux/cgroup_gpu.h b/include/linux/cgroup_gpu.h > new file mode 100644 > index ..cb228a16aa1f > --- /dev/null > +++ b/include/linux/cgroup_gpu.h > @@ -0,0 +1,122 @@ > +/* SPDX-License-Identifier: MIT > + * Copyright 2019 Advanced Micro Devices, Inc. > + * Copyright (C) 2022 Google LLC. > + */ > +#ifndef _CGROUP_GPU_H > +#define _CGROUP_GPU_H > + > +#include > + > +#define GPUCG_BUCKET_NAME_MAX_LEN 64 > + > +struct gpucg; > +struct gpucg_bucket; > + > +#ifdef CONFIG_CGROUP_GPU > + > +/** > + * css_to_gpucg - get the corresponding gpucg ref from a cgroup_subsys_state > + * @css: the target cgroup_subsys_state > + * > + * Returns: gpu cgroup that contains the @css > + */ > +struct gpucg *css_to_gpucg(struct cgroup_subsys_state *css); > + > +/** > + * gpucg_get - get the gpucg reference that a task belongs to > + * @task: the target task > + * > + * This increases the reference count of the css that the @task belongs to. > + * > + * Returns: reference to the gpu cgroup the task belongs to. > + */ > +struct gpucg *gpucg_get(struct task_struct *task); > + > +/** > + * gpucg_put - put a gpucg reference > + * @gpucg: the target gpucg > + * > + * Put a reference obtained via gpucg_get > + */ > +void gpucg_put(struct gpucg *gpucg); > + > +/** > + * gpucg_parent - find the parent of a gpu cgroup > + * @cg: the target gpucg > + * > + * This does not increase the reference count of the parent cgroup > + * > + * Returns: parent gpu cgroup of @cg > + */ > +struct gpucg *gpucg_parent(struct gpucg *cg); > + > +/** > + * gpucg_charge - charge memory to the specified gpucg and gpucg_bucket. > + * Caller must hold a reference to @gpucg obtained through gpucg_get(). The > size of the memory is > + * rounded up to be a multiple of the page size. > + * > + * @gpucg: The gpu cgroup to charge the memory to. > + * @bucket: The bucket to charge the memory to. > + * @size: The size of memory to charge in bytes. > + *This size will be rounded up to the nearest page size. > + * > + * Return: returns 0 if the charging is successful and otherwise returns an > error code. > + */ > +int gpucg_charge(struct gpucg *gpucg, struct gpucg_bucket *bucket, u64 size); > + > +/** > + * gpucg_uncharge - uncharge memory from the specified gpucg and > gpucg_bucket. > + * The caller must hold a reference to @gpucg obtained through gpucg_get(). > + * > + * @gpucg: The gpu cgroup to uncharge the memory from. > + * @bucket: The bucket to uncharge the memory from. > + * @size: The size of memory to uncharge
Re:
On Thu, 19 May 2022 at 10:55, Christian König wrote: > > Just sending that out once more to intel-gfx to let the CI systems take > a look. If all went well it should normally appear at [1][2], if CI was able to pick up the series. Since it's not currently there, I assume it's temporarily stuck in the moderation queue, assuming you are not subscribed to intel-gfx ml? If so, perhaps consider subscribing at [3] and then disable receiving any mail from the ml, so you get full use of CI without getting spammed. [1] https://intel-gfx-ci.01.org/queue/index.html [2] https://patchwork.freedesktop.org/project/intel-gfx/series/ [3] https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > No functional change compared to the last version. > > Christian. > >
[PATCH 06/11] drm/ttm: rename and cleanup ttm_bo_init_reserved
Rename ttm_bo_init_reserved to ttm_bo_init_validate since that better
matches what the function is actually doing.
Remove the unused size parameter, move the function's kerneldoc to the
implementation and cleanup the whole error handling.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 5 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
drivers/gpu/drm/qxl/qxl_object.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 92 ++
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 12 ++-
include/drm/ttm/ttm_bo_api.h | 44 +--
9 files changed, 75 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 5444515c1476..116c8d31e646 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -590,7 +590,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
if (!bp->destroy)
bp->destroy = _bo_destroy;
- r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, bp->type,
+ r = ttm_bo_init_validate(>mman.bdev, >tbo, bp->type,
>placement, page_align, , NULL,
bp->resv, bp->destroy);
if (unlikely(r != 0))
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 7449cbc2f925..73e91baccea0 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -226,7 +226,7 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
drm_device *dev,
* A failing ttm_bo_init will call ttm_buffer_object_destroy
* to release gbo->bo.base and kfree gbo.
*/
- ret = ttm_bo_init_reserved(bdev, >bo, size, ttm_bo_type_device,
+ ret = ttm_bo_init_validate(bdev, >bo, ttm_bo_type_device,
>placement, pg_align, , NULL, NULL,
ttm_buffer_object_destroy);
if (ret)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4c25d9b2f138..253188da91eb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1229,9 +1229,8 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
* Similarly, in delayed_destroy, we can't call ttm_bo_put()
* until successful initialization.
*/
- ret = ttm_bo_init_reserved(>bdev, i915_gem_to_ttm(obj), size,
- bo_type, _sys_placement,
- page_size >> PAGE_SHIFT,
+ ret = ttm_bo_init_validate(>bdev, i915_gem_to_ttm(obj), bo_type,
+ _sys_placement, page_size >> PAGE_SHIFT,
, NULL, NULL, i915_ttm_bo_destroy);
if (ret)
return i915_ttm_err_to_gem(ret);
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 858b9382036c..666941804297 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -308,7 +308,7 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size, int
align, u32 domain,
nouveau_bo_placement_set(nvbo, domain, 0);
INIT_LIST_HEAD(>io_reserve_lru);
- ret = ttm_bo_init_reserved(nvbo->bo.bdev, >bo, size, type,
+ ret = ttm_bo_init_validate(nvbo->bo.bdev, >bo, type,
>placement, align >> PAGE_SHIFT, ,
sg, robj, nouveau_bo_del_ttm);
if (ret) {
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index b42a657e4c2f..da3f76f508ea 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -141,7 +141,7 @@ int qxl_bo_create(struct qxl_device *qdev, unsigned long
size,
qxl_ttm_placement_from_domain(bo, domain);
bo->tbo.priority = priority;
- r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
+ r = ttm_bo_init_validate(>mman.bdev, >tbo, type,
>placement, 0, , NULL, NULL,
_ttm_bo_destroy);
if (unlikely(r != 0)) {
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 1d414ff4ab0c..550ca056b3ac 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -204,7 +204,7 @@ int radeon_bo_create(struct radeon_device *rdev,
radeon_ttm_placement_from_domain(bo, domain);
down_read(>pm.mclk_lock);
- r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
+ r = ttm_bo_init_validate(>mman.bdev, >tbo, type,
[PATCH 03/11] drm/vram-helper: switch over to ttm_bo_init_reserved
Use the new interface instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem_vram_helper.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 123045b58fec..7449cbc2f925 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -186,6 +186,7 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
drm_device *dev,
size_t size,
unsigned long pg_align)
{
+ struct ttm_operation_ctx ctx = { false, false };
struct drm_gem_vram_object *gbo;
struct drm_gem_object *gem;
struct drm_vram_mm *vmm = dev->vram_mm;
@@ -225,12 +226,13 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
drm_device *dev,
* A failing ttm_bo_init will call ttm_buffer_object_destroy
* to release gbo->bo.base and kfree gbo.
*/
- ret = ttm_bo_init(bdev, >bo, size, ttm_bo_type_device,
- >placement, pg_align, false, NULL, NULL,
- ttm_buffer_object_destroy);
- if (ret)
+ ret = ttm_bo_init_reserved(bdev, >bo, size, ttm_bo_type_device,
+ >placement, pg_align, , NULL, NULL,
+ ttm_buffer_object_destroy);
+if (ret)
return ERR_PTR(ret);
+ ttm_bo_unreserve(>bo);
return gbo;
}
EXPORT_SYMBOL(drm_gem_vram_create);
--
2.25.1
[PATCH 02/11] drm/nouveau: switch over to ttm_bo_init_reserved
Use the new interface instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 05076e530e7d..858b9382036c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -302,19 +302,23 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size, int
align, u32 domain,
struct sg_table *sg, struct dma_resv *robj)
{
int type = sg ? ttm_bo_type_sg : ttm_bo_type_device;
+ struct ttm_operation_ctx ctx = { false, false };
int ret;
nouveau_bo_placement_set(nvbo, domain, 0);
INIT_LIST_HEAD(>io_reserve_lru);
- ret = ttm_bo_init(nvbo->bo.bdev, >bo, size, type,
- >placement, align >> PAGE_SHIFT, false, sg,
- robj, nouveau_bo_del_ttm);
+ ret = ttm_bo_init_reserved(nvbo->bo.bdev, >bo, size, type,
+ >placement, align >> PAGE_SHIFT, ,
+ sg, robj, nouveau_bo_del_ttm);
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
return ret;
}
+ if (!robj)
+ ttm_bo_unreserve(>bo);
+
return 0;
}
--
2.25.1
[PATCH 07/11] drm/amdgpu: audit bo->resource usage
Make sure we can at least move and release BOs without backing store.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 116c8d31e646..5cf3a58bc925 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1302,7 +1302,7 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object
*bo)
if (bo->base.resv == >base._resv)
amdgpu_amdkfd_remove_fence_on_pt_pd_bos(abo);
- if (bo->resource->mem_type != TTM_PL_VRAM ||
+ if (!bo->resource || bo->resource->mem_type != TTM_PL_VRAM ||
!(abo->flags & AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE) ||
adev->in_suspend || adev->shutdown)
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index ec26edd4f4d8..b79c93812342 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -471,7 +471,8 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo,
bool evict,
adev = amdgpu_ttm_adev(bo->bdev);
- if (old_mem->mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
+ if (!old_mem || (old_mem->mem_type == TTM_PL_SYSTEM &&
+bo->ttm == NULL)) {
ttm_bo_move_null(bo, new_mem);
goto out;
}
--
2.25.1
[PATCH 09/11] drm/ttm: audit bo->resource usage
Allow BOs to exist without backing store.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2b01cb30694a..a55564c8b57c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -117,12 +117,13 @@ static int ttm_bo_handle_move_mem(struct
ttm_buffer_object *bo,
struct ttm_operation_ctx *ctx,
struct ttm_place *hop)
{
- struct ttm_resource_manager *old_man, *new_man;
struct ttm_device *bdev = bo->bdev;
+ bool old_use_tt, new_use_tt;
int ret;
- old_man = ttm_manager_type(bdev, bo->resource->mem_type);
- new_man = ttm_manager_type(bdev, mem->mem_type);
+ old_use_tt = bo->resource &&
+ ttm_manager_type(bdev, bo->resource->mem_type)->use_tt;
+ new_use_tt = ttm_manager_type(bdev, mem->mem_type)->use_tt;
ttm_bo_unmap_virtual(bo);
@@ -130,11 +131,11 @@ static int ttm_bo_handle_move_mem(struct
ttm_buffer_object *bo,
* Create and bind a ttm if required.
*/
- if (new_man->use_tt) {
+ if (new_use_tt) {
/* Zero init the new TTM structure if the old location should
* have used one as well.
*/
- ret = ttm_tt_create(bo, old_man->use_tt);
+ ret = ttm_tt_create(bo, old_use_tt);
if (ret)
goto out_err;
@@ -160,8 +161,7 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
return 0;
out_err:
- new_man = ttm_manager_type(bdev, bo->resource->mem_type);
- if (!new_man->use_tt)
+ if (!old_use_tt)
ttm_bo_tt_destroy(bo);
return ret;
@@ -898,7 +898,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
/*
* Check whether we need to move buffer.
*/
- if (!ttm_resource_compat(bo->resource, placement)) {
+ if (!bo->resource || !ttm_resource_compat(bo->resource, placement)) {
ret = ttm_bo_move_buffer(bo, placement, ctx);
if (ret)
return ret;
--
2.25.1
[PATCH 10/11] drm/ttm: stop allocating dummy resources during BO creation
That should not be necessary any more when drivers should at least be
able to handle the move without a resource.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a55564c8b57c..31aa4b040d1e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -954,7 +954,6 @@ int ttm_bo_init_validate(struct ttm_device *bdev, struct
ttm_buffer_object *bo,
struct sg_table *sg, struct dma_resv *resv,
void (*destroy) (struct ttm_buffer_object *))
{
- static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
int ret;
kref_init(>kref);
@@ -972,12 +971,6 @@ int ttm_bo_init_validate(struct ttm_device *bdev, struct
ttm_buffer_object *bo,
bo->base.resv = >base._resv;
atomic_inc(_glob.bo_count);
- ret = ttm_resource_alloc(bo, _mem, >resource);
- if (unlikely(ret)) {
- ttm_bo_put(bo);
- return ret;
- }
-
/*
* For ttm_bo_type_device buffers, allocate
* address space from the device.
--
2.25.1
[PATCH 08/11] drm/nouveau: audit bo->resource usage
Make sure we can at least move and release BOs without backing store.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 666941804297..fb903c62d322 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1010,7 +1010,8 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
}
/* Fake bo copy. */
- if (old_reg->mem_type == TTM_PL_SYSTEM && !bo->ttm) {
+ if (!old_reg || (old_reg->mem_type == TTM_PL_SYSTEM &&
+!bo->ttm)) {
ttm_bo_move_null(bo, new_reg);
goto out;
}
--
2.25.1
[PATCH 11/11] drm/ttm: stop allocating a dummy resource for pipelined gutting
That should not be necessary any more when drivers should at least be
able to handle a move without a resource.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 1cbfb00c1d65..585fc529cc75 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -600,16 +600,10 @@ EXPORT_SYMBOL(ttm_bo_move_sync_cleanup);
*/
int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
{
- static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
struct ttm_buffer_object *ghost;
- struct ttm_resource *sys_res;
struct ttm_tt *ttm;
int ret;
- ret = ttm_resource_alloc(bo, _mem, _res);
- if (ret)
- return ret;
-
/* If already idle, no need for ghost object dance. */
ret = ttm_bo_wait(bo, false, true);
if (ret != -EBUSY) {
@@ -617,14 +611,13 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
/* See comment below about clearing. */
ret = ttm_tt_create(bo, true);
if (ret)
- goto error_free_sys_mem;
+ return ret;
} else {
ttm_tt_unpopulate(bo->bdev, bo->ttm);
if (bo->type == ttm_bo_type_device)
ttm_tt_mark_for_clear(bo->ttm);
}
ttm_resource_free(bo, >resource);
- ttm_bo_assign_mem(bo, sys_res);
return 0;
}
@@ -641,7 +634,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
ret = ttm_tt_create(bo, true);
swap(bo->ttm, ttm);
if (ret)
- goto error_free_sys_mem;
+ return ret;
ret = ttm_buffer_object_transfer(bo, );
if (ret)
@@ -655,13 +648,9 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
dma_resv_unlock(>base._resv);
ttm_bo_put(ghost);
bo->ttm = ttm;
- ttm_bo_assign_mem(bo, sys_res);
return 0;
error_destroy_tt:
ttm_tt_destroy(bo->bdev, ttm);
-
-error_free_sys_mem:
- ttm_resource_free(bo, _res);
return ret;
}
--
2.25.1
[PATCH 05/11] drm/ttm: drop ttm_bo_init
Not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 26 -
include/drm/ttm/ttm_bo_api.h | 44
2 files changed, 70 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 296af2b89951..e652055b5175 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -985,32 +985,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
}
EXPORT_SYMBOL(ttm_bo_init_reserved);
-int ttm_bo_init(struct ttm_device *bdev,
- struct ttm_buffer_object *bo,
- size_t size,
- enum ttm_bo_type type,
- struct ttm_placement *placement,
- uint32_t page_alignment,
- bool interruptible,
- struct sg_table *sg,
- struct dma_resv *resv,
- void (*destroy) (struct ttm_buffer_object *))
-{
- struct ttm_operation_ctx ctx = { interruptible, false };
- int ret;
-
- ret = ttm_bo_init_reserved(bdev, bo, size, type, placement,
- page_alignment, , sg, resv, destroy);
- if (ret)
- return ret;
-
- if (!resv)
- ttm_bo_unreserve(bo);
-
- return 0;
-}
-EXPORT_SYMBOL(ttm_bo_init);
-
/*
* buffer object vm functions.
*/
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 2d524f8b0802..29384e2cb704 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -361,50 +361,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
struct sg_table *sg, struct dma_resv *resv,
void (*destroy) (struct ttm_buffer_object *));
-/**
- * ttm_bo_init
- *
- * @bdev: Pointer to a ttm_device struct.
- * @bo: Pointer to a ttm_buffer_object to be initialized.
- * @size: Requested size of buffer object.
- * @type: Requested type of buffer object.
- * @placement: Initial placement for buffer object.
- * @page_alignment: Data alignment in pages.
- * @interruptible: If needing to sleep to wait for GPU resources,
- * sleep interruptible.
- * pinned in physical memory. If this behaviour is not desired, this member
- * holds a pointer to a persistent shmem object. Typically, this would
- * point to the shmem object backing a GEM object if TTM is used to back a
- * GEM user interface.
- * @sg: Scatter-gather table.
- * @resv: Pointer to a dma_resv, or NULL to let ttm allocate one.
- * @destroy: Destroy function. Use NULL for kfree().
- *
- * This function initializes a pre-allocated struct ttm_buffer_object.
- * As this object may be part of a larger structure, this function,
- * together with the @destroy function,
- * enables driver-specific objects derived from a ttm_buffer_object.
- *
- * On successful return, the caller owns an object kref to @bo. The kref and
- * list_kref are usually set to 1, but note that in some situations, other
- * tasks may already be holding references to @bo as well.
- *
- * If a failure occurs, the function will call the @destroy function, or
- * kfree() if @destroy is NULL. Thus, after a failure, dereferencing @bo is
- * illegal and will likely cause memory corruption.
- *
- * Returns
- * -ENOMEM: Out of memory.
- * -EINVAL: Invalid placement flags.
- * -ERESTARTSYS: Interrupted by signal while sleeping waiting for resources.
- */
-int ttm_bo_init(struct ttm_device *bdev, struct ttm_buffer_object *bo,
- size_t size, enum ttm_bo_type type,
- struct ttm_placement *placement,
- uint32_t page_alignment, bool interrubtible,
- struct sg_table *sg, struct dma_resv *resv,
- void (*destroy) (struct ttm_buffer_object *));
-
/**
* ttm_kmap_obj_virtual
*
--
2.25.1
[PATCH 04/11] drm/ttm: move default BO destructor into VMWGFX
It's the only driver using this. Signed-off-by: Christian König --- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c index 85a66014c2b6..c4f376d5e1d0 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c @@ -462,6 +462,9 @@ int vmw_bo_create(struct vmw_private *vmw, return -ENOMEM; } + if (!bo_free) + bo_free = vmw_bo_default_destroy; + ret = vmw_bo_init(vmw, *p_bo, size, placement, interruptible, pin, bo_free); -- 2.25.1
[no subject]
Just sending that out once more to intel-gfx to let the CI systems take a look. No functional change compared to the last version. Christian.
[PATCH 01/11] drm/radeon: switch over to ttm_bo_init_reserved
Use the new interface instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_object.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 6c4a6802ca96..1d414ff4ab0c 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -133,9 +133,12 @@ int radeon_bo_create(struct radeon_device *rdev,
struct dma_resv *resv,
struct radeon_bo **bo_ptr)
{
- struct radeon_bo *bo;
- enum ttm_bo_type type;
unsigned long page_align = roundup(byte_align, PAGE_SIZE) >> PAGE_SHIFT;
+
+ /* Kernel allocation are uninterruptible */
+ struct ttm_operation_ctx ctx = { !kernel, false };
+ enum ttm_bo_type type;
+ struct radeon_bo *bo;
int r;
size = ALIGN(size, PAGE_SIZE);
@@ -200,11 +203,13 @@ int radeon_bo_create(struct radeon_device *rdev,
#endif
radeon_ttm_placement_from_domain(bo, domain);
- /* Kernel allocation are uninterruptible */
down_read(>pm.mclk_lock);
- r = ttm_bo_init(>mman.bdev, >tbo, size, type,
- >placement, page_align, !kernel, sg, resv,
- _ttm_bo_destroy);
+ r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
+>placement, page_align, , sg, resv,
+_ttm_bo_destroy);
+if (!r)
+ ttm_bo_unreserve(>tbo);
+
up_read(>pm.mclk_lock);
if (unlikely(r != 0)) {
return r;
--
2.25.1
[CI 3/3] drm/amd/display: Move connector debugfs to drm
As drm_connector already have the display_info, instead of creating
"output_bpc" debugfs in vendor specific driver, move the logic to
the drm layer.
This patch will also move "Current" bpc to the crtc debugfs from
connector debugfs, since we are getting this info from crtc_state.
Cc: Harry Wentland
Cc: Rodrigo Siqueira
Signed-off-by: Bhanuprakash Modem
Reported-by: kernel test robot
Reviewed-by: Arun R Murthy
Reviewed-by: Harry Wentland
Acked-by: Harry Wentland
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 --
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 38 +++
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.h | 2 -
3 files changed, 13 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index f9ce8cb45e6d..dae0b772865c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6617,14 +6617,12 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
return >base;
}
-#ifdef CONFIG_DRM_AMD_SECURE_DISPLAY
static int amdgpu_dm_crtc_late_register(struct drm_crtc *crtc)
{
crtc_debugfs_init(crtc);
return 0;
}
-#endif
static inline int dm_set_vupdate_irq(struct drm_crtc *crtc, bool enable)
{
@@ -6722,9 +6720,7 @@ static const struct drm_crtc_funcs amdgpu_dm_crtc_funcs =
{
.enable_vblank = dm_enable_vblank,
.disable_vblank = dm_disable_vblank,
.get_vblank_timestamp = drm_crtc_vblank_helper_get_vblank_timestamp,
-#if defined(CONFIG_DRM_AMD_SECURE_DISPLAY)
.late_register = amdgpu_dm_crtc_late_register,
-#endif
};
static enum drm_connector_status
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 188039f14544..78f3974ef7b8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -873,28 +873,18 @@ static int psr_capability_show(struct seq_file *m, void
*data)
}
/*
- * Returns the current and maximum output bpc for the connector.
- * Example usage: cat /sys/kernel/debug/dri/0/DP-1/output_bpc
+ * Returns the current bpc for the crtc.
+ * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/amdgpu_current_bpc
*/
-static int output_bpc_show(struct seq_file *m, void *data)
+static int amdgpu_current_bpc_show(struct seq_file *m, void *data)
{
- struct drm_connector *connector = m->private;
- struct drm_device *dev = connector->dev;
- struct drm_crtc *crtc = NULL;
+ struct drm_crtc *crtc = m->private;
+ struct drm_device *dev = crtc->dev;
struct dm_crtc_state *dm_crtc_state = NULL;
int res = -ENODEV;
unsigned int bpc;
mutex_lock(>mode_config.mutex);
- drm_modeset_lock(>mode_config.connection_mutex, NULL);
-
- if (connector->state == NULL)
- goto unlock;
-
- crtc = connector->state->crtc;
- if (crtc == NULL)
- goto unlock;
-
drm_modeset_lock(>mutex, NULL);
if (crtc->state == NULL)
goto unlock;
@@ -924,18 +914,15 @@ static int output_bpc_show(struct seq_file *m, void *data)
}
seq_printf(m, "Current: %u\n", bpc);
- seq_printf(m, "Maximum: %u\n", connector->display_info.bpc);
res = 0;
unlock:
- if (crtc)
- drm_modeset_unlock(>mutex);
-
- drm_modeset_unlock(>mode_config.connection_mutex);
+ drm_modeset_unlock(>mutex);
mutex_unlock(>mode_config.mutex);
return res;
}
+DEFINE_SHOW_ATTRIBUTE(amdgpu_current_bpc);
/*
* Example usage:
@@ -2541,7 +2528,6 @@ static int target_backlight_show(struct seq_file *m, void
*unused)
DEFINE_SHOW_ATTRIBUTE(dp_dsc_fec_support);
DEFINE_SHOW_ATTRIBUTE(dmub_fw_state);
DEFINE_SHOW_ATTRIBUTE(dmub_tracebuffer);
-DEFINE_SHOW_ATTRIBUTE(output_bpc);
DEFINE_SHOW_ATTRIBUTE(dp_lttpr_status);
#ifdef CONFIG_DRM_AMD_DC_HDCP
DEFINE_SHOW_ATTRIBUTE(hdcp_sink_capability);
@@ -2788,7 +2774,6 @@ static const struct {
const struct file_operations *fops;
} connector_debugfs_entries[] = {
{"force_yuv420_output", _yuv420_output_fops},
- {"output_bpc", _bpc_fops},
{"trigger_hotplug", _hotplug_debugfs_fops},
{"internal_display", _display_fops}
};
@@ -3172,9 +3157,10 @@ static int crc_win_update_get(void *data, u64 *val)
DEFINE_DEBUGFS_ATTRIBUTE(crc_win_update_fops, crc_win_update_get,
crc_win_update_set, "%llu\n");
-
+#endif
void crtc_debugfs_init(struct drm_crtc *crtc)
{
+#ifdef CONFIG_DRM_AMD_SECURE_DISPLAY
struct dentry *dir = debugfs_lookup("crc", crtc->debugfs_entry);
if (!dir)
@@ -3190,9 +3176,11 @@ void crtc_debugfs_init(struct drm_crtc *crtc)
_win_y_end_fops);
[CI 2/3] drm/i915/display/debug: Expose crtc current bpc via debugfs
This new debugfs will expose the currently using bpc by crtc.
It is very useful for verifying whether we enter the correct
output color depth from IGT.
This patch will also add the connector's max supported bpc to
"i915_display_info" debugfs.
Example:
cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc
Current: 8
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Uma Shankar
Signed-off-by: Bhanuprakash Modem
Reviewed-by: Arun R Murthy
Acked-by: Jani Nikula
---
.../drm/i915/display/intel_display_debugfs.c | 28 +++
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 452d773fd4e3..6c3954479047 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -590,6 +590,8 @@ static void intel_connector_info(struct seq_file *m,
seq_puts(m, "\tHDCP version: ");
intel_hdcp_info(m, intel_connector);
+ seq_printf(m, "\tmax bpc: %u\n", connector->display_info.bpc);
+
intel_panel_info(m, intel_connector);
seq_printf(m, "\tmodes:\n");
@@ -2202,6 +2204,29 @@ static const struct file_operations i915_dsc_bpp_fops = {
.write = i915_dsc_bpp_write
};
+/*
+ * Returns the Current CRTC's bpc.
+ * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc
+ */
+static int i915_current_bpc_show(struct seq_file *m, void *data)
+{
+ struct intel_crtc *crtc = to_intel_crtc(m->private);
+ struct intel_crtc_state *crtc_state;
+ int ret;
+
+ ret = drm_modeset_lock_single_interruptible(>base.mutex);
+ if (ret)
+ return ret;
+
+ crtc_state = to_intel_crtc_state(crtc->base.state);
+ seq_printf(m, "Current: %u\n", crtc_state->pipe_bpp / 3);
+
+ drm_modeset_unlock(>base.mutex);
+
+ return ret;
+}
+DEFINE_SHOW_ATTRIBUTE(i915_current_bpc);
+
/**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -2272,4 +2297,7 @@ void intel_crtc_debugfs_add(struct drm_crtc *crtc)
crtc_updates_add(crtc);
intel_fbc_crtc_debugfs_add(to_intel_crtc(crtc));
+
+ debugfs_create_file("i915_current_bpc", 0444, crtc->debugfs_entry, crtc,
+ _current_bpc_fops);
}
--
2.35.1
