Hello!

I think that those dmesg lines are printed when regulator is not specified in device tree file in sata/ahci node (which is read by sata/ahci driver).

On Sunday 24 July 2022 17:36:06 Tony Dinh wrote:

Hi Pali Hi Stefan,

I find it odd that the Linux kernel regulator does not attempt to enable power to the HDD. Is the purpose of the SATA regulator to power up the port with GPIO (GPIO 15 in this case). The Supply AHCI is not found because there is no power to the port, isn't it?

[ 2.415108] ahci-mvebu f10a8000.sata: supply ahci not found, using dummy regulator [ 2.423601] ahci-mvebu f10a8000.sata: supply phy not found, using dummy regulator

If I boot with stock u-boot and then poke GPIO 15 at u-boot prompt, later I would get the same error in dmesg about "dummy regulator", but the SATA drive is spun up OK. So I guess it has nothing to do with whether the SATA port has powered up. Just something wrong about the regulator code when running with the Armada 385 SoC (or with this board in particular).

Thanks, Tony

On Sun, Jul 24, 2022 at 2:27 AM Pali Rohár pali@kernel.org wrote:

...

On Wednesday 20 July 2022 15:47:55 Tony Dinh wrote:

...

Hi Pali/Marek,

I'm writing u-boot for the Synology DS116 (Armada 385, dual core, 1.8 Ghz). I could not seem to get the DM Regulator to power up the SATA port on this board. I'm using Stefan ./board/Marvell/db-88f6820-gp as the starting point, and using the latest DTS

https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/armada-385-s...

I noticed that the Linux kernel boot log (booted with stock Marvell u-boot) shows "supply ahci not found" error. But I can power up the SATA drive in stock u-boot by poking GPIO 15 (SATA power enable). And it works fine with this combination: stock u-boot, kernel 5.18.6.

[ 2.861061] usb_phy_generic usb3_0_phy: dummy supplies not allowed for exclusive requests [ 2.870173] usb_phy_generic usb3_1_phy: dummy supplies not allowed for exclusive requests [ 2.879296] ahci-mvebu f10a8000.sata: supply ahci not found, using dummy regulator [ 2.887704] ahci-mvebu f10a8000.sata: supply phy not found, using dummy regulator [ 2.896101] ahci-mvebu f10a8000.sata: masking port_map 0x3 -> 0x1 [ 2.902951] ahci-mvebu f10a8000.sata: AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x1 impl platform mode [ 2.912750] ahci-mvebu f10a8000.sata: flags: 64bit ncq sntf led only pmp fbs pio slum part sxs [ 2.923184] scsi host0: ahci-mvebu [ 2.927693] scsi host1: ahci-mvebu [ 2.931935] ata1: SATA max UDMA/133 mmio [mem 0xf10a8000-0xf10a9fff] port 0x100 irq 50 [ 2.940610] ata2: DUMMY

My questions: does DM regulator + DM GPIO work for Armada 38x u-boot? and is the error "ahci-mvebu f10a8000.sata: supply ahci, using dummy regulator" a real error? I've googled this and came across some past related posts from you (Pali and Marek), but it is not apparent what was the solution.

I'm really not sure if DM regulator and DM GPIO is working in U-Boot for Armada 38x. Lot of Armada boards touch pinctrl/gpio registers directory to configure GPIOs, instead of using DM GPIO API.

Stefan, any idea?

...

If you are interested in seeing more info while I'm at my new u-boot prompt (kwboot with the SPL kwb), I can post that followup.

Thanks, Tony

Hi Pali,

I'll get the patch and give it a try.

Thanks, Tony

On Mon, Jul 25, 2022 at 12:13 PM Pali Rohár pali@kernel.org wrote:

On Sunday 24 July 2022 11:27:00 Pali Rohár wrote:

...

On Wednesday 20 July 2022 15:47:55 Tony Dinh wrote:

...

Hi Pali/Marek,

