From: Sebastian Kropatsch <seb-dev@mail.de>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: linux-rockchip@lists.infradead.org, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/5] arm64: dts: rockchip: Fix regulators, gmac and naming on NanoPi R6C/R6S
Date: Thu, 20 Jun 2024 23:48:08 +0200 [thread overview]
Message-ID: <dd08df6f-5074-4fc2-909d-1d4f7676b2b3@mail.de> (raw)
In-Reply-To: <2396550.3c9HiEOlIg@diego>
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
next prev parent reply other threads:[~2024-06-20 21:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-12 20:48 [PATCH 0/5] Refactor, fix and improve NanoPi R6 series Sebastian Kropatsch
2024-06-12 20:48 ` [PATCH 1/5] arm64: dts: rockchip: Add common definitions for NanoPi R6C and R6S Sebastian Kropatsch
2024-06-20 18:34 ` Heiko Stübner
2024-06-12 20:48 ` [PATCH 2/5] arm64: dts: rockchip: Fix regulators, gmac and naming on NanoPi R6C/R6S Sebastian Kropatsch
2024-06-20 18:39 ` Heiko Stübner
2024-06-20 21:48 ` Sebastian Kropatsch [this message]
2024-06-12 20:48 ` [PATCH 3/5] arm64: dts: rockchip: Improve LEDs " Sebastian Kropatsch
2024-06-14 15:10 ` kernel test robot
2024-06-20 18:42 ` Heiko Stübner
2024-06-20 21:51 ` Sebastian Kropatsch
2024-06-12 20:48 ` [PATCH 4/5] arm64: dts: rockchip: Enable lower USB3 port " Sebastian Kropatsch
2024-06-12 20:48 ` [PATCH 5/5] arm64: dts: rockchip: Enable GPU " Sebastian Kropatsch
2024-06-13 17:27 ` [PATCH 0/5] Refactor, fix and improve NanoPi R6 series Rob Herring (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dd08df6f-5074-4fc2-909d-1d4f7676b2b3@mail.de \
--to=seb-dev@mail.de \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®