* Re: linux-next: Tree for Jun 24 [build failure on arm64]
From: Jon Hunter @ 2020-06-24 12:29 UTC (permalink / raw)
To: Will Deacon
Cc: Shaokun Zhang, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-tegra
In-Reply-To: <20200624122242.GA6270@willie-the-truck>
On 24/06/2020 13:22, Will Deacon wrote:
> On Wed, Jun 24, 2020 at 12:57:23PM +0100, Jon Hunter wrote:
>> On 24/06/2020 11:55, Will Deacon wrote:
>>> diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
>>> index 1e5a940532da..97d3d3632093 100644
>>> --- a/arch/arm64/kernel/vdso/Makefile
>>> +++ b/arch/arm64/kernel/vdso/Makefile
>>> @@ -23,8 +23,9 @@ btildflags-$(CONFIG_ARM64_BTI_KERNEL) += -z force-bti
>>> # potential future proofing if we end up with internal calls to the exported
>>> # routines, as x86 does (see 6f121e548f83 ("x86, vdso: Reimplement vdso.so
>>> # preparation in build-time C")).
>>> -ldflags-y := -shared -nostdlib -soname=linux-vdso.so.1 --hash-style=sysv \
>>> - -Bsymbolic --no-eh-frame-hdr --build-id -n $(btildflags-y) -T
>>> +ldflags-y := -shared -nostdlib -soname=linux-vdso.so.1 --hash-style=sysv \
>>> + -Bsymbolic $(call ld-option, --no-eh-frame-hdr) --build-id -n \
>>> + $(btildflags-y) -T
>>>
>>> ccflags-y := -fno-common -fno-builtin -fno-stack-protector -ffixed-x18
>>> ccflags-y += -DDISABLE_BRANCH_PROFILING
>>>
>>
>>
>> I am seeing the same build failure and the above does fix it for me.
>
> Cheers, Jon. I'll get this into -next with your Tested-by.
Thanks, that will be great.
Jon
--
nvpublic
^ permalink raw reply
* Re: linux-next: Tree for Jun 24 [build failure on arm64]
From: Will Deacon @ 2020-06-24 12:22 UTC (permalink / raw)
To: Jon Hunter
Cc: Shaokun Zhang, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-tegra
In-Reply-To: <b561e663-a9aa-d600-e23b-09793199141e@nvidia.com>
On Wed, Jun 24, 2020 at 12:57:23PM +0100, Jon Hunter wrote:
> On 24/06/2020 11:55, Will Deacon wrote:
> > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> > index 1e5a940532da..97d3d3632093 100644
> > --- a/arch/arm64/kernel/vdso/Makefile
> > +++ b/arch/arm64/kernel/vdso/Makefile
> > @@ -23,8 +23,9 @@ btildflags-$(CONFIG_ARM64_BTI_KERNEL) += -z force-bti
> > # potential future proofing if we end up with internal calls to the exported
> > # routines, as x86 does (see 6f121e548f83 ("x86, vdso: Reimplement vdso.so
> > # preparation in build-time C")).
> > -ldflags-y := -shared -nostdlib -soname=linux-vdso.so.1 --hash-style=sysv \
> > - -Bsymbolic --no-eh-frame-hdr --build-id -n $(btildflags-y) -T
> > +ldflags-y := -shared -nostdlib -soname=linux-vdso.so.1 --hash-style=sysv \
> > + -Bsymbolic $(call ld-option, --no-eh-frame-hdr) --build-id -n \
> > + $(btildflags-y) -T
> >
> > ccflags-y := -fno-common -fno-builtin -fno-stack-protector -ffixed-x18
> > ccflags-y += -DDISABLE_BRANCH_PROFILING
> >
>
>
> I am seeing the same build failure and the above does fix it for me.
Cheers, Jon. I'll get this into -next with your Tested-by.
Will
^ permalink raw reply
* Re: linux-next: Tree for Jun 24 [build failure on arm64]
From: Jon Hunter @ 2020-06-24 11:57 UTC (permalink / raw)
To: Will Deacon, Shaokun Zhang
Cc: Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-tegra
In-Reply-To: <20200624105528.GB6134@willie-the-truck>
On 24/06/2020 11:55, Will Deacon wrote:
> On Wed, Jun 24, 2020 at 05:08:56PM +0800, Shaokun Zhang wrote:
>> +Will Deacon,
>>
>> Hi Will,
>>
>> There's a build failure on arm64:
>>
>> CALL scripts/atomic/check-atomics.sh
>> CALL scripts/checksyscalls.sh
>> LD arch/arm64/kernel/vdso/vdso.so.dbg
>> ld: unrecognized option '--no-eh-frame-hdr'
>> ld: use the --help option for usage information
>> arch/arm64/kernel/vdso/Makefile:64: recipe for target
>> 'arch/arm64/kernel/vdso/vdso.so.dbg' failed
>> make[1]: *** [arch/arm64/kernel/vdso/vdso.so.dbg] Error 1
>> arch/arm64/Makefile:175: recipe for target 'vdso_prepare' failed
>> make: *** [vdso_prepare] Error 2
>>
>> GCC version is followed:
>> gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
>>
>> It seems caused by
>> 87676cfca141 arm64: vdso: Disable dwarf unwinding through the sigreturn
>> trampoline
>
> Urgh, binutils quality strikes again. If you're able to reproduce locally,
> can you try the diff below, please? All the linkers I have kicking around
> seem to support --no-eh-frame-hdr.
>
> Will
>
> --->8
>
> diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> index 1e5a940532da..97d3d3632093 100644
> --- a/arch/arm64/kernel/vdso/Makefile
> +++ b/arch/arm64/kernel/vdso/Makefile
> @@ -23,8 +23,9 @@ btildflags-$(CONFIG_ARM64_BTI_KERNEL) += -z force-bti
> # potential future proofing if we end up with internal calls to the exported
> # routines, as x86 does (see 6f121e548f83 ("x86, vdso: Reimplement vdso.so
> # preparation in build-time C")).
> -ldflags-y := -shared -nostdlib -soname=linux-vdso.so.1 --hash-style=sysv \
> - -Bsymbolic --no-eh-frame-hdr --build-id -n $(btildflags-y) -T
> +ldflags-y := -shared -nostdlib -soname=linux-vdso.so.1 --hash-style=sysv \
> + -Bsymbolic $(call ld-option, --no-eh-frame-hdr) --build-id -n \
> + $(btildflags-y) -T
>
> ccflags-y := -fno-common -fno-builtin -fno-stack-protector -ffixed-x18
> ccflags-y += -DDISABLE_BRANCH_PROFILING
>
I am seeing the same build failure and the above does fix it for me.
Thanks
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH] dt-bindings: thermal: Get rid of thermal.txt and replace references
From: Amit Kucheria @ 2020-06-24 10:57 UTC (permalink / raw)
To: Rob Herring
Cc: LKML, linux-arm-msm, Lukasz Luba, Daniel Lezcano, Sudeep Holla,
Rafael J. Wysocki, Viresh Kumar, Jean Delvare, Guenter Roeck,
Vasily Khoruzhick, Yangtao Li, Zhang Rui, Maxime Ripard,
Chen-Yu Tsai, Talel Shenhar, Nicolas Saenz Julienne,
Florian Fainelli, Ray Jui, Scott Branden, BROADCOM
In-Reply-To: <20200414164357.GA11178@bogus>
On Tue, Apr 14, 2020 at 10:14 PM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, 1 Apr 2020 20:35:50 +0530, Amit Kucheria wrote:
> > Now that we have yaml bindings for the thermal subsystem, get rid of the
> > old bindings (thermal.txt).
> >
> > Replace all references to thermal.txt in the Documentation with a link
> > to the appropriate YAML bindings using the following search and replace
> > pattern:
> > - If the reference is specific to the thermal-sensor-cells property,
> > replace with a pointer to thermal-sensor.yaml
> > - If the reference is to the cooling-cells property, replace with a
> > pointer to thermal-cooling-devices.yaml
> > - If the reference is generic thermal bindings, replace with a
> > reference to thermal*.yaml.
> >
> > Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> > ---
> > .../devicetree/bindings/arm/arm,scmi.txt | 2 +-
> > .../devicetree/bindings/arm/arm,scpi.txt | 2 +-
> > .../arm/marvell/ap80x-system-controller.txt | 2 +-
> > .../arm/marvell/cp110-system-controller.txt | 2 +-
> > .../bindings/cpufreq/cpufreq-dt.txt | 3 +-
> > .../bindings/cpufreq/cpufreq-mediatek.txt | 4 +-
> > .../devicetree/bindings/hwmon/gpio-fan.txt | 3 +-
> > .../devicetree/bindings/hwmon/lm90.txt | 4 +-
> > .../thermal/allwinner,sun8i-a83t-ths.yaml | 2 +-
> > .../bindings/thermal/amazon,al-thermal.txt | 2 +-
> > .../bindings/thermal/brcm,avs-ro-thermal.yaml | 2 +-
> > .../bindings/thermal/brcm,bcm2835-thermal.txt | 2 +-
> > .../bindings/thermal/hisilicon-thermal.txt | 2 +-
> > .../bindings/thermal/max77620_thermal.txt | 6 +-
> > .../bindings/thermal/mediatek-thermal.txt | 2 +-
> > .../thermal/nvidia,tegra124-soctherm.txt | 10 +-
> > .../thermal/nvidia,tegra186-bpmp-thermal.txt | 2 +-
> > .../bindings/thermal/qcom-spmi-temp-alarm.txt | 2 +-
> > .../bindings/thermal/rockchip-thermal.txt | 2 +-
> > .../bindings/thermal/tango-thermal.txt | 2 +-
> > .../bindings/thermal/thermal-generic-adc.txt | 2 +-
> > .../devicetree/bindings/thermal/thermal.txt | 586 ------------------
> > .../bindings/thermal/uniphier-thermal.txt | 2 +-
> > 23 files changed, 33 insertions(+), 615 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
> >
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Daniel, Rob,
This seems to have been missed in the 5.8 merge window. I suspect this
should go in through the thermal tree.
Regards,
Amit
^ permalink raw reply
* Re: [PATCH 5.7 000/474] 5.7.6-rc2 review
From: Jon Hunter @ 2020-06-24 10:32 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, shuah-DgEjT+Ai2ygdnm+yROfE0A,
patches-ssFOTAMYnuFg9hUCZPvPmw,
ben.hutchings-4yDnlxn2s6sWdaTGBSpHTA,
lkft-triage-cunTk1MwBs8s++Sfvej+rw, stable-u79uwXL29TY76Z2rM5mHXA,
linux-tegra
In-Reply-To: <20200624055938.609070954-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
On 24/06/2020 07:10, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.7.6 release.
> There are 474 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 26 Jun 2020 05:58:09 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.6-rc2.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.7.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v5.7:
11 builds: 11 pass, 0 fail
26 boots: 26 pass, 0 fail
56 tests: 56 pass, 0 fail
Linux version: 5.7.6-rc2-ga5e7ca280376
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 5.4 000/311] 5.4.49-rc2 review
From: Jon Hunter @ 2020-06-24 10:32 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, shuah-DgEjT+Ai2ygdnm+yROfE0A,
patches-ssFOTAMYnuFg9hUCZPvPmw,
ben.hutchings-4yDnlxn2s6sWdaTGBSpHTA,
lkft-triage-cunTk1MwBs8s++Sfvej+rw, stable-u79uwXL29TY76Z2rM5mHXA,
linux-tegra
In-Reply-To: <20200624055926.651441497-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
On 24/06/2020 07:10, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.49 release.
> There are 311 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 26 Jun 2020 05:58:23 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.49-rc2.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v5.4:
11 builds: 11 pass, 0 fail
26 boots: 26 pass, 0 fail
56 tests: 56 pass, 0 fail
Linux version: 5.4.49-rc2-gf7f032930408
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 4.19 000/203] 4.19.130-rc2 review
From: Jon Hunter @ 2020-06-24 10:31 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, shuah-DgEjT+Ai2ygdnm+yROfE0A,
patches-ssFOTAMYnuFg9hUCZPvPmw,
ben.hutchings-4yDnlxn2s6sWdaTGBSpHTA,
lkft-triage-cunTk1MwBs8s++Sfvej+rw, stable-u79uwXL29TY76Z2rM5mHXA,
linux-tegra
In-Reply-To: <20200624055901.258687997-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
On 24/06/2020 07:10, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.130 release.
> There are 203 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 26 Jun 2020 05:58:19 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.130-rc2.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v4.19:
11 builds: 11 pass, 0 fail
22 boots: 22 pass, 0 fail
38 tests: 38 pass, 0 fail
Linux version: 4.19.130-rc2-gf12dcdbf9d54
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 4.14 000/135] 4.14.186-rc2 review
From: Jon Hunter @ 2020-06-24 10:31 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, shuah-DgEjT+Ai2ygdnm+yROfE0A,
patches-ssFOTAMYnuFg9hUCZPvPmw,
ben.hutchings-4yDnlxn2s6sWdaTGBSpHTA,
lkft-triage-cunTk1MwBs8s++Sfvej+rw, stable-u79uwXL29TY76Z2rM5mHXA,
linux-tegra
In-Reply-To: <20200624055849.358124048-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
On 24/06/2020 07:09, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.186 release.
> There are 135 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 26 Jun 2020 05:58:15 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.186-rc2.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v4.14:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
30 tests: 30 pass, 0 fail
Linux version: 4.14.186-rc2-g1c6114e25934
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH] [v5] dmaengine: tegra210-adma: Fix runtime PM imbalance on error
From: Vinod Koul @ 2020-06-24 9:42 UTC (permalink / raw)
To: Dinghao Liu
Cc: kjlu, Laxman Dewangan, Jon Hunter, Dan Williams, Thierry Reding,
dmaengine, linux-tegra, linux-kernel
In-Reply-To: <20200624064626.19855-1-dinghao.liu@zju.edu.cn>
On 24-06-20, 14:46, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> when it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.
Applied, thanks
--
~Vinod
^ permalink raw reply
* Re: [PATCH 1/8] drm/atomic-helper: reset vblank on crtc reset
From: Maxime Ripard @ 2020-06-24 9:42 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, Intel Graphics Development, Laurent Pinchart,
Boris Brezillon, Liviu Dudau, Thierry Reding, Tetsuo Handa,
syzbot+0871b14ca2e2fb64f6e3-Pl5Pbv+GP7P466ipTTIvnc23WoclnBCfAL8bYrjMMd8,
James (Qian) Wang, Mihail Atanassov, Brian Starkey, Sam Ravnborg,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches
In-Reply-To: <20200612160056.2082681-1-daniel.vetter-/w4YWyX8dFk@public.gmane.org>
On Fri, Jun 12, 2020 at 06:00:49PM +0200, Daniel Vetter wrote:
> Only when vblanks are supported ofc.
>
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. syzbot spotted this when loading vkms as a secondary
> output. Given how many drivers are buggy it's best to solve this once
> and for all in shared helper code.
>
> Aside from moving the few existing calls to drm_crtc_vblank_reset into
> helpers (i915 doesn't use helpers, so keeps its own) I think the
> regression risk is minimal: atomic helpers already rely on drivers
> calling drm_crtc_vblank_on/off correctly in their hooks when they
> support vblanks. And driver that's failing to handle vblanks after
> this is missing those calls already, and vblanks could only work by
> accident when enabling a CRTC for the first time right after boot.
>
> Big thanks to Tetsuo for helping track down what's going wrong here.
>
> There's only a few drivers which already had the necessary call and
> needed some updating:
> - komeda, atmel and tidss also needed to be changed to call
> __drm_atomic_helper_crtc_reset() intead of open coding it
> - tegra and msm even had it in the same place already, just code
> motion, and malidp already uses __drm_atomic_helper_crtc_reset().
>
> Only call left is in i915, which doesn't use drm_mode_config_reset,
> but has its own fastboot infrastructure. So that's the only case where
> we actually want this in the driver still.
>
> I've also reviewed all other drivers which set up vblank support with
> drm_vblank_init. After the previous patch fixing mxsfb all atomic
> drivers do call drm_crtc_vblank_on/off as they should, the remaining
> drivers are either legacy kms or legacy dri1 drivers, so not affected
> by this change to atomic helpers.
>
> v2: Use the drm_dev_has_vblank() helper.
>
> v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off
> instead of drm_crtc_vblank_reset. Adjust them too.
>
> v4: Laurent noticed that rcar-du and omap open-code their crtc reset
> and hence would actually be broken by this patch now. So fix them up
> by reusing the helpers, which brings the drm_crtc_vblank_reset() back.
>
> Cc: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> Reviewed-by: Boris Brezillon <boris.brezillon-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> Acked-by: Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org>
> Acked-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Link: https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> Reported-by: Tetsuo Handa <penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
> Reported-by: syzbot+0871b14ca2e2fb64f6e3-Pl5Pbv+GP7P466ipTTIvnc23WoclnBCfAL8bYrjMMd8@public.gmane.org
> Cc: Tetsuo Handa <penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
> Cc: "James (Qian) Wang" <james.qian.wang-5wv7dgnIgG8@public.gmane.org>
> Cc: Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org>
> Cc: Mihail Atanassov <mihail.atanassov-5wv7dgnIgG8@public.gmane.org>
> Cc: Brian Starkey <brian.starkey-5wv7dgnIgG8@public.gmane.org>
> Cc: Sam Ravnborg <sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
> Cc: Boris Brezillon <bbrezillon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Nicolas Ferre <nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> Cc: Alexandre Belloni <alexandre.belloni-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
> Cc: Ludovic Desroches <ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> Cc: Maarten Lankhorst <maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Cc: Maxime Ripard <mripard-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Thomas Zimmermann <tzimmermann-l3A5Bk7waGM@public.gmane.org>
> Cc: David Airlie <airlied-cv59FeDIM0c@public.gmane.org>
> Cc: Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
> Cc: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Cc: Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>
> Cc: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
> Cc: Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Sean Paul <seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Cc: Brian Masney <masneyb-1iNe0GrtECGEi8DpZVb4nw@public.gmane.org>
> Cc: Emil Velikov <emil.velikov-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> Cc: zhengbin <zhengbin13-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
> Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Kieran Bingham <kieran.bingham+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Daniel Vetter <daniel.vetter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Acked-by: Maxime Ripard <mripard-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Maxime
^ permalink raw reply
* Re: [PATCH] [v5] dmaengine: tegra210-adma: Fix runtime PM imbalance on error
From: Jon Hunter @ 2020-06-24 8:58 UTC (permalink / raw)
To: Dinghao Liu, kjlu-OJFnDUYgAso
Cc: Laxman Dewangan, Dan Williams, Vinod Koul, Thierry Reding,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200624064626.19855-1-dinghao.liu-Y5EWUtBUdg4nDS1+zs4M5A@public.gmane.org>
On 24/06/2020 07:46, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> when it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.
I was hoping you would mention explicitly why we are using _noidle in
the changelog. However, let's not beat the dead horse any more and just
merge this. So ...
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Thanks
Jon
> Signed-off-by: Dinghao Liu <dinghao.liu-Y5EWUtBUdg4nDS1+zs4M5A@public.gmane.org>
> ---
>
> Changelog:
>
> v2: - Merge two patches that fix runtime PM imbalance in
> tegra_adma_probe() and tegra_adma_alloc_chan_resources()
> respectively.
>
> v3: - Use pm_runtime_put_noidle() instead of pm_runtime_put_sync()
> in tegra_adma_alloc_chan_resources(). _noidle() is the simplest
> one and it is sufficient for fixing this bug.
>
> v4: - Use pm_runtime_put_noidle() instead of pm_runtime_put_sync()
> in tegra_adma_probe(). _noidle() is the simplest one and it is
> sufficient for fixing this bug.
>
> v5: - Refine commit message.
> ---
> drivers/dma/tegra210-adma.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
> index db58d7e4f9fe..c5fa2ef74abc 100644
> --- a/drivers/dma/tegra210-adma.c
> +++ b/drivers/dma/tegra210-adma.c
> @@ -658,6 +658,7 @@ static int tegra_adma_alloc_chan_resources(struct dma_chan *dc)
>
> ret = pm_runtime_get_sync(tdc2dev(tdc));
> if (ret < 0) {
> + pm_runtime_put_noidle(tdc2dev(tdc));
> free_irq(tdc->irq, tdc);
> return ret;
> }
> @@ -869,8 +870,10 @@ static int tegra_adma_probe(struct platform_device *pdev)
> pm_runtime_enable(&pdev->dev);
>
> ret = pm_runtime_get_sync(&pdev->dev);
> - if (ret < 0)
> + if (ret < 0) {
> + pm_runtime_put_noidle(&pdev->dev);
> goto rpm_disable;
> + }
>
> ret = tegra_adma_init(tdma);
> if (ret)
>
--
nvpublic
^ permalink raw reply
* [PATCH] [v5] dmaengine: tegra210-adma: Fix runtime PM imbalance on error
From: Dinghao Liu @ 2020-06-24 6:46 UTC (permalink / raw)
To: dinghao.liu-Y5EWUtBUdg4nDS1+zs4M5A, kjlu-OJFnDUYgAso
Cc: Laxman Dewangan, Jon Hunter, Dan Williams, Vinod Koul,
Thierry Reding, dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu <dinghao.liu-Y5EWUtBUdg4nDS1+zs4M5A@public.gmane.org>
---
Changelog:
v2: - Merge two patches that fix runtime PM imbalance in
tegra_adma_probe() and tegra_adma_alloc_chan_resources()
respectively.
v3: - Use pm_runtime_put_noidle() instead of pm_runtime_put_sync()
in tegra_adma_alloc_chan_resources(). _noidle() is the simplest
one and it is sufficient for fixing this bug.
v4: - Use pm_runtime_put_noidle() instead of pm_runtime_put_sync()
in tegra_adma_probe(). _noidle() is the simplest one and it is
sufficient for fixing this bug.
v5: - Refine commit message.
---
drivers/dma/tegra210-adma.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index db58d7e4f9fe..c5fa2ef74abc 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -658,6 +658,7 @@ static int tegra_adma_alloc_chan_resources(struct dma_chan *dc)
ret = pm_runtime_get_sync(tdc2dev(tdc));
if (ret < 0) {
+ pm_runtime_put_noidle(tdc2dev(tdc));
free_irq(tdc->irq, tdc);
return ret;
}
@@ -869,8 +870,10 @@ static int tegra_adma_probe(struct platform_device *pdev)
pm_runtime_enable(&pdev->dev);
ret = pm_runtime_get_sync(&pdev->dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_noidle(&pdev->dev);
goto rpm_disable;
+ }
ret = tegra_adma_init(tdma);
if (ret)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] usb: phy: tegra: Remove unnecessary spaces and tables
From: Felipe Balbi @ 2020-06-24 6:45 UTC (permalink / raw)
To: gregkh, thierry.reding, jonathanh
Cc: linux-usb, linux-tegra, linux-kernel, Tang Bin
In-Reply-To: <20200528112859.6160-1-tangbin@cmss.chinamobile.com>
[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]
Hi,
Tang Bin <tangbin@cmss.chinamobile.com> writes:
> The macros in phy-tegra-usb.c have inconsistent sapces between
> the macro name and the value. Thus sets all the macros to have
> a signal space between the name and value.
>
> Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
> ---
> drivers/usb/phy/phy-tegra-usb.c | 214 ++++++++++++++++----------------
> 1 file changed, 107 insertions(+), 107 deletions(-)
>
> diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
> index 6153cc35a..c294dc617 100644
> --- a/drivers/usb/phy/phy-tegra-usb.c
> +++ b/drivers/usb/phy/phy-tegra-usb.c
> @@ -30,124 +30,124 @@
> #include <linux/usb/tegra_usb_phy.h>
> #include <linux/usb/ulpi.h>
>
> -#define ULPI_VIEWPORT 0x170
> +#define ULPI_VIEWPORT 0x170
>
> /* PORTSC PTS/PHCD bits, Tegra20 only */
> -#define TEGRA_USB_PORTSC1 0x184
> -#define TEGRA_USB_PORTSC1_PTS(x) (((x) & 0x3) << 30)
> -#define TEGRA_USB_PORTSC1_PHCD BIT(23)
> +#define TEGRA_USB_PORTSC1 0x184
> +#define TEGRA_USB_PORTSC1_PTS(x) (((x) & 0x3) << 30)
> +#define TEGRA_USB_PORTSC1_PHCD BIT(23)
the idea was the line up the definitions. I'm not taking this, sorry.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* [PATCH AUTOSEL 5.4 13/24] pinctrl: tegra: Use noirq suspend/resume callbacks
From: Sasha Levin @ 2020-06-23 17:35 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Vidya Sagar, Dmitry Osipenko, Linus Walleij, Sasha Levin,
linux-gpio, linux-tegra
In-Reply-To: <20200623173559.1355728-1-sashal@kernel.org>
From: Vidya Sagar <vidyas@nvidia.com>
[ Upstream commit 782b6b69847f34dda330530493ea62b7de3fd06a ]
Use noirq suspend/resume callbacks as other drivers which implement
noirq suspend/resume callbacks (Ex:- PCIe) depend on pinctrl driver to
configure the signals used by their respective devices in the noirq phase.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20200604174935.26560-1-vidyas@nvidia.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/pinctrl/tegra/pinctrl-tegra.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c b/drivers/pinctrl/tegra/pinctrl-tegra.c
index e9a7cbb9aa336..01bcef2c01bcf 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra.c
+++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
@@ -685,8 +685,8 @@ static int tegra_pinctrl_resume(struct device *dev)
}
const struct dev_pm_ops tegra_pinctrl_pm = {
- .suspend = &tegra_pinctrl_suspend,
- .resume = &tegra_pinctrl_resume
+ .suspend_noirq = &tegra_pinctrl_suspend,
+ .resume_noirq = &tegra_pinctrl_resume
};
static bool gpio_node_has_range(const char *compatible)
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.7 14/28] pinctrl: tegra: Use noirq suspend/resume callbacks
From: Sasha Levin @ 2020-06-23 17:35 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA
Cc: Vidya Sagar, Dmitry Osipenko, Linus Walleij, Sasha Levin,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200623173523.1355411-1-sashal-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
From: Vidya Sagar <vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[ Upstream commit 782b6b69847f34dda330530493ea62b7de3fd06a ]
Use noirq suspend/resume callbacks as other drivers which implement
noirq suspend/resume callbacks (Ex:- PCIe) depend on pinctrl driver to
configure the signals used by their respective devices in the noirq phase.
Signed-off-by: Vidya Sagar <vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Reviewed-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Link: https://lore.kernel.org/r/20200604174935.26560-1-vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Sasha Levin <sashal-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
drivers/pinctrl/tegra/pinctrl-tegra.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c b/drivers/pinctrl/tegra/pinctrl-tegra.c
index 21661f6490d68..195cfe557511b 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra.c
+++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
@@ -731,8 +731,8 @@ static int tegra_pinctrl_resume(struct device *dev)
}
const struct dev_pm_ops tegra_pinctrl_pm = {
- .suspend = &tegra_pinctrl_suspend,
- .resume = &tegra_pinctrl_resume
+ .suspend_noirq = &tegra_pinctrl_suspend,
+ .resume_noirq = &tegra_pinctrl_resume
};
static bool tegra_pinctrl_gpio_node_has_range(struct tegra_pmx *pmx)
--
2.25.1
^ permalink raw reply related
* [PATCH] arm64: tegra: Enable VI/CSI support on Jetson Nano
From: Thierry Reding @ 2020-06-23 16:31 UTC (permalink / raw)
To: Thierry Reding
Cc: Jon Hunter, Sowjanya Komatineni,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Enable the VI and CSI controllers on Jetson Nano. Note that this doesn't
hook up any camera sensors and will only allow testing the capturing of
images from the test pattern generator.
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
index 4eb51e5eef3a..c924163a9115 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
@@ -61,6 +61,16 @@ dpaux@54040000 {
status = "okay";
};
+ vi@54080000 {
+ status = "okay";
+
+ avdd-dsi-csi-supply = <&vdd_sys_1v2>;
+
+ csi@838 {
+ status = "okay";
+ };
+ };
+
sor@54540000 {
status = "okay";
--
2.27.0
^ permalink raw reply related
* [PATCH v2 2/2] PCI: tegra: Remove PLL power supplies
From: Thierry Reding @ 2020-06-23 14:55 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring
Cc: Jon Hunter, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200623145528.1658337-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
The Tegra PCI controller driver doesn't need to control the PLL power
supplies directly, but rather uses the pads provided by the XUSB pad
controller, which in turn is responsible for supplying power to the
PLLs.
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
drivers/pci/controller/pci-tegra.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/controller/pci-tegra.c b/drivers/pci/controller/pci-tegra.c
index 235b456698fc..f87a09d21eb0 100644
--- a/drivers/pci/controller/pci-tegra.c
+++ b/drivers/pci/controller/pci-tegra.c
@@ -2025,7 +2025,7 @@ static int tegra_pcie_get_regulators(struct tegra_pcie *pcie, u32 lane_mask)
pcie->supplies[i++].supply = "hvdd-pex";
pcie->supplies[i++].supply = "vddio-pexctl-aud";
} else if (of_device_is_compatible(np, "nvidia,tegra210-pcie")) {
- pcie->num_supplies = 6;
+ pcie->num_supplies = 3;
pcie->supplies = devm_kcalloc(pcie->dev, pcie->num_supplies,
sizeof(*pcie->supplies),
@@ -2033,14 +2033,11 @@ static int tegra_pcie_get_regulators(struct tegra_pcie *pcie, u32 lane_mask)
if (!pcie->supplies)
return -ENOMEM;
- pcie->supplies[i++].supply = "avdd-pll-uerefe";
pcie->supplies[i++].supply = "hvddio-pex";
pcie->supplies[i++].supply = "dvddio-pex";
- pcie->supplies[i++].supply = "dvdd-pex-pll";
- pcie->supplies[i++].supply = "hvdd-pex-pll-e";
pcie->supplies[i++].supply = "vddio-pex-ctl";
} else if (of_device_is_compatible(np, "nvidia,tegra124-pcie")) {
- pcie->num_supplies = 7;
+ pcie->num_supplies = 4;
pcie->supplies = devm_kcalloc(dev, pcie->num_supplies,
sizeof(*pcie->supplies),
@@ -2050,11 +2047,8 @@ static int tegra_pcie_get_regulators(struct tegra_pcie *pcie, u32 lane_mask)
pcie->supplies[i++].supply = "avddio-pex";
pcie->supplies[i++].supply = "dvddio-pex";
- pcie->supplies[i++].supply = "avdd-pex-pll";
pcie->supplies[i++].supply = "hvdd-pex";
- pcie->supplies[i++].supply = "hvdd-pex-pll-e";
pcie->supplies[i++].supply = "vddio-pex-ctl";
- pcie->supplies[i++].supply = "avdd-pll-erefe";
} else if (of_device_is_compatible(np, "nvidia,tegra30-pcie")) {
bool need_pexa = false, need_pexb = false;
--
2.27.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: pci: tegra: Remove PLL power supplies
From: Thierry Reding @ 2020-06-23 14:55 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring
Cc: Jon Hunter, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
The XUSB pad controller, which provides access to various USB, PCI and
SATA pads (or PHYs), needs to bring up the PLLs associated with these
pads. In order to properly do so, it needs to control the power supplied
to these PLLs.
Remove the PLL power supplies from the PCIe controller because it does
not need direct access to them. Instead it will only use the configured
pads provided by the XUSB pad controller.
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Hi Rob,
I already made this change as part of the conversion series, but wanted
to send this out as part of this subseries since it addresses a fairly
long-standing issue that I'd like to clean up irrespective of the DT
binding conversion. Since it looks like the conversion series will take
a bit longer, I think it makes sense to send this out separately.
Thierry
.../devicetree/bindings/pci/nvidia,tegra20-pcie.txt | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
index 7939bca47861..d099f3476ccc 100644
--- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
@@ -112,28 +112,16 @@ Power supplies for Tegra124:
- Required:
- avddio-pex-supply: Power supply for analog PCIe logic. Must supply 1.05 V.
- dvddio-pex-supply: Power supply for digital PCIe I/O. Must supply 1.05 V.
- - avdd-pex-pll-supply: Power supply for dedicated (internal) PCIe PLL. Must
- supply 1.05 V.
- hvdd-pex-supply: High-voltage supply for PCIe I/O and PCIe output clocks.
Must supply 3.3 V.
- - hvdd-pex-pll-e-supply: High-voltage supply for PLLE (shared with USB3).
- Must supply 3.3 V.
- vddio-pex-ctl-supply: Power supply for PCIe control I/O partition. Must
supply 2.8-3.3 V.
- - avdd-pll-erefe-supply: Power supply for PLLE (shared with USB3). Must
- supply 1.05 V.
Power supplies for Tegra210:
- Required:
- - avdd-pll-uerefe-supply: Power supply for PLLE (shared with USB3). Must
- supply 1.05 V.
- hvddio-pex-supply: High-voltage supply for PCIe I/O and PCIe output
clocks. Must supply 1.8 V.
- dvddio-pex-supply: Power supply for digital PCIe I/O. Must supply 1.05 V.
- - dvdd-pex-pll-supply: Power supply for dedicated (internal) PCIe PLL. Must
- supply 1.05 V.
- - hvdd-pex-pll-e-supply: High-voltage supply for PLLE (shared with USB3).
- Must supply 3.3 V.
- vddio-pex-ctl-supply: Power supply for PCIe control I/O partition. Must
supply 1.8 V.
--
2.27.0
^ permalink raw reply related
* Re: [PATCH v2] Input: document inhibiting
From: Pavel Machek @ 2020-06-23 13:35 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
Cc: linux-pm, linux-acpi, linux-kernel, linux-iio, linux-arm-kernel,
linux-samsung-soc, linux-input, linux-tegra, patches,
ibm-acpi-devel, platform-driver-x86, Rafael J . Wysocki,
Len Brown, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Kukjin Kim, Krzysztof Kozlowski,
Dmitry Torokhov, Shawn Guo, Sascha Hauer
In-Reply-To: <20200617101822.8558-1-andrzej.p@collabora.com>
Hi!
> +Inhibiting input devices
> +~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Inhibiting a device means ignoring input events from it. As such it is about maintaining
> +relationships with input handlers - either already existing relationships, or relationships
> +to be established while the device is in inhibited state.
> +
> +If a device is inhibited, no input handler will receive events from it.
> +
> +The fact that nobody wants events from the device is exploited further, by calling device's
> +close() (if there are users) and open() (if there are users) on inhibit and uninhibit
> +operations, respectively. Indeed, the meaning of close() is to stop providing events
> +to the input core and that of open() is to start providing events to the input core.
> +
> +Calling the device's close() method on inhibit (if there are users) allows the driver
> +to save power. Either by directly powering down the device or by releasing the
> +runtime-pm reference it got in open() when the driver is using runtime-pm.
> +
> +Inhibiting and uninhibiting are orthogonal to opening and closing the device by input
> +handlers. Userspace might want to inhibit a device in anticipation before any handler is
> +positively matched against it.
Ok.
> +Inhibiting and uninhibiting are orthogonal to device's being a wakeup source, too.
> Being a +wakeup source plays a role when the system is sleeping, not when the system is
> operating. +How drivers should program their interaction between inhibiting, sleeping
> and being a wakeup +source is driver-specific. + +Taking the analogy with the network
I don't believe making interaction driver-specific is good idea. We should decide
what reasonable behaviour is and then make drivers implement that...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH v6 1/4] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
From: Thierry Reding @ 2020-06-23 12:47 UTC (permalink / raw)
To: Robin Murphy
Cc: Krishna Reddy, treding-DDmLM1+adcrQT0dZR+AlfA,
bhuntsman-DDmLM1+adcrQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
mperttunen-DDmLM1+adcrQT0dZR+AlfA, talho-DDmLM1+adcrQT0dZR+AlfA,
snikam-DDmLM1+adcrQT0dZR+AlfA, nicolinc-DDmLM1+adcrQT0dZR+AlfA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, yhsu-DDmLM1+adcrQT0dZR+AlfA,
praithatha-DDmLM1+adcrQT0dZR+AlfA, will-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bbiswas-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <5f29c794-406a-db13-d6d0-75dcb0d0b0cc-5wv7dgnIgG8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4181 bytes --]
On Tue, Jun 23, 2020 at 12:16:55PM +0100, Robin Murphy wrote:
> On 2020-06-23 11:29, Thierry Reding wrote:
> [...]
> > > diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
> > > index c75b9d957b702..52c84c30f83e4 100644
> > > --- a/drivers/iommu/arm-smmu-impl.c
> > > +++ b/drivers/iommu/arm-smmu-impl.c
> > > @@ -160,6 +160,9 @@ struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
> > > */
> > > switch (smmu->model) {
> > > case ARM_MMU500:
> > > + if (of_device_is_compatible(smmu->dev->of_node,
> > > + "nvidia,tegra194-smmu-500"))
> > > + return nvidia_smmu_impl_init(smmu);
> >
> > Should NVIDIA_TEGRA194_SMMU be a separate value for smmu->model,
> > perhaps? That way we avoid this somewhat odd check here.
>
> No, this is simply in the wrong place. The design here is that we pick up
> anything related to the basic SMMU IP (model) first, then make any
> platform-specific integration checks. That way a platform-specific init
> function can see the model impl set and subclass it if necessary (although
> nobody's actually done that yet). The setup for Cavium is just a short-cut
> since their model is unique to their integration, so the lines get a bit
> blurred and there's little benefit to trying to separate it out.
>
> In short, put this down below with the other of_device_is_compatible()
> checks.
>
> > > smmu->impl = &arm_mmu500_impl;
> > > break;
> > > case CAVIUM_SMMUV2:
> > > diff --git a/drivers/iommu/arm-smmu-nvidia.c b/drivers/iommu/arm-smmu-nvidia.c
> >
> > I wonder if it would be better to name this arm-smmu-tegra.c to make it
> > clearer that this is for a Tegra chip. We do have regular expressions in
> > MAINTAINERS that catch anything with "tegra" in it to make this easier.
>
> There was a notion that these would be grouped by vendor, but if there's a
> strong preference for all NVIDIA-SoC-related stuff to be named "Tegra" then
> I'm not going to complain too much.
Maybe I was being overly cautious. I was just trying to avoid adding
something called nvidia-arm-smmu which might eventually turn out to be
ambiguous if there was ever a non-Tegra chip and the ARM SMMU
implementation was not compatible with the one instantiated on Tegra.
Note that I have no knowledge of such a chip being designed, so this may
never actually become an issue.
In either case, the compatible string already identifies this as Tegra-
specific, so we could always change the driver name later on if we have
to.
> > > new file mode 100644
> > > index 0000000000000..dafc293a45217
> > > --- /dev/null
> > > +++ b/drivers/iommu/arm-smmu-nvidia.c
> > > @@ -0,0 +1,161 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +// Nvidia ARM SMMU v2 implementation quirks
> >
> > s/Nvidia/NVIDIA/
> >
> > > +// Copyright (C) 2019 NVIDIA CORPORATION. All rights reserved.
> >
> > I suppose this should now also include 2020.
> >
> > > +
> > > +#define pr_fmt(fmt) "nvidia-smmu: " fmt
> >
> > Same here. Might be worth making this "tegra-smmu: " for consistency.
>
> On the other hand, a log prefix that is literally the name of a completely
> unrelated driver seems more confusing to users than useful. Same for the
> function naming - the tegra_smmu_* namespace is already owned by that
> driver.
The ARM SMMU replaced the Tegra SMMU on Tegra186 and later, so both
drivers are never going to run concurrently. The only "problem" might be
that both drivers have symbols with the same prefix, but since they
don't export any of those symbols I don't see how that would become a
real issue.
But then again, the Tegra SMMU is also technically an NVIDIA SMMU, so
sticking with the current name might also be confusing.
Perhaps a good compromise would be to use a "tegra194{-,_}smmu" prefix
instead, which would make this fairly specific to just Tegra194 (and
compatible chips). That's a fairly common pattern we've been following
on Tegra, as you can for example see in drivers/gpio/gpio-tegra186.c,
drivers/dma/tegra210-adma.c, drivers/memory/tegra/tegra186-emc.c, etc.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v6 3/4] iommu/arm-smmu: Add global/context fault implementation hooks
From: Thierry Reding @ 2020-06-23 12:33 UTC (permalink / raw)
To: Robin Murphy
Cc: Krishna Reddy, snikam-DDmLM1+adcrQT0dZR+AlfA,
mperttunen-DDmLM1+adcrQT0dZR+AlfA,
bhuntsman-DDmLM1+adcrQT0dZR+AlfA, will-DgEjT+Ai2ygdnm+yROfE0A,
joro-zLv9SwRftAIdnm+yROfE0A, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
praithatha-DDmLM1+adcrQT0dZR+AlfA, talho-DDmLM1+adcrQT0dZR+AlfA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
nicolinc-DDmLM1+adcrQT0dZR+AlfA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, yhsu-DDmLM1+adcrQT0dZR+AlfA,
treding-DDmLM1+adcrQT0dZR+AlfA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bbiswas-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <2dda4530-39cc-d549-1124-26337dd9afbe-5wv7dgnIgG8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]
On Tue, Jun 23, 2020 at 12:30:16PM +0100, Robin Murphy wrote:
> On 2020-06-23 09:36, Thierry Reding wrote:
> [...]
> > > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > > index 243bc4cb2705b..d720e1e191176 100644
> > > --- a/drivers/iommu/arm-smmu.c
> > > +++ b/drivers/iommu/arm-smmu.c
> > > @@ -673,6 +673,7 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
> > > enum io_pgtable_fmt fmt;
> > > struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> > > struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
> > > + irqreturn_t (*context_fault)(int irq, void *dev);
> > > mutex_lock(&smmu_domain->init_mutex);
> > > if (smmu_domain->smmu)
> > > @@ -835,7 +836,9 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
> > > * handler seeing a half-initialised domain state.
> > > */
> > > irq = smmu->irqs[smmu->num_global_irqs + cfg->irptndx];
> > > - ret = devm_request_irq(smmu->dev, irq, arm_smmu_context_fault,
> > > + context_fault = (smmu->impl && smmu->impl->context_fault) ?
> > > + smmu->impl->context_fault : arm_smmu_context_fault;
> >
> > A simpler way might have been to assign arm_smmu_context_fault to all
> > implementations. That way we wouldn't have to perform this check here
> > and instead just always using smmu->impl->context_fault.
>
> But smmu->impl can still be NULL...
>
> Everything in impl, including the presence of impl itself, is optional, so
> the notion of overriding a default with the same default doesn't really make
> much sense, and would go against the pattern everywhere else.
True. I had assumed that every implementation would set smmu->impl
anyway, in which case there'd be little reason to use these default
fallbacks since each implementation could simply directly refer to the
exact implementation that it wants.
Perhaps the above could be made a bit more palatable by using a standard
if/else rather than the ternary operator? That would also more closely
match the pattern elsewhere.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] [v4] dmaengine: tegra210-adma: Fix runtime PM imbalance on error
From: Jon Hunter @ 2020-06-23 12:25 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Dinghao Liu, Kangjie Lu, Laxman Dewangan, Vinod Koul,
Dan Williams, Thierry Reding, dmaengine, linux-tegra,
Linux Kernel Mailing List
In-Reply-To: <CAMuHMdVu=Tm4UTN1GAc3_uy00UhYYJ7ZPyq1qPCXQ+iP3hksfg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Geert,
On 23/06/2020 13:08, Geert Uytterhoeven wrote:
> Hi Jon,
>
> More stirring in the cesspool ;-)
Ha! Indeed.
> On Tue, Jun 23, 2020 at 12:13 PM Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> On 21/06/2020 06:47, Dinghao Liu wrote:
>>> pm_runtime_get_sync() increments the runtime PM usage counter even
>>> when it returns an error code. Thus a pairing decrement is needed on
>>> the error handling path to keep the counter balanced.
>>
>> So you have not mentioned here why you are using _noidle and not _put.
>> Furthermore, in this patch [0] you are not using _noidle to fix the same
>> problem in another driver. We should fix this in a consistent manner
>> across all drivers, otherwise it leads to more confusion.
>>
>> Finally, Rafael mentions we should just use _put [0] and so I think we
>> should follow his recommendation.
>>
>> Jon
>>
>> [0] https://lkml.org/lkml/2020/5/21/601
>
> "_noidle() is the simplest one and it is sufficient."
> https://lore.kernel.org/linux-i2c/CAJZ5v0i87NGcy9+kxubScdPDyByr8ypQWcGgBFn+V-wDd69BHQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org/
Good to know. This detail should be spelled out in the changelog so that
it is clear why we are using _noidle and not _put. I did take a look and
it did seem to handle the usage_count OK, but I was concerned if there
could be something else in the _put path that may get missed.
Anyway, I am fine with the change, but with an updated changelog on why
_noidle is being used.
> You never know what additional things the other put* variants
> will start doing in the future...
Hopefully not, as that would be a breakage of the API itself. From what
Rafael said that all _put calls should work and if at some point in the
future they don't, then that seems like a regression.
Jon
--
nvpublic
^ permalink raw reply
* Hello.
From: YAVUZ BEKTER @ 2020-06-23 12:15 UTC (permalink / raw)
I am the foreign operations director of Bank of Turkey.
My name is Mr, Yavuz. I have a sensitive investment project to discuss
with you, please reply now.
________________________
Ik ben de directeur buitenlandse activiteiten van de Bank of Turkey.
Mijn naam is meneer Yavuz. Ik moet een gevoelig investeringsproject bespreken
met u, antwoord dan nu.
^ permalink raw reply
* [RFC] Host1x/TegraDRM UAPI
From: Mikko Perttunen @ 2020-06-23 12:09 UTC (permalink / raw)
To: Thierry Reding, Jon Hunter, Dmitry Osipenko, David Airlie,
Daniel Vetter, sumit.semwal-QSEj5FYQhm4dnm+yROfE0A,
gustavo-THi1TnShQwVAfugRpC6u6w
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dri-devel,
talho-DDmLM1+adcrQT0dZR+AlfA, bhuntsman-DDmLM1+adcrQT0dZR+AlfA
# Host1x/TegraDRM UAPI proposal
This is a proposal for a stable UAPI for Host1x and TegraDRM, to replace
the current TegraDRM UAPI that is behind `STAGING` and quite obsolete in
many ways.
I haven't written any implementation yet -- I'll do that once there is
some agreement on the high-level design.
Current open items:
* The syncpoint UAPI allows userspace to create sync_file FDs with
arbitrary syncpoint fences. dma_fence code currently seems to assume all
fences will be signaled, which would not necessarily be the case with
this interface.
* Previously present GEM IOCTLs (GEM_CREATE, GEM_MMAP) are not present.
Not sure if they are still needed.
## Introduction to the hardware
Tegra Host1x is a hardware block providing the following capabilities:
* Syncpoints, a unified whole-system synchronization primitive, allowing
synchronization of work between graphics, compute and multimedia
engines, CPUs including cross-VM synchronization, and devices on the
PCIe bus, without incurring CPU overhead.
* Channels, a command DMA mechanism allowing asynchronous programming of
various engines, integrating with syncpoints.
* Hardware virtualization support for syncpoints and channels. (On
Tegra186 and newer)
This proposal defines APIs for userspace access to syncpoints and
channels. Kernel drivers can additionally use syncpoints and channels
internally, providing other userspace interfaces (e.g. V4L2).
Syncpoint and channel interfaces are split into separate parts, as
syncpoints are useful as a system synchronization primitive even without
using the engine drivers provided through TegraDRM. For example, a
computer vision pipeline consisting of video capture, CPU processing and
GPU processing would not necessarily use the engines provided by
TegraDRM. See the Example workflows section for more details.
## Syncpoint interface
Syncpoints are a set of 32-bit values providing the following operations:
* Atomically increment value by one
* Read current value
* Wait until value reaches specified threshold. For waiting, the 32-bit
value space is treated modulo 2^32; e.g. if the current value is
0xffffffff, then value 0x0 is considered to be one increment in the future.
Each syncpoint is identified by a system-global ID ranging between [0,
number of syncpoints supported by hardware). The entire system has
read-only access to all syncpoints based on their ID.
Syncpoints are managed through the device node /dev/host1x provided by
the gpu/host1x driver.
### IOCTL HOST1X_ALLOCATE_SYNCPOINT (on /dev/host1x)
Allocates a free syncpoint, returning a file descriptor representing it.
Only the owner of the file descriptor is allowed to mutate the value of
the syncpoint.
```
struct host1x_ctrl_allocate_syncpoint {
/**
* @fd:
*
* [out] New file descriptor representing the allocated syncpoint.
*/
__s32 fd;
__u32 reserved[3];
};
```
### IOCTL HOST1X_SYNCPOINT_INFO (on syncpoint file descriptor)
Allows retrieval of system-global syncpoint ID corresponding to syncpoint.
Use cases:
* Passing ID to other system components that identify syncpoints by ID
* Debugging and testing
```
struct host1x_syncpoint_info {
/**
* @id:
*
* [out] System-global ID of the syncpoint.
*/
__u32 id;
__u32 reserved[3];
};
```
### IOCTL HOST1X_SYNCPOINT_INCREMENT (on syncpoint file descriptor)
Allows incrementing of the syncpoint value.
Use cases:
* Signalling work completion when executing a pipeline step on the CPU
* Debugging and testing
```
struct host1x_syncpoint_increment {
/**
* @count:
*
* [in] Number of times to increment syncpoint. Value can be
* observed in in-between values, but increments are atomic.
*/
__u32 count;
};
```
### IOCTL HOST1X_READ_SYNCPOINT (on /dev/host1x)
Read the value of a syncpoint based on its ID.
Use cases:
* Allows more fine-grained tracking of task progression for debugging
purposes
```
struct host1x_ctrl_read_syncpoint {
/**
* @id:
*
* [in] ID of syncpoint to read.
*/
__u32 id;
/**
* @value:
*
* [out] Value of the syncpoint.
*/
__u32 value;
};
```
### IOCTL HOST1X_CREATE_FENCE (on /dev/host1x)
Creates a new SYNC_FILE fence file descriptor for the specified
syncpoint ID and threshold.
Use cases:
* Creating a fence when receiving ID/threshold pair from another system
component
* Creating a postfence when executing a pipeline step on the CPU
* Creating a postfence when executing a pipeline step controlled by
userspace (e.g. GPU userspace submission)
```
struct host1x_ctrl_create_fence {
/**
* @id:
*
* [in] ID of the syncpoint for which to create a fence.
*/
__u32 id;
/**
* @threshold:
*
* [in] Threshold value for fence.
*/
__u32 threshold;
/**
* @fence_fd:
*
* [out] New sync_file FD corresponding to the ID and threshold.
*/
__s32 fence_fd;
__u32 reserved[1];
};
```
### IOCTL HOST1X_GET_FENCE_INFO (on /dev/host1x)
Allows retrieval of the ID/threshold pairs corresponding to a SYNC_FILE
fence or fence array.
Use cases:
* Debugging and testing
* Transmitting a fence to another system component requiring ID/threshold
* Getting ID/threshold for prefence when programming a pipeline step
controlled by userspace (e.g. GPU userspace submission)
```
/* If set, corresponding fence is backed by Host1x syncpoints. */
#define HOST1X_CTRL_FENCE_INFO_SYNCPOINT_FENCE (1 << 0)
struct host1x_ctrl_fence_info {
/**
* @flags:
*
* [out] HOST1X_CTRL_FENCE_INFO flags.
*/
__u32 flags;
/**
* @id:
*
* [out] ID of the syncpoint corresponding to this fence.
* Only set if HOST1X_CTRL_FENCE_INFO_SYNCPOINT_FENCE is set.
*/
__u32 id;
/**
* @threshold:
*
* [out] Signalling threshold of the fence.
* Only set if HOST1X_CTRL_FENCE_INFO_SYNCPOINT_FENCE is set.
*/
__u32 threshold;
__u32 reserved[1];
};
struct host1x_ctrl_get_fence_info {
/**
* @fence_fd:
*
* [in] Syncpoint-backed sync_file FD for which to retrieve info.
*/
__s32 fence_fd;
/**
* @num_fences:
*
* [in] Size of `fence_info` array in elements.
* [out] Number of fences held by the FD.
*/
__u32 num_fences;
/**
* @fence_info:
*
* [in] Pointer to array of 'struct host1x_ctrl_fence_info'
where info will be stored.
*/
__u64 fence_info;
__u32 reserved[1];
};
```
## Channel interface
### DRM_TEGRA_OPEN_CHANNEL
```
struct drm_tegra_open_channel {
/**
* @class:
*
* [in] Host1x class (engine) the channel will target.
*/
__u32 host1x_class;
/**
* @flags:
*
* [in] Flags. Currently none are specified.
*/
__u32 flags;
/**
* @channel_id:
*
* [out] Process-specific identifier corresponding to opened
* channel. Not the hardware channel ID.
*/
__u32 channel_id;
/**
* @hardware_version:
*
* [out] Hardware version of the engine targeted by the channel.
* Userspace can use this to select appropriate programming
* sequences.
*/
__u32 hardware_version;
/**
* @mode:
*
* [out] Mode the hardware is executing in. Some engines can be
* configured with different firmware supporting different
* functionality depending on the system configuration. This
* value allows userspace to detect if the engine is configured
* for the intended use case.
*/
__u32 mode;
__u32 reserved[3];
};
```
### DRM_TEGRA_CLOSE_CHANNEL
```
struct drm_tegra_close_channel {
/**
* @channel_id:
*
* [in] ID of channel to close.
*/
__u32 channel_id;
__u32 reserved[3];
};
```
### DRM_TEGRA_CHANNEL_MAP
Make memory accessible by the engine while executing work on the channel.
```
#define DRM_TEGRA_CHANNEL_MAP_READWRITE (1<<0)
struct drm_tegra_channel_map {
/*
* [in] ID of the channel for which to map memory to.
*/
__u32 channel_id;
/*
* [in] GEM handle of the memory to map.
*/
__u32 handle;
/*
* [in] Offset in GEM handle of the memory area to map.
*
* Must be aligned by 4K.
*/
__u64 offset;
/*
* [in] Length of memory area to map in bytes.
*
* Must be aligned by 4K.
*/
__u64 length;
/*
* [out] IOVA of mapped memory. Userspace can use this IOVA
* directly to refer to the memory to skip using relocations.
* Only available if hardware memory isolation is enabled.
*
* Will be set to 0xffff_ffff_ffff_ffff if unavailable.
*/
__u64 iova;
/*
* [out] ID corresponding to the mapped memory to be used for
* relocations or unmapping.
*/
__u32 mapping_id;
/*
* [in] Flags.
*/
__u32 flags;
__u32 reserved[6];
};
```
### DRM_TEGRA_CHANNEL_UNMAP
Unmap previously mapped memory. Userspace shall do this only after it
has determined the channel will no longer access the memory.
```
struct drm_tegra_channel_unmap {
/*
* [in] ID of the mapping to remove.
*/
__u32 mapping_id;
__u32 reserved[3];
};
```
### DRM_TEGRA_CHANNEL_SUBMIT
Submit a job to the engine/class targeted by the channel.
```
struct drm_tegra_submit_syncpt_incr {
/*
* [in] Syncpoint FD of the syncpoint that the job will
* increment.
*/
__s32 syncpt_fd;
/*
* [in] Number of increments that the job will do.
*/
__u32 num_incrs;
/*
* [out] Value the syncpoint will have once all increments have
* executed.
*/
__u32 fence_value;
__u32 reserved[1];
};
/* Sets paddr/IOVA bit 39 on T194 to enable MC swizzling */
#define DRM_TEGRA_SUBMIT_RELOCATION_BLOCKLINEAR (1<<0)
struct drm_tegra_submit_relocation {
/* [in] Index of GATHER or GATHER_UPTR command in commands. */
__u32 gather_command_index;
/*
* [in] Mapping handle (obtained through CHANNEL_MAP) of the memory
* the address of which will be patched in.
*/
__u32 mapping_id;
/*
* [in] Offset in the gather that will be patched.
*/
__u64 gather_offset;
/*
* [in] Offset in target buffer whose paddr/IOVA will be written
* to the gather.
*/
__u64 target_offset;
/*
* [in] Number of bits the resulting address will be logically
* shifted right before writing to gather.
*/
__u32 shift;
__u32 reserved[1];
};
/* Command is an opcode gather from a GEM handle */
#define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0
/* Command is an opcode gather from a user pointer */
#define DRM_TEGRA_SUBMIT_COMMAND_GATHER_UPTR 1
/* Command is a wait for syncpt fence completion */
#define DRM_TEGRA_SUBMIT_COMMAND_WAIT_SYNCPT 2
/* Command is a wait for SYNC_FILE FD completion */
#define DRM_TEGRA_SUBMIT_COMMAND_WAIT_SYNC_FILE 3
/* Command is a wait for DRM syncobj completion */
#define DRM_TEGRA_SUBMIT_COMMAND_WAIT_SYNCOBJ 4
/*
* Allow driver to skip command execution if engine
* was not accessed by another channel between
* submissions.
*/
#define DRM_TEGRA_SUBMIT_CONTEXT_SETUP (1<<0)
struct drm_tegra_submit_command {
__u16 type;
__u16 flags;
union {
struct {
/* GEM handle */
__u32 handle;
/*
* Offset into GEM object in bytes.
* Must be aligned by 4.
*/
__u64 offset;
/*
* Length of gather in bytes.
* Must be aligned by 4.
*/
__u64 length;
} gather;
struct {
__u32 reserved[1];
/*
* Pointer to gather data.
* Must be aligned by 4 bytes.
*/
__u64 base;
/*
* Length of gather in bytes.
* Must be aligned by 4.
*/
__u64 length;
} gather_uptr;
struct {
__u32 syncpt_id;
__u32 threshold;
__u32 reserved[1];
} wait_syncpt;
struct {
__s32 fd;
} wait_sync_file;
struct {
__u32 handle;
} wait_syncobj;
};
};
#define DRM_TEGRA_SUBMIT_CREATE_POST_SYNC_FILE (1<<0)
#define DRM_TEGRA_SUBMIT_CREATE_POST_SYNCOBJ (1<<1)
struct drm_tegra_channel_submit {
__u32 channel_id;
__u32 flags;
/**
* [in] Timeout in microseconds after which the kernel may
* consider the job to have hung and may reap it and
* fast-forward its syncpoint increments.
*
* The value may be capped by the kernel.
*/
__u32 timeout;
__u32 num_syncpt_incrs;
__u32 num_relocations;
__u32 num_commands;
__u64 syncpt_incrs;
__u64 relocations;
__u64 commands;
/**
* [out] Invalid, SYNC_FILE FD or syncobj handle, depending on
* if DRM_TEGRA_SUBMIT_CREATE_POST_SYNC_FILE,
* DRM_TEGRA_SUBMIT_CREATE_POST_SYNCOBJ, or neither are passed.
* Passing both is an error.
*
* The created fence object is signaled when all syncpoint
* increments specified in `syncpt_incrs' have executed.
*/
__u32 post_fence;
__u32 reserved[3];
};
```
## Example workflows
### Image processing with TegraDRM/VIC
This example is a simple single-step operation using VIC through
TegraDRM. For example, assume we have a dma-buf fd with an image we want
to convert from YUV to RGB. This can occur for example as part of video
decoding.
Syncpoint initialization
1. Allocate syncpoint (HOST1X_ALLOCATE_SYNCPOINT)
1. This is used to track VIC submission completion.
2. Retrieve syncpoint ID (HOST1X_SYNCPOINT_INFO)
1. The ID is required to program the increment as part of the
submission.
Buffer allocation
3. Allocate memory for configuration buffers (DMA Heaps)
4. Import configuration buffer dma-buf as GEM object
5. Import input image dma-buf as GEM object
Channel initialization
6. Open VIC channel (DRM_TEGRA_OPEN_CHANNEL)
7. Map buffers for access by VIC (DRM_TEGRA_CHANNEL_MAP)
8. Create Host1x opcode buffer as userspace memory
1. If buffer mapping returned an IOVA, that IOVA can be placed
directly into the buffer. Otherwise, a relocation has to be passed as
part of the submission
2. The buffer should contain a syncpoint increment for the syncpoint
allocated earlier.
9. Submit work, passing in the syncpoint file descriptor allocated in
the beginning. The submit optionally returns a syncfd/syncobj that can
be used to wait for submission completion.
1. If more fine-grained syncpoint waiting is required, the 'fence'
out-parameter of 'drm_tegra_submit_syncpt_incr' can be used in
conjunction with HOST1X_CREATE_FENCE to create specific fences.
### Camera-GPU-CPU pipeline without TegraDRM
This example shows a pipeline with image input from a camera being
processed using the GPU programmed from userspace, and then finally
analyzed by CPU. This kind of usecase can occur e.g. as part of a
computer vision usecase.
Syncpoint initialization
1. Camera V4L2 driver allocates a syncpoint internally within the kernel.
2. For CPU job tracking, allocate a syncpoint as in "Image processing
with TegraDRM/VIC".
3. For GPU job tracking, the GPU kernel driver would allocate a
syncpoint and assign it such that the GPU channel can access it.
Camera pipeline step
4. Allocate a dma-buf to store the captured image.
5. Trigger camera capture and store the resulting sync_file fd.
GPU pipeline step
6. Use HOST1X_GET_FENCE_INFO to extract syncpoint ID/threshold pair(s)
from camera step's post-fence sync_file FD. If the sync_file FD is not
backed by syncpoints, wait for the sync_file FD to signal otherwise
(e.g. through polling it).
7. Use HOST1X_CREATE_FENCE to create a postfence that is signaled when
the GPU step is complete.
8. Program the GPU to
1. Wait for the syncpoint thresholds extracted from the camera
postfence, if we were able to do so.
2. Execute image processing on GPU.
3. Increment GPU's job tracking syncpoint, causing the GPU
post-fence FD to get signaled.
CPU pipeline step
9. Wait for GPU's post-fence sync_file FD
10. Map the dma-buf containing the image and retrieve results.
In place of the GPU pipeline step, a similar workflow would apply for a
step executed on the CPU.
^ permalink raw reply
* Re: [PATCH] [v4] dmaengine: tegra210-adma: Fix runtime PM imbalance on error
From: Geert Uytterhoeven @ 2020-06-23 12:08 UTC (permalink / raw)
To: Jon Hunter
Cc: Dinghao Liu, Kangjie Lu, Laxman Dewangan, Vinod Koul,
Dan Williams, Thierry Reding, dmaengine, linux-tegra,
Linux Kernel Mailing List
In-Reply-To: <44d7771e-5600-19c2-888a-dd226cbc4b50-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Hi Jon,
More stirring in the cesspool ;-)
On Tue, Jun 23, 2020 at 12:13 PM Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> On 21/06/2020 06:47, Dinghao Liu wrote:
> > pm_runtime_get_sync() increments the runtime PM usage counter even
> > when it returns an error code. Thus a pairing decrement is needed on
> > the error handling path to keep the counter balanced.
>
> So you have not mentioned here why you are using _noidle and not _put.
> Furthermore, in this patch [0] you are not using _noidle to fix the same
> problem in another driver. We should fix this in a consistent manner
> across all drivers, otherwise it leads to more confusion.
>
> Finally, Rafael mentions we should just use _put [0] and so I think we
> should follow his recommendation.
>
> Jon
>
> [0] https://lkml.org/lkml/2020/5/21/601
"_noidle() is the simplest one and it is sufficient."
https://lore.kernel.org/linux-i2c/CAJZ5v0i87NGcy9+kxubScdPDyByr8ypQWcGgBFn+V-wDd69BHQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org/
You never know what additional things the other put* variants
will start doing in the future...
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox