linux-rockchip.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Johan Jonker <jbx6244@gmail.com>
To: "Uwe Kleine-König" <uwe@kleine-koenig.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Aditya Prayoga" <aditya@kobol.io>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org
Subject: Re: [PATCH v3 2/2] arm64: dts: rockchip: Add basic support for Kobol's Helios64
Date: Wed, 14 Oct 2020 00:41:20 +0200	[thread overview]
Message-ID: <99032f48-c807-def0-e672-7b2c408e1cc3@gmail.com> (raw)
In-Reply-To: <66aa4ffd-15f8-7c45-282e-e3bddc1af421@kleine-koenig.org>

Hi Uwe,

On 10/13/20 10:22 PM, Uwe Kleine-König wrote:
> Hello Johan,
>
> On 10/13/20 7:34 PM, Johan Jonker wrote:
>> Part 1 of 2 missing here.
>
> Please complain to gmail then, given that patch 1 can be found on
>
https://lore.kernel.org/linux-arm-kernel/20201013161340.720403-2-uwe@kleine-koenig.org/.

Will check my spam.

>
>> Submit all patches to all maintainers and mail lists.
>> Don't forget robh+dt !
>
> I'm really surprised you insist here. In my experience Rob (with his
> dt-hat on) is not interested in specifics of the machine files and he
> already acked patch 1.

As rule of the dumb. Keep everybody in that list informed till the last
version. What they do with is not our problem or concern.

>
>> Add a little change log here.
>
> I assume you also didn't get the cover letter?
>
>>> +		fault-led {
>> fault_led: led-0 {}
>>
>> My fault.
>> Change ones more...
>>   # The first form is preferred, but fall back to just 'led' anywhere
in the
>>   # node name to at least catch some child nodes.
>>   "(^led-[0-9a-f]$|led)":
>
> ok, the label isn't necessary, is it?

Not really, for legacy and readability reasons keep it.
Without label both in nodename and as property one has to compare pin
numbers in pinctrl to see which node belong to each other.
Some users may want to add there own functions. With already available
label they can do so.

>
>>> +			label = "helios64:green:status";
>>> +			gpios = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
>>
>>> +			linux,default-trigger = "none";
>>
>> Don't use 'none' for mainline.
>
> Oh, I missed that. Thanks for your persistence.

No thanks.

>
>>> +			default-state = "on";
>>> +		};
>>> +	};
>>> +
>>> +	vcc1v8_sys_s0: vcc1v8-sys-s0 {
>>> +		compatible = "regulator-fixed";
>>> +		regulator-name = "vcc1v8_sys_s0";
>>> +		regulator-always-on;
>>> +		regulator-boot-on;
>>> +		regulator-min-microvolt = <1800000>;
>>> +		regulator-max-microvolt = <1800000>;
>>> +		vin-supply = <&vcc1v8_sys_s3>;
>>> +	};
>>> +
>>> +	vcc3v0_sd: vcc3v0-sd {
>>> +		compatible = "regulator-fixed";
>>> +		regulator-name = "vcc3v0_sd";
>>
>> Doesn't a sd card need a on/off gpio?
>> Could you check the schematics?
>
> Hmm, there is a GPIO. I didn't consider a problem there given that the
> machine logs
>
> 	[   31.708706] vcc3v0_sd: disabling
>
> when there is no SD-card in the slot. Will investigate further.

Let us know...

>
>>> +		pinctrl-names = "default";
>>> +		pinctrl-0 = <&pmic_int_l>;
>>
>> sort
>
> I would expect this is an exception from the sorting rule.
>
> $ git grep pinctrl-names linus/master:arch/arm64/boot/dts/ | wc -l
> 1905
>
> $ git grep -A1 pinctrl-names linus/master:arch/arm64/boot/dts/ | \
>   grep pinctrl-0 | wc -l
> 1412
>
> When grepping over arch/arm64/boot/dts/rockchip the numbers are
> 453 and 445 respectively.
>
> Will use pinctrl-names above pinctrl-0 consistently.

That people in the past blindly followed the manufacturer dts doesn't
make it an exception to the sort rule. Whatever you do, do it consistent.

>
>>> +				regulator-max-microvolt = <1350000>;
>>> +				regulator-min-microvolt = <750000>;
>>
>>
>> The rest has min above max.
>> Exception to the sort rule, not sure what Heiko wants, but keep it every
>> where the same.
>
> OK, most rockchip dts have min before max, will fix up.
>
>>> +	i2c-scl-rising-time-ns = <160>;
>>> +	i2c-scl-falling-time-ns = <30>;
>>
>> sort
>
> I consider it logical to have rise before fall. In 43 of 59 cases in
> arch/arm64/boot/dts/rockchip/ it is done this way.

That people in the past blindly followed the manufacturer dts doesn't
make it an exception to the sort rule. Whatever you do, do it consistent.

>
>>> +	vqmmc-supply = <&vcc1v8_sys_s0>;
>>> +	status = "okay";
>>> +};
>>> +
>>> +&sdmmc {
>>> +	bus-width = <4>;
>>> +	cap-sd-highspeed;
>>
>>> +	cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
>>
>> see regulator?

Little longer version:
See my question at the sd regulator.
We have a pin to detect, but not to switch the regulator.
Haven't looked at the schematics. Just a reminder to check if it's
correct. Let us know..

>
> GPIO0_A7 is the card detect line. I don't understand your question. Is
> it the same as above, i.e. that it should be possible that the SD
> regulator can be disabled?
>
>>> +	disable-wp;
>>> +	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
>>> +	pinctrl-names = "default";
>>> +	vmmc-supply = <&vcc3v0_sd>;
>>> +	vqmmc-supply = <&vcc_sdio_s0>;
>>> +	status = "okay";
>>> +};
>
> Best regards
> Uwe
>

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2020-10-13 22:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-13 16:13 [PATCH v3 0/2] arm64: Add basic support for Kobol's Helios64 Uwe Kleine-König
2020-10-13 16:13 ` [PATCH v3 1/2] dt-bindings: vendor-prefixes: Add kobol prefix Uwe Kleine-König
2020-10-13 16:13 ` [PATCH v3 2/2] arm64: dts: rockchip: Add basic support for Kobol's Helios64 Uwe Kleine-König
2020-10-13 17:34   ` Johan Jonker
2020-10-13 20:22     ` Uwe Kleine-König
2020-10-13 22:41       ` Johan Jonker [this message]
2020-10-14 12:17         ` Robin Murphy

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=99032f48-c807-def0-e672-7b2c408e1cc3@gmail.com \
    --to=jbx6244@gmail.com \
    --cc=aditya@kobol.io \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=uwe@kleine-koenig.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;
as well as URLs for NNTP newsgroup(s).