Re: [PATCH 2/5] arm64: dts: rockchip: Fix regulators, gmac and naming on NanoPi R6C/R6S

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

Am 20.06.2024 um 20:39 schrieb Heiko Stübner:
Am Mittwoch, 12. Juni 2024, 22:48:11 CEST schrieb Sebastian Kropatsch:
Fix the alphabetical ordering in some nodes and rename some regulators
and pins to match the schematics [1][2] as well as to adhere to
preferred naming schemes.

General rule of thumb, when you need an "and" in your subject or a list
like the above - you definitly want to split the change into multiple
commits.

Thanks for the advice! I wasn't sure and didn't want to spam the list.
Also, my email provider only allows a limited number of emails to be
sent every day (series with 5 patches, with 9 recipients = 45 emails
sent). So I might have to send the patch series by spanning the
different patches over multiple days.

If anyone knows an email provider which is better suited for this kind
of open source work/mailing lists and is also privacy respecting, please
let me know :)

I will definitely split these changes into separate commits.

In addition to that:
* vcc_3v3_sd_s0: Fix voltage to be 3.3V
* vcc3v3_pcie:
     - Move to NanoPi R6C, this power switch is not available on R6S
     - Fix vin-supply (is vcc_5v0 per schematics)
     - Add gpios/pincrtl to enable power

this defnitly needs its own patch

* vcc5v0_usb: Remove this regulator since according to the schematics,

this too

* vcc5v0_host_20 and vcc5v0_usb_otg0 are directly powered by vcc_5v0

this could be grouped together with the 3.3v change

* gmac1: Add rx_delay of 0 (no delay since phy-mode = "rgmii-rxid")

with rxid mode, why is the rx_delay needed at all?
Shouldn't this just work without the property?

In theory yes, but with the property missing, you'll get a warning
message in dmesg which says:

	Can not read property: rx_delay.
	Set rx_delay to 0x10

So it will set the rx_delay to a value which is not 0, even if rxid
mode is selected. I guess this is something which can be fixed in the
driver, but that may be beyond my abilities.
Setting the rx_delay to 0 gets rid of this warning, so it seems to
be a viable workaround.

* rgmii_phy1: Add phy-supply as seen in schematics

separate patch

* pcie2*:
     - Add pinctrl reset pins
     - Update vpcie3v3-supply to match the schematics

separate patch

* sdhci: Add vmmc-supply and vqmmc-supply

separate patch


Thanks,
Sebastian





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux