It has been a while. But now the driver changes for GNSS are upstream,
so we can add support to the KingFisher board. First clean up the 3.3V
regulators as suggested by Geert, then add the node. Further comments in
the individual patches.
Wolfram Sang (2):
arm64: dts: renesas: ulcb-kf: drop duplicate 3.3v regulators
arm64: dts: renesas: ulcb-kf: add node for GNSS
arch/arm64/boot/dts/renesas/ulcb-kf.dtsi | 42 ++++++++----------------
1 file changed, 14 insertions(+), 28 deletions(-)
--
2.39.2
Signed-off-by: Wolfram Sang <[email protected]>
---
Changes since last version:
* use 'reg_3p3v' instead of custom regulator
arch/arm64/boot/dts/renesas/ulcb-kf.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
index 40a5f98c1190..e3cc0e0e73cc 100644
--- a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
@@ -392,6 +392,13 @@ &scif1 {
pinctrl-names = "default";
status = "okay";
+
+ gnss {
+ compatible = "u-blox,neo-m8";
+ reset-gpios = <&gpio_exp_75 6 GPIO_ACTIVE_LOW>;
+ vcc-supply = <®_3p3v>;
+ current-speed = <9600>;
+ };
};
&sdhi3 {
--
2.39.2
Schematics say that all these 3.3v sources are driven by "D3.3V". We
have a regulator for it already in ulcb.dtsi. Use it instead.
Signed-off-by: Wolfram Sang <[email protected]>
---
Following a suggestion from Geert[1], let's inherit the 3.3V regulator
from ulcb.dtsi. I kept the other KF regulators because:
- 'hdmi_1v8' is really derived from d3.3v on the KingFisher board. It is
named "T1.8V" in the schematics. Maybe we rename it?
- 'snd_vcc5v' looks like D5V to me. While it seems available on the
connectors, it looks unused on the ULCB. So, keep it KingFisher only.
But maybe rename it to "reg_5v"?
[1] https://lore.kernel.org/r/CAMuHMdXbpBeKNL6QC_vYTrocf7xPcvUBQmoV9vboqVt_ciio+g@mail.gmail.com
Changes since last version:
* new patch
arch/arm64/boot/dts/renesas/ulcb-kf.dtsi | 35 +++++-------------------
1 file changed, 7 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
index 3885ef3454ff..40a5f98c1190 100644
--- a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
@@ -32,13 +32,6 @@ hdmi1_con: endpoint {
};
};
- accel_3v3: regulator-acc-3v3 {
- compatible = "regulator-fixed";
- regulator-name = "accel-3v3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
hdmi_1v8: regulator-hdmi-1v8 {
compatible = "regulator-fixed";
regulator-name = "hdmi-1v8";
@@ -46,20 +39,6 @@ hdmi_1v8: regulator-hdmi-1v8 {
regulator-max-microvolt = <1800000>;
};
- hdmi_3v3: regulator-hdmi-3v3 {
- compatible = "regulator-fixed";
- regulator-name = "hdmi-3v3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- snd_3p3v: regulator-snd_3p3v {
- compatible = "regulator-fixed";
- regulator-name = "snd-3.3v";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
snd_vcc5v: regulator-snd_vcc5v {
compatible = "regulator-fixed";
regulator-name = "snd-vcc5v";
@@ -160,7 +139,7 @@ hdmi@3d {
avdd-supply = <&hdmi_1v8>;
dvdd-supply = <&hdmi_1v8>;
pvdd-supply = <&hdmi_1v8>;
- dvdd-3v-supply = <&hdmi_3v3>;
+ dvdd-3v-supply = <®_3p3v>;
bgvdd-supply = <&hdmi_1v8>;
adi,input-depth = <8>;
@@ -198,8 +177,8 @@ accelerometer@1d {
compatible = "st,lsm9ds0-imu";
reg = <0x1d>;
- vdd-supply = <&accel_3v3>;
- vddio-supply = <&accel_3v3>;
+ vdd-supply = <®_3p3v>;
+ vddio-supply = <®_3p3v>;
};
pcm3168a: audio-codec@44 {
@@ -209,8 +188,8 @@ pcm3168a: audio-codec@44 {
clocks = <&clksndsel>;
clock-names = "scki";
- VDD1-supply = <&snd_3p3v>;
- VDD2-supply = <&snd_3p3v>;
+ VDD1-supply = <®_3p3v>;
+ VDD2-supply = <®_3p3v>;
VCCAD1-supply = <&snd_vcc5v>;
VCCAD2-supply = <&snd_vcc5v>;
VCCDA1-supply = <&snd_vcc5v>;
@@ -221,8 +200,8 @@ gyroscope@6b {
compatible = "st,lsm9ds0-gyro";
reg = <0x6b>;
- vdd-supply = <&accel_3v3>;
- vddio-supply = <&accel_3v3>;
+ vdd-supply = <®_3p3v>;
+ vddio-supply = <®_3p3v>;
};
};
};
--
2.39.2
Hi Wolfram,
On Wed, Jan 17, 2024 at 2:18 PM Wolfram Sang
<[email protected]> wrote:
> Schematics say that all these 3.3v sources are driven by "D3.3V". We
> have a regulator for it already in ulcb.dtsi. Use it instead.
>
> Signed-off-by: Wolfram Sang <[email protected]>
> ---
>
> Following a suggestion from Geert[1], let's inherit the 3.3V regulator
> from ulcb.dtsi. I kept the other KF regulators because:
Thanks for the update!
Reviewed-by: Geert Uytterhoeven <[email protected]>
i.e. will queue in renesas-devel for v6.9.
> - 'hdmi_1v8' is really derived from d3.3v on the KingFisher board. It is
> named "T1.8V" in the schematics. Maybe we rename it?
>
> - 'snd_vcc5v' looks like D5V to me. While it seems available on the
Yes, it's D5 (KF) aka D5.0V (ULCB).
> connectors, it looks unused on the ULCB. So, keep it KingFisher only.
> But maybe rename it to "reg_5v"?
These two can be updated later.
> [1] https://lore.kernel.org/r/CAMuHMdXbpBeKNL6QC_vYTrocf7xPcvUBQmoV9vboqVt_ciio+g@mail.gmail.com
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Wolfram,
On Wed, Jan 17, 2024 at 2:18 PM Wolfram Sang
<[email protected]> wrote:
> Signed-off-by: Wolfram Sang <[email protected]>
> ---
> Changes since last version:
>
> * use 'reg_3p3v' instead of custom regulator
Thanks for the update!
> --- a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> +++ b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> @@ -392,6 +392,13 @@ &scif1 {
> pinctrl-names = "default";
>
> status = "okay";
> +
> + gnss {
> + compatible = "u-blox,neo-m8";
> + reset-gpios = <&gpio_exp_75 6 GPIO_ACTIVE_LOW>;
> + vcc-supply = <®_3p3v>;
> + current-speed = <9600>;
> + };
> };
>
> &sdhi3 {
LGTM, so
Reviewed-by: Geert Uytterhoeven <[email protected]>
Before I queue this, I have one remaining question.
The device is also connected to I2C bus i2c@7 aka AUDIO_S{DA,CL}.
Can it be used over I2C too? Is there some strapping to select the
interface used? I couldn't find that in the documentation.
(It does support clock stretching! ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
> Can it be used over I2C too? Is there some strapping to select the
> interface used? I couldn't find that in the documentation.
It looks to me they both work at the same time. I was able to write and
read via I2C (thus not very meaningful data) while serial port was doing
the real work. I am not aware of a full GNSS implementation supporting
the I2C interface, so I considered it good at that point.
Hi Wolfram,
On Fri, Jan 26, 2024 at 4:05 PM Wolfram Sang
<[email protected]> wrote:
> > Can it be used over I2C too? Is there some strapping to select the
> > interface used? I couldn't find that in the documentation.
>
> It looks to me they both work at the same time. I was able to write and
> read via I2C (thus not very meaningful data) while serial port was doing
> the real work. I am not aware of a full GNSS implementation supporting
> the I2C interface, so I considered it good at that point.
Indeed, drivers/gnss/ seems to have no support for I2C yet.
Queuing in renesas-devel for v6.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
> Indeed, drivers/gnss/ seems to have no support for I2C yet.
Neither does GPSD. But looking again, I found a I2C->virtualSerial
script to do it: https://github.com/MaffooClock/gpsd-i2c
Everything exists! :)