[1/2] arm64: dts: sun50i-a64-pinephone: Add AF8133J to PinePhone

Commit Message

Andrey Skvortsov Sept. 8, 2024, 9:47 p.m. UTC

From: Icenowy Zheng <[e-mail]>

New batches of PinePhones switched the magnetometer to AF8133J from
LIS3MDL because lack of ST components.

Both chips use the same PB1 pin, but in different modes.
LIS3MDL uses it as an gpio input to handle interrupt.
AF8133J uses it as an gpio output as a reset signal.

It wasn't possible at runtime to enable both device tree nodes and
detect supported sensor at probe time, because both drivers try to
acquire the same gpio in different modes.

Device tree fixup will be done in firmware without introducing new board
revision and new dts.

Signed-off-by: Icenowy Zheng <[e-mail]>
Signed-off-by: Andrey Skvortsov <[e-mail]>
Link: https://patchwork.ozlabs.org/project/uboot/patch/[e-mail]/

---
 .../boot/dts/allwinner/sun50i-a64-pinephone.dtsi     | 12 ++++++++++++
 1 file changed, 12 insertions(+)

Comments

Chen-Yu Tsai Sept. 9, 2024, 8:08 a.m. UTC | #1

On Mon, Sep 9, 2024 at 5:48 AM Andrey Skvortsov
<[e-mail]> wrote:
>
> From: Icenowy Zheng <[e-mail]>
>
> New batches of PinePhones switched the magnetometer to AF8133J from
> LIS3MDL because lack of ST components.
>
> Both chips use the same PB1 pin, but in different modes.
> LIS3MDL uses it as an gpio input to handle interrupt.
> AF8133J uses it as an gpio output as a reset signal.
>
> It wasn't possible at runtime to enable both device tree nodes and
> detect supported sensor at probe time, because both drivers try to
> acquire the same gpio in different modes.
>
> Device tree fixup will be done in firmware without introducing new board
> revision and new dts.

FYI I've been working on an in-kernel prober [1] for such alternative
components. This does not require firmware support.

[1] https://lore.kernel.org/all/[e-mail]/

> Signed-off-by: Icenowy Zheng <[e-mail]>
> Signed-off-by: Andrey Skvortsov <[e-mail]>
> Link: https://patchwork.ozlabs.org/project/uboot/patch/[e-mail]/
>
> ---
>  .../boot/dts/allwinner/sun50i-a64-pinephone.dtsi     | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> index 6eab61a12cd8f..66fbb35a7fae9 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> @@ -188,6 +188,18 @@ touchscreen@5d {
>  &i2c1 {
>         status = "okay";
>
> +       /* Alternative magnetometer */
> +       af8133j: magnetometer@1c {
> +               compatible = "voltafield,af8133j";
> +               reg = <0x1c>;
> +               reset-gpios = <&pio 1 1 GPIO_ACTIVE_LOW>;
> +               avdd-supply = <&reg_dldo1>;
> +               dvdd-supply = <&reg_dldo1>;
> +
> +               /* status will be fixed up in firmware */
> +               status = "disabled";
> +       };
> +
>         /* Magnetometer */
>         lis3mdl: magnetometer@1e {
>                 compatible = "st,lis3mdl-magn";
> --
> 2.45.2
>

Andrey Skvortsov Sept. 15, 2024, 10:12 a.m. UTC | #2

Hi Chen-Yu Tsai,

On 24-09-09 16:08, Chen-Yu Tsai wrote:
> On Mon, Sep 9, 2024 at 5:48 AM Andrey Skvortsov
> <[e-mail]> wrote:
> >
> > From: Icenowy Zheng <[e-mail]>
> >
> > New batches of PinePhones switched the magnetometer to AF8133J from
> > LIS3MDL because lack of ST components.
> >
> > Both chips use the same PB1 pin, but in different modes.
> > LIS3MDL uses it as an gpio input to handle interrupt.
> > AF8133J uses it as an gpio output as a reset signal.
> >
> > It wasn't possible at runtime to enable both device tree nodes and
> > detect supported sensor at probe time, because both drivers try to
> > acquire the same gpio in different modes.
> >
> > Device tree fixup will be done in firmware without introducing new board
> > revision and new dts.
> 
> FYI I've been working on an in-kernel prober [1] for such alternative
> components. This does not require firmware support.
> 
> [1] https://lore.kernel.org/all/[e-mail]/

Thank you for the information.

I've tried to use in-kernel prober from your v7 patchset [1] on top of
-next and it worked without any changes to firmware.

Since there is still on-going review of your patches it looks like
it's to early to submit my changes for review. But I'm ready to test
your new patches.

[1] https://lore.kernel.org/all/[e-mail]/

Chen-Yu Tsai Oct. 19, 2024, 2:04 a.m. UTC | #3

On Sun, Sep 15, 2024 at 6:12 PM Andrey Skvortsov
<[e-mail]> wrote:
>
> Hi Chen-Yu Tsai,
>
> On 24-09-09 16:08, Chen-Yu Tsai wrote:
> > On Mon, Sep 9, 2024 at 5:48 AM Andrey Skvortsov
> > <[e-mail]> wrote:
> > >
> > > From: Icenowy Zheng <[e-mail]>
> > >
> > > New batches of PinePhones switched the magnetometer to AF8133J from
> > > LIS3MDL because lack of ST components.
> > >
> > > Both chips use the same PB1 pin, but in different modes.
> > > LIS3MDL uses it as an gpio input to handle interrupt.
> > > AF8133J uses it as an gpio output as a reset signal.
> > >
> > > It wasn't possible at runtime to enable both device tree nodes and
> > > detect supported sensor at probe time, because both drivers try to
> > > acquire the same gpio in different modes.
> > >
> > > Device tree fixup will be done in firmware without introducing new board
> > > revision and new dts.
> >
> > FYI I've been working on an in-kernel prober [1] for such alternative
> > components. This does not require firmware support.
> >
> > [1] https://lore.kernel.org/all/[e-mail]/
>
> Thank you for the information.
>
> I've tried to use in-kernel prober from your v7 patchset [1] on top of
> -next and it worked without any changes to firmware.
>
> Since there is still on-going review of your patches it looks like
> it's to early to submit my changes for review. But I'm ready to test
> your new patches.

FYI I'm open to either approach. If the firmware can do it, that is also
fine. I don't know if it makes sense to have both disabled by default
though? That would break existing users, but so would the in-kernel
prober approach, which requires both components be marked as
"fail-needs-probe", and also requires that the kernel driver be enabled.

In other words, I think the firmware approach is friendlier for existing
users that have the original batches.


ChenYu


> [1] https://lore.kernel.org/all/[e-mail]/
>
> --
> Best regards,
> Andrey Skvortsov
>

Andrey Skvortsov Nov. 5, 2024, 7:51 p.m. UTC | #4

Hi Chen-Yu Tsai,

On 24-10-19 10:04, Chen-Yu Tsai wrote:
> On Sun, Sep 15, 2024 at 6:12 PM Andrey Skvortsov
> <[e-mail]> wrote:
> >
> > Hi Chen-Yu Tsai,
> >
> > On 24-09-09 16:08, Chen-Yu Tsai wrote:
> > > On Mon, Sep 9, 2024 at 5:48 AM Andrey Skvortsov
> > > <[e-mail]> wrote:
> > > >
> > > > From: Icenowy Zheng <[e-mail]>
> > > >
> > > > New batches of PinePhones switched the magnetometer to AF8133J from
> > > > LIS3MDL because lack of ST components.
> > > >
> > > > Both chips use the same PB1 pin, but in different modes.
> > > > LIS3MDL uses it as an gpio input to handle interrupt.
> > > > AF8133J uses it as an gpio output as a reset signal.
> > > >
> > > > It wasn't possible at runtime to enable both device tree nodes and
> > > > detect supported sensor at probe time, because both drivers try to
> > > > acquire the same gpio in different modes.
> > > >
> > > > Device tree fixup will be done in firmware without introducing new board
> > > > revision and new dts.
> > >
> > > FYI I've been working on an in-kernel prober [1] for such alternative
> > > components. This does not require firmware support.
> > >
> > > [1] https://lore.kernel.org/all/[e-mail]/
> >
> > Thank you for the information.
> >
> > I've tried to use in-kernel prober from your v7 patchset [1] on top of
> > -next and it worked without any changes to firmware.
> >
> > Since there is still on-going review of your patches it looks like
> > it's to early to submit my changes for review. But I'm ready to test
> > your new patches.
> 
> FYI I'm open to either approach. If the firmware can do it, that is also
> fine. I don't know if it makes sense to have both disabled by default
> though? That would break existing users, but so would the in-kernel
> prober approach, which requires both components be marked as
> "fail-needs-probe", and also requires that the kernel driver be enabled.
> In other words, I think the firmware approach is friendlier for existing
> users that have the original batches.

Current patches leave original magnetometer enabled as before. So only
the new alternative magnetometer is disabled. Firmware prober will set
the correct status. So you are right firmware approach is a bit nicer
for existing users, nothing will change for them with any combination
of kernel and firmware. Let's go with a firmware approach with current
patches then, if nobody 

But I like your in-kernel approach as well. 
JFYI I've applied your v10 patches [1] on top of next-20241105 and retested
it with patches for magnetometer. It's available here [2]. 

1. https://lore.kernel.org/lkml/[e-mail]/#t
2. https://github.com/AndreySV/linux-stable/commits/in-kernel-hwprober-magnetometer/

Chen-Yu Tsai Nov. 6, 2024, 2:31 a.m. UTC | #5

On Wed, Nov 6, 2024 at 3:51 AM Andrey Skvortsov
<[e-mail]> wrote:
>
> Hi Chen-Yu Tsai,
>
> On 24-10-19 10:04, Chen-Yu Tsai wrote:
> > On Sun, Sep 15, 2024 at 6:12 PM Andrey Skvortsov
> > <[e-mail]> wrote:
> > >
> > > Hi Chen-Yu Tsai,
> > >
> > > On 24-09-09 16:08, Chen-Yu Tsai wrote:
> > > > On Mon, Sep 9, 2024 at 5:48 AM Andrey Skvortsov
> > > > <[e-mail]> wrote:
> > > > >
> > > > > From: Icenowy Zheng <[e-mail]>
> > > > >
> > > > > New batches of PinePhones switched the magnetometer to AF8133J from
> > > > > LIS3MDL because lack of ST components.
> > > > >
> > > > > Both chips use the same PB1 pin, but in different modes.
> > > > > LIS3MDL uses it as an gpio input to handle interrupt.
> > > > > AF8133J uses it as an gpio output as a reset signal.
> > > > >
> > > > > It wasn't possible at runtime to enable both device tree nodes and
> > > > > detect supported sensor at probe time, because both drivers try to
> > > > > acquire the same gpio in different modes.
> > > > >
> > > > > Device tree fixup will be done in firmware without introducing new board
> > > > > revision and new dts.
> > > >
> > > > FYI I've been working on an in-kernel prober [1] for such alternative
> > > > components. This does not require firmware support.
> > > >
> > > > [1] https://lore.kernel.org/all/[e-mail]/
> > >
> > > Thank you for the information.
> > >
> > > I've tried to use in-kernel prober from your v7 patchset [1] on top of
> > > -next and it worked without any changes to firmware.
> > >
> > > Since there is still on-going review of your patches it looks like
> > > it's to early to submit my changes for review. But I'm ready to test
> > > your new patches.
> >
> > FYI I'm open to either approach. If the firmware can do it, that is also
> > fine. I don't know if it makes sense to have both disabled by default
> > though? That would break existing users, but so would the in-kernel
> > prober approach, which requires both components be marked as
> > "fail-needs-probe", and also requires that the kernel driver be enabled.
> > In other words, I think the firmware approach is friendlier for existing
> > users that have the original batches.
>
> Current patches leave original magnetometer enabled as before. So only
> the new alternative magnetometer is disabled. Firmware prober will set
> the correct status. So you are right firmware approach is a bit nicer
> for existing users, nothing will change for them with any combination
> of kernel and firmware. Let's go with a firmware approach with current
> patches then, if nobody

If?

I'll wait a day before applying this patch then.

ChenYu

> But I like your in-kernel approach as well.
> JFYI I've applied your v10 patches [1] on top of next-20241105 and retested
> it with patches for magnetometer. It's available here [2].
>
> 1. https://lore.kernel.org/lkml/[e-mail]/#t
> 2. https://github.com/AndreySV/linux-stable/commits/in-kernel-hwprober-magnetometer/
>
> --
> Best regards,
> Andrey Skvortsov

Andrey Skvortsov Nov. 6, 2024, 7:05 a.m. UTC | #6

Hi,

On 24-11-06 10:31, Chen-Yu Tsai wrote:
> On Wed, Nov 6, 2024 at 3:51 AM Andrey Skvortsov
> <[e-mail]> wrote:

> >
> > >
> > > FYI I'm open to either approach. If the firmware can do it, that is also
> > > fine. I don't know if it makes sense to have both disabled by default
> > > though? That would break existing users, but so would the in-kernel
> > > prober approach, which requires both components be marked as
> > > "fail-needs-probe", and also requires that the kernel driver be enabled.
> > > In other words, I think the firmware approach is friendlier for existing
> > > users that have the original batches.
> >
> > Current patches leave original magnetometer enabled as before. So only
> > the new alternative magnetometer is disabled. Firmware prober will set
> > the correct status. So you are right firmware approach is a bit nicer
> > for existing users, nothing will change for them with any combination
> > of kernel and firmware. Let's go with a firmware approach with current
> > patches then, if nobody
> 
> If?
if no one has anything against that.


> I'll wait a day before applying this patch then.
Sure, thanks.

Patch

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index 6eab61a12cd8f..66fbb35a7fae9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -188,6 +188,18 @@  touchscreen@5d {
 &i2c1 {
 	status = "okay";
 
+	/* Alternative magnetometer */
+	af8133j: magnetometer@1c {
+		compatible = "voltafield,af8133j";
+		reg = <0x1c>;
+		reset-gpios = <&pio 1 1 GPIO_ACTIVE_LOW>;
+		avdd-supply = <&reg_dldo1>;
+		dvdd-supply = <&reg_dldo1>;
+
+		/* status will be fixed up in firmware */
+		status = "disabled";
+	};
+
 	/* Magnetometer */
 	lis3mdl: magnetometer@1e {
 		compatible = "st,lis3mdl-magn";