I'm writing u-boot for the Synology DS116 (Armada 385, dual core, 1.8 Ghz). I could not seem to get the DM Regulator to power up the SATA port on this board. I'm using Stefan ./board/Marvell/db-88f6820-gp as the starting point, and using the latest DTS

https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/armada-385-s...

I noticed that the Linux kernel boot log (booted with stock Marvell u-boot) shows "supply ahci not found" error. But I can power up the SATA drive in stock u-boot by poking GPIO 15 (SATA power enable). And it works fine with this combination: stock u-boot, kernel 5.18.6.

[ 2.861061] usb_phy_generic usb3_0_phy: dummy supplies not allowed for exclusive requests [ 2.870173] usb_phy_generic usb3_1_phy: dummy supplies not allowed for exclusive requests [ 2.879296] ahci-mvebu f10a8000.sata: supply ahci not found, using dummy regulator [ 2.887704] ahci-mvebu f10a8000.sata: supply phy not found, using dummy regulator [ 2.896101] ahci-mvebu f10a8000.sata: masking port_map 0x3 -> 0x1 [ 2.902951] ahci-mvebu f10a8000.sata: AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x1 impl platform mode [ 2.912750] ahci-mvebu f10a8000.sata: flags: 64bit ncq sntf led only pmp fbs pio slum part sxs [ 2.923184] scsi host0: ahci-mvebu [ 2.927693] scsi host1: ahci-mvebu [ 2.931935] ata1: SATA max UDMA/133 mmio [mem 0xf10a8000-0xf10a9fff] port 0x100 irq 50 [ 2.940610] ata2: DUMMY

My questions: does DM regulator + DM GPIO work for Armada 38x u-boot? and is the error "ahci-mvebu f10a8000.sata: supply ahci, using dummy regulator" a real error? I've googled this and came across some past related posts from you (Pali and Marek), but it is not apparent what was the solution.

I'm really not sure if DM regulator and DM GPIO is working in U-Boot for Armada 38x. Lot of Armada boards touch pinctrl/gpio registers directory to configure GPIOs, instead of using DM GPIO API.

DM GPIO for A38x is semi-broken. It requires DM pinctrl A38x driver, which is not in U-Boot yet. I implemented it and sent to ML: https://patchwork.ozlabs.org/project/uboot/list/?series=311133&state=*

With this change U-Boot 'gpio' command is working fine on Turris Omnia (A385 board).

It is possible that on other mvebu boards are gpios already working fine without new driver. It depends on initial MPP configuration. Above new pinctrl driver ensures that gpio subsystem set particular pin to GPIO mode (if it is not by default initialized to gpio) prior using it.

...

Stefan, any idea?

...

If you are interested in seeing more info while I'm at my new u-boot prompt (kwboot with the SPL kwb), I can post that followup.

Thanks, Tony

Hello!

On Monday 25 July 2022 17:04:33 Tony Dinh wrote:

Hi Pali,

Great work! I applied the patch and removed the DM Regulator configs, rebuilt, and kwboot it.

Using the improved GPIO command, I discovered my problem was the pins were misconfigured in the DTS include chain, or in the MPP configs somewhere. So the improved GPIO command did the trick :) ... I think we were flying blind with the old GPIO command, never realizing a pin was misconfigured.

If your power supply is controlled by GPIO, then you should define "regulator-gpio" compatible node in device tree with corresponding GPIO. See examples in existing DTS files. This should automatically set GPIO to correct output value without need to call gpio command manually.

DS116> gpio clear mvebu0_15 Warning: Changing mpp15 function from ge0_rxd3 to gpio... gpio: pin mvebu0_15 (gpio 15) value is 0 DS116> gpio set mvebu0_15 gpio: pin mvebu0_15 (gpio 15) value is 1 DS116> scsi reset Reset SCSI scanning bus for devices... Target spinup took 0 ms. SATA link 1 timeout. AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Device 0: (0:0) Vendor: ATA Prod.: HGST HTS721010A9 Rev: JB0O Type: Hard Disk Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)

