Re: [PATCH 1/3] init: Declare rodata_enabled and mark_rodata_ro() at all time
Hi, On Mon, Jan 29, 2024 at 12:09:50PM -0800, Luis Chamberlain wrote: > On Thu, Dec 21, 2023 at 10:02:46AM +0100, Christophe Leroy wrote: > > Declaring rodata_enabled and mark_rodata_ro() at all time > > helps removing related #ifdefery in C files. > > > > Signed-off-by: Christophe Leroy > > Very nice cleanup, thanks!, applied and pushed > > Luis On next-20240130, which has your modules-next branch, and thus this series and the other "module: Use set_memory_rox()" series applied, my kernel crashes in some very weird way. Reverting your branch makes the crash go away. I thought I'd report it right away. Maybe you folks would know what's happening here? This is on arm64. [ 10.481015] Unable to handle kernel paging request at virtual address ffde85245d30 [ 10.490369] KASAN: maybe wild-memory-access in range [0x00f42922e980-0x00f42922e987] [ 10.503744] Mem abort info: [ 10.509383] ESR = 0x9647 [ 10.514400] EC = 0x25: DABT (current EL), IL = 32 bits [ 10.522366] SET = 0, FnV = 0 [ 10.526343] EA = 0, S1PTW = 0 [ 10.530695] FSC = 0x07: level 3 translation fault [ 10.537081] Data abort info: [ 10.540839] ISV = 0, ISS = 0x0047, ISS2 = 0x [ 10.546456] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 [ 10.551726] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 10.557612] swapper pgtable: 4k pages, 39-bit VAs, pgdp=41f98000 [ 10.565214] [ffde85245d30] pgd=10023003, p4d=10023003, pud=10023003, pmd=1001121eb003, pte= [ 10.578887] Internal error: Oops: 9647 [#1] PREEMPT SMP [ 10.585815] Modules linked in: [ 10.590235] CPU: 6 PID: 195 Comm: (udev-worker) Tainted: GB 6.8.0-rc2-next-20240130-02908-ge8ad01d60927-dirty #163 3f2318148ecc5fa70d1092c2b874f9b59bdb7d60 [ 10.607021] Hardware name: Google Tentacruel board (DT) [ 10.613607] pstate: a049 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 10.621954] pc : module_bug_finalize+0x118/0x148 [ 10.626823] lr : module_bug_finalize+0x118/0x148 [ 10.631463] sp : ffc0820478d0 [ 10.631466] x29: ffc0820478d0 x28: ffc082047ca0 x27: ffde8d7d31a0 [ 10.631477] x26: ffde85223780 x25: x24: ffde8c413cc0 [ 10.631486] x23: ffde8dfcec80 x22: ffde8dfce000 x21: ffde85223ba8 [ 10.631495] x20: ffde85223780 x19: ffde85245d28 x18: [ 10.631504] x17: ffde8aa15938 x16: ffde8aabdd90 x15: ffde8aab8124 [ 10.631513] x14: ffde8acdd380 x13: 41b58ab3 x12: ffbbd1bf9d91 [ 10.631522] x11: 1ffbd1bf9d90 x10: ffbbd1bf9d90 x9 : dfc0 [ 10.631531] x8 : 00442e406270 x7 : ffde8dfcec87 x6 : 0001 [ 10.631539] x5 : ffde8dfcec80 x4 : x3 : ffde8bbadf08 [ 10.631548] x2 : 0001 x1 : ffde8eaff080 x0 : [ 10.631556] Call trace: [ 10.631559] module_bug_finalize+0x118/0x148 [ 10.631565] load_module+0x25ec/0x2a78 [ 10.631572] __do_sys_init_module+0x234/0x418 [ 10.631578] __arm64_sys_init_module+0x4c/0x68 [ 10.631584] invoke_syscall+0x68/0x198 [ 10.631589] el0_svc_common.constprop.0+0x11c/0x150 [ 10.631594] do_el0_svc+0x38/0x50 [ 10.631598] el0_svc+0x50/0xa0 [ 10.631604] el0t_64_sync_handler+0x120/0x130 [ 10.631609] el0t_64_sync+0x1a8/0x1b0 [ 10.631619] Code: 97c5418e c89ffef5 91002260 97c53ca7 (f9000675) [ 10.631624] ---[ end trace ]--- [ 10.642965] Kernel panic - not syncing: Oops: Fatal exception [ 10.642975] SMP: stopping secondary CPUs [ 10.648339] Kernel Offset: 0x1e0a80 from 0xffc08000 [ 10.648343] PHYS_OFFSET: 0x4000 [ 10.648345] CPU features: 0x0,c061,7002814a,2100720b [ 10.648350] Memory Limit: none
Re: [PATCH] remoteproc: mediatek: Refactor single core check and fix retrocompatibility
On Wed, Sep 20, 2023 at 11:03 PM Laura Nao wrote:
>
> On 9/19/23 11:23, AngeloGioacchino Del Regno wrote:
> > In older devicetrees we had the ChromeOS EC in a node called "cros-ec"
> > instead of the newer "cros-ec-rpmsg", but this driver is now checking
> > only for the latter, breaking compatibility with those.
> >
> > Besides, we can check if the SCP is single or dual core by simply
> > walking through the children of the main SCP node and checking if
> > if there's more than one "mediatek,scp-core" compatible node.
> >
> > Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core
> > SCP")
> > Signed-off-by: AngeloGioacchino Del Regno
> >
> > ---
> > drivers/remoteproc/mtk_scp.c | 18 +++---
> > 1 file changed, 7 insertions(+), 11 deletions(-)
> >
>
> Tested on asurada (spherion) and jacuzzi (juniper). The issue was detected by
> KernelCI, so:
>
> Reported-by: "kernelci.org bot"
> Tested-by: Laura Nao
Reviewed-by: Chen-Yu Tsai
Tested-by: Chen-Yu Tsai
on Hayato (MT8192) and Juniper (MT8183).
Re: [PATCH] remoteproc: mediatek: Detect single/multi core SCP with rpmsg-name property
On Tue, Sep 19, 2023 at 5:26 PM AngeloGioacchino Del Regno
wrote:
>
> Il 19/09/23 07:03, Chen-Yu Tsai ha scritto:
> > In the just landed multi-core SCP work, detection of single/multi core
> > SCP is done by checking the immediate child node of the SCP complex
> > device node. In the original work this was done by matching the child
> > node's name. However the name wasn't previously standardized. This
> > resulted in breakage on MT8183 and MT8192 Chromebooks while the driver
> > side changes were picked up and the device tree changes were not picked
> > up.
> >
> > Instead, match against the "mediatek,rpmsg-name" property, which is
> > required to be present in the rpmsg sub-node. This makes the
> > aforementioned devices running old device trees working again.
> >
> > Reported-by: Laura Nao
> > Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core
> > SCP")
> > Signed-off-by: Chen-Yu Tsai
> > ---
> > The patch is based on next-20230918 with a whole bunch of local patches
> > stacked on top. None of my local patches are related to remoteproc, so
> > it should be fine.
> >
> > I tested on both MT8183 Juniper and MT8192 Hayato and on both systems
> > the SCP successfully probed again.
>
> Instead of checking "mediatek,rpmsg-name", I think that a better way of
> checking if
> this is single or multi core is to count the number of cores...
>
> I've sent my own version of this, please check [1].
My version checks the structure of the device node, much like the original
code, just against a different property/node name. If it's multi-core,
there would be sub-nodes for each core, and the rpmsg property would be
under those.
Either way works. What we need right now is a quick fix to get things
working again. We can discuss how to make things better later.
Honestly I think it should just be based on the compatible string. However
the current design seems quite fragile. The driver probably can't handle
the core device nodes being out of order.
ChenYu
Re: [PATCH v17 00/14] Add support for MT8195 SCP 2nd core
On Tue, Sep 19, 2023 at 9:17 AM Mathieu Poirier wrote: > > On Mon, Sep 18, 2023 at 06:44:25PM +0800, Chen-Yu Tsai wrote: > > On Mon, Sep 18, 2023 at 6:32 PM Laura Nao wrote: > > > > > > > Other than patch 2 and 14, I have applied this set. The remaining > > > > patches will > > > > have to be resent to Matthias. > > > > > > > Thanks, > > > > Mathieu > > > > > > Hello, > > > > > > With patch 2 missing, the SCP is not probed correctly anymore on asurada > > > (MT8192) and kukui (MT8183). The mtk-scp driver relies on the existence > > > of the `cros-ec-rpmsg` node in the dt to determine if the SCP is single > > > or multicore. Without patch 2 the driver wrongly assumes the SCP on > > > MT8192 and MT8183 are multicore, leading to the following errors during > > > initialization: > > > > > > 10696 04:33:59.126671 <3>[ 15.465714] platform 1050.scp:cros-ec: > > > invalid resource (null) > > > 10697 04:33:59.142855 <3>[ 15.478560] platform 1050.scp:cros-ec: > > > Failed to parse and map sram memory > > > 10698 04:33:59.149650 <3>[ 15.486121] mtk-scp 1050.scp: Failed to > > > initialize core 0 rproc > > > > > > The issue was caught by KernelCI, complete logs can be found here: > > > - asurada: > > > https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8192-asurada-spherion-r0.html > > > - kukui: > > > https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8183-kukui-jacuzzi-juniper-sku16.html > > > > > > Reporting the issue so that patch 2 and 14 can be resent and merged soon. > > > > This being a backward incompatible DT binding change, maybe we should revert > > the node name change. Or, the driver could simply count the number of child > > nodes that have the "mediatek,rpmsg-name" property, which is required. > > > > You have a point. Can someone send a patch that makes this patchset backward > compatible? Please do so as quickly as possible to that it can go in the next > merge window with the rest of this feature. Otherwize I'll have to back out > the > whole thing. I sent out a patch [1] implementing my proposed change. ChenYu [1] https://lore.kernel.org/linux-remoteproc/20230919050305.3817347-1-we...@chromium.org/
[PATCH] remoteproc: mediatek: Detect single/multi core SCP with rpmsg-name property
In the just landed multi-core SCP work, detection of single/multi core
SCP is done by checking the immediate child node of the SCP complex
device node. In the original work this was done by matching the child
node's name. However the name wasn't previously standardized. This
resulted in breakage on MT8183 and MT8192 Chromebooks while the driver
side changes were picked up and the device tree changes were not picked
up.
Instead, match against the "mediatek,rpmsg-name" property, which is
required to be present in the rpmsg sub-node. This makes the
aforementioned devices running old device trees working again.
Reported-by: Laura Nao
Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core
SCP")
Signed-off-by: Chen-Yu Tsai
---
The patch is based on next-20230918 with a whole bunch of local patches
stacked on top. None of my local patches are related to remoteproc, so
it should be fine.
I tested on both MT8183 Juniper and MT8192 Hayato and on both systems
the SCP successfully probed again.
drivers/remoteproc/mtk_scp.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index ea227b566c54..ca15d9f382a1 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -1149,13 +1149,23 @@ static int scp_is_single_core(struct platform_device
*pdev)
struct device *dev = >dev;
struct device_node *np = dev_of_node(dev);
struct device_node *child;
+ bool has_rpmsg;
child = of_get_next_available_child(np, NULL);
if (!child)
return dev_err_probe(dev, -ENODEV, "No child node\n");
+ /*
+* On single core SCP systems, the immediate child of the SCP device
+* is the rpmsg node; on multi core systems, there's an intermediate
+* level node, one describing each core. Instead of matching on the
+* node name, which was recently changed in the DT binding in a
+* backward incompatible way, match against the "mediatek,rpmsg-name"
+* property, which is required in all rpmsg sub-nodes.
+*/
+ has_rpmsg = of_property_present(child, "mediatek,rpmsg-name");
of_node_put(child);
- return of_node_name_eq(child, "cros-ec-rpmsg");
+ return has_rpmsg;
}
static int scp_cluster_init(struct platform_device *pdev, struct
mtk_scp_of_cluster *scp_cluster)
--
2.42.0.459.ge4e396fd5e-goog
Re: [PATCH v17 00/14] Add support for MT8195 SCP 2nd core
On Mon, Sep 18, 2023 at 6:32 PM Laura Nao wrote: > > > Other than patch 2 and 14, I have applied this set. The remaining patches > > will > > have to be resent to Matthias. > > > Thanks, > > Mathieu > > Hello, > > With patch 2 missing, the SCP is not probed correctly anymore on asurada > (MT8192) and kukui (MT8183). The mtk-scp driver relies on the existence of > the `cros-ec-rpmsg` node in the dt to determine if the SCP is single or > multicore. Without patch 2 the driver wrongly assumes the SCP on MT8192 and > MT8183 are multicore, leading to the following errors during initialization: > > 10696 04:33:59.126671 <3>[ 15.465714] platform 1050.scp:cros-ec: > invalid resource (null) > 10697 04:33:59.142855 <3>[ 15.478560] platform 1050.scp:cros-ec: > Failed to parse and map sram memory > 10698 04:33:59.149650 <3>[ 15.486121] mtk-scp 1050.scp: Failed to > initialize core 0 rproc > > The issue was caught by KernelCI, complete logs can be found here: > - asurada: > https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8192-asurada-spherion-r0.html > - kukui: > https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8183-kukui-jacuzzi-juniper-sku16.html > > Reporting the issue so that patch 2 and 14 can be resent and merged soon. This being a backward incompatible DT binding change, maybe we should revert the node name change. Or, the driver could simply count the number of child nodes that have the "mediatek,rpmsg-name" property, which is required. ChenYu
Re: [PATCH 0/2] sunxi: Enforce consistent MMC numbering
Hi, On Mon, Apr 19, 2021 at 10:52 AM Samuel Holland wrote: > > Dealing with the inconsistent numbering has been a major pain, and > there is a solution with (as far as I can tell) no tangible downsides. > So let's use it. > > Yes, I know the kernel supports UUIDs for root=. But UUIDs do not help > when referencing the whole, unpartitioned device, like is needed for > updating the bootloader and firmware. So for the use case of "write a > bootloader to the SD card, regardless of where the board is currently > booted from", I know of two options: > - Dig around in sysfs to find the mmc number from the MMIO address, > which means I have to know the MMIO addresses for every SoC, or > - Apply patches like these. > > Samuel Holland (2): > ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering > arm64: dts: allwinner: Enforce consistent MMC numbering > > arch/arm/boot/dts/sunxi-h3-h5.dtsi| 6 ++ > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++ > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 6 ++ At least with Rockchip this is now done at the board level. IIRC it was a request from other people to not do it at the SoC level. I don't recall exactly who though. ChenYu > 3 files changed, 18 insertions(+) > > -- > 2.26.3 > >
Re: [PATCH] nvmem: sunxi_sid: Set type to OTP
On Mon, Apr 19, 2021 at 9:58 AM Samuel Holland wrote: > > This device currently reports an "Unknown" type in sysfs. > Since it is an eFuse hardware device, set its type to OTP. > > Signed-off-by: Samuel Holland Acked-by: Chen-Yu Tsai
Re: [PATCH v2 3/6] ARM: dts: rockchip: remove interrupts properties from pwm nodes rv1108.dtsi
On Mon, Apr 12, 2021 at 6:03 PM Johan Jonker wrote: > > On 4/12/21 5:15 AM, Chen-Yu Tsai wrote: > > On Sun, Apr 11, 2021 at 9:11 PM Johan Jonker wrote: > >> > >> A test with the command below gives this error: > >> > >> /arch/arm/boot/dts/rv1108-evb.dt.yaml: > >> pwm@1028: 'interrupts' does not match any of the regexes: > >> 'pinctrl-[0-9]+' > >> > >> "interrupts" is an undocumented property, so remove them > >> from pwm nodes in rv1108.dtsi. > >> > >> make ARCH=arm dtbs_check > >> DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml > >> > >> Signed-off-by: Johan Jonker > > > > Given that the interrupts were specified, meaning they are wired up in > > hardware, > > shouldn't the solution be to add the interrupts property to the binding > > instead? > > > > After all, the device tree describes the actual hardware, not just what the > > implementations need. > > > > ChenYu > > > > Hi, > > The question of what to do with it was asked in version 1, but no answer > was given, so I made a proposal. > The device tree description should be complete, but also as lean as > possible. If someone manages to sneak in undocumented properties without > reason then the ultimate consequence should be removal I think. > > Not sure about the (missing?) rv1108 TRM, but for rk3328 the interrupt > is used for: > > PWM_INTSTS 0x0040 W 0x Interrupt Status Register > Channel Interrupt Polarity Flag > This bit is used in capture mode in order to identify the > transition of the input waveform when interrupt is generated. > Channel Interrupt Status > Interrupt generated > > PWM_INT_EN 0x0044 W 0x Interrupt Enable Register > Channel Interrupt Enable > > Is there any current realistic use/setup for it to convince rob+dt this > should be added to pwm-rockchip.yaml? Well, the PWM core has capture support, and pwm-sti implements it with interrupt support, so I guess there's at least a legitimate case for adding that to the binding. Whether someone has an actual use case for it and adds code to implement it is another story. > The rk3328 interrupt rkpwm_int seems shared between channels, but only > included to pwm3. What is the proper way for that? I guess the bigger question is why was the PWM controller split into four device nodes, instead of just one encompassing the whole block. Now we'd have to introduce a new binding to support capture mode and interrupts. In that case I agree with dropping the interrupts for now, as it just won't fit. But I would add this additional information to the commit message. Regards ChenYu
Re: [PATCH v2 3/6] ARM: dts: rockchip: remove interrupts properties from pwm nodes rv1108.dtsi
On Sun, Apr 11, 2021 at 9:11 PM Johan Jonker wrote: > > A test with the command below gives this error: > > /arch/arm/boot/dts/rv1108-evb.dt.yaml: > pwm@1028: 'interrupts' does not match any of the regexes: > 'pinctrl-[0-9]+' > > "interrupts" is an undocumented property, so remove them > from pwm nodes in rv1108.dtsi. > > make ARCH=arm dtbs_check > DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml > > Signed-off-by: Johan Jonker Given that the interrupts were specified, meaning they are wired up in hardware, shouldn't the solution be to add the interrupts property to the binding instead? After all, the device tree describes the actual hardware, not just what the implementations need. ChenYu
Re: [PATCH v2] rockchip: enabled LAN port on NanoPi R2S
On Mon, Apr 5, 2021 at 7:03 PM Johan Jonker wrote:
>
> Hi Tianling,
>
> On 4/5/21 11:34 AM, Tianling Shen wrote:
> > From: David Bauer
> >
> > Enable the USB3 port on the FriendlyARM NanoPi R2S.
> > This is required for the USB3 attached LAN port to work.
> >
> > Signed-off-by: David Bauer
> > [added device node for USB Ethernet controller]
> > Signed-off-by: Tianling Shen
> > ---
> > .../boot/dts/rockchip/rk3328-nanopi-r2s.dts | 32 +++
> > 1 file changed, 32 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > index faf496d789cf..18936b393d9d 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > @@ -13,6 +13,10 @@
> > model = "FriendlyElec NanoPi R2S";
> > compatible = "friendlyarm,nanopi-r2s", "rockchip,rk3328";
> >
> > + aliases {
> > + ethernet1 =
> > + };
> > +
> > chosen {
> > stdout-path = "serial2:150n8";
> > };
> > @@ -37,6 +41,16 @@
> > };
> > };
> >
>
> > + vcc_rtl8153: vcc-rtl8153-regulator {
>
> sort nodename
>
> > + compatible = "regulator-fixed";
> > + gpio = < RK_PC6 GPIO_ACTIVE_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_en_drv>;
> > + regulator-always-on;
>
> > + regulator-name = "vcc_rtl8153";
>
> exception to the sort rule
> sort regulator-name above all other regulator properties
>
> > + enable-active-high;
>
> sort
>
>
> Heiko's sort rules:
>
> compatible
> reg
> interrupts
> [alphabetical]
> status [if needed]
>
>
>
> > + };
> > +
> > leds {
> > compatible = "gpio-leds";
> > pinctrl-0 = <_led_pin>, <_led_pin>, <_led_pin>;
> > @@ -265,6 +279,12 @@
> > };
> > };
> > };
> > +
> > + usb {
> > + rtl8153_en_drv: rtl8153-en-drv {
> > + rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO
> > _pull_none>;
> > + };
> > + };
> > };
> >
> > _domains {
> > @@ -364,6 +384,18 @@
> > dr_mode = "host";
> > };
> >
> > + {
> > + dr_mode = "host";
> > + status = "okay";
> > +
>
> > + r8153: usb-eth@2 {
>
> With YAML undocumented additional properties and nodes generate
> notifications.
> We need a change in the documents below for that.
> rockchip,dwc3.yaml > usb-drd.yaml > usb.yaml
>
> Is there a standard for the usb-eth nodename?
The USB devices binding seems to specify "device" and then
"interface" sub-nodes.
> > + compatible = "realtek,rtl8153";
>
> Since a while Rob has improved has scripts.
> There's no escape anymore.
> Add a YAML document to this serie for "realtek,rtl8153".
Actually it should be "usbbda,8153", which conforms to
Documentation/devicetree/bindings/usb/usb-device.yaml
Giving "realtek,rtl8153" to the kernel will not help it match any
device.
ChenYu
> Improve checking for undocumented compatible strings
> https://github.com/devicetree-org/dt-schema/commit/93e7ada8d53af099074cb5d53f7caa12835784e0
>
> > + reg = <2>;
>
> Why 2 ?
>
> > +
>
> > + local-mac-address = [ 00 00 00 00 00 00 ]; /* Filled in by
> > U-Boot */
>
> This is a private property.
> In a generic dts that's up to the user.
>
> > + };
> > +};
> > +
> > _host0_ehci {
> > status = "okay";
> > };
> >
>
Re: [PATCH] rockchip: enabled LAN port on NanoPi R2S
On Mon, Apr 5, 2021 at 4:53 PM Tianling Shen wrote:
>
> Hi Chen-Yu,
>
> On 2021-04-05 16:14, Chen-Yu Tsai wrote:
> >
> > Hi,
> >
> > On Mon, Apr 5, 2021 at 3:46 PM Tianling Shen wrote:
> > >
> > > From: David Bauer
> > >
> > > Enable the USB3 port on the FriendlyARM NanoPi R2S.
> > > This is required for the USB3 attached LAN port to work.
> > >
> > > Signed-off-by: David Bauer
> > > Signed-off-by: Tianling Shen
> > > ---
> > > .../boot/dts/rockchip/rk3328-nanopi-r2s.dts | 23 +++
> > > 1 file changed, 23 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > > b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > > index faf496d789cf..6ba9799a95c5 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > > @@ -37,6 +37,18 @@
> > > };
> > > };
> > >
> > > + vcc_rtl8153: vcc-rtl8153-regulator {
> > > + compatible = "regulator-fixed";
> > > + gpio = < RK_PC6 GPIO_ACTIVE_HIGH>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_en_drv>;
> > > + regulator-always-on;
> > > + regulator-name = "vcc_rtl8153";
> > > + regulator-min-microvolt = <500>;
> > > + regulator-max-microvolt = <500>;
> >
> > This is just a simple switch, not an actual regulator.
> > It would make more sense to drop the voltage range and
> > instead have the implementation pass-through voltage
> > constraints from its parent.
>
> Thanks, I'll remove them in v2.
>
> >
> > > + enable-active-high;
> > > + };
> > > +
> > > leds {
> > > compatible = "gpio-leds";
> > > pinctrl-0 = <_led_pin>, <_led_pin>,
> > > <_led_pin>;
> > > @@ -265,6 +277,12 @@
> > > };
> > > };
> > > };
> > > +
> > > + usb {
> > > + rtl8153_en_drv: rtl8153-en-drv {
> > > + rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO
> > > _pull_none>;
> > > + };
> > > + };
> > > };
> > >
> > > _domains {
> > > @@ -364,6 +382,11 @@
> > > dr_mode = "host";
> > > };
> > >
> > > + {
> > > + dr_mode = "host";
> > > + status = "okay";
> >
> > Please also add a device node for the actual Ethernet controller, and
> > set up an aliases node for it, so that the bootloader has some place
> > to fill in a MAC address.
>
> But there's no valid (unique) MAC address for both this or on-board
> ethernet...
> They're non-existent in design.
Correct. And thanks for confirming that it's not just me and Robin that
got boards without the MAC address EEPROM...
If the user sets some MAC address in the bootloader environment by hand,
the bootloader could still potentially pass that MAC address to Linux
through the device tree. Whether the board has a valid address or not
is beside the point.
ChenYu
> Thanks,
> Tianling.
>
> >
> >
> > ChenYu
> >
> > > +};
> > > +
> > > _host0_ehci {
> > > status = "okay";
> > > };
> > > --
> > > 2.17.1
> > >
> > >
> > > ___
> > > linux-arm-kernel mailing list
> > > linux-arm-ker...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH] rockchip: enabled LAN port on NanoPi R2S
Hi,
On Mon, Apr 5, 2021 at 3:46 PM Tianling Shen wrote:
>
> From: David Bauer
>
> Enable the USB3 port on the FriendlyARM NanoPi R2S.
> This is required for the USB3 attached LAN port to work.
>
> Signed-off-by: David Bauer
> Signed-off-by: Tianling Shen
> ---
> .../boot/dts/rockchip/rk3328-nanopi-r2s.dts | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> index faf496d789cf..6ba9799a95c5 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> @@ -37,6 +37,18 @@
> };
> };
>
> + vcc_rtl8153: vcc-rtl8153-regulator {
> + compatible = "regulator-fixed";
> + gpio = < RK_PC6 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_en_drv>;
> + regulator-always-on;
> + regulator-name = "vcc_rtl8153";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
This is just a simple switch, not an actual regulator.
It would make more sense to drop the voltage range and
instead have the implementation pass-through voltage
constraints from its parent.
> + enable-active-high;
> + };
> +
> leds {
> compatible = "gpio-leds";
> pinctrl-0 = <_led_pin>, <_led_pin>, <_led_pin>;
> @@ -265,6 +277,12 @@
> };
> };
> };
> +
> + usb {
> + rtl8153_en_drv: rtl8153-en-drv {
> + rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO
> _pull_none>;
> + };
> + };
> };
>
> _domains {
> @@ -364,6 +382,11 @@
> dr_mode = "host";
> };
>
> + {
> + dr_mode = "host";
> + status = "okay";
Please also add a device node for the actual Ethernet controller, and
set up an aliases node for it, so that the bootloader has some place
to fill in a MAC address.
ChenYu
> +};
> +
> _host0_ehci {
> status = "okay";
> };
> --
> 2.17.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 28/38] dt-bindings: power: supply: axp20x: Convert to DT schema format
On Fri, Mar 12, 2021 at 11:52 PM Sebastian Reichel wrote: > > Convert the binding to DT schema format. > > Cc: Chen-Yu Tsai > Signed-off-by: Sebastian Reichel Looks good to me. Though I'm not well versed in the new YAML binding format yet. Acked-by: Chen-Yu Tsai
Re: [linux-sunxi] [PATCH v2] ARM: dts: sun8i: h3: beelink-x2: Add power button
On Wed, Mar 24, 2021 at 4:44 AM Jernej Skrabec wrote: > > Beelink X2 has power button. Add node for it. > > Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai
Re: [PATCH v3 6/8] power: supply: Clean-up few drivers by using managed work init
Hi,
On Tue, Mar 23, 2021 at 9:58 PM Matti Vaittinen
wrote:
>
> Few drivers implement remove call-back only for ensuring a delayed
> work gets cancelled prior driver removal. Clean-up these by switching
> to use devm_delayed_work_autocancel() instead.
>
> This change is compile-tested only. All testing is appreciated.
>
> Signed-off-by: Matti Vaittinen
> Acked-by: Sebastian Reichel
> ---
> Changelog from RFCv2:
> - RFC dropped. No functional changes.
>
> drivers/power/supply/axp20x_usb_power.c | 15 +--
> drivers/power/supply/bq24735-charger.c | 18 ++
> drivers/power/supply/ltc2941-battery-gauge.c | 20 +++-
> drivers/power/supply/sbs-battery.c | 16 +---
> 4 files changed, 23 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/power/supply/axp20x_usb_power.c
> b/drivers/power/supply/axp20x_usb_power.c
> index 8933ae26c3d6..4259709e3491 100644
> --- a/drivers/power/supply/axp20x_usb_power.c
> +++ b/drivers/power/supply/axp20x_usb_power.c
> @@ -8,6 +8,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -646,21 +647,16 @@ static int axp20x_usb_power_probe(struct
> platform_device *pdev)
> }
> }
>
> + ret = devm_delayed_work_autocancel(>dev, >vbus_detect,
> + axp20x_usb_power_poll_vbus);
> + if (ret)
> + return ret;
This doesn't look right. The IRQ is requested before this, and the delayed_work
struct is initialized even earlier, so you'd be re-initializing the struct,
with the work item potentially running or queued up already.
ChenYu
> if (axp20x_usb_vbus_needs_polling(power))
> queue_delayed_work(system_power_efficient_wq,
> >vbus_detect, 0);
>
> return 0;
> }
>
> -static int axp20x_usb_power_remove(struct platform_device *pdev)
> -{
> - struct axp20x_usb_power *power = platform_get_drvdata(pdev);
> -
> - cancel_delayed_work_sync(>vbus_detect);
> -
> - return 0;
> -}
> -
> static const struct of_device_id axp20x_usb_power_match[] = {
> {
> .compatible = "x-powers,axp202-usb-power-supply",
> @@ -680,7 +676,6 @@ MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
>
> static struct platform_driver axp20x_usb_power_driver = {
> .probe = axp20x_usb_power_probe,
> - .remove = axp20x_usb_power_remove,
> .driver = {
> .name = DRVNAME,
> .of_match_table = axp20x_usb_power_match,
Re: [RFC RESEND PATCH v2 6/8] power: supply: Clean-up few drivers by using managed work init
Hi,
On Mon, Mar 22, 2021 at 3:38 PM Matti Vaittinen
wrote:
>
> Few drivers implement remove call-back only for ensuring a delayed
> work gets cancelled prior driver removal. Clean-up these by switching
> to use devm_delayed_work_autocancel() instead.
>
> This change is compile-tested only. All testing is appreciated.
>
> Signed-off-by: Matti Vaittinen
> Acked-by: Sebastian Reichel
> ---
> drivers/power/supply/axp20x_usb_power.c | 15 +--
> drivers/power/supply/bq24735-charger.c | 18 ++
> drivers/power/supply/ltc2941-battery-gauge.c | 20 +++-
> drivers/power/supply/sbs-battery.c | 16 +---
> 4 files changed, 23 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/power/supply/axp20x_usb_power.c
> b/drivers/power/supply/axp20x_usb_power.c
> index 8933ae26c3d6..4259709e3491 100644
> --- a/drivers/power/supply/axp20x_usb_power.c
> +++ b/drivers/power/supply/axp20x_usb_power.c
> @@ -8,6 +8,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -646,21 +647,16 @@ static int axp20x_usb_power_probe(struct
> platform_device *pdev)
> }
> }
>
> + ret = devm_delayed_work_autocancel(>dev, >vbus_detect,
> + axp20x_usb_power_poll_vbus);
> + if (ret)
> + return ret;
This doesn't look right. The IRQ is requested before this, and the delayed_work
struct is initialized even earlier, so you'd be re-initializing the struct,
with the work item potentially running or queued up already.
ChenYu
> if (axp20x_usb_vbus_needs_polling(power))
> queue_delayed_work(system_power_efficient_wq,
> >vbus_detect, 0);
>
> return 0;
> }
>
> -static int axp20x_usb_power_remove(struct platform_device *pdev)
> -{
> - struct axp20x_usb_power *power = platform_get_drvdata(pdev);
> -
> - cancel_delayed_work_sync(>vbus_detect);
> -
> - return 0;
> -}
> -
> static const struct of_device_id axp20x_usb_power_match[] = {
> {
> .compatible = "x-powers,axp202-usb-power-supply",
> @@ -680,7 +676,6 @@ MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
>
> static struct platform_driver axp20x_usb_power_driver = {
> .probe = axp20x_usb_power_probe,
> - .remove = axp20x_usb_power_remove,
> .driver = {
> .name = DRVNAME,
> .of_match_table = axp20x_usb_power_match,
Re: [PATCH] media: platform: sunxi: sun6i-csi: fix error return code of sun6i_video_start_streaming()
On Sat, Mar 6, 2021 at 10:15 PM Jia-Ju Bai wrote:
>
> When sun6i_video_remote_subdev() returns NULL to subdev, no error return
> code of sun6i_video_start_streaming() is assigned.
> To fix this bug, ret is assigned with -EINVAL in this case.
>
> Reported-by: TOTE Robot
> Signed-off-by: Jia-Ju Bai
This should have the tag:
Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s")
Please try to add them when fixing bugs. And this should also be tagged
for stable, so
Cc:
Otherwise,
Acked-by: Chen-Yu Tsai
[PATCH] arm64: dts: allwinner: h6: Switch to macros for RSB clock/reset indices
From: Chen-Yu Tsai
The macros for the clock and reset indices for the RSB hardware block
were replaced with raw numbers when the RSB controller node was added.
This was done to avoid cross-tree dependencies.
Now that both the clk and DT changes have been merged, we can switch
back to using the macros.
Fixes: aaad900757a6 ("arm64: dts: allwinner: h6: Add RSB controller node")
Signed-off-by: Chen-Yu Tsai
---
Small patch split out from the H6 RSB clock support patch.
This should be merged for v5.12.
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 49e979794094..af8b7d0ef750 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -995,9 +995,9 @@ r_rsb: rsb@7083000 {
compatible = "allwinner,sun8i-a23-rsb";
reg = <0x07083000 0x400>;
interrupts = ;
- clocks = <_ccu 13>;
+ clocks = <_ccu CLK_R_APB2_RSB>;
clock-frequency = <300>;
- resets = <_ccu 7>;
+ resets = <_ccu RST_R_APB2_RSB>;
pinctrl-names = "default";
pinctrl-0 = <_rsb_pins>;
status = "disabled";
--
2.30.1
Re: [PATCH] clk: sunxi-ng: v3s: add support for variable rate audio pll output
On Thu, Feb 18, 2021 at 4:06 PM Icenowy Zheng wrote: > > > > 于 2021年2月18日 GMT+08:00 下午3:58:35, Maxime Ripard 写到: > >Hi, > > > >On Fri, Feb 12, 2021 at 02:57:25PM +0100, Tobias Schramm wrote: > >> Previously the variable rate audio pll output was fixed to a divider > >of > >> four. This is unfortunately incompatible with generating commonly > >used > >> I2S core clock rates like 24.576MHz from the 24MHz parent clock. > >> This commit adds support for arbitrary audio pll output dividers to > >fix > >> that. > >> > >> Signed-off-by: Tobias Schramm > > > >It's not really clear to me how that would help. > > We have introducee SDM-based accurate audio PLL on several > other SoCs. Some people is quite sensitive about audio-related things. Right. What you really want is the SDM-based fractional clock support. Just look at the other drivers. > > > >The closest frequency we can provide for 24.576MHz would be 24580645 > >Hz, > >with N = 127, M = 31 and P = 4, so it would work with what we have > >already? Correct. And that is still slightly off. It's even worse for the 44.1khz family. ChenYu > >Maxime > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: Re: [PATCH 2/5] drm/sun4i: tcon: set sync polarity for tcon1 channel
On Sat, Feb 6, 2021 at 12:21 AM Jernej Škrabec wrote:
>
> Dne petek, 05. februar 2021 ob 17:01:30 CET je Maxime Ripard napisal(a):
> > On Fri, Feb 05, 2021 at 11:21:22AM +0800, Chen-Yu Tsai wrote:
> > > On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec
> wrote:
> > > >
> > > > Channel 1 has polarity bits for vsync and hsync signals but driver never
> > > > sets them. It turns out that with pre-HDMI2 controllers seemingly there
> > > > is no issue if polarity is not set. However, with HDMI2 controllers
> > > > (H6) there often comes to de-synchronization due to phase shift. This
> > > > causes flickering screen. It's safe to assume that similar issues might
> > > > happen also with pre-HDMI2 controllers.
> > > >
> > > > Solve issue with setting vsync and hsync polarity. Note that display
> > > > stacks with tcon top have polarity bits actually in tcon0 polarity
> > > > register.
> > > >
> > > > Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> > > > Tested-by: Andre Heider
> > > > Signed-off-by: Jernej Skrabec
> > > > ---
> > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 24
> > > > drivers/gpu/drm/sun4i/sun4i_tcon.h | 5 +
> > > > 2 files changed, 29 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/
> sun4i_tcon.c
> > > > index 6b9af4c08cd6..0d132dae58c0 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > @@ -672,6 +672,29 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon
> *tcon,
> > > > SUN4I_TCON1_BASIC5_V_SYNC(vsync) |
> > > > SUN4I_TCON1_BASIC5_H_SYNC(hsync));
> > > >
> > > > + /* Setup the polarity of sync signals */
> > > > + if (tcon->quirks->polarity_in_ch0) {
> > > > + val = 0;
> > > > +
> > > > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > > > + val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> > > > +
> > > > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > > > + val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> > > > +
> > > > + regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG, val);
> > > > + } else {
> > > > + val = SUN4I_TCON1_IO_POL_UNKNOWN;
> > >
> > > I think a comment for the origin of this is warranted.
> >
> > If it's anything like TCON0, it's the pixel clock polarity
>
> Hard to say, DW HDMI controller has "data enable" polarity along hsync and
> vsync. It could be either or none of those.
>
> What should I write in comment? BSP drivers and documentation use only generic
> names like io2_inv.
Just say that we don't know exactly what it is, but it is required for things
to work properly? Would be interesting to know what happens if you don't set
this bit, but do set VSYNC/HSYNC polarity properly.
ChenYu
Re: [linux-sunxi] [PATCH 5/5] drm/sun4i: dw-hdmi: Fix max. frequency for H6
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> It turns out that reasoning for lowering max. supported frequency is
> wrong. Scrambling works just fine. Several now fixed bugs prevented
> proper functioning, even with rates lower than 340 MHz. Issues were just
> more pronounced with higher frequencies.
>
> Fix that by allowing max. supported frequency in HW and fix the comment.
>
> Fixes: cd9063757a22 ("drm/sun4i: DW HDMI: Lower max. supported rate for H6")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
Re: [linux-sunxi] [PATCH 4/5] drm/sun4i: Fix H6 HDMI PHY configuration
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> cpce value for 594 MHz is set differently in BSP driver. Fix that.
>
> Fixes: c71c9b2fee17 ("drm/sun4i: Add support for Synopsys HDMI PHY")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
Re: [PATCH 3/5] drm/sun4i: dw-hdmi: always set clock rate
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> As expected, HDMI controller clock should always match pixel clock. In
> the past, changing HDMI controller rate would seemingly worsen
> situation. However, that was the result of other bugs which are now
> fixed.
>
> Fix that by removing set_rate quirk and always set clock rate.
>
> Fixes: 40bb9d3147b2 ("drm/sun4i: Add support for H6 DW HDMI controller")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
Re: [PATCH 2/5] drm/sun4i: tcon: set sync polarity for tcon1 channel
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> Channel 1 has polarity bits for vsync and hsync signals but driver never
> sets them. It turns out that with pre-HDMI2 controllers seemingly there
> is no issue if polarity is not set. However, with HDMI2 controllers
> (H6) there often comes to de-synchronization due to phase shift. This
> causes flickering screen. It's safe to assume that similar issues might
> happen also with pre-HDMI2 controllers.
>
> Solve issue with setting vsync and hsync polarity. Note that display
> stacks with tcon top have polarity bits actually in tcon0 polarity
> register.
>
> Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 24
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 5 +
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 6b9af4c08cd6..0d132dae58c0 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -672,6 +672,29 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> SUN4I_TCON1_BASIC5_V_SYNC(vsync) |
> SUN4I_TCON1_BASIC5_H_SYNC(hsync));
>
> + /* Setup the polarity of sync signals */
> + if (tcon->quirks->polarity_in_ch0) {
> + val = 0;
> +
> + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> + val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> +
> + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> + val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> +
> + regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG, val);
> + } else {
> + val = SUN4I_TCON1_IO_POL_UNKNOWN;
I think a comment for the origin of this is warranted.
Otherwise,
Reviewed-by: Chen-Yu Tsai
> +
> + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> + val |= SUN4I_TCON1_IO_POL_HSYNC_POSITIVE;
> +
> + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> + val |= SUN4I_TCON1_IO_POL_VSYNC_POSITIVE;
> +
> + regmap_write(tcon->regs, SUN4I_TCON1_IO_POL_REG, val);
> + }
> +
> /* Map output pins to channel 1 */
> regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
>SUN4I_TCON_GCTL_IOMAP_MASK,
> @@ -1500,6 +1523,7 @@ static const struct sun4i_tcon_quirks
> sun8i_a83t_tv_quirks = {
>
> static const struct sun4i_tcon_quirks sun8i_r40_tv_quirks = {
> .has_channel_1 = true,
> + .polarity_in_ch0= true,
> .set_mux= sun8i_r40_tcon_tv_set_mux,
> };
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index c5ac1b02482c..b504fb2d3de5 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -154,6 +154,10 @@
> #define SUN4I_TCON1_BASIC5_V_SYNC(height) (((height) - 1) &
> 0x3ff)
>
> #define SUN4I_TCON1_IO_POL_REG 0xf0
> +#define SUN4I_TCON1_IO_POL_UNKNOWN BIT(26)
> +#define SUN4I_TCON1_IO_POL_HSYNC_POSITIVE BIT(25)
> +#define SUN4I_TCON1_IO_POL_VSYNC_POSITIVE BIT(24)
> +
> #define SUN4I_TCON1_IO_TRI_REG 0xf4
>
> #define SUN4I_TCON_ECC_FIFO_REG0xf8
> @@ -236,6 +240,7 @@ struct sun4i_tcon_quirks {
> boolneeds_de_be_mux; /* sun6i needs mux to select backend */
> boolneeds_edp_reset; /* a80 edp reset needed for tcon0 access */
> boolsupports_lvds; /* Does the TCON support an LVDS output? */
> + boolpolarity_in_ch0; /* some tcon1 channels have polarity bits in
> tcon0 pol register */
> u8 dclk_min_div; /* minimum divider for TCON0 DCLK */
>
> /* callback to handle tcon muxing options */
> --
> 2.30.0
>
Re: [linux-sunxi] [PATCH 1/5] clk: sunxi-ng: mp: fix parent rate change flag check
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> CLK_SET_RATE_PARENT flag is checked on parent clock instead of current
> one. Fix that.
>
> Fixes: 3f790433c3cb ("clk: sunxi-ng: Adjust MP clock parent rate when
> allowed")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
Re: [linux-sunxi] Re: [PATCH v5 06/20] mfd: axp20x: Allow AXP chips without interrupt lines
On Thu, Jan 28, 2021 at 6:15 PM Maxime Ripard wrote: > > On Wed, Jan 27, 2021 at 05:24:46PM +, Andre Przywara wrote: > > Currently the AXP chip requires to have its IRQ line connected to some > > interrupt controller, and will fail probing when this is not the case. > > > > On a new Allwinner SoC (H616) there is no NMI pin anymore, and at > > least one board does not connect the AXP's IRQ pin to anything else, > > so the interrupt functionality of the AXP chip is simply not available. > > > > Check whether the interrupt line number returned by the platform code is > > valid, before trying to register the irqchip. If not, we skip this > > registration, to avoid the driver to bail out completely. > > > > Signed-off-by: Andre Przywara > > Acked-by: Maxime Ripard Acked-by: Chen-Yu Tsai
Re: [PATCH v5 14/20] dt-bindings: bus: rsb: Add H616 compatible string
On Thu, Jan 28, 2021 at 1:26 AM Andre Przywara wrote: > > Add the obvious compatible name to the existing RSB binding, and pair > it with the existing A23 fallback compatible string, as the devices are > compatible. > > Signed-off-by: Andre Przywara Acked-by: Chen-Yu Tsai
Re: [linux-sunxi] [PATCH v5 04/20] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)
Hi, On Thu, Jan 28, 2021 at 1:26 AM Andre Przywara wrote: > > The AXP305 PMIC used in AXP805 seems to be fully compatible to the ^ This statement doesn't quite make sense. I assume you wanted to mention a board or the H616 SoC here? > AXP805 PMIC, so add the proper chain of compatible strings. > > Also at least on one board (Orangepi Zero2) there is no interrupt line > connected to the CPU, so make the "interrupts" property optional. > > Signed-off-by: Andre Przywara > --- > Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt > b/Documentation/devicetree/bindings/mfd/axp20x.txt > index 4991a6415796..4fd748101e3c 100644 > --- a/Documentation/devicetree/bindings/mfd/axp20x.txt > +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt > @@ -26,10 +26,10 @@ Required properties: > * "x-powers,axp803" > * "x-powers,axp806" > * "x-powers,axp805", "x-powers,axp806" > +* "x-powers,axp803", "x-powers,axp805", "x-powers,axp806" axp305? axp803 is used with A64 IIRC. ChenYu > * "x-powers,axp809" > * "x-powers,axp813" > - reg: The I2C slave address or RSB hardware address for the AXP chip > -- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin > - interrupt-controller: The PMIC has its own internal IRQs > - #interrupt-cells: Should be set to 1 > > @@ -43,6 +43,7 @@ more information: > AXP20x/LDO3: software-based implementation > > Optional properties: > +- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin > - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz > AXP152/20X: range: 750-1875, Default: 1.5 MHz > AXP22X/8XX: range: 1800-4050, Default: 3 MHz > -- > 2.17.5 > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/linux-sunxi/20210127172500.13356-5-andre.przywara%40arm.com.
Re: arm: sunxi: &83t: WARNING: CPU: 2 PID: 57 at drivers/thermal/thermal_core.c:563 thermal_zone_device_update
Hi, On Sun, Jan 31, 2021 at 12:54 AM Corentin Labbe wrote: > > Hello > > When booting next-20210128, I got the following warning on by bpim3 > 6.148421] [ cut here ] > [6.153145] WARNING: CPU: 2 PID: 57 at drivers/thermal/thermal_core.c:563 > thermal_zone_device_update+0x134/0x154 > [6.163378] 'thermal_zone_device_update' must not be called without > 'get_temp' ops set > [6.171300] Modules linked in: sha256_generic libsha256 > [6.176553] CPU: 2 PID: 57 Comm: kworker/2:1 Not tainted > 5.11.0-rc1-00042-gf3788af62cfe #399 > [6.184984] Hardware name: Allwinner A83t board > [6.189517] Workqueue: events deferred_probe_work_func > [6.194686] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [6.202438] [] (show_stack) from [] > (dump_stack+0x98/0xac) > [6.209666] [] (dump_stack) from [] (__warn+0xc0/0xd8) > [6.216545] [] (__warn) from [] > (warn_slowpath_fmt+0x98/0xc0) > [6.224030] [] (warn_slowpath_fmt) from [] > (thermal_zone_device_update+0x134/0x154) > [6.233426] [] (thermal_zone_device_update) from [] > (__thermal_cooling_device_register+0x334/0x35c) > [6.244204] [] (__thermal_cooling_device_register) from > [] (__cpufreq_cooling_register.constprop.0+0x184/0x294) > [6.256026] [] (__cpufreq_cooling_register.constprop.0) from > [] (of_cpufreq_cooling_register+0x40/0x7c) > [6.267153] [] (of_cpufreq_cooling_register) from [] > (cpufreq_online+0x2b4/0x8f4) > [6.276379] [] (cpufreq_online) from [] > (cpufreq_add_dev+0x6c/0x78) > [6.284383] [] (cpufreq_add_dev) from [] > (subsys_interface_register+0xa4/0xf0) > [6.293344] [] (subsys_interface_register) from [] > (cpufreq_register_driver+0x144/0x2dc) > [6.303169] [] (cpufreq_register_driver) from [] > (dt_cpufreq_probe+0x298/0x3b8) > [6.312215] [] (dt_cpufreq_probe) from [] > (platform_probe+0x5c/0xb8) > [6.320313] [] (platform_probe) from [] > (really_probe+0x1dc/0x3b8) > [6.328231] [] (really_probe) from [] > (driver_probe_device+0x5c/0xb4) > [6.336406] [] (driver_probe_device) from [] > (bus_for_each_drv+0x84/0xc8) > [6.344928] [] (bus_for_each_drv) from [] > (__device_attach+0xe8/0x154) > [6.353189] [] (__device_attach) from [] > (bus_probe_device+0x84/0x8c) > [6.361365] [] (bus_probe_device) from [] > (deferred_probe_work_func+0x64/0x90) > [6.370321] [] (deferred_probe_work_func) from [] > (process_one_work+0x1dc/0x438) > [6.379456] [] (process_one_work) from [] > (worker_thread+0x25c/0x55c) > [6.387632] [] (worker_thread) from [] > (kthread+0x124/0x150) > [6.395032] [] (kthread) from [] > (ret_from_fork+0x14/0x24) > [6.402256] Exception stack(0xc12d1fb0 to 0xc12d1ff8) > [6.407307] 1fa0: > > [6.415478] 1fc0: > > [6.423648] 1fe0: 0013 > [6.430301] ---[ end trace bd63a5c976f3611c ]--- > > I bisected the problem to > ARM: dts: sunxi: Remove thermal zones without trip points > > Reverting this commit remove the warning. The thermal subsystem seems to require a thermal zone be present for each thermal sensor that is registered. So maybe a better solution is not to remove the thermal zones without trip points, but just add the standard passive and critical trip points based on the SoC's thermal limits. ChenYu
Re: [PATCH v5 00/10] sunxi: Support IRQ wakeup from deep sleep
On Mon, Jan 25, 2021 at 6:56 PM Maxime Ripard wrote:
>
> On Sat, Jan 23, 2021 at 12:26:26AM -0600, Samuel Holland wrote:
> > On 1/22/21 4:47 AM, Maxime Ripard wrote:
> > > On Thu, Jan 21, 2021 at 07:33:54PM -0600, Samuel Holland wrote:
> > >> On 1/21/21 2:35 PM, Marc Zyngier wrote:
> > >>> On Sun, 17 Jan 2021 23:50:30 -0600, Samuel Holland wrote:
> > Allwinner sun6i/sun8i/sun50i SoCs (A31 and newer) have two interrupt
> > controllers: GIC and R_INTC. GIC does not support wakeup. R_INTC
> > handles
> > the external NMI pin, and provides 32+ IRQs to the ARISC. The first 16
> > of these correspond 1:1 to a block of GIC IRQs starting with the NMI.
> > The last 13-16 multiplex the first (up to) 128 GIC SPIs.
> >
> > This series replaces the existing chained irqchip driver that could
> > only
> > control the NMI, with a stacked irqchip driver that also provides
> > wakeup
> > capability for those multiplexed SPI IRQs. The idea is to preconfigure
> > the ARISC's IRQ controller, and then the ARISC firmware knows to wake
> > up
> > as soon as it receives an IRQ. It can also decide how deep it can
> > suspend based on the enabled wakeup IRQs.
> >
> > [...]
> > >>>
> > >>> Applied to irq/irqchip-5.12, thanks!
> > >>>
> > >>> [01/10] dt-bindings: irq: sun6i-r: Split the binding from sun7i-nmi
> > >>> commit: ad6b47cdef760410311f41876b21eb0c6fda4717
> > >>> [02/10] dt-bindings: irq: sun6i-r: Add a compatible for the H3
> > >>> commit: 6436eb4417094ea3308b33d8392fc02a1068dc78
> > >>> [03/10] irqchip/sun6i-r: Use a stacked irqchip driver
> > >>> commit: 4e34614636b31747b190488240a95647c227021f
> > >>> [04/10] irqchip/sun6i-r: Add wakeup support
> > >>> commit: 7ab365f6cd6de1e2b0cb1e1e3873dbf68e6f1003
> > >>>
> > >>> Please route the dts patches via the soc tree. Also, I had to
> > >>> manually fix the first patch as it wouldn't apply on top of
> > >>> 5.11-rc4 (which tree has it been diffed against?). Please
> > >>> check that the resolution is correct.
> > >>
> > >> This series was based on sunxi/for-next, which contains commit
> > >> 752b0aac99c7 ("dt-bindings: irq: sun7i-nmi: Add binding documentation
> > >> for the V3s NMI")[1].
> > >
> > > I assume merging the DT bits alone would break things? If so, I guess we
> > > can wait for 5.12 to be released before merging it
> >
> > Patch 5 does not depend on the new driver, so it could be merged at any
> > time. Yes, the remaining patches would break things if merged without
> > the driver.
>
> I've applied patch 5 then, could you send the rest of the DT patches
> when 5.13-rc1 is out?
I've put them in a for-5.13-late branch and merged them into for-next.
This should get a bit of boot testing via KernelCI. Maybe we'll get to
sending a late pull request for 5.13, maybe not.
ChenYu
Re: [PATCH] power: supply: axp20x_usb_power: Init work before enabling IRQs
On Sun, Jan 24, 2021 at 11:24 PM Samuel Holland wrote:
>
> The IRQ handler calls mod_delayed_work() on power->vbus_detect. However,
> that work item is not initialized until after the IRQs are enabled. If
> an IRQ is already pending when the driver is probed, the driver calls
> mod_delayed_work() on an uninitialized work item, which causes an oops.
>
> Fixes: bcfb7ae3f50b ("power: supply: axp20x_usb_power: Only poll while
> offline")
> Signed-off-by: Samuel Holland
> ---
> drivers/power/supply/axp20x_usb_power.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/power/supply/axp20x_usb_power.c
> b/drivers/power/supply/axp20x_usb_power.c
> index 20817a49110b..02aba3da271a 100644
> --- a/drivers/power/supply/axp20x_usb_power.c
> +++ b/drivers/power/supply/axp20x_usb_power.c
> @@ -711,20 +711,21 @@ static int axp20x_usb_power_probe(struct
> platform_device *pdev)
> struct_size(power, irqs,
> axp_data->num_irq_names),
> GFP_KERNEL);
> if (!power)
> return -ENOMEM;
>
> platform_set_drvdata(pdev, power);
>
> power->axp20x_id = axp_data->axp20x_id;
> power->regmap = axp20x->regmap;
> power->num_irqs = axp_data->num_irq_names;
> + INIT_DELAYED_WORK(>vbus_detect, axp20x_usb_power_poll_vbus);
Nit:
Since axp20x_usb_power_poll_vbus() calls power_supply_changed() on
power->supply, it would make more sense to have INIT_DELAYED_WORK()
after devm_power_supply_register(), just so things are ordered correctly.
In practice this has no effect on the end result, since by the time the
interrupts are enabled the power supply would have been registered.
ChenYu
> if (power->axp20x_id == AXP202_ID) {
> /* Enable vbus valid checking */
> ret = regmap_update_bits(power->regmap, AXP20X_VBUS_MON,
> AXP20X_VBUS_MON_VBUS_VALID,
> AXP20X_VBUS_MON_VBUS_VALID);
> if (ret)
> return ret;
>
> if (IS_ENABLED(CONFIG_AXP20X_ADC))
> @@ -763,21 +764,20 @@ static int axp20x_usb_power_probe(struct
> platform_device *pdev)
> ret = devm_request_any_context_irq(>dev, power->irqs[i],
>axp20x_usb_power_irq, 0,
>DRVNAME, power);
> if (ret < 0) {
> dev_err(>dev, "Error requesting %s IRQ: %d\n",
> axp_data->irq_names[i], ret);
> return ret;
> }
> }
>
> - INIT_DELAYED_WORK(>vbus_detect, axp20x_usb_power_poll_vbus);
> if (axp20x_usb_vbus_needs_polling(power))
> queue_delayed_work(system_power_efficient_wq,
> >vbus_detect, 0);
>
> return 0;
> }
>
> static int axp20x_usb_power_remove(struct platform_device *pdev)
> {
> struct axp20x_usb_power *power = platform_get_drvdata(pdev);
>
> --
> 2.26.2
>
Re: [PATCH v2] ARM: dts: sun7i: a20: bananapro: Fix ethernet node
On Fri, Jan 22, 2021 at 3:54 AM Jernej Škrabec wrote: > > Dne četrtek, 21. januar 2021 ob 18:08:36 CET je Hermann Lauer napisal(a): > > BPi Pro needs TX and RX delay for Gbit to work reliable and avoid high > > packet loss rates. The realtek phy driver overrides the settings of the > > pull ups for the delays, so fix this for Banana Pro. > > > > Signed-off-by: Hermann Lauer > > Much better. Now the only thing missing is "Fixes" tag, which references > commit which introduced the issue. Probably this will be the commit which > added ethernet node. This tag is important for deciding which commits should > be backported to stable releases. Take a look in v1 for M2U fixes tag. > > Btw, each version should have changelog under "---" line, so maintainers and > reviewers know what changed. The subject line should also be more concise. "Fix ethernet phy-mode" reads much better than "Fix ethernet node", which could mean a number of things. ChenYu
[PATCH v4 4/4] arm64: dts: rockchip: rk3399: Add NanoPi M4B
From: Chen-Yu Tsai
The NanoPi M4B is a minor revision of the original M4.
The differences against the original Nanopi M4 that are common with the
other M4V2 revision include:
- microphone header removed
- power button added
- recovery button added
Additional changes specific to the M4B:
- USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x
USB 2.0 ports
- ADB toggle switch added; this changes the top USB 3.0 host port to
a peripheral port
- Type-C port no longer supports data or PD
- WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0
but only 1T1R (down from 2T2R) for WiFi
Add a new dts file for the new board revision that shows the difference
against the original.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-nanopi-m4b.dts | 52 +++
2 files changed, 53 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index b29a445b355a..62d3abc17a24 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -34,6 +34,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-kobol-helios64.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4b.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-pinebook-pro.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
new file mode 100644
index ..72182c58cc46
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * FriendlyElec NanoPi M4B board device tree source
+ *
+ * Copyright (c) 2020 Chen-Yu Tsai
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi-m4.dts"
+
+/ {
+ model = "FriendlyElec NanoPi M4B";
+ compatible = "friendlyarm,nanopi-m4b", "rockchip,rk3399";
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <150>;
+ poll-interval = <100>;
+
+ recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <18000>;
+ };
+ };
+};
+
+/* No USB type-C PD power manager */
+/delete-node/
+
+ {
+ status = "disabled";
+};
+
+_host {
+ phy-supply = <_usb2>;
+};
+
+_otg {
+ phy-supply = <_typec>;
+};
+
+_otg {
+ phy-supply = <_usb1>;
+};
+
+_typec {
+ enable-active-high;
+ gpios = < RK_PD2 GPIO_ACTIVE_HIGH>;
+};
--
2.29.2
[PATCH v4 3/4] arm64: dts: rockchip: nanopi4: Move ep-gpios property to nanopc-t4
From: Chen-Yu Tsai
Only the NanoPC T4 hs the PCIe reset pin routed to the SoC. For the
NanoPi M4 family, no such signal is routed to the expansion header on
the base board.
As the schematics for the expansion board were not released, it is
unclear how this is handled, but the likely answer is that the signal
is always pulled high.
Move the ep-gpios property from the common nanopi4.dtsi file to the
board level nanopc-t4.dts file. This makes the nanopi-m4 lack ep-gpios,
matching the board design.
A companion patch "PCI: rockchip: make ep_gpio optional" for the Linux
driver is required, as the driver currently requires the property to be
present.
Fixes: e7a095908227 ("arm64: dts: rockchip: Add devicetree for NanoPC-T4")
Reviewed-by: Robin Murphy
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts | 1 +
arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
index e0d75617bb7e..452728b82e42 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
@@ -95,6 +95,7 @@ map3 {
};
{
+ ep-gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
num-lanes = <4>;
vpcie3v3-supply = <_sys>;
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
index 76a8b40a93c6..48ed4aaa37f3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
@@ -504,7 +504,6 @@ _phy {
};
{
- ep-gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
max-link-speed = <2>;
num-lanes = <2>;
vpcie0v9-supply = <_s3>;
--
2.29.2
[PATCH v4 2/4] dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B
From: Chen-Yu Tsai The NanoPi M4B is a minor revision of the original M4. The differences against the original Nanopi M4 that are common with the other M4V2 revision include: - microphone header removed - power button added - recovery button added Additional changes specific to the M4B: - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x USB 2.0 ports - ADB toggle switch added; this changes the top USB 3.0 host port to a peripheral port - Type-C port no longer supports data or PD - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 but only 1T1R (down from 2T2R) for WiFi Add a compatible string for the new board revision. Acked-by: Rob Herring Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/arm/rockchip.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 8a2dd9f1cff2..c3036f95c7bc 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -132,6 +132,7 @@ properties: - enum: - friendlyarm,nanopc-t4 - friendlyarm,nanopi-m4 + - friendlyarm,nanopi-m4b - friendlyarm,nanopi-neo4 - const: rockchip,rk3399 -- 2.29.2
[PATCH v4 0/4] arm64: rockchip: Fix PCIe ep-gpios requirement and Add Nanopi M4B
From: Chen-Yu Tsai Hi everyone, This is v4 of my Nanopi M4B series. Changes since v3 include: - Directly return dev_err_probe() instead of having a separate return statement Changes since v2 include: - Replaced dev_err() with dev_err_probe() for gpiod_get_optional() error - Added Reviewed-by tag from Robin Murphy for patch 3 Changes since v1 include: - Rewrite subject of patch 1 to match existing convention and reference 'ep-gpios' DT property instead of the 'ep_gpio' field This series mainly adds support for the new Nanopi M4B, which is a newer variant of the Nanopi M4. The differences against the original Nanopi M4 that are common with the other M4V2 revision include: - microphone header removed - power button added - recovery button added Additional changes specific to the M4B: - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x USB 2.0 ports - ADB toggle switch added; this changes the top USB 3.0 host port to a peripheral port - Type-C port no longer supports data or PD - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 but only 1T1R (down from 2T2R) for WiFi While working on this, I found that for the M4 family, the PCIe reset pin (from the M.2 expansion board) was not wired to the SoC. Only the NanoPC T4 has this wired. This ended up in patches 1 and 3. Patch 1 makes ep_gpio in the Rockchip PCIe driver optional. This property is optional in the DT binding, so this just makes the driver adhere to the binding. Patch 2 adds a new compatible string for the new board. Patch 3 moves the ep-gpios property of the pcie controller from the common nanopi4.dtsi file to the nanopc-t4.dts file. Patch 4 adds a new device tree file for the new board. It includes the original device tree for the M4, and then lists the differences. Given that patch 3 would make PCIe unusable without patch 1, I suggest merging patch 1 through the PCI tree as a fix for 5.11, and the rest for 5.12 through the Rockchip tree. Please have a look. The changes are mostly trivial. Regards ChenYu Chen-Yu Tsai (4): PCI: rockchip: Make 'ep-gpios' DT property optional dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B arm64: dts: rockchip: nanopi4: Move ep-gpios property to nanopc-t4 arm64: dts: rockchip: rk3399: Add NanoPi M4B .../devicetree/bindings/arm/rockchip.yaml | 1 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3399-nanopc-t4.dts| 1 + .../boot/dts/rockchip/rk3399-nanopi-m4b.dts | 52 +++ .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - drivers/pci/controller/pcie-rockchip.c| 9 ++-- 6 files changed, 59 insertions(+), 6 deletions(-) create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts -- 2.29.2
[PATCH v4 1/4] PCI: rockchip: Make 'ep-gpios' DT property optional
From: Chen-Yu Tsai
The Rockchip PCIe controller DT binding clearly states that 'ep-gpios' is
an optional property. And indeed there are boards that don't require it.
Make the driver follow the binding by using devm_gpiod_get_optional()
instead of devm_gpiod_get().
Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
Fixes: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver")
Fixes: 964bac9455be ("PCI: rockchip: Split out rockchip_pcie_parse_dt() to
parse DT")
Signed-off-by: Chen-Yu Tsai
---
Changes since v3:
- Directly return dev_err_probe() instead of having a separate return
statement
Changes since v2:
- Fix error message for failed GPIO
Changes since v1:
- Rewrite subject to match existing convention and reference
'ep-gpios' DT property instead of the 'ep_gpio' field
---
drivers/pci/controller/pcie-rockchip.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/controller/pcie-rockchip.c
b/drivers/pci/controller/pcie-rockchip.c
index 904dec0d3a88..a2ad0b7614a4 100644
--- a/drivers/pci/controller/pcie-rockchip.c
+++ b/drivers/pci/controller/pcie-rockchip.c
@@ -118,11 +118,10 @@ int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
}
if (rockchip->is_rc) {
- rockchip->ep_gpio = devm_gpiod_get(dev, "ep", GPIOD_OUT_HIGH);
- if (IS_ERR(rockchip->ep_gpio)) {
- dev_err(dev, "missing ep-gpios property in node\n");
- return PTR_ERR(rockchip->ep_gpio);
- }
+ rockchip->ep_gpio = devm_gpiod_get_optional(dev, "ep",
GPIOD_OUT_HIGH);
+ if (IS_ERR(rockchip->ep_gpio))
+ return dev_err_probe(dev, PTR_ERR(rockchip->ep_gpio),
+"failed to get ep GPIO\n");
}
rockchip->aclk_pcie = devm_clk_get(dev, "aclk");
--
2.29.2
Re: [PATCH v4 1/4] dt-bindings: usb: add rk3328 dwc3 docs
On Thu, Jan 21, 2021 at 12:30 PM Lindsey Stanpoor wrote: > > On Fri, Nov 6, 2020 at 11:42 PM Felipe Balbi wrote: > > > > > > Hi, > > > > Lindsey Stanpoor writes: > > > On Wed, Sep 2, 2020 at 11:12 AM wrote: > > >> > > >> From: Cameron Nemo > > >> > > >> Document compatible for dwc3 on the Rockchip rk3328 platform. > > > > > > Hi all, > > > > > > Wanted to give this patch submission a gentle ping. > > > > > > Rob Herring acked the documentation changes, but I have not heard > > > anything > > > from the USB or Rockchip maintainers. This patchset would facilitate USB3 > > > support for Rockchip rk3328 devices like the Pine Rock64. > > > > > > If there is anything I can do to help move this along, please let me know. > > > > Sorry, it had fallen through the cracks. It's now in my testing/next. > > Following up on this. Will this move out of your testing/next? The binding changes are likely stale now that the dwc3 binding has been converted to YAML. See Greg's USB tree. Also the DT changes should go through the arm-soc tree separately, so we can stack on additional changes enabling USB3 on other boards. ChenYu > -- > Cameron > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v3 1/4] PCI: rockchip: Make 'ep-gpios' DT property optional
On Tue, Jan 19, 2021 at 5:11 PM Heiko Stübner wrote:
>
> Am Mittwoch, 6. Januar 2021, 14:46:14 CET schrieb Chen-Yu Tsai:
> > From: Chen-Yu Tsai
> >
> > The Rockchip PCIe controller DT binding clearly states that 'ep-gpios' is
> > an optional property. And indeed there are boards that don't require it.
> >
> > Make the driver follow the binding by using devm_gpiod_get_optional()
> > instead of devm_gpiod_get().
> >
> > Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
> > Fixes: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver")
> > Fixes: 964bac9455be ("PCI: rockchip: Split out rockchip_pcie_parse_dt() to
> > parse DT")
> > Signed-off-by: Chen-Yu Tsai
> > ---
> > Heiko, I dropped you reviewed-by due to the error message change
> >
> > Changes since v2:
> > - Fix error message for failed GPIO
> >
> > Changes since v1:
> > - Rewrite subject to match existing convention and reference
> > 'ep-gpios' DT property instead of the 'ep_gpio' field
> > ---
> > drivers/pci/controller/pcie-rockchip.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-rockchip.c
> > b/drivers/pci/controller/pcie-rockchip.c
> > index 904dec0d3a88..90c957e3bc73 100644
> > --- a/drivers/pci/controller/pcie-rockchip.c
> > +++ b/drivers/pci/controller/pcie-rockchip.c
> > @@ -118,9 +118,10 @@ int rockchip_pcie_parse_dt(struct rockchip_pcie
> > *rockchip)
> > }
> >
> > if (rockchip->is_rc) {
> > - rockchip->ep_gpio = devm_gpiod_get(dev, "ep", GPIOD_OUT_HIGH);
> > + rockchip->ep_gpio = devm_gpiod_get_optional(dev, "ep",
> > GPIOD_OUT_HIGH);
> > if (IS_ERR(rockchip->ep_gpio)) {
> > - dev_err(dev, "missing ep-gpios property in node\n");
> > + dev_err_probe(dev, PTR_ERR(rockchip->ep_gpio),
> > + "failed to get ep GPIO\n");
> > return PTR_ERR(rockchip->ep_gpio);
>
> looking at [0] shouldn't that be just
> return dev_err_probe(dev, PTR_ERR(.)...);
> instead of dev_err_probe + additional return?
You're right. I was only expecting dev_err_probe() to deal with -EPROBE_DEFER.
I believe there won't be any future changes that would add any code here,
so I'll respin with the proper changes you mentioned.
Thanks!
ChenYu
> Heiko
>
> [0] https://elixir.bootlin.com/linux/latest/source/drivers/base/core.c#L4223
>
> > }
> > }
> >
>
>
>
>
Re: [PATCH v3 0/4] arm64: rockchip: Fix PCIe ep-gpios requirement and Add Nanopi M4B
Hi, On Wed, Jan 6, 2021 at 9:46 PM Chen-Yu Tsai wrote: > > From: Chen-Yu Tsai > > Hi everyone, > > This is v3 of my Nanopi M4B series. Changes since v2 include: > > - Replaced dev_err() with dev_err_probe() for gpiod_get_optional() error > - Added Reviewed-by tag from Robin Murphy for patch 3 > > Changes since v1 include: > > - Rewrite subject of patch 1 to match existing convention and reference > 'ep-gpios' DT property instead of the 'ep_gpio' field > > This series mainly adds support for the new Nanopi M4B, which is a newer > variant of the Nanopi M4. > > The differences against the original Nanopi M4 that are common with the > other M4V2 revision include: > > - microphone header removed > - power button added > - recovery button added > > Additional changes specific to the M4B: > > - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x > USB 2.0 ports > - ADB toggle switch added; this changes the top USB 3.0 host port to > a peripheral port > - Type-C port no longer supports data or PD > - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 > but only 1T1R (down from 2T2R) for WiFi > > While working on this, I found that for the M4 family, the PCIe reset > pin (from the M.2 expansion board) was not wired to the SoC. Only the > NanoPC T4 has this wired. This ended up in patches 1 and 3. > > Patch 1 makes ep_gpio in the Rockchip PCIe driver optional. This property > is optional in the DT binding, so this just makes the driver adhere to > the binding. > > Patch 2 adds a new compatible string for the new board. > > Patch 3 moves the ep-gpios property of the pcie controller from the > common nanopi4.dtsi file to the nanopc-t4.dts file. > > Patch 4 adds a new device tree file for the new board. It includes the > original device tree for the M4, and then lists the differences. > > Given that patch 3 would make PCIe unusable without patch 1, I suggest > merging patch 1 through the PCI tree as a fix for 5.10, and the rest > for 5.11 through the Rockchip tree. Gentle ping. I would really like to get the PCIe controller fix merged before -rc6 (cut-off for arm-soc -next) and be able to get the new board into 5.12. Or we could have all of them merged for 5.12, though depending on the order the PRs are sent and merged by Linus there would be a possible window where PCIe doesn't work for the Nanopi M4's. Thanks ChenYu > Please have a look. The changes are mostly trivial. > > > Regards > ChenYu > > Chen-Yu Tsai (4): > PCI: rockchip: Make 'ep-gpios' DT property optional > dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B > arm64: dts: rockchip: nanopi4: Move ep-gpios property to nanopc-t4 > arm64: dts: rockchip: rk3399: Add NanoPi M4B > > .../devicetree/bindings/arm/rockchip.yaml | 1 + > arch/arm64/boot/dts/rockchip/Makefile | 1 + > .../boot/dts/rockchip/rk3399-nanopc-t4.dts| 1 + > .../boot/dts/rockchip/rk3399-nanopi-m4b.dts | 52 +++ > .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - > drivers/pci/controller/pcie-rockchip.c| 5 +- > 6 files changed, 58 insertions(+), 3 deletions(-) > create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts > > -- > 2.29.2 >
Re: [linux-sunxi] Re: [PATCH v3 02/21] mmc: sunxi: add support for A100 mmc controller
On Mon, Jan 18, 2021 at 11:53 PM Andre Przywara wrote: > > On Mon, 18 Jan 2021 14:28:54 +0100 > Maxime Ripard wrote: > > Hi Maxime, > > > On Mon, Jan 18, 2021 at 02:08:29AM +, Andre Przywara wrote: > > > From: Yangtao Li > > > > > > This patch adds support for A100 MMC controller, which use word > > > address for internal dma. > > > > > > Signed-off-by: Yangtao Li > > > Signed-off-by: Andre Przywara > > > > We should also disable the timings setup in probe to derive them from > > the DT. This is causing issues on some SoCs already, so it would be > > best to not make the situation worse > > But only for those new SoCs, where we have the speed modes in the DT > in every case (so only new ones)? And this disabling would be > SoC/compatible string dependent? Happy to send a patch later if that is > what you were thinking about. > > Also I was wondering about the voltage dependent speed modes: At the > moment the driver declares both MMC_CAP_1_8V_DDR and MMC_CAP_3_3V_DDR, > so I mimic this in the .dtsi. However in the eventual DTB this looks > somewhat dodgy, since most boards only support one of those voltages. Do > we ignore this, and rely on the vqmmc-supply to limit this choice? IIRC the DDR flags for separate voltages was added after we (I) added MMC DDR support to our driver. And yes, the core also checks vqmmc-supply before actually selecting the mode. ChenYu > Cheers, > Andre > > Btw: This patch is already in Ulf's -next tree, I just included it here > for the sake of completeness. Is that a problem? I don't think it > affects the build, so we don't care too much? > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/linux-sunxi/20210118155228.3bd0e909%40slackpad.fritz.box.
Re: [linux-sunxi] Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection
On Wed, Jan 13, 2021 at 5:16 PM Chen-Yu Tsai wrote: > > On Thu, Jan 7, 2021 at 6:27 PM Samuel Holland wrote: > > > > On 1/6/21 5:38 AM, Chen-Yu Tsai wrote: > > > On Wed, Jan 6, 2021 at 7:06 PM Maxime Ripard wrote: > > >> > > >> On Mon, Jan 04, 2021 at 10:54:19AM +, André Przywara wrote: > > >>> On 03/01/2021 10:00, Samuel Holland wrote: > > >>>> On boards where the only peripheral connected to PL0/PL1 is an X-Powers > > >>>> PMIC, configure the connection to use the RSB bus rather than the I2C > > >>>> bus. Compared to the I2C controller that shares the pins, the RSB > > >>>> controller allows a higher bus frequency, and it is more CPU-efficient. > > >>> > > >>> But is it really necessary to change the DTs for those boards in this > > >>> way? It means those newer DTs now become incompatible with older > > >>> kernels, and I don't know if those reasons above really justify this. > > >>> > > >>> I understand that we officially don't care about "newer DTs on older > > >>> kernels", but do we really need to break this deliberately, for no > > >>> pressing reasons? > > >>> > > >>> P.S. I am fine with supporting RSB on H6, and even using it on new DTs, > > >>> just want to avoid breaking existing ones. > > >> > > >> Doing so would also introduce some inconsistencies, one more thing to > > >> consider during reviews, and would require more testing effort. > > >> > > >> I'm not sure that stretching our - already fairly sparse - resources > > >> thin would be very wise here, especially for something that we don't > > >> have to do and for a setup that isn't really used that much. > > > > > > As soon as some software component starts running RSB, (which I assume > > > is what Samuel is planning to do in Crust?), there's a chance that it > > > doesn't switch the chip back to I2C. And then Linux won't be able to > > > access it. > > > > Crust can handle either way via a config option, which currently > > defaults to I2C for H6. It must use the same selection as Linux, not > > only because of the PMIC mode, but also because of the pinctrl. > > Could Crust be made to also handle pinctrl? > > > TF-A is already converted to use RSB[1], and it does switch the PMIC > > back to I2C before handing off to U-Boot[2]. So new TF-A + old Linux is > > fine. However, Linux currently does not switch the PMIC back. So the > > most likely problem from this patch is that, with new Linux + old TF-A, > > TF-A will be unable to power down the board or access regulators after > > an SoC reset. > > > > I expect there will be a TF-A release between now and when 5.12 hits > > stable, but people tend not upgrade their U-Boot/TF-A very often. > > > > We could solve this by having the Linux RSB driver switch all child > > devices back to I2C in .shutdown, or by dropping this patch and only > > using RSB for new boards (which would also address Andre's concern). > > This will work for most cases, except in a kernel panic or IIRC direct > reboot using sysrq. So it's not robust as we'd like it to be. I also wonder what would happen when there are multiple RSB devices, and we switch them back to I2C one by one. It's not like there's an option to switch all of them back at the same time, unlike switching from I2C to RSB. The A80 and A83T are the platforms that would be affected. So I merged the previous patch, i.e. changes to the .dtsi, but I think we should delay this one by a release. That would give us more time to think about it, and let users upgrade U-Boot/TF-A. ChenYu > ChenYu > > > Cheers, > > Samuel > > > > [1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7576 > > [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7575 > > > > > So I'm for keeping things consistent and converting all users to RSB. > > > > > > > > > ChenYu > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "linux-sunxi" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to linux-sunxi+unsubscr...@googlegroups.com. > > To view this discussion on the web, visit > > https://groups.google.com/d/msgid/linux-sunxi/bc95a8d2-ebec-489c-10af-fd5a80ea1276%40sholland.org.
Re: [PATCH] ARM: dts: sun8i-v3s: Add CSI0 MCLK pin definition
On Wed, Dec 30, 2020 at 11:29 AM Chen-Yu Tsai wrote: > > On Tue, Dec 22, 2020 at 4:17 PM Jernej Škrabec > wrote: > > > > Hi! > > > > Dne petek, 18. december 2020 ob 20:50:33 CET je Paul Kocialkowski > > napisal(a): > > > This adds a device-tree definition for the CSI0 MCLK pin, > > > which can be used for feeding MIPI CSI-2 sensors. > > > > > > Signed-off-by: Paul Kocialkowski > > > > Is this used anywhere? Current policy is to add pin definitions only if any > > user exists. > > IIRC we sort of loosened that requirement with the use of /omit-if-no-ref/. > The A20 dtsi file has a whole bunch of pins defined that are not directly > used but are available for users to reference, especially in overlays. > The "-@" parameter for the device tree compiler, used to build overlay > compatible DTBs, makes the compiler ignore /omit-if-no-ref/ and include > all the nodes. I've queued up this patch for 5.12. ChenYu
[PATCH v2 2/3] dt-bindings: arm: rockchip: Add Radxa ROCK Pi E
From: Chen-Yu Tsai Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC. As the official wiki page puts it, "E for Ethernets". It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both directly served by Ethernet controllers in the SoC, a USB 3.0 host port, a power-only USB type-C port, a 3.5mm headphone jack for audio output, two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT and PoE header. The board comes in multiple configurations, differing in the amount of onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants can all share the same device tree. The USB 2.0 OTG controller is available on the 40-pin header. This is not enabled in the device tree, since it is possible to use it in a host-only configuration, or in OTG mode with an extra pin from the header as the ID pin. The device tree is based on the one of the Rock64, with various parts modified to match the ROCK Pi E, and some parts updated to newer styles, such as the gmac2io node's mdio sub-node. Add a compatible string for the new board. Acked-by: Rob Herring Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/arm/rockchip.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 773fd4c531ed..c3036f95c7bc 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -468,6 +468,11 @@ properties: - const: radxa,rockpi4 - const: rockchip,rk3399 + - description: Radxa ROCK Pi E +items: + - const: radxa,rockpi-e + - const: rockchip,rk3328 + - description: Radxa ROCK Pi N8 items: - const: radxa,rockpi-n8 -- 2.29.2
[PATCH v2 1/3] arm64: dts: rockchip: rk3328: Add clock_in_out property to gmac2phy node
From: Chen-Yu Tsai
The gmac2phy is integrated with the PHY within the SoC. Any properties
related to this integration can be included in the .dtsi file, instead
of having board dts files specify them separately.
Add the clock_in_out property to specify the direction of the PHY clock.
This is the minimum required to have gmac2phy working on Linux. Other
examples include assigned-clocks, assigned-clock-rates, and
assigned-clock-parents properties, but the hardware default plus the
implementation requesting the appropriate clock rate also works.
Fixes: 9c4cc910fe28 ("ARM64: dts: rockchip: Add gmac2phy node support for
rk3328")
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index db0d5c8e5f96..93c734d8a46c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -928,6 +928,7 @@ gmac2phy: ethernet@ff55 {
phy-mode = "rmii";
phy-handle = <>;
snps,txpbl = <0x4>;
+ clock_in_out = "output";
status = "disabled";
mdio {
--
2.29.2
[PATCH v2 0/3] arm64: rockchip: rk3328: Add Radxa ROCK Pi E
From: Chen-Yu Tsai Hi everyone, This is v2 of my ROCK Pi E support series. Changes since v1: - Picked up Rob's Ack for the binding - Dropped comment about LED color - Dropped max-frequency from emmc node - Changed pingroup name from "ethernet-phy" to "ephy" to avoid DT binding check failure - Dropped cap-mmc-highspeed from sdmmc node - Fixed regulator properties to have consistent ordering - Added adc-key for recovery button - Sorted header files This series adds support for the Radxa ROCK Pi E. This is a router oriented SBC based on Rockchip's RK3328 SoC. As the official wiki page puts it, "E for Ethernets". It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both directly served by Ethernet controllers in the SoC, a USB 3.0 host port, a power-only USB type-C port, a 3.5mm headphone jack for audio output, two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT and PoE header. The board comes in multiple configurations, differing in the amount of onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants can all share the same device tree. Currently, the 802.11ac chip lacks an in-kernel driver. The USB 2.0 OTG controller is available on the 40-pin header. This is not enabled in the device tree, since it is possible to use it in a host-only configuration, or in OTG mode with an extra pin from the header as the ID pin. The device tree is based on the one of the Rock64, with various parts modified to match the ROCK Pi E, and some parts updated to newer styles, such as the gmac2io node's mdio sub-node. Patch 1 adds the clock_in_out property to the gmac2phy node. This would always have the same setting for gmac2phy, which uses an integrated PHY in RMII mode. Having this set by default makes enabling gmac2phy at the board level simpler. Patch 2 adds a compatible string for this board to the list of Rockchip based devices. Patch 3 adds a device tree file for this board. This is based on the one for the Rock64, with many modifications to adapt it to the new board, as well as style updates. Please have a look. Regards ChenYu Chen-Yu Tsai (3): arm64: dts: rockchip: rk3328: Add clock_in_out property to gmac2phy node dt-bindings: arm: rockchip: Add Radxa ROCK Pi E arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E .../devicetree/bindings/arm/rockchip.yaml | 5 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3328-rock-pi-e.dts| 382 ++ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1 + 4 files changed, 389 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts -- 2.29.2
[PATCH v2 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
From: Chen-Yu Tsai
Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC.
As the official wiki page puts it, "E for Ethernets".
It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both
directly served by Ethernet controllers in the SoC, a USB 3.0 host port,
a power-only USB type-C port, a 3.5mm headphone jack for audio output,
two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT
and PoE header.
The board comes in multiple configurations, differing in the amount of
onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac
2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants
can all share the same device tree.
The USB 2.0 OTG controller is available on the 40-pin header. This is
not enabled in the device tree, since it is possible to use it in a
host-only configuration, or in OTG mode with an extra pin from the
header as the ID pin.
The device tree is based on the one of the Rock64, with various parts
modified to match the ROCK Pi E, and some parts updated to newer styles,
such as the gmac2io node's mdio sub-node.
Add a new device tree file for the new board.
The voltages for the adc-keys were selected to have some tolerances for
resistor variances and the ADC itself also causing voltage drops. Since
the recover button is the only button on the adc line, this should not
cause any issues.
Signed-off-by: Chen-Yu Tsai
---
Changes since v1:
- Dropped comment about LED color
- Dropped max-frequency from emmc node
- Changed pingroup name from "ethernet-phy" to "ephy"
to avoid DT binding check failure
- Dropped cap-mmc-highspeed from sdmmc node
- Fixed regulator properties to have consistent ordering
- Added adc-key for recovery button
- Sorted header files
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3328-rock-pi-e.dts| 382 ++
2 files changed, 383 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index 622d320ddd13..62d3abc17a24 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -11,6 +11,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-a1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
new file mode 100644
index ..2d71ca7e429c
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * (C) Copyright 2020 Chen-Yu Tsai
+ *
+ * Based on ./rk3328-rock64.dts, which is
+ *
+ * Copyright (c) 2017 PINE64
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include
+
+#include "rk3328.dtsi"
+
+/ {
+ model = "Radxa ROCK Pi E";
+ compatible = "radxa,rockpi-e", "rockchip,rk3328";
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <175>;
+
+ /* This button is unpopulated out of the factory. */
+ button-recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <1>;
+ };
+ };
+
+ gmac_clkin: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "gmac_clkin";
+ #clock-cells = <0>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <_pin>;
+ pinctrl-names = "default";
+
+ led-0 {
+ color = ;
+ gpios = < RK_PA5 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ vcc_sd: sdmmc-regulator {
+ compatible = "regulator-fixed";
+ gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pin>;
+ regulator-name = "vcc_sd";
+ regulator-boot-on;
+ vin-supply
Re: [PATCH] ARM: dts: sun8i: h2-plus: bananapi-m2-zero: Increase BT UART speed
On Sat, Jan 16, 2021 at 6:37 PM Jernej Skrabec wrote: > > Bluetooth module on BananaPi M2 Zero can also be used for streaming > audio. However, for that case higher UART speed is required. > > Add a max-speed property. > > Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai
Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: bananapi-m2-plus: Increase BT UART speed
On Sat, Jan 16, 2021 at 6:52 PM Jernej Skrabec wrote: > > Bluetooth module on BananaPi M2 Plus can also be used for streaming > audio. However, for that case higher UART speed is required. > > Add a max-speed property. > > Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai
Re: [linux-sunxi] Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection
On Thu, Jan 7, 2021 at 6:27 PM Samuel Holland wrote: > > On 1/6/21 5:38 AM, Chen-Yu Tsai wrote: > > On Wed, Jan 6, 2021 at 7:06 PM Maxime Ripard wrote: > >> > >> On Mon, Jan 04, 2021 at 10:54:19AM +, André Przywara wrote: > >>> On 03/01/2021 10:00, Samuel Holland wrote: > >>>> On boards where the only peripheral connected to PL0/PL1 is an X-Powers > >>>> PMIC, configure the connection to use the RSB bus rather than the I2C > >>>> bus. Compared to the I2C controller that shares the pins, the RSB > >>>> controller allows a higher bus frequency, and it is more CPU-efficient. > >>> > >>> But is it really necessary to change the DTs for those boards in this > >>> way? It means those newer DTs now become incompatible with older > >>> kernels, and I don't know if those reasons above really justify this. > >>> > >>> I understand that we officially don't care about "newer DTs on older > >>> kernels", but do we really need to break this deliberately, for no > >>> pressing reasons? > >>> > >>> P.S. I am fine with supporting RSB on H6, and even using it on new DTs, > >>> just want to avoid breaking existing ones. > >> > >> Doing so would also introduce some inconsistencies, one more thing to > >> consider during reviews, and would require more testing effort. > >> > >> I'm not sure that stretching our - already fairly sparse - resources > >> thin would be very wise here, especially for something that we don't > >> have to do and for a setup that isn't really used that much. > > > > As soon as some software component starts running RSB, (which I assume > > is what Samuel is planning to do in Crust?), there's a chance that it > > doesn't switch the chip back to I2C. And then Linux won't be able to > > access it. > > Crust can handle either way via a config option, which currently > defaults to I2C for H6. It must use the same selection as Linux, not > only because of the PMIC mode, but also because of the pinctrl. Could Crust be made to also handle pinctrl? > TF-A is already converted to use RSB[1], and it does switch the PMIC > back to I2C before handing off to U-Boot[2]. So new TF-A + old Linux is > fine. However, Linux currently does not switch the PMIC back. So the > most likely problem from this patch is that, with new Linux + old TF-A, > TF-A will be unable to power down the board or access regulators after > an SoC reset. > > I expect there will be a TF-A release between now and when 5.12 hits > stable, but people tend not upgrade their U-Boot/TF-A very often. > > We could solve this by having the Linux RSB driver switch all child > devices back to I2C in .shutdown, or by dropping this patch and only > using RSB for new boards (which would also address Andre's concern). This will work for most cases, except in a kernel panic or IIRC direct reboot using sysrq. So it's not robust as we'd like it to be. ChenYu > Cheers, > Samuel > > [1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7576 > [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7575 > > > So I'm for keeping things consistent and converting all users to RSB. > > > > > > ChenYu > > > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/linux-sunxi/bc95a8d2-ebec-489c-10af-fd5a80ea1276%40sholland.org.
Re: [linux-sunxi] [PATCH] arm64: dts: allwinner: h6: PineH64 model B: Add bluetooth
On Mon, Jan 11, 2021 at 5:16 AM Jernej Skrabec wrote: > > PineH64 model B has wifi+bt combo module. Wifi is already supported, so > lets add also bluetooth node. > > Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Looks good to me, though I couldn't find anything on the polarity of the interrupt lines. ChenYu
Re: [PATCH v3 2/4] dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B
On Wed, Jan 6, 2021 at 9:46 PM Chen-Yu Tsai wrote: > > From: Chen-Yu Tsai > > The NanoPi M4B is a minor revision of the original M4. > > The differences against the original Nanopi M4 that are common with the > other M4V2 revision include: > > - microphone header removed > - power button added > - recovery button added > > Additional changes specific to the M4B: > > - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x > USB 2.0 ports > - ADB toggle switch added; this changes the top USB 3.0 host port to > a peripheral port > - Type-C port no longer supports data or PD > - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 > but only 1T1R (down from 2T2R) for WiFi > > Add a compatible string for the new board revision. > > Signed-off-by: Chen-Yu Tsai This was Acked-by: Rob Herring back in v2.
Re: [PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
On Mon, Jan 11, 2021 at 3:50 PM Heiko Stübner wrote:
>
> Am Montag, 11. Januar 2021, 04:27:47 CET schrieb Chen-Yu Tsai:
> > On Mon, Jan 11, 2021 at 4:06 AM Heiko Stübner wrote:
> > >
> > > Hi,
> > >
> > > Am Sonntag, 10. Januar 2021, 16:37:15 CET schrieb Chen-Yu Tsai:
> > > > > > + vcc_sd: sdmmc-regulator {
> > > > > > + compatible = "regulator-fixed";
> > > > > > + gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
> > > > > > + pinctrl-names = "default";
> > > > > > + pinctrl-0 = <_pin>;
> > > > >
> > > > > > + regulator-boot-on;
> > > > > > + regulator-name = "vcc_sd";
> > > > >
> > > > > regulator-name above other regulator properties
> > > >
> > > > That is actually what I was used to, but some other rockchip dts files
> > > > have all the properties sorted alphabetically. So I stuck with what I
> > > > saw.
> > >
> > > I try to keep it alphabetical except for the exceptions :-D .
> > >
> > > regulator-name is such an exception. Similar to compatibles, the
> > > regulator-name is an entry needed to see if you're at the right node,
> > > so I really like it being the topmost regulator-foo property - just makes
> > > reading easier.
> > >
> > > (same for the compatible first, then regs, interrupts parts, as well
> > > as "status-last")
> > >
> > > But oftentimes, I just fix the ordering when applying - but seem to have
> > > missed this somewhere in those "other Rockchip dts files" ;-) .
> >
> > I was slightly confused. I looked again and yes regulator-name is always the
> > first regulator related property. What's off is that in some cases min/max
> > voltage comes before always-on/boot-on, and in others vice versa.
> >
> > For example in the Rock64 and ROC-RK3328-CC device trees, in the fixed
> > regulators, always-on/boot-on come before min/max voltage, while in the
> > PMIC the other order is used.
>
> That's likely undecidednes on my part ;-)
>
> There could be an argument for a "name, voltages, flags" sorting, but on
> the other hand just keeping it alphabetical with the naming on top
> creates less special cases.
And min before max? :D
Re: [PATCH] arm64: dts: rockchip: rename pinctrl nodename to gmac2io for nanopi-r2s board
Hi Rob,
On Mon, Jan 11, 2021 at 3:50 AM Johan Jonker wrote:
>
> A test with the command below gives this error:
> /arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dt.yaml:
> ethernet-phy: 'reg' is a required property
>
> The pinctrl nodename "ethernet-phy" conflicts with the rules
> in the "ethernet-phy.yaml" document, so rename it to "gmac2io".
This seems more like an unintended side effect of the ethernet-phy binding.
Is there a way to limit the matching of the binding only if the parent is an
"mdio" or "ethernet" node? Would that make more sense?
Regards
ChenYu
> make ARCH=arm64 dtbs_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/ethernet-phy.yaml
>
> Signed-off-by: Johan Jonker
> ---
> arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> index 2ee07d15a..86732b45d 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> @@ -280,7 +280,7 @@
> };
> };
>
> - ethernet-phy {
> + gmac2io {
> eth_phy_reset_pin: eth-phy-reset-pin {
> rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO
> _pull_down>;
> };
> --
> 2.11.0
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
On Mon, Jan 11, 2021 at 4:17 AM Johan Jonker wrote:
>
> Hi Chen-Yu,
>
> Most is already answered by Heiko.
>
> On 1/10/21 4:37 PM, Chen-Yu Tsai wrote:
> > Hi,
> >
> > On Sun, Jan 10, 2021 at 10:45 PM Johan Jonker wrote:
> >>
> >> Hi Chen-Yu,
> >>
> >> Some comments, have a look if it is useful...
> >>
> >> On 1/10/21 4:58 AM, Chen-Yu Tsai wrote:
> >>> From: Chen-Yu Tsai
> >>>
> >>> Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC.
> >>> As the official wiki page puts it, "E for Ethernets".
> >>>
> >>> It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both
> >>> directly served by Ethernet controllers in the SoC, a USB 3.0 host port,
> >>> a power-only USB type-C port, a 3.5mm headphone jack for audio output,
> >>
> >>> two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT
> >>> and PoE header.
> >>>
> >>> The board comes in multiple configurations, differing in the amount of
> >>> onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac
> >>> 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants
> >>> can all share the same device tree.
> >>>
> >>> The USB 2.0 OTG controller is available on the 40-pin header. This is
> >>> not enabled in the device tree, since it is possible to use it in a
> >>> host-only configuration, or in OTG mode with an extra pin from the
> >>> header as the ID pin.
> >>>
> >>> The device tree is based on the one of the Rock64, with various parts
> >>> modified to match the ROCK Pi E, and some parts updated to newer styles,
> >>> such as the gmac2io node's mdio sub-node.
> >>>
> >>> Add a new device tree file for the new board.
> >>>
> >>> Signed-off-by: Chen-Yu Tsai
> >>> ---
> >>> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> >>> .../boot/dts/rockchip/rk3328-rock-pi-e.dts| 369 ++
> >>> 2 files changed, 370 insertions(+)
> >>> create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> >>>
> >>> diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> >>> b/arch/arm64/boot/dts/rockchip/Makefile
> >>> index 622d320ddd13..62d3abc17a24 100644
> >>> --- a/arch/arm64/boot/dts/rockchip/Makefile
> >>> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> >>> @@ -11,6 +11,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-a1.dtb
> >>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
> >>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s.dtb
> >>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
> >>> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb
> >>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
> >>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
> >>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
> >>> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> >>> b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> >>> new file mode 100644
> >>> index ..7818d2e8180c
> >>> --- /dev/null
> >>> +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> >>> @@ -0,0 +1,369 @@
> >>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >>> +/*
> >>> + * (C) Copyright 2020 Chen-Yu Tsai
> >>> + *
> >>> + * Based on ./rk3328-rock64.dts, which is
> >>> + *
> >>> + * Copyright (c) 2017 PINE64
> >>> + */
> >>> +
> >>> +/dts-v1/;
> >>> +
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include "rk3328.dtsi"
> >>> +
> >>> +/ {
> >>> + model = "Radxa ROCK Pi E";
> >>> + compatible = "radxa,rockpi-e", "rockchip,rk3328";
> >>> +
> >>> + chosen {
> >>> + stdout-path = "serial2:150n8";
> >>> + };
> >>> +
> >>> + gmac_clkin: external-gmac-clock {
> >>> + compatible = "fixed-clock";
> >>> + clock-frequency = <12500>;
> >>> + clock-output-names = "gmac_clkin";
> >>> + #clock-cells = <0>
Re: [PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
On Mon, Jan 11, 2021 at 4:06 AM Heiko Stübner wrote:
>
> Hi,
>
> Am Sonntag, 10. Januar 2021, 16:37:15 CET schrieb Chen-Yu Tsai:
> > > > + vcc_sd: sdmmc-regulator {
> > > > + compatible = "regulator-fixed";
> > > > + gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
> > > > + pinctrl-names = "default";
> > > > + pinctrl-0 = <_pin>;
> > >
> > > > + regulator-boot-on;
> > > > + regulator-name = "vcc_sd";
> > >
> > > regulator-name above other regulator properties
> >
> > That is actually what I was used to, but some other rockchip dts files
> > have all the properties sorted alphabetically. So I stuck with what I
> > saw.
>
> I try to keep it alphabetical except for the exceptions :-D .
>
> regulator-name is such an exception. Similar to compatibles, the
> regulator-name is an entry needed to see if you're at the right node,
> so I really like it being the topmost regulator-foo property - just makes
> reading easier.
>
> (same for the compatible first, then regs, interrupts parts, as well
> as "status-last")
>
> But oftentimes, I just fix the ordering when applying - but seem to have
> missed this somewhere in those "other Rockchip dts files" ;-) .
I was slightly confused. I looked again and yes regulator-name is always the
first regulator related property. What's off is that in some cases min/max
voltage comes before always-on/boot-on, and in others vice versa.
For example in the Rock64 and ROC-RK3328-CC device trees, in the fixed
regulators, always-on/boot-on come before min/max voltage, while in the
PMIC the other order is used.
ChenYu
Re: [PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
Hi,
On Sun, Jan 10, 2021 at 10:45 PM Johan Jonker wrote:
>
> Hi Chen-Yu,
>
> Some comments, have a look if it is useful...
>
> On 1/10/21 4:58 AM, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai
> >
> > Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC.
> > As the official wiki page puts it, "E for Ethernets".
> >
> > It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both
> > directly served by Ethernet controllers in the SoC, a USB 3.0 host port,
> > a power-only USB type-C port, a 3.5mm headphone jack for audio output,
>
> > two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT
> > and PoE header.
> >
> > The board comes in multiple configurations, differing in the amount of
> > onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac
> > 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants
> > can all share the same device tree.
> >
> > The USB 2.0 OTG controller is available on the 40-pin header. This is
> > not enabled in the device tree, since it is possible to use it in a
> > host-only configuration, or in OTG mode with an extra pin from the
> > header as the ID pin.
> >
> > The device tree is based on the one of the Rock64, with various parts
> > modified to match the ROCK Pi E, and some parts updated to newer styles,
> > such as the gmac2io node's mdio sub-node.
> >
> > Add a new device tree file for the new board.
> >
> > Signed-off-by: Chen-Yu Tsai
> > ---
> > arch/arm64/boot/dts/rockchip/Makefile | 1 +
> > .../boot/dts/rockchip/rk3328-rock-pi-e.dts| 369 ++
> > 2 files changed, 370 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> > b/arch/arm64/boot/dts/rockchip/Makefile
> > index 622d320ddd13..62d3abc17a24 100644
> > --- a/arch/arm64/boot/dts/rockchip/Makefile
> > +++ b/arch/arm64/boot/dts/rockchip/Makefile
> > @@ -11,6 +11,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-a1.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
> > +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> > b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> > new file mode 100644
> > index ..7818d2e8180c
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> > @@ -0,0 +1,369 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * (C) Copyright 2020 Chen-Yu Tsai
> > + *
> > + * Based on ./rk3328-rock64.dts, which is
> > + *
> > + * Copyright (c) 2017 PINE64
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include
> > +#include
> > +#include
> > +#include "rk3328.dtsi"
> > +
> > +/ {
> > + model = "Radxa ROCK Pi E";
> > + compatible = "radxa,rockpi-e", "rockchip,rk3328";
> > +
> > + chosen {
> > + stdout-path = "serial2:150n8";
> > + };
> > +
> > + gmac_clkin: external-gmac-clock {
> > + compatible = "fixed-clock";
> > + clock-frequency = <12500>;
> > + clock-output-names = "gmac_clkin";
> > + #clock-cells = <0>;
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > + pinctrl-0 = <_pin>;
> > + pinctrl-names = "default";
> > +
> > + led-0 {
>
> > + /* schematic say green but the actual thing is blue */
>
> In rockpie-v1.2-20200427-sch.pdf this led is already called "LED_BLUE",
> so comment maybe not needed anymore?
Thanks. Did not notice there was a new revision.
> > + color = ;
> > + gpios = < RK_PA5 GPIO_ACTIVE_LOW>;
> > + linux,default-trigger = "heartbeat";
> > + };> + };
> > +
> > + vcc_sd: sdmmc-regulator {
> > + compatible = "regulator-fixed";
> > + gpio
[PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
From: Chen-Yu Tsai
Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC.
As the official wiki page puts it, "E for Ethernets".
It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both
directly served by Ethernet controllers in the SoC, a USB 3.0 host port,
a power-only USB type-C port, a 3.5mm headphone jack for audio output,
two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT
and PoE header.
The board comes in multiple configurations, differing in the amount of
onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac
2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants
can all share the same device tree.
The USB 2.0 OTG controller is available on the 40-pin header. This is
not enabled in the device tree, since it is possible to use it in a
host-only configuration, or in OTG mode with an extra pin from the
header as the ID pin.
The device tree is based on the one of the Rock64, with various parts
modified to match the ROCK Pi E, and some parts updated to newer styles,
such as the gmac2io node's mdio sub-node.
Add a new device tree file for the new board.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3328-rock-pi-e.dts| 369 ++
2 files changed, 370 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index 622d320ddd13..62d3abc17a24 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -11,6 +11,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-a1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
new file mode 100644
index ..7818d2e8180c
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
@@ -0,0 +1,369 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * (C) Copyright 2020 Chen-Yu Tsai
+ *
+ * Based on ./rk3328-rock64.dts, which is
+ *
+ * Copyright (c) 2017 PINE64
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "rk3328.dtsi"
+
+/ {
+ model = "Radxa ROCK Pi E";
+ compatible = "radxa,rockpi-e", "rockchip,rk3328";
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ gmac_clkin: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "gmac_clkin";
+ #clock-cells = <0>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <_pin>;
+ pinctrl-names = "default";
+
+ led-0 {
+ /* schematic say green but the actual thing is blue */
+ color = ;
+ gpios = < RK_PA5 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ vcc_sd: sdmmc-regulator {
+ compatible = "regulator-fixed";
+ gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pin>;
+ regulator-boot-on;
+ regulator-name = "vcc_sd";
+ vin-supply = <_io>;
+ };
+
+ vcc_host_5v: vcc-host-5v-regulator {
+ compatible = "regulator-fixed";
+ gpio = < RK_PA7 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_host_drv>;
+ enable-active-high;
+ regulator-name = "vcc_host_5v";
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <_sys>;
+ };
+
+ vcc_sys: vcc-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ vcc_wifi: vcc-wifi-regulator {
+ compatible = "regulator-fixed";
+ gpio = < RK_PA0 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pin
[PATCH 1/3] arm64: dts: rockchip: rk3328: Add clock_in_out property to gmac2phy node
From: Chen-Yu Tsai
The gmac2phy is integrated with the PHY within the SoC. Any properties
related to this integration can be included in the .dtsi file, instead
of having board dts files specify them separately.
Add the clock_in_out property to specify the direction of the PHY clock.
This is the minimum required to have gmac2phy working on Linux. Other
examples include assigned-clocks, assigned-clock-rates, and
assigned-clock-parents properties, but the hardware default plus the
implementation requesting the appropriate clock rate also works.
Fixes: 9c4cc910fe28 ("ARM64: dts: rockchip: Add gmac2phy node support for
rk3328")
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index db0d5c8e5f96..93c734d8a46c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -928,6 +928,7 @@ gmac2phy: ethernet@ff55 {
phy-mode = "rmii";
phy-handle = <>;
snps,txpbl = <0x4>;
+ clock_in_out = "output";
status = "disabled";
mdio {
--
2.29.2
[PATCH 0/3] arm64: rockchip: rk3328: Add Radxa ROCK Pi E
From: Chen-Yu Tsai Hi everyone, This series adds support for the Radxa ROCK Pi E. This is a router oriented SBC based on Rockchip's RK3328 SoC. As the official wiki page puts it, "E for Ethernets". It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both directly served by Ethernet controllers in the SoC, a USB 3.0 host port, a power-only USB type-C port, a 3.5mm headphone jack for audio output, two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT and PoE header. The board comes in multiple configurations, differing in the amount of onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants can all share the same device tree. Currently, the 802.11ac chip lacks an in-kernel driver. The USB 2.0 OTG controller is available on the 40-pin header. This is not enabled in the device tree, since it is possible to use it in a host-only configuration, or in OTG mode with an extra pin from the header as the ID pin. The device tree is based on the one of the Rock64, with various parts modified to match the ROCK Pi E, and some parts updated to newer styles, such as the gmac2io node's mdio sub-node. Patch 1 adds the clock_in_out property to the gmac2phy node. This would always have the same setting for gmac2phy, which uses an integrated PHY in RMII mode. Having this set by default makes enabling gmac2phy at the board level simpler. Patch 2 adds a compatible string for this board to the list of Rockchip based devices. Patch 3 adds a device tree file for this board. This is based on the one for the Rock64, with many modifications to adapt it to the new board, as well as style updates. Please have a look. Regards ChenYu Chen-Yu Tsai (3): arm64: dts: rockchip: rk3328: Add clock_in_out property to gmac2phy node dt-bindings: arm: rockchip: Add Radxa ROCK Pi E arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E .../devicetree/bindings/arm/rockchip.yaml | 5 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3328-rock-pi-e.dts| 369 ++ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1 + 4 files changed, 376 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts -- 2.29.2
[PATCH 2/3] dt-bindings: arm: rockchip: Add Radxa ROCK Pi E
From: Chen-Yu Tsai Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC. As the official wiki page puts it, "E for Ethernets". It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both directly served by Ethernet controllers in the SoC, a USB 3.0 host port, a power-only USB type-C port, a 3.5mm headphone jack for audio output, two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT and PoE header. The board comes in multiple configurations, differing in the amount of onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants can all share the same device tree. The USB 2.0 OTG controller is available on the 40-pin header. This is not enabled in the device tree, since it is possible to use it in a host-only configuration, or in OTG mode with an extra pin from the header as the ID pin. The device tree is based on the one of the Rock64, with various parts modified to match the ROCK Pi E, and some parts updated to newer styles, such as the gmac2io node's mdio sub-node. Add a compatible string for the new board. Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/arm/rockchip.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 773fd4c531ed..c3036f95c7bc 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -468,6 +468,11 @@ properties: - const: radxa,rockpi4 - const: rockchip,rk3399 + - description: Radxa ROCK Pi E +items: + - const: radxa,rockpi-e + - const: rockchip,rk3328 + - description: Radxa ROCK Pi N8 items: - const: radxa,rockpi-n8 -- 2.29.2
[PATCH] staging: rtl8723bs: wifi_regd.c: Fix incorrect number of regulatory rules
From: Chen-Yu Tsai
The custom regulatory ruleset in the rtl8723bs driver lists an incorrect
number of rules: one too many. This results in an out-of-bounds access,
as detected by KASAN. This was possible thanks to the newly added support
for KASAN on ARMv7.
Fix this by filling in the correct number of rules given.
KASAN report:
==
BUG: KASAN: global-out-of-bounds in cfg80211_does_bw_fit_range+0x14/0x4c
[cfg80211]
Read of size 4 at addr bf20c254 by task ip/971
CPU: 2 PID: 971 Comm: ip Tainted: G C
5.11.0-rc2-00020-gf7fe528a7ebe #1
Hardware name: Allwinner sun8i Family
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x9c/0xb4)
[] (dump_stack) from []
(print_address_description.constprop.2+0x1dc/0x2dc)
[] (print_address_description.constprop.2) from []
(kasan_report+0x1a8/0x1c4)
[] (kasan_report) from []
(cfg80211_does_bw_fit_range+0x14/0x4c [cfg80211])
[] (cfg80211_does_bw_fit_range [cfg80211]) from []
(freq_reg_info_regd.part.6+0x108/0x124 [>
[] (freq_reg_info_regd.part.6 [cfg80211]) from []
(handle_channel_custom.constprop.12+0x48/>
[] (handle_channel_custom.constprop.12 [cfg80211]) from []
(wiphy_apply_custom_regulatory+0>
[] (wiphy_apply_custom_regulatory [cfg80211]) from []
(rtw_regd_init+0x60/0x70 [r8723bs])
[] (rtw_regd_init [r8723bs]) from []
(rtw_cfg80211_init_wiphy+0x164/0x1e8 [r8723bs])
[] (rtw_cfg80211_init_wiphy [r8723bs]) from []
(_netdev_open+0xe4/0x28c [r8723bs])
[] (_netdev_open [r8723bs]) from [] (netdev_open+0x60/0x88
[r8723bs])
[] (netdev_open [r8723bs]) from [] (__dev_open+0x178/0x220)
[] (__dev_open) from [] (__dev_change_flags+0x258/0x2c4)
[] (__dev_change_flags) from [] (dev_change_flags+0x40/0x80)
[] (dev_change_flags) from [] (do_setlink+0x538/0x1160)
[] (do_setlink) from [] (__rtnl_newlink+0x65c/0xad8)
[] (__rtnl_newlink) from [] (rtnl_newlink+0x4c/0x6c)
[] (rtnl_newlink) from [] (rtnetlink_rcv_msg+0x1f8/0x454)
[] (rtnetlink_rcv_msg) from [] (netlink_rcv_skb+0xc4/0x1e0)
[] (netlink_rcv_skb) from [] (netlink_unicast+0x2c8/0x3c4)
[] (netlink_unicast) from [] (netlink_sendmsg+0x320/0x5f0)
[] (netlink_sendmsg) from [] (sys_sendmsg+0x320/0x3e0)
[] (sys_sendmsg) from [] (___sys_sendmsg+0xe8/0x12c)
[] (___sys_sendmsg) from [] (__sys_sendmsg+0xc0/0x120)
[] (__sys_sendmsg) from [] (ret_fast_syscall+0x0/0x58)
Exception stack(0xc5693fa8 to 0xc5693ff0)
3fa0: 0074 c7a39800 0003 b6cee648
3fc0: 0074 c7a39800 0001 0128 78d18349 b6ceeda0 004f7cb0
3fe0: 0128 b6cee5e8 aeca151f aec1d746
The buggy address belongs to the variable:
rtw_drv_halt+0xf908/0x6b4 [r8723bs]
Memory state around the buggy address:
bf20c100: 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9
bf20c180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>bf20c200: 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9
^
bf20c280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
bf20c300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==
Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
Signed-off-by: Chen-Yu Tsai
---
drivers/staging/rtl8723bs/os_dep/wifi_regd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/wifi_regd.c
b/drivers/staging/rtl8723bs/os_dep/wifi_regd.c
index 578b9f734231..65592bf84f38 100644
--- a/drivers/staging/rtl8723bs/os_dep/wifi_regd.c
+++ b/drivers/staging/rtl8723bs/os_dep/wifi_regd.c
@@ -34,7 +34,7 @@
NL80211_RRF_PASSIVE_SCAN)
static const struct ieee80211_regdomain rtw_regdom_rd = {
- .n_reg_rules = 3,
+ .n_reg_rules = 2,
.alpha2 = "99",
.reg_rules = {
RTW_2GHZ_CH01_11,
--
2.29.2
[PATCH v3 0/4] arm64: rockchip: Fix PCIe ep-gpios requirement and Add Nanopi M4B
From: Chen-Yu Tsai Hi everyone, This is v3 of my Nanopi M4B series. Changes since v2 include: - Replaced dev_err() with dev_err_probe() for gpiod_get_optional() error - Added Reviewed-by tag from Robin Murphy for patch 3 Changes since v1 include: - Rewrite subject of patch 1 to match existing convention and reference 'ep-gpios' DT property instead of the 'ep_gpio' field This series mainly adds support for the new Nanopi M4B, which is a newer variant of the Nanopi M4. The differences against the original Nanopi M4 that are common with the other M4V2 revision include: - microphone header removed - power button added - recovery button added Additional changes specific to the M4B: - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x USB 2.0 ports - ADB toggle switch added; this changes the top USB 3.0 host port to a peripheral port - Type-C port no longer supports data or PD - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 but only 1T1R (down from 2T2R) for WiFi While working on this, I found that for the M4 family, the PCIe reset pin (from the M.2 expansion board) was not wired to the SoC. Only the NanoPC T4 has this wired. This ended up in patches 1 and 3. Patch 1 makes ep_gpio in the Rockchip PCIe driver optional. This property is optional in the DT binding, so this just makes the driver adhere to the binding. Patch 2 adds a new compatible string for the new board. Patch 3 moves the ep-gpios property of the pcie controller from the common nanopi4.dtsi file to the nanopc-t4.dts file. Patch 4 adds a new device tree file for the new board. It includes the original device tree for the M4, and then lists the differences. Given that patch 3 would make PCIe unusable without patch 1, I suggest merging patch 1 through the PCI tree as a fix for 5.10, and the rest for 5.11 through the Rockchip tree. Please have a look. The changes are mostly trivial. Regards ChenYu Chen-Yu Tsai (4): PCI: rockchip: Make 'ep-gpios' DT property optional dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B arm64: dts: rockchip: nanopi4: Move ep-gpios property to nanopc-t4 arm64: dts: rockchip: rk3399: Add NanoPi M4B .../devicetree/bindings/arm/rockchip.yaml | 1 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3399-nanopc-t4.dts| 1 + .../boot/dts/rockchip/rk3399-nanopi-m4b.dts | 52 +++ .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - drivers/pci/controller/pcie-rockchip.c| 5 +- 6 files changed, 58 insertions(+), 3 deletions(-) create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts -- 2.29.2
[PATCH v3 1/4] PCI: rockchip: Make 'ep-gpios' DT property optional
From: Chen-Yu Tsai
The Rockchip PCIe controller DT binding clearly states that 'ep-gpios' is
an optional property. And indeed there are boards that don't require it.
Make the driver follow the binding by using devm_gpiod_get_optional()
instead of devm_gpiod_get().
Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
Fixes: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver")
Fixes: 964bac9455be ("PCI: rockchip: Split out rockchip_pcie_parse_dt() to
parse DT")
Signed-off-by: Chen-Yu Tsai
---
Heiko, I dropped you reviewed-by due to the error message change
Changes since v2:
- Fix error message for failed GPIO
Changes since v1:
- Rewrite subject to match existing convention and reference
'ep-gpios' DT property instead of the 'ep_gpio' field
---
drivers/pci/controller/pcie-rockchip.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-rockchip.c
b/drivers/pci/controller/pcie-rockchip.c
index 904dec0d3a88..90c957e3bc73 100644
--- a/drivers/pci/controller/pcie-rockchip.c
+++ b/drivers/pci/controller/pcie-rockchip.c
@@ -118,9 +118,10 @@ int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
}
if (rockchip->is_rc) {
- rockchip->ep_gpio = devm_gpiod_get(dev, "ep", GPIOD_OUT_HIGH);
+ rockchip->ep_gpio = devm_gpiod_get_optional(dev, "ep",
GPIOD_OUT_HIGH);
if (IS_ERR(rockchip->ep_gpio)) {
- dev_err(dev, "missing ep-gpios property in node\n");
+ dev_err_probe(dev, PTR_ERR(rockchip->ep_gpio),
+ "failed to get ep GPIO\n");
return PTR_ERR(rockchip->ep_gpio);
}
}
--
2.29.2
[PATCH v3 2/4] dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B
From: Chen-Yu Tsai The NanoPi M4B is a minor revision of the original M4. The differences against the original Nanopi M4 that are common with the other M4V2 revision include: - microphone header removed - power button added - recovery button added Additional changes specific to the M4B: - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x USB 2.0 ports - ADB toggle switch added; this changes the top USB 3.0 host port to a peripheral port - Type-C port no longer supports data or PD - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 but only 1T1R (down from 2T2R) for WiFi Add a compatible string for the new board revision. Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/arm/rockchip.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index ef4544ad6f82..773fd4c531ed 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -132,6 +132,7 @@ properties: - enum: - friendlyarm,nanopc-t4 - friendlyarm,nanopi-m4 + - friendlyarm,nanopi-m4b - friendlyarm,nanopi-neo4 - const: rockchip,rk3399 -- 2.29.2
[PATCH v3 4/4] arm64: dts: rockchip: rk3399: Add NanoPi M4B
From: Chen-Yu Tsai
The NanoPi M4B is a minor revision of the original M4.
The differences against the original Nanopi M4 that are common with the
other M4V2 revision include:
- microphone header removed
- power button added
- recovery button added
Additional changes specific to the M4B:
- USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x
USB 2.0 ports
- ADB toggle switch added; this changes the top USB 3.0 host port to
a peripheral port
- Type-C port no longer supports data or PD
- WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0
but only 1T1R (down from 2T2R) for WiFi
Add a new dts file for the new board revision that shows the difference
against the original.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-nanopi-m4b.dts | 52 +++
2 files changed, 53 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index 1ab55a124a87..622d320ddd13 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -33,6 +33,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-kobol-helios64.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4b.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-pinebook-pro.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
new file mode 100644
index ..72182c58cc46
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * FriendlyElec NanoPi M4B board device tree source
+ *
+ * Copyright (c) 2020 Chen-Yu Tsai
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi-m4.dts"
+
+/ {
+ model = "FriendlyElec NanoPi M4B";
+ compatible = "friendlyarm,nanopi-m4b", "rockchip,rk3399";
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <150>;
+ poll-interval = <100>;
+
+ recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <18000>;
+ };
+ };
+};
+
+/* No USB type-C PD power manager */
+/delete-node/
+
+ {
+ status = "disabled";
+};
+
+_host {
+ phy-supply = <_usb2>;
+};
+
+_otg {
+ phy-supply = <_typec>;
+};
+
+_otg {
+ phy-supply = <_usb1>;
+};
+
+_typec {
+ enable-active-high;
+ gpios = < RK_PD2 GPIO_ACTIVE_HIGH>;
+};
--
2.29.2
[PATCH v3 3/4] arm64: dts: rockchip: nanopi4: Move ep-gpios property to nanopc-t4
From: Chen-Yu Tsai
Only the NanoPC T4 hs the PCIe reset pin routed to the SoC. For the
NanoPi M4 family, no such signal is routed to the expansion header on
the base board.
As the schematics for the expansion board were not released, it is
unclear how this is handled, but the likely answer is that the signal
is always pulled high.
Move the ep-gpios property from the common nanopi4.dtsi file to the
board level nanopc-t4.dts file. This makes the nanopi-m4 lack ep-gpios,
matching the board design.
A companion patch "PCI: rockchip: make ep_gpio optional" for the Linux
driver is required, as the driver currently requires the property to be
present.
Fixes: e7a095908227 ("arm64: dts: rockchip: Add devicetree for NanoPC-T4")
Reviewed-by: Robin Murphy
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts | 1 +
arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
index e0d75617bb7e..452728b82e42 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
@@ -95,6 +95,7 @@ map3 {
};
{
+ ep-gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
num-lanes = <4>;
vpcie3v3-supply = <_sys>;
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
index 76a8b40a93c6..48ed4aaa37f3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
@@ -504,7 +504,6 @@ _phy {
};
{
- ep-gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
max-link-speed = <2>;
num-lanes = <2>;
vpcie0v9-supply = <_s3>;
--
2.29.2
Re: [PATCH 0/4] bus: sunxi-rsb: Implement power managment
On Wed, Jan 6, 2021 at 6:50 PM Maxime Ripard wrote: > > Hi! > > On Sun, Jan 03, 2021 at 05:06:31AM -0600, Samuel Holland wrote: > > This series adds system (complete power down) and runtime (clock gate) > > PM hooks to the RSB controller driver. Tested on A64 and H6. > > > > Samuel Holland (4): > > bus: sunxi-rsb: Move OF match table > > bus: sunxi-rsb: Split out controller init/exit functions > > bus: sunxi-rsb: Implement suspend/resume/shutdown callbacks > > bus: sunxi-rsb: Implement runtime power management > > > > drivers/bus/sunxi-rsb.c | 211 > > 1 file changed, 150 insertions(+), 61 deletions(-) > > For the whole series, > > Acked-by: Maxime Ripard Thanks! Pushed out to kernel.org.
Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection
On Wed, Jan 6, 2021 at 7:06 PM Maxime Ripard wrote: > > On Mon, Jan 04, 2021 at 10:54:19AM +, André Przywara wrote: > > On 03/01/2021 10:00, Samuel Holland wrote: > > > On boards where the only peripheral connected to PL0/PL1 is an X-Powers > > > PMIC, configure the connection to use the RSB bus rather than the I2C > > > bus. Compared to the I2C controller that shares the pins, the RSB > > > controller allows a higher bus frequency, and it is more CPU-efficient. > > > > But is it really necessary to change the DTs for those boards in this > > way? It means those newer DTs now become incompatible with older > > kernels, and I don't know if those reasons above really justify this. > > > > I understand that we officially don't care about "newer DTs on older > > kernels", but do we really need to break this deliberately, for no > > pressing reasons? > > > > P.S. I am fine with supporting RSB on H6, and even using it on new DTs, > > just want to avoid breaking existing ones. > > Doing so would also introduce some inconsistencies, one more thing to > consider during reviews, and would require more testing effort. > > I'm not sure that stretching our - already fairly sparse - resources > thin would be very wise here, especially for something that we don't > have to do and for a setup that isn't really used that much. As soon as some software component starts running RSB, (which I assume is what Samuel is planning to do in Crust?), there's a chance that it doesn't switch the chip back to I2C. And then Linux won't be able to access it. So I'm for keeping things consistent and converting all users to RSB. ChenYu
Re: [PATCH net-next 5/5] net: stmmac: dwmac-sun8i: Add a shutdown callback
On Sun, Jan 3, 2021 at 7:25 PM Samuel Holland wrote: > > The Ethernet MAC and PHY are usually major consumers of power on boards > which may not be able to fully power off (that have no PMIC). Powering > down the MAC and internal PHY saves power while these boards are "off". > > Signed-off-by: Samuel Holland Reviewed-by: Chen-Yu Tsai
Re: [PATCH net-next 4/5] net: stmmac: dwmac-sun8i: Minor probe function cleanup
On Sun, Jan 3, 2021 at 7:25 PM Samuel Holland wrote: > > Adjust the spacing and use an explicit "return 0" in the success path > to make the function easier to parse. > > Signed-off-by: Samuel Holland Reviewed-by: Chen-Yu Tsai
Re: [PATCH net-next 2/5] net: stmmac: dwmac-sun8i: Remove unnecessary PHY power check
On Sun, Jan 3, 2021 at 7:25 PM Samuel Holland wrote: > > sun8i_dwmac_unpower_internal_phy already checks if the PHY is powered, > so there is no need to do it again here. > > Signed-off-by: Samuel Holland Reviewed-by: Chen-Yu Tsai
Re: [PATCH net-next 3/5] net: stmmac: dwmac-sun8i: Use reset_control_reset
On Sun, Jan 3, 2021 at 7:25 PM Samuel Holland wrote: > > Use the appropriate function instead of reimplementing it, > and update the error message to match the code. > > Signed-off-by: Samuel Holland Reviewed-by: Chen-Yu Tsai
Re: [PATCH net-next 1/5] net: stmmac: dwmac-sun8i: Return void from PHY unpower
On Sun, Jan 3, 2021 at 7:25 PM Samuel Holland wrote: > > This is a deinitialization function that always returned zero, and that > return value was always ignored. Have it return void instead. > > Signed-off-by: Samuel Holland Reviewed-by: Chen-Yu Tsai
Re: [PATCH v2 2/4] pinctrl: sunxi: h6-r: Add s_rsb pin functions
On Wed, Jan 6, 2021 at 6:35 AM Linus Walleij wrote: > > On Sun, Jan 3, 2021 at 11:00 AM Samuel Holland wrote: > > > As there is an RSB controller in the H6 SoC, there should be some pin > > configuration for it. While no such configuration is documented, the > > "s_i2c" pins are suspiciously on the "alternate" function 3, with no > > primary function 2 given. This suggests the primary function for these > > pins is actually RSB, and that is indeed the case. > > > > Add the "s_rsb" pin functions so the RSB controller can be used. > > > > Signed-off-by: Samuel Holland > > Is it OK if I just apply this patch to the pinctrl tree? Please do. Thanks ChenYu
Re: [PATCH net 1/4] net: stmmac: dwmac-sun8i: Fix probe error handling
On Sun, Jan 3, 2021 at 7:17 PM Samuel Holland wrote:
>
> stmmac_pltfr_remove does three things in one function, making it
> inapproprate for unwinding the steps in the probe function. Currently,
> a failure before the call to stmmac_dvr_probe would leak OF node
> references due to missing a call to stmmac_remove_config_dt. And an
> error in stmmac_dvr_probe would cause the driver to attempt to remove a
> netdevice that was never added. Fix these by reordering the init and
> splitting out the error handling steps.
>
> Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i")
> Fixes: 40a1dcee2d18 ("net: ethernet: dwmac-sun8i: Use the correct function in
> exit path")
> Signed-off-by: Samuel Holland
Reviewed-by: Chen-Yu Tsai
Re: [PATCH net 2/4] net: stmmac: dwmac-sun8i: Balance internal PHY resource references
On Sun, Jan 3, 2021 at 7:17 PM Samuel Holland wrote:
>
> While stmmac_pltfr_remove calls sun8i_dwmac_exit, the sun8i_dwmac_init
> and sun8i_dwmac_exit functions are also called by the stmmac_platform
> suspend/resume callbacks. They may be called many times during the
> device's lifetime and should not release resources used by the driver.
>
> Furthermore, there was no error handling in case registering the MDIO
> mux failed during probe, and the EPHY clock was never released at all.
>
> Fix all of these issues by moving the deinitialization code to a driver
> removal callback. Also ensure the EPHY is powered down before removal.
>
> Fixes: 634db83b8265 ("net: stmmac: dwmac-sun8i: Handle integrated/external
> MDIOs")
> Signed-off-by: Samuel Holland
Reviewed-by: Chen-Yu Tsai
Re: [PATCH 0/4] bus: sunxi-rsb: Implement power managment
Hi, On Sun, Jan 3, 2021 at 7:06 PM Samuel Holland wrote: > > This series adds system (complete power down) and runtime (clock gate) > PM hooks to the RSB controller driver. Tested on A64 and H6. > > Samuel Holland (4): > bus: sunxi-rsb: Move OF match table > bus: sunxi-rsb: Split out controller init/exit functions > bus: sunxi-rsb: Implement suspend/resume/shutdown callbacks > bus: sunxi-rsb: Implement runtime power management > > drivers/bus/sunxi-rsb.c | 211 > 1 file changed, 150 insertions(+), 61 deletions(-) Looks good to me. Acked-by: Chen-Yu Tsai I already queued them up locally, but I think it's best to give other people some time to review as well. ChenYu
Re: [linux-sunxi] [PATCH v2 0/4] Allwinner H6 RSB support
Hi,
On Sun, Jan 03, 2021 at 04:00:03AM -0600, Samuel Holland wrote:
> The Allwinner H6 SoC contains an RSB controller. It is almost completely
> undocumented, so it was missed when doing the initial SoC bringup.
>
> This series adds the clock/reset, pin configuration, and device tree
> node needed to use the RSB controller. Since RSB is faster, simpler, and
> generally more reliable than the I2C controller IP in the SoC, switch to
> using it where possible.
>
> This was tested on an Orange Pi 3 and a Pine H64 model B. This series
> does not switch the Pine H64 to use RSB, as doing so would prevent
> accessing the external RTC that shares the I2C bus.
>
> Changes v1->v2:
> - Put the new values at the end of the DT binding headers
>
> Samuel Holland (4):
> clk: sunxi-ng: h6-r: Add R_APB2_RSB clock and reset
> pinctrl: sunxi: h6-r: Add s_rsb pin functions
> arm64: dts: allwinner: h6: Add RSB controller node
> arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection
I queued up patches 1, 3, and 4 locally for v5.12. Obviously this won't
work unless the pinctrl patch is also queued up, so they won't be pushed
out until that happens.
Regarding patch 3, I replaced the clock and reset macros with raw
numbers to get rid of cross-tree dependencies. The following fix
will be posted for v5.12 later on during its RC cycle.
>8 ----
commit 0b4781666adc5e19c4d4fb4a2bff33883181cc39
Author: Chen-Yu Tsai
Date: Mon Jan 4 16:19:17 2021 +0800
arm64: dts: allwinner: h6: Switch to macros for RSB clock/reset indices
The macros for the clock and reset indices for the RSB hardware block
were replaced with raw numbers when the RSB controller node was added.
This was done to avoid cross-tree dependencies.
Now that both the clk and DT changes have been merged, we can switch
back to using the macros.
Signed-off-by: Chen-Yu Tsai
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index d897697849d6..b043beea8e6e 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -988,9 +988,9 @@ r_rsb: rsb@7083000 {
compatible = "allwinner,sun8i-a23-rsb";
reg = <0x07083000 0x400>;
interrupts = ;
- clocks = <_ccu 13>;
+ clocks = <_ccu CLK_R_APB2_RSB>;
clock-frequency = <300>;
- resets = <_ccu 7>;
+ resets = <_ccu RST_R_APB2_RSB>;
pinctrl-names = "default";
pinctrl-0 = <_rsb_pins>;
status = "disabled";
>8
>
> .../dts/allwinner/sun50i-h6-beelink-gs1.dts | 38 +--
> .../dts/allwinner/sun50i-h6-orangepi-3.dts| 14 +++
> .../dts/allwinner/sun50i-h6-orangepi.dtsi | 22 +--
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 19 ++
> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c| 5 +++
> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h| 2 +-
> drivers/pinctrl/sunxi/pinctrl-sun50i-h6-r.c | 2 +
> include/dt-bindings/clock/sun50i-h6-r-ccu.h | 2 +
> include/dt-bindings/reset/sun50i-h6-r-ccu.h | 1 +
> 9 files changed, 67 insertions(+), 38 deletions(-)
>
> --
> 2.26.2
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/linux-sunxi/2021010317.32867-1-samuel%40sholland.org.
Re: [linux-sunxi] [PATCH v2 2/4] pinctrl: sunxi: h6-r: Add s_rsb pin functions
On Sun, Jan 3, 2021 at 6:00 PM Samuel Holland wrote: > > As there is an RSB controller in the H6 SoC, there should be some pin > configuration for it. While no such configuration is documented, the > "s_i2c" pins are suspiciously on the "alternate" function 3, with no > primary function 2 given. This suggests the primary function for these > pins is actually RSB, and that is indeed the case. > > Add the "s_rsb" pin functions so the RSB controller can be used. > > Signed-off-by: Samuel Holland Acked-by: Chen-Yu Tsai
Re: [PATCH] arm64: dts: sun50i-a64-pinephone: add 'pine64, pinephone' to the compatible list
On Tue, Dec 29, 2020 at 11:42 PM Dylan Van Assche wrote: > > All revisions of the PinePhone share most of the hardware. > This patch makes it easier to detect PinePhone hardware without > having to check for each possible revision. Sounds good. > Signed-off-by: Dylan Van Assche > --- > arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts | 2 +- > arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts | 2 +- > arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts | 2 +- Please also update the DT binding file: Documentation/devicetree/bindings/arm/sunxi.yaml ChenYu
Re: [PATCH] ARM: dts: sun8i-v3s: Add CSI0 MCLK pin definition
On Tue, Dec 22, 2020 at 4:17 PM Jernej Škrabec wrote:
>
> Hi!
>
> Dne petek, 18. december 2020 ob 20:50:33 CET je Paul Kocialkowski napisal(a):
> > This adds a device-tree definition for the CSI0 MCLK pin,
> > which can be used for feeding MIPI CSI-2 sensors.
> >
> > Signed-off-by: Paul Kocialkowski
>
> Is this used anywhere? Current policy is to add pin definitions only if any
> user exists.
IIRC we sort of loosened that requirement with the use of /omit-if-no-ref/.
The A20 dtsi file has a whole bunch of pins defined that are not directly
used but are available for users to reference, especially in overlays.
The "-@" parameter for the device tree compiler, used to build overlay
compatible DTBs, makes the compiler ignore /omit-if-no-ref/ and include
all the nodes.
ChenYu
> Best regards,
> Jernej
>
> > ---
> > arch/arm/boot/dts/sun8i-v3s.dtsi | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
> > b/arch/arm/boot/dts/sun8i-v3s.dtsi index a9f5795d4e57..bff822b9fa01 100644
> > --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> > @@ -337,6 +337,12 @@ pio: pinctrl@1c20800 {
> > interrupt-controller;
> > #interrupt-cells = <3>;
> >
> > + /omit-if-no-ref/
> > + csi0_mclk_pin: csi0-mclk-pin {
> > + pins = "PE20";
> > + function = "csi_mipi";
> > + };
> > +
> > /omit-if-no-ref/
> > csi1_8bit_pins: csi1-8bit-pins {
> > pins = "PE0", "PE2", "PE3",
> "PE8", "PE9",
>
>
>
>
Re: [linux-sunxi] Re: [PATCH RESEND] ARM: configs: sunxi: enable brcm wireless
On Mon, Dec 28, 2020 at 4:03 AM Jernej Škrabec wrote: > > Hi! > > Dne nedelja, 27. december 2020 ob 21:00:00 CET je Corentin Labbe napisal(a): > > Lot of sunxi boards have BRCM wireless device, so let's enable necessary > > options for it in our defconfig. > > Idea is good but modules (=m) instead of build in (=y) would be better. As you > said, not all boards have such wifi and there is no need to make kernel binary > bigger. It's probably not very useful on its own if built in, since it also needs firmware blobs, and when built in it doesn't wait for the rootfs to be available. ChenYu > Best regards, > Jernej > > > > > Signed-off-by: Corentin Labbe > > --- > > arch/arm/configs/sunxi_defconfig | 23 ++- > > 1 file changed, 22 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm/configs/sunxi_defconfig > > b/arch/arm/configs/sunxi_defconfig index a60c134c5e04..4891aefdef7d 100644 > > --- a/arch/arm/configs/sunxi_defconfig > > +++ b/arch/arm/configs/sunxi_defconfig > > @@ -52,7 +52,28 @@ CONFIG_STMMAC_ETH=y > > # CONFIG_NET_VENDOR_WIZNET is not set > > CONFIG_MICREL_PHY=y > > CONFIG_REALTEK_PHY=y > > -# CONFIG_WLAN is not set > > +CONFIG_WLAN=y > > +# CONFIG_WLAN_VENDOR_ADMTEK is not set > > +# CONFIG_WLAN_VENDOR_ATH is not set > > +# CONFIG_WLAN_VENDOR_ATMEL is not set > > +CONFIG_WLAN_VENDOR_BROADCOM=y > > +# CONFIG_WLAN_VENDOR_CISCO is not set > > +# CONFIG_WLAN_VENDOR_INTEL is not set > > +# CONFIG_WLAN_VENDOR_INTERSIL is not set > > +# CONFIG_WLAN_VENDOR_MARVELL is not set > > +# CONFIG_WLAN_VENDOR_MEDIATEK is not set > > +# CONFIG_WLAN_VENDOR_MICROCHIP is not set > > +# CONFIG_WLAN_VENDOR_RALINK is not set > > +# CONFIG_WLAN_VENDOR_REALTEK is not set > > +# CONFIG_WLAN_VENDOR_RSI is not set > > +# CONFIG_WLAN_VENDOR_ST is not set > > +# CONFIG_WLAN_VENDOR_TI is not set > > +# CONFIG_WLAN_VENDOR_ZYDAS is not set > > +# CONFIG_WLAN_VENDOR_QUANTENNA is not set > > +CONFIG_CFG80211=y > > +CONFIG_CFG80211_WEXT=y > > +CONFIG_MAC80211=y > > +CONFIG_BRCMFMAC=y > > CONFIG_INPUT_EVDEV=y > > CONFIG_KEYBOARD_SUN4I_LRADC=y > > # CONFIG_INPUT_MOUSE is not set > > > > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/linux-sunxi/25142918.GuFC1uy7vR%40jernej-laptop.
Re: [PATCH] net: allwinner: Fix some resources leak in the error handling path of the probe and in the remove function
On Wed, Dec 16, 2020 at 4:16 AM Christophe JAILLET
wrote:
>
> Le 15/12/2020 à 20:35, Dan Carpenter a écrit :
> > On Tue, Dec 15, 2020 at 08:08:15PM +0100, Maxime Ripard wrote:
> >> On Tue, Dec 15, 2020 at 07:18:48PM +0100, Christophe JAILLET wrote:
> >>> Le 15/12/2020 à 12:37, Maxime Ripard a écrit :
> On Tue, Dec 15, 2020 at 12:11:53PM +0300, Dan Carpenter wrote:
> > On Tue, Dec 15, 2020 at 09:56:55AM +0100, Maxime Ripard wrote:
> >> Hi,
> >>
> >> On Mon, Dec 14, 2020 at 09:21:17PM +0100, Christophe JAILLET wrote:
> >>> 'irq_of_parse_and_map()' should be balanced by a corresponding
> >>> 'irq_dispose_mapping()' call. Otherwise, there is some resources
> >>> leaks.
> >>
> >> Do you have a source to back that? It's not clear at all from the
> >> documentation for those functions, and couldn't find any user calling
> >> it
> >> from the ten-or-so random picks I took.
> >
> > It looks like irq_create_of_mapping() needs to be freed with
> > irq_dispose_mapping() so this is correct.
>
> The doc should be updated first to make that clear then, otherwise we're
> going to fix one user while multiples will have poped up
>
> Maxime
>
> >>>
> >>> Hi,
> >>>
> >>> as Dan explained, I think that 'irq_dispose_mapping()' is needed because
> >>> of
> >>> the 'irq_create_of_mapping()" within 'irq_of_parse_and_map()'.
> >>>
> >>> As you suggest, I'll propose a doc update to make it clear and more future
> >>> proof.
> >>
> >> Thanks :)
> >>
> >> And if you feel like it, a coccinelle script would be awesome too so
> >> that other users get fixed over time
> >>
> >> Maxime
> >
> > Smatch has a new check for resource leaks which hopefully people will
> > find useful.
> >
> > https://github.com/error27/smatch/blob/master/check_unwind.c
>
> Nice :)
> I wasn't aware of it.
>
> >
> > To check for these I would need to add the following lines to the table:
> >
> > { "irq_of_parse_and_map", ALLOC, -1, "$", _one, _max},
> > { "irq_create_of_mapping", ALLOC, -1, "$", _one, _max},
> > { "irq_dispose_mapping", RELEASE, 0, "$"},
> >
> > The '-1, "$"' means the returned value. irq_of_parse_and_map() and
> > irq_create_of_mapping() return positive int on success.
> >
> > The irq_dispose_mapping() frees its zeroth parameter so it's listed as
> > '0, "$"'. We don't care about the returns from irq_dispose_mapping().
> >
> > It doesn't apply in this case but if a function frees a struct member
> > then that's listed as '0, "$->member_name"'.
> >
> > regards,
> > dan carpenter
> >
>
> The script I use to try to spot missing release function is:
> ///
> @@
> expression x, y;
> identifier f, l;
> @@
>
> * x = irq_of_parse_and_map(...);
> ... when any
> * y = f(...);
> ... when any
> * if (<+... y ...+>)
> {
> ...
> (
> * goto l;
> |
> * return ...;
> )
> ...
> }
> ... when any
> *l:
> ... when != irq_dispose_mapping(...);
> * return ...;
> ///
>
> It is likely that some improvement can be made, but it works pretty well
> for what I want.
>
> And I have a collection of alloc/free functions that I manually put in
> place of irq_of_parse_and_map and irq_dispose_mapping.
AFAICT the resource leak is likely larger in scope, as many drivers use
platform_get_irq(), which eventually ends up calling irq_create_of_mapping()
through of_irq_get() in the OF path. Same goes for platform_get_irq_byname().
ChenYu
> Up to know, this list is:
>
> // alloc_etherdev/alloc_etherdev_mq/alloc_etherdev_mqs - free_netdev
> // alloc_workqueue - destroy_workqueue
> // class_register - class_unregister
> // clk_get - clk_put
> // clk_prepare - clk_unprepare
> // create_workqueue - destroy_workqueue
> // create_singlethread_workqueue - destroy_workqueue
> //
> dev_pm_domain_attach/dev_pm_domain_attach_by_id/dev_pm_domain_attach_by_name
> - dev_pm_domain_detach
> // devres_alloc - devres_free
> // dma_alloc_coherent - dma_free_coherent
> // dma_map_resource - dma_unmap_resource
> // dma_map_single - dma_unmap_single
> // dma_request_slave_channel - dma_release_channel
> // dma_request_chan - dma_release_channel
> // framebuffer_alloc - framebuffer_release
> // get_device - put_device
> // iio_channel_get - iio_channel_release
> // ioremap - iounmap
> // input_allocate_device - input_free_device
> // input_register_handle - input_unregister_handle
> // irq_of_parse_and_map / irq_create_of_mapping - irq_dispose_mapping
> // kmalloc - kfree
> // mempool_alloc - mempool_free
> // of_node_get - of_node_put
> // of_reserved_mem_device_init - of_reserved_mem_device_release
> // pinctrl_register - pinctrl_unregister
> // request_irq - free_irq
> // request_region - release_region
> // request_mem_region - release_mem_region
> // reset_control_assert - reset_control_deassert
> // scsi_host_alloc - scsi_host_put
>
> //
Re: [linux-sunxi] Re: [PATCH v2 19/21] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
On Mon, Dec 14, 2020 at 8:53 PM Andre Przywara wrote:
>
> On Mon, 14 Dec 2020 10:58:31 +0100
> Maxime Ripard wrote:
>
> Hi,
>
> > On Fri, Dec 11, 2020 at 01:19:32AM +, Andre Przywara wrote:
> > > + reserved-memory {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > +
> > > + /* 512KiB reserved for ARM Trusted Firmware (BL31)
> > > */
> > > + secmon_reserved: secmon@4000 {
> > > + reg = <0x0 0x4000 0x0 0x8>;
> > > + no-map;
> > > + };
> > > + };
> >
> > This should still be set by the firmware
> >
> > > + mmc0: mmc@402 {
> > > + compatible = "allwinner,sun50i-h616-mmc",
> > > +"allwinner,sun50i-a100-mmc";
> > > + reg = <0x0402 0x1000>;
> > > + clocks = < CLK_BUS_MMC0>, <
> > > CLK_MMC0>;
> > > + clock-names = "ahb", "mmc";
> > > + resets = < RST_BUS_MMC0>;
> > > + reset-names = "ahb";
> > > + interrupts = > > IRQ_TYPE_LEVEL_HIGH>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_pins>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> >
> > Somewhat related: we shouldn't set the MMC speed flags in the drivers.
> > This is biting us on the already supported SoCs, so it would be great
> > to not repeat the same mistake with the new ones
>
> Do you mean to list the "sd-uhs-sdr50" and friends properties here in
> the DT?
> What is the best practice here in terms putting them in the .dts vs.
> the .dtsi? Surely the controller has limits, but bad traces on a board
> could impose further restrictions, right?
> Though that's probably rare, so it sounds like a lot of churn to list
> them in every board DT. So can we list everything in here (.dtsi), then
> delete in those affected boards only?
The driver will most certainly already have the basic high speed modes
enabled. Or we can list them in the .dtsi file.
For HS-DDR mode, we probably want to list that in the .dtsi file as well,
as that seems to be the one that is failing most of the time.
All the UHS-1 modes would be listed by board, since it requires a way
to cut power to the card and the ability to change I/O voltage levels.
I wonder if Allwinner still keeps the timing information in the driver,
or have they moved that to their vendor device tree files. We might want
to consider moving it as well.
ChenYu
Re: [PATCH 2/8] pinctrl: sunxi: Add support for the Allwinner H616 pin controller
On Mon, Dec 14, 2020 at 12:28 AM Icenowy Zheng wrote: > > 在 2020-12-02星期三的 13:54 +，Andre Przywara写道： > > Port A is used for an internal connection to some analogue circuitry > > which looks like an AC200 IP (as in the H6), though this is not > > mentioned in the manual. > > When developing for V831, I found that PIO controller in H616 (and > V831) has the functionality of selecting IO voltage of PF bank (needed > to handle UHS-I). > > How should we model this in PIO driver? I suppose we could expose it as a regulator for the mmc node to consume as its vqmmc-supply? ChenYu
Re: [PATCH v2 1/4] PCI: rockchip: Make 'ep-gpios' DT property optional
On Mon, Dec 7, 2020 at 10:11 PM Rob Herring wrote:
>
> On Wed, Nov 18, 2020 at 1:17 AM Chen-Yu Tsai wrote:
> >
> > From: Chen-Yu Tsai
> >
> > The Rockchip PCIe controller DT binding clearly states that 'ep-gpios' is
> > an optional property. And indeed there are boards that don't require it.
> >
> > Make the driver follow the binding by using devm_gpiod_get_optional()
> > instead of devm_gpiod_get().
> >
> > Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
> > Fixes: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver")
> > Fixes: 964bac9455be ("PCI: rockchip: Split out rockchip_pcie_parse_dt() to
> > parse DT")
> > Signed-off-by: Chen-Yu Tsai
> > ---
> > Changes since v1:
> >
> > - Rewrite subject to match existing convention and reference
> > 'ep-gpios' DT property instead of the 'ep_gpio' field
> > ---
> > drivers/pci/controller/pcie-rockchip.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/controller/pcie-rockchip.c
> > b/drivers/pci/controller/pcie-rockchip.c
> > index 904dec0d3a88..c95950e9004f 100644
> > --- a/drivers/pci/controller/pcie-rockchip.c
> > +++ b/drivers/pci/controller/pcie-rockchip.c
> > @@ -118,7 +118,7 @@ int rockchip_pcie_parse_dt(struct rockchip_pcie
> > *rockchip)
> > }
> >
> > if (rockchip->is_rc) {
> > - rockchip->ep_gpio = devm_gpiod_get(dev, "ep",
> > GPIOD_OUT_HIGH);
> > + rockchip->ep_gpio = devm_gpiod_get_optional(dev, "ep",
> > GPIOD_OUT_HIGH);
> > if (IS_ERR(rockchip->ep_gpio)) {
> > dev_err(dev, "missing ep-gpios property in node\n");
>
> You should drop the error message. What it says is now never the
> reason for the error and it could most likely be a deferred probe
> which you don't want an error message for.
What about switching to dev_err_probe() instead?
That way deferred probe errors get silenced (or get a better debug message),
and error messages for other issues, such as miswritten gpio properties are
still produced.
ChenYu
> > return PTR_ERR(rockchip->ep_gpio);
> > --
> > 2.29.1
> >
Re: [PATCH V2 3/3] arm64: dts: allwinner: a100: Add CPU Operating Performance Points table
On Mon, Dec 7, 2020 at 5:20 PM Shuosheng Huang
wrote:
>
> Add an Operating Performance Points table for the CPU cores to
> enable Dynamic Voltage & Frequency Scaling on the A100.
>
> Signed-off-by: Shuosheng Huang
> ---
> .../allwinner/sun50i-a100-allwinner-perf1.dts | 5 ++
> .../dts/allwinner/sun50i-a100-cpu-opp.dtsi| 90 +++
> .../arm64/boot/dts/allwinner/sun50i-a100.dtsi | 8 ++
> 3 files changed, 103 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> index d34c2bb1079f..7c579923f973 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> @@ -6,6 +6,7 @@
> /dts-v1/;
>
> #include "sun50i-a100.dtsi"
> +#include "sun50i-a100-cpu-opp.dtsi"
>
> /{
> model = "Allwinner A100 Perf1";
> @@ -20,6 +21,10 @@ chosen {
> };
> };
>
> + {
> + cpu-supply = <_dcdc2>;
> +};
> +
Please add this for all CPU cores.
IIRC people (I don't remember exactly who) have reported that if the first
CPU core is offline, i.e. having Linux booting off one of the other CPU
cores, then cpufreq sort of breaks as the CPU no longer has a regulator tied
to it.
Also, please separate the changes in sun50i-a100-allwinner-perf1.dts to
one patch titled "Enable cpufreq for ".
> {
> vcc-pb-supply = <_dcdc1>;
> vcc-pc-supply = <_eldo1>;
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
> new file mode 100644
> index ..e245823d70e8
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
> @@ -0,0 +1,90 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (c) 2020 Yangtao Li
> +// Copyright (c) 2020 ShuoSheng Huang
> +
> +/ {
> + cpu_opp_table: cpu-opp-table {
> + compatible = "allwinner,sun50i-h6-operating-points";
> + nvmem-cells = <_speed_grade>;
> + opp-shared;
> +
> + opp@40800 {
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-hz = /bits/ 64 <40800>;
> +
> + opp-microvolt-speed0 = <90 90 120>;
> + opp-microvolt-speed1 = <90 90 120>;
> + opp-microvolt-speed2 = <90 90 120>;
> + };
> +
> + opp@6 {
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-hz = /bits/ 64 <6>;
> +
> + opp-microvolt-speed0 = <90 90 120>;
> + opp-microvolt-speed1 = <90 90 120>;
> + opp-microvolt-speed2 = <90 90 120>;
> + };
> +
> + opp@81600 {
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-hz = /bits/ 64 <81600>;
> +
> + opp-microvolt-speed0 = <94 94 120>;
> + opp-microvolt-speed1 = <90 90 120>;
> + opp-microvolt-speed2 = <90 90 120>;
> + };
> +
> + opp@108000 {
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-hz = /bits/ 64 <108000>;
> +
> + opp-microvolt-speed0 = <102 102 120>;
> + opp-microvolt-speed1 = <98 98 120>;
> + opp-microvolt-speed2 = <95 95 120>;
> + };
> +
> + opp@12 {
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-hz = /bits/ 64 <12>;
> +
> + opp-microvolt-speed0 = <110 110 120>;
> + opp-microvolt-speed1 = <102 102 120>;
> + opp-microvolt-speed2 = <100 100 120>;
> + };
> +
> + opp@132000 {
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-hz = /bits/ 64 <132000>;
> +
> + opp-microvolt-speed0 = <116 116 120>;
> + opp-microvolt-speed1 = <106 106 120>;
> + opp-microvolt-speed2 = <103 103 120>;
> + };
> +
> + opp@146400 {
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-hz = /bits/ 64 <146400>;
> +
> + opp-microvolt-speed0 = <118 118 120>;
> +
Re: [PATCH v2 1/4] PCI: rockchip: Make 'ep-gpios' DT property optional
Ping
On Wed, Nov 18, 2020 at 4:49 PM Heiko Stübner wrote:
>
> Am Mittwoch, 18. November 2020, 08:17:21 CET schrieb Chen-Yu Tsai:
> > From: Chen-Yu Tsai
> >
> > The Rockchip PCIe controller DT binding clearly states that 'ep-gpios' is
> > an optional property. And indeed there are boards that don't require it.
> >
> > Make the driver follow the binding by using devm_gpiod_get_optional()
> > instead of devm_gpiod_get().
> >
> > Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
> > Fixes: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver")
> > Fixes: 964bac9455be ("PCI: rockchip: Split out rockchip_pcie_parse_dt() to
> > parse DT")
> > Signed-off-by: Chen-Yu Tsai
>
> Reviewed-by: Heiko Stuebner I'll pick up patches 2-4 separately, after giving Rob a chance to look at
> the simple binding.
>
>
> Heiko
>
> > ---
> > Changes since v1:
> >
> > - Rewrite subject to match existing convention and reference
> > 'ep-gpios' DT property instead of the 'ep_gpio' field
> > ---
> > drivers/pci/controller/pcie-rockchip.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/controller/pcie-rockchip.c
> > b/drivers/pci/controller/pcie-rockchip.c
> > index 904dec0d3a88..c95950e9004f 100644
> > --- a/drivers/pci/controller/pcie-rockchip.c
> > +++ b/drivers/pci/controller/pcie-rockchip.c
> > @@ -118,7 +118,7 @@ int rockchip_pcie_parse_dt(struct rockchip_pcie
> > *rockchip)
> > }
> >
> > if (rockchip->is_rc) {
> > - rockchip->ep_gpio = devm_gpiod_get(dev, "ep", GPIOD_OUT_HIGH);
> > + rockchip->ep_gpio = devm_gpiod_get_optional(dev, "ep",
> > GPIOD_OUT_HIGH);
> > if (IS_ERR(rockchip->ep_gpio)) {
> > dev_err(dev, "missing ep-gpios property in node\n");
> > return PTR_ERR(rockchip->ep_gpio);
> >
>
>
>
>
Re: [PATCH v2] regulatx DLDO2 voltage control register mask for AXP22x
On Sat, Dec 5, 2020 at 1:40 AM Mark Brown wrote: > > On Fri, Dec 04, 2020 at 10:34:21AM +0800, Chen-Yu Tsai wrote: > > On Thu, Dec 3, 2020 at 12:11 AM Mark Brown wrote: > > > > No, no sign. You can check if things are at least hitting the list at: > > > > https://lore.kernel.org/lkml/ > > > I did receive it though. Would it help if I tried to bounce it to you > > and the lists? > > Possibly? It depends on what the issue is. Looks like v3 was already there the first time though: https://lore.kernel.org/lkml/20201201001000.22302-1-dinghua.ma...@gmail.com/ Me bouncing it again had no real effect. ChenYu
[PATCH] arm64: dts: rockchip: rk3328: Fix UART pull-ups
From: Chen-Yu Tsai
For UARTs, the local pull-ups should be on the RX pin, not the TX pin.
UARTs transmit active-low, so a disconnected RX pin should be pulled
high instead of left floating to prevent noise being interpreted as
transmissions.
This gets rid of bogus sysrq events when the UART console is not
connected.
Fixes: 52e02d377a72 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs")
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 521c4678ec35..1e3aa6acbc11 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -1265,8 +1265,8 @@ otp_out: otp-out {
uart0 {
uart0_xfer: uart0-xfer {
- rockchip,pins = <1 RK_PB1 1 _pull_up>,
- <1 RK_PB0 1 _pull_none>;
+ rockchip,pins = <1 RK_PB1 1 _pull_none>,
+ <1 RK_PB0 1 _pull_up>;
};
uart0_cts: uart0-cts {
@@ -1284,8 +1284,8 @@ uart0_rts_pin: uart0-rts-pin {
uart1 {
uart1_xfer: uart1-xfer {
- rockchip,pins = <3 RK_PA4 4 _pull_up>,
- <3 RK_PA6 4 _pull_none>;
+ rockchip,pins = <3 RK_PA4 4 _pull_none>,
+ <3 RK_PA6 4 _pull_up>;
};
uart1_cts: uart1-cts {
@@ -1303,15 +1303,15 @@ uart1_rts_pin: uart1-rts-pin {
uart2-0 {
uart2m0_xfer: uart2m0-xfer {
- rockchip,pins = <1 RK_PA0 2 _pull_up>,
- <1 RK_PA1 2 _pull_none>;
+ rockchip,pins = <1 RK_PA0 2 _pull_none>,
+ <1 RK_PA1 2 _pull_up>;
};
};
uart2-1 {
uart2m1_xfer: uart2m1-xfer {
- rockchip,pins = <2 RK_PA0 1 _pull_up>,
- <2 RK_PA1 1 _pull_none>;
+ rockchip,pins = <2 RK_PA0 1 _pull_none>,
+ <2 RK_PA1 1 _pull_up>;
};
};
--
2.29.2
Re: [PATCH v2] ARM: dts: sun8i: v3s: SRAM_C real mapping
On Fri, Dec 4, 2020 at 2:15 AM Martin Cerveny wrote:
>
> VideoEngine (cedrus) needs assign dedicated SRAM for decoding.
> SRAM_C1 is usually used for Allwinner platforms.
> Allwinner V3s scale down chip has not SRAM_C1 but only small SRAM_C (44kB).
>
> Result of additional testing:
>
> SRAM_C is mapped in two regions 0x_4000 (primary location,
> by Datasheet) (size is 0xb000, probably exact size is 0xb0c0
> and it is mapped to 4k boundary (to 0x_))
> and to 0x01d0_4000 (traditional SRAM_C1 region from 0x01d0_).
>
> Rest of 0x01d0_ are discontinuously filled with R/W register sets
> (probably some internals registers from VE) that I thought to be SRAM too.
>
> Programming register SRAM_CTRL_REG0 (0x01c00_) with value 0x7fff_
> switch out whole region 0x01d0_-0x01df_ and 0x_4000-0x_
> (dedicate access to VE).
>
> VE/cedrus code use this SRAM region indirectly
> (VE_AVC_SRAM_PORT_OFFSET/VE_AVC_SRAM_PORT_DATA...)
> and it is not influenced by "real" SRAM mapping or size
> so it is working even without this patch.
>
> Signed-off-by: Martin Cerveny
> ---
> arch/arm/boot/dts/sun8i-v3s.dtsi | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
> b/arch/arm/boot/dts/sun8i-v3s.dtsi
> index e8f304125e2d..bc4b4a0200cb 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -162,17 +162,17 @@ syscon: system-control@1c0 {
> #size-cells = <1>;
> ranges;
>
> - sram_c: sram@1d0 {
> + sram_c: sram@4000 {
> compatible = "mmio-sram";
> - reg = <0x01d0 0x8>;
> + reg = <0x4000 0xb000>;
> #address-cells = <1>;
> #size-cells = <1>;
> - ranges = <0 0x01d0 0x8>;
> + ranges = <0 0x4000 0xb000>;
>
> ve_sram: sram-section@0 {
> compatible =
> "allwinner,sun8i-v3s-sram-c1",
Using C1 in the compatible string is confusing at this point, as the
name is never mentioned in the manual.
Please change it to sram-ve instead. Please also update the binding.
Since the DT patches this depends on haven't been merged yet, please
just do another version of the remaining patches with the changes
included.
ChenYu
>
> "allwinner,sun4i-a10-sram-c1";
> - reg = <0x00 0x8>;
> + reg = <0x0 0xb000>;
> };
> };
> };
> --
> 2.25.1
>
Re: [PATCH v2] regulatx DLDO2 voltage control register mask for AXP22x
On Thu, Dec 3, 2020 at 12:11 AM Mark Brown wrote: > > On Thu, Dec 03, 2020 at 12:04:05AM +0800, dinghua ma wrote: > > I sent a new email. I don’t know if you received it. The subject is "[PATCH > > v3] regulator: axp20x: Fix DLDO2 voltage control register mask for AXP22x" > > No, no sign. You can check if things are at least hitting the list at: > > https://lore.kernel.org/lkml/ I did receive it though. Would it help if I tried to bounce it to you and the lists? ChenYu
Re: [PATCH v3 3/6] ARM: dts: sun8i: v3s: Add node for system control
On Fri, Dec 4, 2020 at 12:25 AM Martin Cerveny wrote:
>
> Hello.
>
> On Thu, 3 Dec 2020, Chen-Yu Tsai wrote:
>
> > Hi,
> >
> > On Mon, Nov 16, 2020 at 8:57 PM Martin Cerveny
> > wrote:
> >>
> >> Allwinner V3s has system control and SRAM C1 region similar to H3.
> >>
> >> Signed-off-by: Martin Cerveny
> >> ---
> >> arch/arm/boot/dts/sun8i-v3s.dtsi | 14 ++
> >> 1 file changed, 14 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
> >> b/arch/arm/boot/dts/sun8i-v3s.dtsi
> >> index 0c7341676921..70193512c222 100644
> >> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> >> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> >> @@ -161,6 +161,20 @@ syscon: system-control@1c0 {
> >> #address-cells = <1>;
> >> #size-cells = <1>;
> >> ranges;
> >> +
> >> + sram_c: sram@1d0 {
> >> + compatible = "mmio-sram";
> >> + reg = <0x01d0 0x8>;
> >
> > How was this address derived? Did you check that there is actually SRAM
> > here?
>
> Yes, I did some checking (mmap). But I repeated measurement and found
> mirrored regions:
>
> - SRAM_C is mirrored from 0x_4000 (primary location) to 0x01d0_4000 (size
> 0xb000)
>(probably exact size is 0xb0c0)
> - rest of 0x01d0_ are discontinuously filled with R/W register sets
>(probably some internals registers from VE) that I thought to be SRAM too
> - register SRAM_CTRL_REG0==0x01c00_ (value 0x7fff_) switch whole
>region 0x01d0_-0x01df_ __AND__ 0x_4000-0x_
> - VE/cedrus code use this regions indirectly
>(VE_AVC_SRAM_PORT_OFFSET/VE_AVC_SRAM_PORT_DATA...)
>and it is not influenced by "true" SRAM mapping or size
Could you add this to your commit log? That would make the information
available to others, and you could mention that you only added the
location that is contiguous SRAM without the interspersed registers.
So based on this, and what we've seen with the H616, I'm guessing
0x01d0_ - 0x01df_ exposes all the internal guts of the VE,
while SRAM C @ 0x4000 just maps a small portion out.
> -> so I suppose to better use only SRAM_C lower definition:
Yes that would be more appropriate, as it matches the manual, and as you
mentioned, is *real* SRAM.
> ---
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
> b/arch/arm/boot/dts/sun8i-v3s.dtsi
> index e8f304125e2d..90d703e5b73b 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -162,17 +162,17 @@ syscon: system-control@1c0 {
> #size-cells = <1>;
> ranges;
>
> - sram_c: sram@1d0 {
> + sram_c: sram@4000 {
> compatible = "mmio-sram";
> - reg = <0x01d0 0x8>;
> + reg = <0x4000 0xb000>;
> #address-cells = <1>;
> #size-cells = <1>;
> - ranges = <0 0x01d0 0x8>;
> + ranges = <0 0 0x4000 0xb000>;
>
> ve_sram: sram-section@0 {
> compatible =
> "allwinner,sun8i-v3s-sram-c1",
>
> "allwinner,sun4i-a10-sram-c1";
> - reg = <0x00 0x8>;
> + reg = <0x0 0xb000>;
> };
> };
> };
> ---
>
> Does someone have accessible specific documentation of VE/cedrus for V3s ?
I doubt such information exists.
Regards
ChenYu
> Regards, Martin
>
> > ChenYu
> >
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + ranges = <0 0x01d0 0x8>;
> >> +
> >> + ve_sram: sram-section@0 {
> >> + compatible =
> >> "allwinner,sun8i-v3s-sram-c1",
> >> +
> >> "allwinner,sun4i-a10-sram-c1";
> >> + reg = <0x00 0x8>;
> >> + };
> >> + };
> >> };
> >>
> >> tcon0: lcd-controller@1c0c000 {
> >> --
> >> 2.25.1
> >>
> >>
> >> ___
> >> linux-arm-kernel mailing list
> >> linux-arm-ker...@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
Re: [linux-sunxi] Re: [PATCH 7/8] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
On Thu, Dec 3, 2020 at 11:45 PM André Przywara wrote:
>
> On 03/12/2020 15:02, Chen-Yu Tsai wrote:
> > On Thu, Dec 3, 2020 at 6:54 PM André Przywara
> > wrote:
> >>
> >> On 03/12/2020 03:16, Samuel Holland wrote:
> >>
> >> Hi,
> >>
> >>> On 12/2/20 7:54 AM, Andre Przywara wrote:
> >>> ...
> >>>> +soc {
> >>>> +compatible = "simple-bus";
> >>>> +#address-cells = <1>;
> >>>> +#size-cells = <1>;
> >>>> +ranges = <0x0 0x0 0x0 0x4000>;
> >>>> +
> >>>> +syscon: syscon@300 {
> >>>> +compatible = "allwinner,sun50i-h616-system-control",
> >>>> + "allwinner,sun50i-a64-system-control";
> >>>> +reg = <0x0300 0x1000>;
> >>>> +#address-cells = <1>;
> >>>> +#size-cells = <1>;
> >>>> +ranges;
> >>>> +
> >>>> +sram_c: sram@28000 {
> >>>> +compatible = "mmio-sram";
> >>>> +reg = <0x00028000 0x3>;
> >>>> +#address-cells = <1>;
> >>>> +#size-cells = <1>;
> >>>> +ranges = <0 0x00028000 0x3>;
> >>>> +};
> >>>> +
> >>>> +sram_c1: sram@1a0 {
> >>>> +compatible = "mmio-sram";
> >>>> +reg = <0x01a0 0x20>;
> >>>> +#address-cells = <1>;
> >>>> +#size-cells = <1>;
> >>>> +ranges = <0 0x01a0 0x20>;
> >>>> +
> >>>> +ve_sram: sram-section@0 {
> >>>> +compatible =
> >>>> "allwinner,sun50i-h616-sram-c1",
> >>>> +
> >>>> "allwinner,sun4i-a10-sram-c1";
> >>>> +reg = <0x00 0x20>;
> >>>> +};
> >>>> +};
> >>>> +};
> >>>
> >>> You mentioned that you could not find a SRAM A2. How were these SRAM
> >>> ranges
> >>> verified? If you can load eGON.BT0 larger than 32 KiB, then presumably
> >>> NBROM
> >>> uses SRAM C, and it is in the manual, but I see no mention of SRAM C1.
> >>
> >> The manual says that SRAM C *can* be used by "the system", at boot time,
> >> as long as it's configured correctly. I couldn't find any details on how
> >> to switch clock sources for SRAM C, and the manual stanza on this is
> >> quite gibberish. I presume it's configured either by BROM or by reset
> >> default this way. I think the idea is that the later users (VE, DE) take
> >> ownership at some point (which means we can't run any firmware in there).
> >> The BSP boot0 is 48KB already, so reaching into SRAM C, and the code
> >> itself heavily uses SRAM C (found by hacking boot0 to drop to FEL and
> >> inspecting the memory afterwards).
> >>
> >> For C1: I copied this name from the H6 .dtsi, the manual calls this
> >> "VE-SRAM", in both manuals, and the description looks identical there
> >> for both SoCs. I think this will be later used by the video engine, so I
> >> kept it in. The large size made me suspicious, and from former
> >> experiments it looks like being aliased to (parts of) SRAM C.
> >
> > I would just call it sram_ve or ve_sram. SRAM C1 would make more sense if
> > it were part of SRAM C, not the other way around.
>
> But isn't that what we do? "sram_c1" is just the node name alias used
> for the parent node. That is actually never referenced anywhere (in any
> of the the H6 .dts), so we can actually remove it, I guess.
> The actual SRAM section is called ve_sram already.
This is what I had in mind:
syscon: {
sram_c: sram@28000 {
compatible = "mmio-sram";
Re: [linux-sunxi] Re: [PATCH 7/8] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
On Thu, Dec 3, 2020 at 6:54 PM André Przywara wrote:
>
> On 03/12/2020 03:16, Samuel Holland wrote:
>
> Hi,
>
> > On 12/2/20 7:54 AM, Andre Przywara wrote:
> > ...
> >> +soc {
> >> +compatible = "simple-bus";
> >> +#address-cells = <1>;
> >> +#size-cells = <1>;
> >> +ranges = <0x0 0x0 0x0 0x4000>;
> >> +
> >> +syscon: syscon@300 {
> >> +compatible = "allwinner,sun50i-h616-system-control",
> >> + "allwinner,sun50i-a64-system-control";
> >> +reg = <0x0300 0x1000>;
> >> +#address-cells = <1>;
> >> +#size-cells = <1>;
> >> +ranges;
> >> +
> >> +sram_c: sram@28000 {
> >> +compatible = "mmio-sram";
> >> +reg = <0x00028000 0x3>;
> >> +#address-cells = <1>;
> >> +#size-cells = <1>;
> >> +ranges = <0 0x00028000 0x3>;
> >> +};
> >> +
> >> +sram_c1: sram@1a0 {
> >> +compatible = "mmio-sram";
> >> +reg = <0x01a0 0x20>;
> >> +#address-cells = <1>;
> >> +#size-cells = <1>;
> >> +ranges = <0 0x01a0 0x20>;
> >> +
> >> +ve_sram: sram-section@0 {
> >> +compatible =
> >> "allwinner,sun50i-h616-sram-c1",
> >> +
> >> "allwinner,sun4i-a10-sram-c1";
> >> +reg = <0x00 0x20>;
> >> +};
> >> +};
> >> +};
> >
> > You mentioned that you could not find a SRAM A2. How were these SRAM ranges
> > verified? If you can load eGON.BT0 larger than 32 KiB, then presumably NBROM
> > uses SRAM C, and it is in the manual, but I see no mention of SRAM C1.
>
> The manual says that SRAM C *can* be used by "the system", at boot time,
> as long as it's configured correctly. I couldn't find any details on how
> to switch clock sources for SRAM C, and the manual stanza on this is
> quite gibberish. I presume it's configured either by BROM or by reset
> default this way. I think the idea is that the later users (VE, DE) take
> ownership at some point (which means we can't run any firmware in there).
> The BSP boot0 is 48KB already, so reaching into SRAM C, and the code
> itself heavily uses SRAM C (found by hacking boot0 to drop to FEL and
> inspecting the memory afterwards).
>
> For C1: I copied this name from the H6 .dtsi, the manual calls this
> "VE-SRAM", in both manuals, and the description looks identical there
> for both SoCs. I think this will be later used by the video engine, so I
> kept it in. The large size made me suspicious, and from former
> experiments it looks like being aliased to (parts of) SRAM C.
I would just call it sram_ve or ve_sram. SRAM C1 would make more sense if
it were part of SRAM C, not the other way around.
Also the sram-section node would make more sense if it were in sram_c, as
that is the part that gets switched around, not the full region @ 1a0.
ChenYu
> Maybe some guys with more VE knowledge can shine some light on this?
>
> Cheers,
> Andre
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/linux-sunxi/34e5618e-4a3d-9a46-5077-179c82592fce%40arm.com.
Re: [PATCH v3 3/6] ARM: dts: sun8i: v3s: Add node for system control
Hi,
On Mon, Nov 16, 2020 at 8:57 PM Martin Cerveny wrote:
>
> Allwinner V3s has system control and SRAM C1 region similar to H3.
>
> Signed-off-by: Martin Cerveny
> ---
> arch/arm/boot/dts/sun8i-v3s.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
> b/arch/arm/boot/dts/sun8i-v3s.dtsi
> index 0c7341676921..70193512c222 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -161,6 +161,20 @@ syscon: system-control@1c0 {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
> +
> + sram_c: sram@1d0 {
> + compatible = "mmio-sram";
> + reg = <0x01d0 0x8>;
How was this address derived? Did you check that there is actually SRAM here?
ChenYu
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x01d0 0x8>;
> +
> + ve_sram: sram-section@0 {
> + compatible =
> "allwinner,sun8i-v3s-sram-c1",
> +
> "allwinner,sun4i-a10-sram-c1";
> + reg = <0x00 0x8>;
> + };
> + };
> };
>
> tcon0: lcd-controller@1c0c000 {
> --
> 2.25.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[PATCH 3/3] arm64: dts: rockchip: rk3328-roc-cc: Enable analog audio
From: Chen-Yu Tsai
Now that driver support for the RK3328's audio codec, and the plumbing
is defined at the SoC level, we can enable analog audio at the board
level.
Enable analog audio by enabling the codec and the I2S interface
connected and the simple-audio-card that binds them together.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index 697fce709031..19959bfba451 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -104,6 +104,14 @@ user_led: led-1 {
};
};
+_sound {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
{
cpu-supply = <_arm>;
};
@@ -278,6 +286,10 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
_domains {
status = "okay";
--
2.29.2
[PATCH 2/3] arm64: dts: rockchip: rk3328-roc-cc: Enable HDMI audio
From: Chen-Yu Tsai
The RK3328-ROC-CC already has HDMI display output enabled. Now that
audio for the HDMI controller is supported, it can be enabled as well.
Enable the simple-audio-card, and the I2S interface the audio is fed
from.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index b76282e704de..697fce709031 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -161,6 +161,10 @@ {
status = "okay";
};
+_sound {
+ status = "okay";
+};
+
{
status = "okay";
@@ -270,6 +274,10 @@ regulator-state-mem {
};
};
+ {
+ status = "okay";
+};
+
_domains {
status = "okay";
--
2.29.2
