* Re: [PATCH v11 02/13] dt-bindings: video-interface: Replace 'rotation' description
From: Pavel Machek @ 2020-05-25 11:16 UTC (permalink / raw)
To: Jacopo Mondi
Cc: open list:MEDIA INPUT INFRASTRUCTURE (V4L/DVB), libcamera-devel,
Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
Laurent Pinchart, Rob Herring, tfiga, devicetree
In-Reply-To: <20200509090456.3496481-3-jacopo@jmondi.org>
[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]
On Sat 2020-05-09 11:04:45, Jacopo Mondi wrote:
> Replace the 'rotation' property description by providing a definition
> relative to the camera sensor pixel array coordinate system and the
> captured scene.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> ---
> .../bindings/media/video-interfaces.txt | 359 +++++++++++++++++-
> 1 file changed, 356 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
> index b1ff492c7da7a..3920f25a91235 100644
> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> @@ -85,9 +85,362 @@ Optional properties
>
> - lens-focus: A phandle to the node of the focus lens controller.
>
> -- rotation: The device, typically an image sensor, is not mounted upright,
> - but a number of degrees counter clockwise. Typical values are 0 and 180
> - (upside down).
> +- rotation: The camera rotation is expressed as the angular difference in
> + degrees between two reference systems, one relative to the camera module, and
> + one defined on the external world scene to be captured when projected on the
> + image sensor pixel array.
So.. how is this supposed to work. There's a phone, with its main
camera. It is designed to be used in both portrait and landscape
modes, internal accelerometr can tell between the two.
Plus you have phone with a keyboard. Common usage is portrait with
keyboard closed, and landscape with keyboard open...
And yes, there's linux with v4l2 working on Nokia N900.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v11 01/13] dt-bindings: video-interfaces: Document 'orientation' property
From: Pavel Machek @ 2020-05-25 11:13 UTC (permalink / raw)
To: Jacopo Mondi
Cc: open list:MEDIA INPUT INFRASTRUCTURE (V4L/DVB), libcamera-devel,
Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
Laurent Pinchart, Rob Herring, tfiga, devicetree, Tomasz Figa
In-Reply-To: <20200509090456.3496481-2-jacopo@jmondi.org>
[-- Attachment #1: Type: text/plain, Size: 894 bytes --]
Hi!
> +- orientation: The orientation of a device (typically an image sensor or a flash
> + LED) describing its mounting position relative to the usage orientation of the
> + system where the device is installed on.
> + Possible values are:
> + 0 - Front. The device is mounted on the front facing side of the system.
> + For mobile devices such as smartphones, tablets and laptops the front side is
> + the user facing side.
> + 1 - Back. The device is mounted on the back side of the system, which is
> + defined as the opposite side of the front facing one.
Well.. except we have devices where camera is both front and back
according to this definiton.
https://www.gsmarena.com/samsung_galaxy_fold-9523.php
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
From: Maxime Ripard @ 2020-05-25 11:11 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: Nicolas Saenz Julienne, Eric Anholt, dri-devel, linux-rpi-kernel,
bcm-kernel-feedback-list, linux-arm-kernel, Linux Kernel,
devicetree, linux-clk, linux-i2c, Linux Upstreaming Team
In-Reply-To: <CAPpJ_ed9TMJjN8xS1_3saf5obQhULJSLNgQSAFxgiWM2QX9A7Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 9081 bytes --]
Hi,
On Mon, May 11, 2020 at 11:12:05AM +0800, Jian-Hong Pan wrote:
> Jian-Hong Pan <jian-hong@endlessm.com> 於 2020年5月8日 週五 下午2:20寫道：
> >
> > Maxime Ripard <maxime@cerno.tech> 於 2020年5月8日 週五 上午1:22寫道：
> > >
> > > On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote:
> > > > Maxime Ripard <maxime@cerno.tech> 於 2020年4月29日 週三 上午12:21寫道：
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote:
> > > > > > Hi Maxime,
> > > > > >
> > > > > > Thanks for your V2 patch series! I'm testing it.
> > > > > >
> > > > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built.
> > > > > > System can boot into console text mode, but no graphic UI.
> > > > > >
> > > > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]:
> > > > > >
> > > > > > [ 5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46
> > > > > > [ 5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' already present!
> > > > > > [ 5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi mapping ok
> > > > > > [ 5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name!
> > > > > > [ 5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops)
> > > > > > [ 5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46
> > > > > > [ 5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already present!
> > > > > > [ 5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi mapping ok
> > > > > > [ 5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name!
> > > > > > [ 5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops)
> > > > > > [ 5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops)
> > > > > > [ 5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops)
> > > > > > [ 5.588934] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops)
> > > > > > [ 5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [ 5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [ 5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [ 5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [ 5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [ 5.589294] checking generic (3e513000 6d8c00) vs hw (0 ffffffffffffffff)
> > > > > > [ 5.589297] fb0: switching to vc4drmfb from simple
> > > > > > [ 5.589433] Console: switching to colour dummy device 80x25
> > > > > > [ 5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > > > > > [ 5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> > > > > > [ 5.601079] ------------[ cut here ]------------
> > > > > > [ 5.601095] WARNING: CPU: 2 PID: 127 at drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [ 5.601097] Modules linked in:
> > > > > > [ 5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted 5.7.0-rc2-00091-ga181df59a930 #7
> > > > > > [ 5.601105] Hardware name: Raspberry Pi 4 Model B (DT)
> > > > > > [ 5.601112] Workqueue: events deferred_probe_work_func
> > > > > > [ 5.601116] pstate: 20000005 (nzCv daif -PAN -UAO)
> > > > > > [ 5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [ 5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > > > > [ 5.601124] sp : ffff80001217b410
> > > > > > [ 5.601126] x29: ffff80001217b410 x28: ffff0000ec6370f0
> > > > > > [ 5.601129] x27: ffff0000f650d400 x26: 000000008a500000
> > > > > > [ 5.601132] x25: ffff8000113b4ac0 x24: 0000000000002060
> > > > > > [ 5.601135] x23: 000000000a500000 x22: 0000000000000300
> > > > > > [ 5.601137] x21: 0000000008d9ee20 x20: ffff0000ec535080
> > > > > > [ 5.601140] x19: 000000010989e7c0 x18: 0000000000000000
> > > > > > [ 5.601142] x17: 0000000000000001 x16: 0000000000005207
> > > > > > [ 5.601145] x15: 00004932ad293c92 x14: 0000000000000137
> > > > > > [ 5.601147] x13: ffff800010015000 x12: 0000000000000001
> > > > > > [ 5.601150] x11: 0000000000000001 x10: 0000000000000000
> > > > > > [ 5.601152] x9 : 0000000000000000 x8 : ffff800010015038
> > > > > > [ 5.601154] x7 : 0000000000000001 x6 : ffff80001217b368
> > > > > > [ 5.601157] x5 : 0000000000000000 x4 : 000000000000004c
> > > > > > [ 5.601159] x3 : 0000000000000000 x2 : ffff8000113b4ac0
> > > > > > [ 5.601162] x1 : ffff8000120c5f44 x0 : 00000000dc8984ff
> > > > > > [ 5.601164] Call trace:
> > > > > > [ 5.601169] vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [ 5.601172] vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > > > > [ 5.601176] drm_atomic_helper_commit_modeset_enables+0x224/0x248
> > > > > > [ 5.601179] vc4_atomic_complete_commit+0x400/0x558
> > > > > > [ 5.601182] vc4_atomic_commit+0x1e0/0x200
> > > > > > [ 5.601185] drm_atomic_commit+0x4c/0x60
> > > > > > [ 5.601190] drm_client_modeset_commit_atomic.isra.0+0x17c/0x238
> > > > > > [ 5.601192] drm_client_modeset_commit_locked+0x5c/0x198
> > > > > > [ 5.601195] drm_client_modeset_commit+0x30/0x58
> > > > > > [ 5.601201] drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0
> > > > > > [ 5.601204] drm_fb_helper_set_par+0x30/0x68
> > > > > > [ 5.601208] fbcon_init+0x3d4/0x598
> > > > > > [ 5.601212] visual_init+0xb0/0x108
> > > > > > [ 5.601214] do_bind_con_driver+0x1d0/0x3a8
> > > > > > [ 5.601217] do_take_over_console+0x144/0x208
> > > > > > [ 5.601219] do_fbcon_takeover+0x68/0xd8
> > > > > > [ 5.601222] fbcon_fb_registered+0x100/0x118
> > > > > > [ 5.601226] register_framebuffer+0x1f4/0x338
> > > > > > [ 5.601229] __drm_fb_helper_initial_config_and_unlock+0x2f8/0x4a0
> > > > > > [ 5.601232] drm_fbdev_client_hotplug+0xd4/0x1b0
> > > > > > [ 5.601235] drm_fbdev_generic_setup+0xb0/0x130
> > > > > > [ 5.601238] vc4_drm_bind+0x184/0x1a0
> > > > > > [ 5.601241] try_to_bring_up_master+0x168/0x1c8
> > > > > > [ 5.601244] __component_add+0xa4/0x170
> > > > > > [ 5.601246] component_add+0x14/0x20
> > > > > > [ 5.601248] vc4_vec_dev_probe+0x20/0x30
> > > > > > [ 5.601252] platform_drv_probe+0x54/0xa8
> > > > > > [ 5.601254] really_probe+0xd8/0x320
> > > > > > [ 5.601256] driver_probe_device+0x58/0xf0
> > > > > > [ 5.601258] __device_attach_driver+0x84/0xc8
> > > > > > [ 5.601263] bus_for_each_drv+0x78/0xc8
> > > > > > [ 5.601265] __device_attach+0xe4/0x140
> > > > > > [ 5.601267] device_initial_probe+0x14/0x20
> > > > > > [ 5.601269] bus_probe_device+0x9c/0xa8
> > > > > > [ 5.601271] deferred_probe_work_func+0x74/0xb0
> > > > > > [ 5.601276] process_one_work+0x1bc/0x338
> > > > > > [ 5.601279] worker_thread+0x1f8/0x428
> > > > > > [ 5.601282] kthread+0x138/0x158
> > > > > > [ 5.601286] ret_from_fork+0x10/0x1c
> > > > > > [ 5.601288] ---[ end trace cfba0996218c3f3d ]---
> > > > >
> > > > > Thanks for testing!
> > > > >
> > > > > Do you have a bit more details regarding your setup? Was it connected to an
> > > > > external display?
> > > >
> > > > Yes, the HDMI cable is connected to HDMI0 port on RPi 4.
> > > >
> > > > > If so, do you know the resolution it was trying to setup?
> > > >
> > > > According to the log, I think it is 1920x1080:
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-1 connected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-2 disconnected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > Composite-1 disconnected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Using
> > > > exact sizes for initial modes
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-1 using initial mode 1920x1080 +0+0
> > > >
> > > > https://gist.github.com/starnight/45e1468bfa0426a54d2fb4a9269cfb94
> > >
> > > It looks to be fairly standard then, and I'm testing on the same resolution so
> > > it should be alright.
> > >
> > > Given from your log, it looks like you're running as arm64 though, while I stuck
> > > with arm32, so it could be the explanation.
> >
> > Yes, I build it as arm64.
> >
> > > Can you share your config.txt and .config so that I can try to reproduce it
> > > here?
> >
> > Here is the config
> > https://gist.github.com/starnight/320b757441b6769c36160704b401c98b
>
> Here is the only one line in config.txt:
> enable_uart=1
>
> Actually, we make the Raspberry Pi's firmware bring up U-Boot, then
> U-Boot boots kernel.
I gave it a try today, and it seems that you also need arm_64bit=1 in the
config.txt, but then the communication with the firmware doesn't work anymore
and the kernel just falls apart.
I'll give it a try with U-boot
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: ls1028a: add one more thermal zone support
From: Daniel Lezcano @ 2020-05-25 11:08 UTC (permalink / raw)
To: Yuantian Tang, shawnguo, robh+dt, mark.rutland, catalin.marinas,
will.deacon
Cc: devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20200525073827.13272-1-andy.tang@nxp.com>
On 25/05/2020 09:38, Yuantian Tang wrote:
> There are 2 thermal zones in ls1028a soc. Current dts only
> includes one. This patch adds the other thermal zone node
> in dts to enable it.
For my personal information, is there a cooling device for the DDR?
> Signed-off-by: Yuantian Tang <andy.tang@nxp.com>
> ---
> .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 22 ++++++++++++++++++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 055f114cf848..bc6f0c0f85da 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -129,11 +129,31 @@
> };
>
> thermal-zones {
> - core-cluster {
> + ddr-controller {
> polling-delay-passive = <1000>;
> polling-delay = <5000>;
> thermal-sensors = <&tmu 0>;
>
> + trips {
> + ddr-ctrler-alert {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + ddr-ctrler-crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + core-cluster {
> + polling-delay-passive = <1000>;
> + polling-delay = <5000>;
> + thermal-sensors = <&tmu 1>;
> +
> trips {
> core_cluster_alert: core-cluster-alert {
> temperature = <85000>;
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node
From: Jonathan Marek @ 2020-05-25 11:08 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: linux-arm-msm, Andy Gross, Bjorn Andersson, Rob Herring,
devicetree, linux-kernel, linux-arm-msm-owner
In-Reply-To: <2a35f3b85d8311fb4298aaea82236967@codeaurora.org>
On 5/25/20 6:54 AM, Sai Prakash Ranjan wrote:
> On 2020-05-25 15:39, Jonathan Marek wrote:
>> Hi,
>>
>> On 5/25/20 5:42 AM, Sai Prakash Ranjan wrote:
>>> Hi Jonathan,
>>>
>>> On 2020-05-24 08:08, Jonathan Marek wrote:
>>>> Add the apps_smmu node for sm8250. Note that adding the iommus field
>>>> for
>>>> UFS is required because initializing the iommu removes the bypass
>>>> mapping
>>>> that created by the bootloader.
>>>>
>>>
>>> This statement doesn't seem right, you can just say since the bypass
>>> is disabled
>>> by default now, we need to add this property to enable translation
>>> and avoid global faults.
>>>
>>
>> If I use this patch [1] then the UFS iommu property isn't needed. In
>> downstream, the identity (bypass?) stream mapping is inherited from
>> the bootloader, and UFS is used without any iommu property. Setting
>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n doesn't make it work on its own
>> (without the UFS iommu property), so there's more to it than just
>> "bypass is disabled by default now".
>>
>> https://patchwork.kernel.org/patch/11310757/
>>
>
> "iommus" property is not about inheriting stream mapping from bootloader,
> it is used to enable SMMU address translation for the corresponding
> master when specified. So when you have disabled bypass, i.e.,
> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y or via cmdline
> "arm-smmu.disable_bypass=1"
> and iommus property with SID and mask is not specified, then it will result
> in SMMU global faults.
>
> Downstream has bypass enabled(ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n),so you
> won't see any global faults if you do not have iommus property.
>
> Patch in your link is for display because of the usecase for splash screen
> on android and some other devices where the bootloader will configure SMMU,
> it has not yet merged and not likely to get merged in the current state.
>
> So yes "there is *not* much more to it than bypass is disabled by
> default now"
> and you have to specify "iommus" for the master devices or you should
> enable bypass,
> i.e., ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or arm-smmu.disable_bypass=n
>
> Try without the patch in the link and without iommus for UFS and
> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y and you will see.
>
> -Sai
I know that the "iommus" property is not about inheriting stream
mapping. Probing the iommu removes the stream mapping created by the
bootloader, the iommus property is added so that new mappings are
created to replace what was removed.
You seem to be under the impression that the SM8150/SM8250 bootloader
does not configure SMMU. It does, for both UFS and SDHC, just like it
does for display/splash screen on some devices.
With either value of ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT, it will not
work without the iommus property.
^ permalink raw reply
* Re: [PATCH v2 3/3] leds: add aw2013 driver
From: Pavel Machek @ 2020-05-25 10:55 UTC (permalink / raw)
To: nikitos.tr
Cc: dmurphy, robh+dt, linux-leds, devicetree, linux-kernel,
~postmarketos/upstreaming
In-Reply-To: <20200511111128.16210-3-nikitos.tr@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 535 bytes --]
On Mon 2020-05-11 16:11:28, nikitos.tr@gmail.com wrote:
> From: Nikita Travkin <nikitos.tr@gmail.com>
>
> This commit adds support for AWINIC AW2013 3-channel LED driver.
> The chip supports 3 PWM channels and is controlled with I2C.
>
> Signed-off-by: Nikita Travkin <nikitos.tr@gmail.com>
Thanks, I applied 2 and 3/. 1/ should go through Rob AFAICT.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node
From: Sai Prakash Ranjan @ 2020-05-25 10:54 UTC (permalink / raw)
To: Jonathan Marek
Cc: linux-arm-msm, Andy Gross, Bjorn Andersson, Rob Herring,
devicetree, linux-kernel, linux-arm-msm-owner
In-Reply-To: <0f58e2fd-ef55-cf38-d403-4782662aa89e@marek.ca>
On 2020-05-25 15:39, Jonathan Marek wrote:
> Hi,
>
> On 5/25/20 5:42 AM, Sai Prakash Ranjan wrote:
>> Hi Jonathan,
>>
>> On 2020-05-24 08:08, Jonathan Marek wrote:
>>> Add the apps_smmu node for sm8250. Note that adding the iommus field
>>> for
>>> UFS is required because initializing the iommu removes the bypass
>>> mapping
>>> that created by the bootloader.
>>>
>>
>> This statement doesn't seem right, you can just say since the bypass
>> is disabled
>> by default now, we need to add this property to enable translation and
>> avoid global faults.
>>
>
> If I use this patch [1] then the UFS iommu property isn't needed. In
> downstream, the identity (bypass?) stream mapping is inherited from
> the bootloader, and UFS is used without any iommu property. Setting
> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n doesn't make it work on its own
> (without the UFS iommu property), so there's more to it than just
> "bypass is disabled by default now".
>
> https://patchwork.kernel.org/patch/11310757/
>
"iommus" property is not about inheriting stream mapping from
bootloader,
it is used to enable SMMU address translation for the corresponding
master when specified. So when you have disabled bypass, i.e.,
ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y or via cmdline
"arm-smmu.disable_bypass=1"
and iommus property with SID and mask is not specified, then it will
result
in SMMU global faults.
Downstream has bypass enabled(ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n),so
you
won't see any global faults if you do not have iommus property.
Patch in your link is for display because of the usecase for splash
screen
on android and some other devices where the bootloader will configure
SMMU,
it has not yet merged and not likely to get merged in the current state.
So yes "there is *not* much more to it than bypass is disabled by
default now"
and you have to specify "iommus" for the master devices or you should
enable bypass,
i.e., ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or arm-smmu.disable_bypass=n
Try without the patch in the link and without iommus for UFS and
ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y and you will see.
-Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: iio: magnetometer: ak8975: add gpio reset support
From: Jonathan Albrieux @ 2020-05-25 10:53 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-kernel@vger.kernel.org, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jonathan Cameron,
Lars-Peter Clausen, open list:IIO SUBSYSTEM AND DRIVERS,
Peter Meerwald-Stadler, Steve Winslow, Thomas Gleixner,
Jonathan Cameron, Rob Herring
In-Reply-To: <CACRpkdZrcie3Op2aLoTQgwT-2so+s2FqKn0R4B8VQ7qcxz2oCg@mail.gmail.com>
On Mon, May 25, 2020 at 10:43:35AM +0200, Linus Walleij wrote:
> On Mon, May 18, 2020 at 3:37 PM Jonathan Albrieux
> <jonathan.albrieux@gmail.com> wrote:
>
> > + reset-gpio:
> > + description: an optional pin needed for AK09911 to set the reset state
>
> This kind of properties should always be plural, so
> reset-gpios please.
>
> Yours,
> Linus Walleij
Thank you, will include this change in current patch version I'm working on.
Best regards,
Jonathan Albrieux
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add Shanghai Awinic Technology Co., Ltd.
From: Pavel Machek @ 2020-05-25 10:52 UTC (permalink / raw)
To: Rob Herring
Cc: nikitos.tr, dmurphy, robh+dt, linux-kernel, linux-leds,
devicetree, ~postmarketos/upstreaming
In-Reply-To: <20200518221435.GA6734@bogus>
[-- Attachment #1: Type: text/plain, Size: 820 bytes --]
On Mon 2020-05-18 16:14:35, Rob Herring wrote:
> On Mon, 11 May 2020 16:11:26 +0500, wrote:
> > From: Nikita Travkin <nikitos.tr@gmail.com>
> >
> > Add the "awinic" vendor prefix for Shanghai Awinic Technology Co., Ltd.
> > Website: https://www.awinic.com/
> >
> > Signed-off-by: Nikita Travkin <nikitos.tr@gmail.com>
> > ---
> > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
>
> Reviewed-by: Rob Herring <robh@kernel.org>
I can take 2/ and 3/ of the series, but I believe we'll get conflicts
if I change vendor-prefixes.yaml in the LED tree. Can you take this
one?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v5 10/13] soc: mediatek: cmdq: export finalize function
From: Chun-Kuang Hu @ 2020-05-25 10:48 UTC (permalink / raw)
To: Matthias Brugger
Cc: Chun-Kuang Hu, Dennis YC Hsieh, Rob Herring, Mark Rutland,
Jassi Brar, Philipp Zabel, David Airlie, Daniel Vetter,
devicetree, wsd_upstream, linux-kernel, DRI Development, HS Liao,
moderated list:ARM/Mediatek SoC support, Houlong Wei, Linux ARM
In-Reply-To: <e487573a-2252-cd52-3a3d-c271f67fcb9a@gmail.com>
Hi, Matthias:
Matthias Brugger <matthias.bgg@gmail.com> 於 2020年5月25日 週一 下午4:38寫道：
>
>
>
> On 25/05/2020 02:23, Chun-Kuang Hu wrote:
> > Hi, Matthias:
> >
> > Matthias Brugger <matthias.bgg@gmail.com> 於 2020年5月17日 週日 上午2:22寫道：
> >>
> >>
> >>
> >> On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> >>> Export finalize function to client which helps append eoc and jump
> >>> command to pkt. Let client decide call finalize or not.
> >>>
> >>> Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
> >>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
> >>> ---
> >>> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 +
> >>> drivers/soc/mediatek/mtk-cmdq-helper.c | 7 ++-----
> >>> include/linux/soc/mediatek/mtk-cmdq.h | 8 ++++++++
> >>> 3 files changed, 11 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> >>> index 0dfcd1787e65..7daaabc26eb1 100644
> >>> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> >>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> >>> @@ -490,6 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
> >>> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> >>> cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
> >>> mtk_crtc_ddp_config(crtc, cmdq_handle);
> >>> + cmdq_pkt_finalize(cmdq_handle);
> >>> cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
> >>> }
> >>> #endif
> >>
> >> This should be a independent patch.
> >> Other then that patch looks good.
> >
> > Apply only drm part or only cmdq helpr part, it would be abnormal.
>
> Right it would break DRM driver (if only applied to cmdq) or compilation if only
> applied to DRM.
>
> > Shall we seperate this patch?
>
> After thinking twice, I think we can leave it as it is. If you provide your
> Acked-by I can take it thorugh my tree, if that's OK for you.
This is OK for me, so
Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
>
> Regards,
> Matthias
>
> > Or seperate it but make sure these two patches be in the same tree?
> >
> > Regards,
> > Chun-Kuang.
> >
> >>
> >>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>> index a9ebbabb7439..59bc1164b411 100644
> >>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>> @@ -372,7 +372,7 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
> >>> }
> >>> EXPORT_SYMBOL(cmdq_pkt_assign);
> >>>
> >>> -static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> >>> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> >>> {
> >>> struct cmdq_instruction inst = { {0} };
> >>> int err;
> >>> @@ -392,6 +392,7 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> >>>
> >>> return err;
> >>> }
> >>> +EXPORT_SYMBOL(cmdq_pkt_finalize);
> >>>
> >>> static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
> >>> {
> >>> @@ -426,10 +427,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
> >>> unsigned long flags = 0;
> >>> struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
> >>>
> >>> - err = cmdq_pkt_finalize(pkt);
> >>> - if (err < 0)
> >>> - return err;
> >>> -
> >>> pkt->cb.cb = cb;
> >>> pkt->cb.data = data;
> >>> pkt->async_cb.cb = cmdq_pkt_flush_async_cb;
> >>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> >>> index fec292aac83c..99e77155f967 100644
> >>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> >>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> >>> @@ -213,6 +213,14 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
> >>> */
> >>> int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
> >>>
> >>> +/**
> >>> + * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
> >>> + * @pkt: the CMDQ packet
> >>> + *
> >>> + * Return: 0 for success; else the error code is returned
> >>> + */
> >>> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
> >>> +
> >>> /**
> >>> * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
> >>> * packet and call back at the end of done packet
> >>>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH net v2 1/4] net: ethernet: fec: move GPR register offset and bit into DT
From: Sascha Hauer @ 2020-05-25 10:48 UTC (permalink / raw)
To: fugang.duan
Cc: andrew, martin.fuzzey, davem, netdev, robh+dt, shawnguo,
devicetree, kuba
In-Reply-To: <1590390569-4394-2-git-send-email-fugang.duan@nxp.com>
On Mon, May 25, 2020 at 03:09:26PM +0800, fugang.duan@nxp.com wrote:
> From: Fugang Duan <fugang.duan@nxp.com>
>
> The commit da722186f654 (net: fec: set GPR bit on suspend by DT
> configuration) set the GPR reigster offset and bit in driver for
> wake on lan feature.
>
> But it introduces two issues here:
> - one SOC has two instances, they have different bit
> - different SOCs may have different offset and bit
>
> So to support wake-on-lan feature on other i.MX platforms, it should
> configure the GPR reigster offset and bit from DT.
>
> So the patch is to improve the commit da722186f654 (net: fec: set GPR
> bit on suspend by DT configuration) to support multiple ethernet
> instances on i.MX series.
>
> v2:
> * switch back to store the quirks bitmask in driver_data
>
> Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
> ---
> drivers/net/ethernet/freescale/fec_main.c | 103 ++++++++++--------------------
> 1 file changed, 34 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index 2e20914..4f55d30 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -86,56 +86,6 @@ static void fec_enet_itr_coal_init(struct net_device *ndev);
> #define FEC_ENET_OPD_V 0xFFF0
> #define FEC_MDIO_PM_TIMEOUT 100 /* ms */
>
> -struct fec_devinfo {
> - u32 quirks;
> - u8 stop_gpr_reg;
> - u8 stop_gpr_bit;
> -};
Honestly I like the approach of having a struct fec_devinfo for
abstracting differences between different hardware variants. It gives
you more freedom to describe the differences. Converting this back to a
single bitfield is a step backward, even when currently struct
fec_devinfo only contains a single value.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v5 2/3] dt-bindings: arm: actions: Document Caninos Loucos Labrador
From: Andreas Färber @ 2020-05-25 10:41 UTC (permalink / raw)
To: Matheus Castello, manivannan.sadhasivam, robh+dt
Cc: mark.rutland, edgar.righi, igor.lima, linux-arm-kernel,
devicetree, linux-kernel, linux-actions, Rob Herring
In-Reply-To: <20200525013008.108750-3-matheus@castello.eng.br>
Hi,
Am 25.05.20 um 03:30 schrieb Matheus Castello:
> Update the documentation to add the Caninos Loucos Labrador. Labrador
> project consists of a computer on module based on the Actions Semi S500
> processor and the Labrador base board.
>
> Signed-off-by: Matheus Castello <matheus@castello.eng.br>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/arm/actions.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/actions.yaml b/Documentation/devicetree/bindings/arm/actions.yaml
> index ace3fdaa8396..2187e1c5bc73 100644
> --- a/Documentation/devicetree/bindings/arm/actions.yaml
> +++ b/Documentation/devicetree/bindings/arm/actions.yaml
> @@ -19,6 +19,11 @@ properties:
> - allo,sparky # Allo.com Sparky
> - cubietech,cubieboard6 # Cubietech CubieBoard6
> - const: actions,s500
> + - items:
> + - enum:
> + - caninos,labrador-v2 # Labrador Core v2
> + - caninos,labrador-base-m # Labrador Base Board M v1
This enum still strikes me as wrong, it means either-or. (Was planning
to look into it myself, but no time yet...) caninos,labrador-v2 should
be a const one level down: board, SoM, SoC from most specific to most
generic. Compare Guitar below.
> + - const: actions,s500
> - items:
> - enum:
> - lemaker,guitar-bb-rev-b # LeMaker Guitar Base Board rev. B
Regards,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v5 09/13] soc: mediatek: cmdq: add write_s value function
From: Dennis-YC Hsieh @ 2020-05-25 10:38 UTC (permalink / raw)
To: Matthias Brugger
Cc: Rob Herring, Mark Rutland, Jassi Brar, Philipp Zabel,
David Airlie, Daniel Vetter, linux-kernel, linux-mediatek,
devicetree, wsd_upstream, dri-devel, Bibby Hsieh, CK Hu,
Houlong Wei, linux-arm-kernel, HS Liao
In-Reply-To: <68535bf6-9824-5077-4811-374c893cdc03@gmail.com>
On Mon, 2020-05-25 at 10:39 +0200, Matthias Brugger wrote:
>
> On 25/05/2020 04:27, Dennis-YC Hsieh wrote:
> >
> > On Sun, 2020-05-24 at 20:13 +0200, Matthias Brugger wrote:
> >>
> >> On 24/05/2020 19:31, Dennis-YC Hsieh wrote:
> >>> Hi Matthias,
> >>>
> >>> Thanks for your comment.
> >>>
> >>> On Sat, 2020-05-16 at 20:20 +0200, Matthias Brugger wrote:
> >>>>
> >>>> On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> >>>>> add write_s function in cmdq helper functions which
> >>>>> writes a constant value to address with large dma
> >>>>> access support.
> >>>>>
> >>>>> Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
> >>>>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
> >>>>> ---
> >>>>> drivers/soc/mediatek/mtk-cmdq-helper.c | 26 ++++++++++++++++++++++++++
> >>>>> include/linux/soc/mediatek/mtk-cmdq.h | 14 ++++++++++++++
> >>>>> 2 files changed, 40 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>>>> index 03c129230cd7..a9ebbabb7439 100644
> >>>>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>>>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>>>> @@ -269,6 +269,32 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> >>>>> }
> >>>>> EXPORT_SYMBOL(cmdq_pkt_write_s);
> >>>>>
> >>>>> +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> >>>>> + u16 addr_low, u32 value, u32 mask)
> >>>>> +{
> >>>>> + struct cmdq_instruction inst = { {0} };
> >>>>> + int err;
> >>>>> +
> >>>>> + if (mask != U32_MAX) {
> >>>>> + inst.op = CMDQ_CODE_MASK;
> >>>>> + inst.mask = ~mask;
> >>>>> + err = cmdq_pkt_append_command(pkt, inst);
> >>>>> + if (err < 0)
> >>>>> + return err;
> >>>>> +
> >>>>> + inst.op = CMDQ_CODE_WRITE_S_MASK;
> >>>>> + } else {
> >>>>> + inst.op = CMDQ_CODE_WRITE_S;
> >>>>> + }
> >>>>> +
> >>>>> + inst.sop = high_addr_reg_idx;
> >>>>
> >>>> Writing u16 value in a 5 bit wide variable?
> >>>
> >>> We need only 5 bits in this case. I'll change high_addr_reg_idx
> >>> parameter to u8.
> >>>
> >>
> >> Ok, please make sure to mask the value, so that it's explicit in the code that
> >> we only use the lowest 5 bits of high_addr_reg_idx.
> >
> > Is it necessary to mask the value?
> > Since sop already defined as "u8 sop:5;", I thought it is explicit that
> > only use 5 bits and compiler should do the rest jobs.
>
> Yes but it makes the code more explicit if we have a
> inst.sop = high_addr_reg_idx & 0x1f;
>
> What do you think?
The value assign to sop will restrict by hardware spec. Clients call
this function will define constant value and use it as parameter. So I
think we don't worry about client call this api with wrong value.
Regards,
Dennis
>
> Regards,
> Matthias
>
> >
> >
> > Regards,
> > Dennis
> >
> >>
> >> Regards,
> >> Matthias
> >>
> >>>>
> >>>>> + inst.offset = addr_low;
> >>>>> + inst.value = value;
> >>>>> +
> >>>>> + return cmdq_pkt_append_command(pkt, inst);
> >>>>> +}
> >>>>> +EXPORT_SYMBOL(cmdq_pkt_write_s_value);
> >>>>> +
> >>>>> int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> >>>>> {
> >>>>> struct cmdq_instruction inst = { {0} };
> >>>>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> >>>>> index 01b4184af310..fec292aac83c 100644
> >>>>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> >>>>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> >>>>> @@ -135,6 +135,20 @@ int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx, u16 addr_low,
> >>>>> int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> >>>>> u16 addr_low, u16 src_reg_idx, u32 mask);
> >>>>>
> >>>>> +/**
> >>>>> + * cmdq_pkt_write_s_value() - append write_s command with mask to the CMDQ
> >>>>> + * packet which write value to a physical address
> >>>>> + * @pkt: the CMDQ packet
> >>>>> + * @high_addr_reg_idx: internal regisger ID which contains high address of pa
> >>>>
> >>>> register
> >>>
> >>> will fix
> >>>
> >>>
> >>> Regards,
> >>> Dennis
> >>>
> >>>>
> >>>>> + * @addr_low: low address of pa
> >>>>> + * @value: the specified target value
> >>>>> + * @mask: the specified target mask
> >>>>> + *
> >>>>> + * Return: 0 for success; else the error code is returned
> >>>>> + */
> >>>>> +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> >>>>> + u16 addr_low, u32 value, u32 mask);
> >>>>> +
> >>>>> /**
> >>>>> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
> >>>>> * @pkt: the CMDQ packet
> >>>>>
> >>>
> >
^ permalink raw reply
* Re: [PATCH 8/8] ARM: dts: r8a7742: Add xhci support
From: Geert Uytterhoeven @ 2020-05-25 10:21 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Bjorn Helgaas, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Magnus Damm, dmaengine, linux-pci, USB list,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590356277-19993-9-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, May 24, 2020 at 11:40 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Add xhci support to R8A7742 SoC DT.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 7/8] ARM: dts: r8a7742: Add USB-DMAC and HSUSB device nodes
From: Geert Uytterhoeven @ 2020-05-25 10:20 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Bjorn Helgaas, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Magnus Damm, dmaengine, linux-pci, USB list,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590356277-19993-8-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, May 24, 2020 at 11:40 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Add usb dmac and hsusb device nodes on RZ/G1H SoC dtsi.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 10/16] gpio: add a reusable generic gpio_chip using regmap
From: Michael Walle @ 2020-05-25 10:20 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Andy Shevchenko, linux-gpio, linux-devicetree, LKML, linux-hwmon,
linux-pwm, LINUXWATCHDOG, arm-soc, Linus Walleij, Rob Herring,
Jean Delvare, Guenter Roeck, Lee Jones, Thierry Reding,
Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Mark Brown,
Greg Kroah-Hartman
In-Reply-To: <CAMpxmJXctc5cbrjSeJxa7DfmjiVsbyhqAbEKt-gtayKhQj0Cnw@mail.gmail.com>
Am 2020-05-25 11:05, schrieb Bartosz Golaszewski:
> wt., 12 maj 2020 o 16:41 Michael Walle <michael@walle.cc> napisał(a):
>>
>> >> +
>> >> +MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
>> >> +MODULE_DESCRIPTION("GPIO generic regmap driver core");
>> >> +MODULE_LICENSE("GPL");
>> >> diff --git a/include/linux/gpio-regmap.h b/include/linux/gpio-regmap.h
>> >> new file mode 100644
>> >> index 000000000000..a868cbcde6e9
>> >> --- /dev/null
>> >> +++ b/include/linux/gpio-regmap.h
>> >> @@ -0,0 +1,69 @@
>> >> +/* SPDX-License-Identifier: GPL-2.0-only */
>> >> +
>> >> +#ifndef _LINUX_GPIO_REGMAP_H
>> >> +#define _LINUX_GPIO_REGMAP_H
>> >> +
>> >> +struct gpio_regmap;
>> >> +
>> >> +#define GPIO_REGMAP_ADDR_ZERO ((unsigned long)(-1))
>> >> +#define GPIO_REGMAP_ADDR(addr) ((addr) ? : GPIO_REGMAP_ADDR_ZERO)
>> >> +
>> >
>> > What if the addr is actually 0?
>>
>> Then the driver has to set GPIO_REGMAP_ADDR_ZERO or use the
>> convenience
>> macro GPIO_REGMAP_ADDR.
>>
>> So you can have
>>
>> struct gpio_regmap_config config = { 0 };
>> config.reg_dat_base = 0x10;
>> config.reg_dir_out_base = 0x20;
>>
>> or
>>
>> config.reg_dat_base = GPIO_REGMAP_ADDR_ZERO;
>>
>> or if you can't be sure if the RHS value might be zero:
>>
>> config.reg_dat_base = GPIO_REGMAP_ADDR(reg);
>>
>>
>> > Maybe drop GPIO_REGMAP_ADDR and require users to set unused registers
>> > to GPIO_REGMAP_ADDR_ZERO?
>>
>> Thats bad because:
>> * you'd have to set plenty of unused base registers for a simple
>> driver
>> * if there will be additional properties in the future, you have to
>> touch
>> all other drivers, because they are initialized as 0 (ie. valid
>> reg
>> 0).
>>
>> >> +/**
>> >> + * struct gpio_regmap_config - Description of a generic regmap
>> >> gpio_chip.
>> >> + *
>> >> + * @parent: The parent device
>> >> + * @regmap: The regmap used to access the registers
>> >> + * given, the name of the device is used
>> >> + * @label: (Optional) Descriptive name for GPIO
>> >> controller.
>> >> + * If not given, the name of the device is used.
>> >> + * @ngpio: Number of GPIOs
>> >> + * @reg_dat_base: (Optional) (in) register base address
>> >> + * @reg_set_base: (Optional) set register base address
>> >> + * @reg_clr_base: (Optional) clear register base address
>> >> + * @reg_dir_in_base: (Optional) out setting register base address
>> >> + * @reg_dir_out_base: (Optional) in setting register base address
>> >
>> > The two above are inverted I think?
>> good catch.
>>
>> > Also: why the limitation of only supporting one at a time?
>>
>> they should be exclusive, either you have a register where you set the
>> output bits to one, or the input bits. Maybe this need a bit more
>> context
>> above. in gpio-mmio.c you can set both and both are used in
>> set_direction(), but only one is read in get_direction().
>>
>> That being said, I have no strong opinion wether they should be
>> exclusive
>> or not, besides the symmetry of set_/get_direction().
>>
>> -michael
>>
>
> Sorry for the late response, your comments make sense to me. Are you
> going to submit a v4 before the v5.8 merge window?
I'm currently stuck with how to handle the MFD part. Ie. Rob doesn't
seem to like the logicial device numbering - or at least there wasn't
an answer to that one anymore, see patch 5/16.
If you like I could submit this patch on its own. But then there
wouldn't be a user for it.
-michael
^ permalink raw reply
* Re: [PATCH 6/8] ARM: dts: r8a7742: Add USB 2.0 host support
From: Geert Uytterhoeven @ 2020-05-25 10:20 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Bjorn Helgaas, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Magnus Damm, dmaengine, linux-pci, USB list,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590356277-19993-7-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, May 24, 2020 at 11:40 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Describe internal PCI bridge devices, USB phy device and
> link PCI USB devices to USB phy.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 5/8] dt-bindings: usb: usb-xhci: Document r8a7742 support
From: Geert Uytterhoeven @ 2020-05-25 10:18 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Bjorn Helgaas, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Magnus Damm, dmaengine, linux-pci, USB list,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590356277-19993-6-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, May 24, 2020 at 11:40 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Document r8a7742 xhci support. The driver will use the fallback
> compatible string "renesas,rcar-gen2-xhci", therefore no driver
> change is needed.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 2/6] dt-bindings: interrupt-controller: Add Loongson HTVEC
From: Marc Zyngier @ 2020-05-25 10:12 UTC (permalink / raw)
To: Jiaxun Yang, Rob Herring
Cc: Thomas Gleixner, Jason Cooper, Huacai Chen, linux-kernel,
devicetree, linux-mips
In-Reply-To: <20200516082912.3673033-2-jiaxun.yang@flygoat.com>
On Sat, 16 May 2020 09:29:02 +0100,
Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>
> Add binding for Loongson-3 HyperTransport Interrupt Vector Controller.
>
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> --
> v4: Drop ref, '|', add additionalProperties, fix example
Rob, do you have any input on this?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node
From: Jonathan Marek @ 2020-05-25 10:09 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: linux-arm-msm, Andy Gross, Bjorn Andersson, Rob Herring,
devicetree, linux-kernel, linux-arm-msm-owner
In-Reply-To: <42f39eeb2af9c82a551a417c62ea21d7@codeaurora.org>
Hi,
On 5/25/20 5:42 AM, Sai Prakash Ranjan wrote:
> Hi Jonathan,
>
> On 2020-05-24 08:08, Jonathan Marek wrote:
>> Add the apps_smmu node for sm8250. Note that adding the iommus field for
>> UFS is required because initializing the iommu removes the bypass mapping
>> that created by the bootloader.
>>
>
> This statement doesn't seem right, you can just say since the bypass is
> disabled
> by default now, we need to add this property to enable translation and
> avoid global faults.
>
If I use this patch [1] then the UFS iommu property isn't needed. In
downstream, the identity (bypass?) stream mapping is inherited from the
bootloader, and UFS is used without any iommu property. Setting
ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n doesn't make it work on its own
(without the UFS iommu property), so there's more to it than just
"bypass is disabled by default now".
https://patchwork.kernel.org/patch/11310757/
>> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
>> ---
>> arch/arm64/boot/dts/qcom/sm8250.dtsi | 107 +++++++++++++++++++++++++++
>> 1 file changed, 107 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> b/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> index 2f99c350c287..43c5e48c15e2 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> @@ -323,6 +323,8 @@ ufs_mem_hc: ufshc@1d84000 {
>>
>> power-domains = <&gcc UFS_PHY_GDSC>;
>>
>> + iommus = <&apps_smmu 0x0e0 0>, <&apps_smmu 0x4e0 0>;
>> +
>> clock-names =
>> "core_clk",
>> "bus_aggr_clk",
>> @@ -428,6 +430,111 @@ tlmm: pinctrl@f100000 {
>> wakeup-parent = <&pdc>;
>> };
>>
>> + apps_smmu: iommu@15000000 {
>> + compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
>
> This should be qcom,sm8250-smmu-500 and also you need to update the
> arm-smmu
> binding with this compatible in a separate patch.
>
> -Sai
>
^ permalink raw reply
* Re: [PATCH 4/8] dt-bindings: dmaengine: renesas,usb-dmac: Add binding for r8a7742
From: Geert Uytterhoeven @ 2020-05-25 10:05 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Bjorn Helgaas, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Magnus Damm, dmaengine, linux-pci, USB list,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590356277-19993-5-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, May 24, 2020 at 11:40 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/8] dt-bindings: usb: renesas,usbhs: Add support for r8a7742
From: Geert Uytterhoeven @ 2020-05-25 10:04 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Bjorn Helgaas, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Magnus Damm, dmaengine, linux-pci, USB list,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590356277-19993-4-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, May 24, 2020 at 11:39 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Document support for RZ/G1H (R8A7742) SoC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/8] dt-bindings: PCI: pci-rcar-gen2: Add device tree support for r8a7742
From: Geert Uytterhoeven @ 2020-05-25 10:03 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Bjorn Helgaas, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Magnus Damm, dmaengine, linux-pci, USB list,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590356277-19993-3-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, May 24, 2020 at 11:39 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Add internal PCI bridge support for r8a7742 SoC. The Renesas RZ/G1H
> (R8A7742) internal PCI bridge is identical to the R-Car Gen2 family.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/8] dt-bindings: phy: rcar-gen2: Add r8a7742 support
From: Geert Uytterhoeven @ 2020-05-25 10:01 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Bjorn Helgaas, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Magnus Damm, dmaengine, linux-pci, USB list,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590356277-19993-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, May 24, 2020 at 11:38 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Add USB PHY support for r8a7742 SoC. Renesas RZ/G1H (R8A7742)
> USB PHY is identical to the R-Car Gen2 family.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node
From: Sai Prakash Ranjan @ 2020-05-25 9:42 UTC (permalink / raw)
To: Jonathan Marek
Cc: linux-arm-msm, Andy Gross, Bjorn Andersson, Rob Herring,
devicetree, linux-kernel, linux-arm-msm-owner
In-Reply-To: <20200524023815.21789-3-jonathan@marek.ca>
Hi Jonathan,
On 2020-05-24 08:08, Jonathan Marek wrote:
> Add the apps_smmu node for sm8250. Note that adding the iommus field
> for
> UFS is required because initializing the iommu removes the bypass
> mapping
> that created by the bootloader.
>
This statement doesn't seem right, you can just say since the bypass is
disabled
by default now, we need to add this property to enable translation and
avoid global faults.
> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> ---
> arch/arm64/boot/dts/qcom/sm8250.dtsi | 107 +++++++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> index 2f99c350c287..43c5e48c15e2 100644
> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> @@ -323,6 +323,8 @@ ufs_mem_hc: ufshc@1d84000 {
>
> power-domains = <&gcc UFS_PHY_GDSC>;
>
> + iommus = <&apps_smmu 0x0e0 0>, <&apps_smmu 0x4e0 0>;
> +
> clock-names =
> "core_clk",
> "bus_aggr_clk",
> @@ -428,6 +430,111 @@ tlmm: pinctrl@f100000 {
> wakeup-parent = <&pdc>;
> };
>
> + apps_smmu: iommu@15000000 {
> + compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
This should be qcom,sm8250-smmu-500 and also you need to update the
arm-smmu
binding with this compatible in a separate patch.
-Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
^ 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