And verifying that ge0_rxd3 is not used by Ethernet.

You could run 'pinmux status -a' command to verify how is each MPP pin configured.

DS116> ping 192.168.0.220 ethernet@70000 Waiting for PHY auto negotiation to complete........ done Using ethernet@70000 device host 192.168.0.220 is alive

The USB GPIO 26 and 27 were also similarly misconfigured . And now I can power up both USB ports with a clear/set GPIO.

Thanks for an awesome patch in such a short time! Tony

Perfect!

On Mon, Jul 25, 2022 at 1:22 PM Tony Dinh mibodhi@gmail.com wrote:

...

Hi Pali,

I'll get the patch and give it a try.

Thanks, Tony

On Mon, Jul 25, 2022 at 12:13 PM Pali Rohár pali@kernel.org wrote:

...

On Sunday 24 July 2022 11:27:00 Pali Rohár wrote:

...

On Wednesday 20 July 2022 15:47:55 Tony Dinh wrote:

...

Hi Pali/Marek,

I'm writing u-boot for the Synology DS116 (Armada 385, dual core, 1.8 Ghz). I could not seem to get the DM Regulator to power up the SATA port on this board. I'm using Stefan ./board/Marvell/db-88f6820-gp as the starting point, and using the latest DTS

https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/armada-385-s...

I noticed that the Linux kernel boot log (booted with stock Marvell u-boot) shows "supply ahci not found" error. But I can power up the SATA drive in stock u-boot by poking GPIO 15 (SATA power enable). And it works fine with this combination: stock u-boot, kernel 5.18.6.

[ 2.861061] usb_phy_generic usb3_0_phy: dummy supplies not allowed for exclusive requests [ 2.870173] usb_phy_generic usb3_1_phy: dummy supplies not allowed for exclusive requests [ 2.879296] ahci-mvebu f10a8000.sata: supply ahci not found, using dummy regulator [ 2.887704] ahci-mvebu f10a8000.sata: supply phy not found, using dummy regulator [ 2.896101] ahci-mvebu f10a8000.sata: masking port_map 0x3 -> 0x1 [ 2.902951] ahci-mvebu f10a8000.sata: AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x1 impl platform mode [ 2.912750] ahci-mvebu f10a8000.sata: flags: 64bit ncq sntf led only pmp fbs pio slum part sxs [ 2.923184] scsi host0: ahci-mvebu [ 2.927693] scsi host1: ahci-mvebu [ 2.931935] ata1: SATA max UDMA/133 mmio [mem 0xf10a8000-0xf10a9fff] port 0x100 irq 50 [ 2.940610] ata2: DUMMY

My questions: does DM regulator + DM GPIO work for Armada 38x u-boot? and is the error "ahci-mvebu f10a8000.sata: supply ahci, using dummy regulator" a real error? I've googled this and came across some past related posts from you (Pali and Marek), but it is not apparent what was the solution.

I'm really not sure if DM regulator and DM GPIO is working in U-Boot for Armada 38x. Lot of Armada boards touch pinctrl/gpio registers directory to configure GPIOs, instead of using DM GPIO API.

DM GPIO for A38x is semi-broken. It requires DM pinctrl A38x driver, which is not in U-Boot yet. I implemented it and sent to ML: https://patchwork.ozlabs.org/project/uboot/list/?series=311133&state=*

With this change U-Boot 'gpio' command is working fine on Turris Omnia (A385 board).

It is possible that on other mvebu boards are gpios already working fine without new driver. It depends on initial MPP configuration. Above new pinctrl driver ensures that gpio subsystem set particular pin to GPIO mode (if it is not by default initialized to gpio) prior using it.

...

Stefan, any idea?

...

If you are interested in seeing more info while I'm at my new u-boot prompt (kwboot with the SPL kwb), I can post that followup.

Thanks, Tony