All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shawn Lin <shawn.lin@rock-chips.com>
To: Klaus Goger <klaus.goger@theobroma-systems.com>
Cc: shawn.lin@rock-chips.com, "Mark Rutland" <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, "Heiko Stübner" <heiko@sntech.de>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org, kever.yang@rock-chips.com,
	linux-rockchip@lists.infradead.org,
	"Rob Herring" <robh+dt@kernel.org>,
	"Philipp Tomsich" <philipp.tomsich@theobroma-systems.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4/4] arm64: dts: add RK3399-Q7 (Puma) SoM
Date: Thu, 29 Jun 2017 08:14:53 +0800	[thread overview]
Message-ID: <8319b665-dd0d-36fc-999d-f4ae1afbd38b@rock-chips.com> (raw)
In-Reply-To: <8378C275-0F65-4B91-A9B8-23E78799F7E5@theobroma-systems.com>

Hi

On 2017/6/28 22:01, Klaus Goger wrote:
> Hi Shawn,
> 
>> On 28 Jun 2017, at 14:41, Shawn Lin <shawn.lin@rock-chips.com> wrote:
>>

--8<-----------

>>>
>>>> +&pcie0 {
>>>> +	ep-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
>>>> +	num-lanes = <4>;
>>>> +	pinctrl-names = "default";
>>>> +	pinctrl-0 = <&pcie_clkreqn>;
>>>> +	status = "okay";
>>>
>>> vpcie{3v3, 1v8, 0v9}-supply properties?
>>
>> These supply are optional which depend on the HW design.
>> But pcie_clkreqn doesn't really work. I think we should
>> use pcie_clkreqn_cpm instead and fix this for rk3399-evb.dts
>> to prevent the further copy-n-paste.
> 
> I could add the supply properties but since they where optional and
> are generated by dedicated always-on regulators supplied from the
> also always on regulator vcc3v3_sys I didn’t see the need for it.
> But if anyone to have a full model of the power tree visible in the
> devicetree even if not controllable I can add it in v2.

Ok, so you don't need to add these here. :)

> 
> Since the properties are optional maybe we should also change
> the dev_info "no xxx regulator found” in pcie-rockchip.c to something
> less severe sounding.
> 
>>>> +};
>>>> +
>>>
>>> [...]
>>>
>>>> +&sdmmc {
>>>> +	clock-frequency = <150000000>;
>>
>> we deprecates this now, so please use max-frequency instead.
>>
>>>> +	bus-width = <4>;
>>>> +	cap-mmc-highspeed;
>>>> +	cap-sd-highspeed;
>>>> +	cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
>>
>> Really this board use gpio-based card detect pin?
>>
>>>> +	wp-gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_LOW>;
>>>> +	num-slots = <1>;
>>>> +	pinctrl-names = "default";
>>>> +	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_gpio &sdmmc_bus4>;
>>
>> I guess you don't need sdmmc_gpio and let mmc core request
>> this gpio as irq pin from parsing cd-gpios?
> 
> I tried to just use the PA7 as SDMMC0_DET but didn’t get any state changes when

Hmm.. we use PA7 as SDMMC0_DET for vendor kernel 4.4.
I guess something goes wrong here and will check if later.

> removing it or pugging it in after bootup. I tried to follow the mmc code path to see
> which of the 3 card detection modes get configured. It looked to me as the CDETECT
> register gets used but this would not generate any interrupts and requires polling of the
> register. So not using a a gpio card detect requires the broken-cd property for me.
> If i overlooked something I’m happy to change it, I was planning to take a look at it later
> anyways
> 
>>
>>>> +	status = "okay";
>>>> +};
>>
>> And I would be more happy here to see the present of vqmmc and vmmc
>> supply if possible.
> 
> Since we are a SoM vmmc would be a property required to be provided from the baseboard
> and not part of the module dts.
> I will add vqmmc for the I/O voltage supplying APIO#

good to know that.

> 
>>>> +
>>>> +
>>>
>>> double empty line
>>>
>>>
>>>> +&spi1 {
>>>> +	status = "okay";
>>>> +
>>>> +	flash: norflash@0 {
>>>
>>> norflash: flash@0 maybe?
>>>
>>> You reference the phandle and at the position it gets referenced
>>> the specific name might be more helpful.
>>>
>>>
>>>> +		compatible = "jedec,spi-nor";
>>>> +		reg = <0>;
>>>> +		spi-max-frequency = <50000000>;
>>>> +	};
>>>> +};
>>>
>>>
>>>
>>>> +&pinctrl {
>>>> +	pinctrl-names = "default";
>>>> +	pinctrl-0 = <&puma_pin_hog>;
>>>> +
>>>> +	hog {
>>>> +			puma_pin_hog: puma_pin_hog {
>>>
>>> puma_pin_hog: puma-pin-hog
>>>
>>> Same for more defined pinctrl nodes below that.
>>>
>>>
>>> Heiko
>>>
>>> _______________________________________________
>>> Linux-rockchip mailing list
>>> Linux-rockchip@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>>>
>>
>>
>> -- 
>> Best Regards
>> Shawn Lin
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 

WARNING: multiple messages have this Message-ID (diff)
From: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
To: Klaus Goger
	<klaus.goger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
Cc: shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	"Mark Rutland" <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
	"Catalin Marinas" <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
	"Will Deacon" <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kever.yang-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	"Rob Herring" <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"Philipp Tomsich"
	<philipp.tomsich-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 4/4] arm64: dts: add RK3399-Q7 (Puma) SoM
Date: Thu, 29 Jun 2017 08:14:53 +0800	[thread overview]
Message-ID: <8319b665-dd0d-36fc-999d-f4ae1afbd38b@rock-chips.com> (raw)
In-Reply-To: <8378C275-0F65-4B91-A9B8-23E78799F7E5-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>

Hi

On 2017/6/28 22:01, Klaus Goger wrote:
> Hi Shawn,
> 
>> On 28 Jun 2017, at 14:41, Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
>>

--8<-----------

>>>
>>>> +&pcie0 {
>>>> +	ep-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
>>>> +	num-lanes = <4>;
>>>> +	pinctrl-names = "default";
>>>> +	pinctrl-0 = <&pcie_clkreqn>;
>>>> +	status = "okay";
>>>
>>> vpcie{3v3, 1v8, 0v9}-supply properties?
>>
>> These supply are optional which depend on the HW design.
>> But pcie_clkreqn doesn't really work. I think we should
>> use pcie_clkreqn_cpm instead and fix this for rk3399-evb.dts
>> to prevent the further copy-n-paste.
> 
> I could add the supply properties but since they where optional and
> are generated by dedicated always-on regulators supplied from the
> also always on regulator vcc3v3_sys I didn’t see the need for it.
> But if anyone to have a full model of the power tree visible in the
> devicetree even if not controllable I can add it in v2.

Ok, so you don't need to add these here. :)

> 
> Since the properties are optional maybe we should also change
> the dev_info "no xxx regulator found” in pcie-rockchip.c to something
> less severe sounding.
> 
>>>> +};
>>>> +
>>>
>>> [...]
>>>
>>>> +&sdmmc {
>>>> +	clock-frequency = <150000000>;
>>
>> we deprecates this now, so please use max-frequency instead.
>>
>>>> +	bus-width = <4>;
>>>> +	cap-mmc-highspeed;
>>>> +	cap-sd-highspeed;
>>>> +	cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
>>
>> Really this board use gpio-based card detect pin?
>>
>>>> +	wp-gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_LOW>;
>>>> +	num-slots = <1>;
>>>> +	pinctrl-names = "default";
>>>> +	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_gpio &sdmmc_bus4>;
>>
>> I guess you don't need sdmmc_gpio and let mmc core request
>> this gpio as irq pin from parsing cd-gpios?
> 
> I tried to just use the PA7 as SDMMC0_DET but didn’t get any state changes when

Hmm.. we use PA7 as SDMMC0_DET for vendor kernel 4.4.
I guess something goes wrong here and will check if later.

> removing it or pugging it in after bootup. I tried to follow the mmc code path to see
> which of the 3 card detection modes get configured. It looked to me as the CDETECT
> register gets used but this would not generate any interrupts and requires polling of the
> register. So not using a a gpio card detect requires the broken-cd property for me.
> If i overlooked something I’m happy to change it, I was planning to take a look at it later
> anyways
> 
>>
>>>> +	status = "okay";
>>>> +};
>>
>> And I would be more happy here to see the present of vqmmc and vmmc
>> supply if possible.
> 
> Since we are a SoM vmmc would be a property required to be provided from the baseboard
> and not part of the module dts.
> I will add vqmmc for the I/O voltage supplying APIO#

good to know that.

> 
>>>> +
>>>> +
>>>
>>> double empty line
>>>
>>>
>>>> +&spi1 {
>>>> +	status = "okay";
>>>> +
>>>> +	flash: norflash@0 {
>>>
>>> norflash: flash@0 maybe?
>>>
>>> You reference the phandle and at the position it gets referenced
>>> the specific name might be more helpful.
>>>
>>>
>>>> +		compatible = "jedec,spi-nor";
>>>> +		reg = <0>;
>>>> +		spi-max-frequency = <50000000>;
>>>> +	};
>>>> +};
>>>
>>>
>>>
>>>> +&pinctrl {
>>>> +	pinctrl-names = "default";
>>>> +	pinctrl-0 = <&puma_pin_hog>;
>>>> +
>>>> +	hog {
>>>> +			puma_pin_hog: puma_pin_hog {
>>>
>>> puma_pin_hog: puma-pin-hog
>>>
>>> Same for more defined pinctrl nodes below that.
>>>
>>>
>>> Heiko
>>>
>>> _______________________________________________
>>> Linux-rockchip mailing list
>>> Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>>>
>>
>>
>> -- 
>> Best Regards
>> Shawn Lin
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: shawn.lin@rock-chips.com (Shawn Lin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] arm64: dts: add RK3399-Q7 (Puma) SoM
Date: Thu, 29 Jun 2017 08:14:53 +0800	[thread overview]
Message-ID: <8319b665-dd0d-36fc-999d-f4ae1afbd38b@rock-chips.com> (raw)
In-Reply-To: <8378C275-0F65-4B91-A9B8-23E78799F7E5@theobroma-systems.com>

Hi

On 2017/6/28 22:01, Klaus Goger wrote:
> Hi Shawn,
> 
>> On 28 Jun 2017, at 14:41, Shawn Lin <shawn.lin@rock-chips.com> wrote:
>>

--8<-----------

>>>
>>>> +&pcie0 {
>>>> +	ep-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
>>>> +	num-lanes = <4>;
>>>> +	pinctrl-names = "default";
>>>> +	pinctrl-0 = <&pcie_clkreqn>;
>>>> +	status = "okay";
>>>
>>> vpcie{3v3, 1v8, 0v9}-supply properties?
>>
>> These supply are optional which depend on the HW design.
>> But pcie_clkreqn doesn't really work. I think we should
>> use pcie_clkreqn_cpm instead and fix this for rk3399-evb.dts
>> to prevent the further copy-n-paste.
> 
> I could add the supply properties but since they where optional and
> are generated by dedicated always-on regulators supplied from the
> also always on regulator vcc3v3_sys I didn?t see the need for it.
> But if anyone to have a full model of the power tree visible in the
> devicetree even if not controllable I can add it in v2.

Ok, so you don't need to add these here. :)

> 
> Since the properties are optional maybe we should also change
> the dev_info "no xxx regulator found? in pcie-rockchip.c to something
> less severe sounding.
> 
>>>> +};
>>>> +
>>>
>>> [...]
>>>
>>>> +&sdmmc {
>>>> +	clock-frequency = <150000000>;
>>
>> we deprecates this now, so please use max-frequency instead.
>>
>>>> +	bus-width = <4>;
>>>> +	cap-mmc-highspeed;
>>>> +	cap-sd-highspeed;
>>>> +	cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
>>
>> Really this board use gpio-based card detect pin?
>>
>>>> +	wp-gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_LOW>;
>>>> +	num-slots = <1>;
>>>> +	pinctrl-names = "default";
>>>> +	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_gpio &sdmmc_bus4>;
>>
>> I guess you don't need sdmmc_gpio and let mmc core request
>> this gpio as irq pin from parsing cd-gpios?
> 
> I tried to just use the PA7 as SDMMC0_DET but didn?t get any state changes when

Hmm.. we use PA7 as SDMMC0_DET for vendor kernel 4.4.
I guess something goes wrong here and will check if later.

> removing it or pugging it in after bootup. I tried to follow the mmc code path to see
> which of the 3 card detection modes get configured. It looked to me as the CDETECT
> register gets used but this would not generate any interrupts and requires polling of the
> register. So not using a a gpio card detect requires the broken-cd property for me.
> If i overlooked something I?m happy to change it, I was planning to take a look at it later
> anyways
> 
>>
>>>> +	status = "okay";
>>>> +};
>>
>> And I would be more happy here to see the present of vqmmc and vmmc
>> supply if possible.
> 
> Since we are a SoM vmmc would be a property required to be provided from the baseboard
> and not part of the module dts.
> I will add vqmmc for the I/O voltage supplying APIO#

good to know that.

> 
>>>> +
>>>> +
>>>
>>> double empty line
>>>
>>>
>>>> +&spi1 {
>>>> +	status = "okay";
>>>> +
>>>> +	flash: norflash at 0 {
>>>
>>> norflash: flash at 0 maybe?
>>>
>>> You reference the phandle and at the position it gets referenced
>>> the specific name might be more helpful.
>>>
>>>
>>>> +		compatible = "jedec,spi-nor";
>>>> +		reg = <0>;
>>>> +		spi-max-frequency = <50000000>;
>>>> +	};
>>>> +};
>>>
>>>
>>>
>>>> +&pinctrl {
>>>> +	pinctrl-names = "default";
>>>> +	pinctrl-0 = <&puma_pin_hog>;
>>>> +
>>>> +	hog {
>>>> +			puma_pin_hog: puma_pin_hog {
>>>
>>> puma_pin_hog: puma-pin-hog
>>>
>>> Same for more defined pinctrl nodes below that.
>>>
>>>
>>> Heiko
>>>
>>> _______________________________________________
>>> Linux-rockchip mailing list
>>> Linux-rockchip at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>>>
>>
>>
>> -- 
>> Best Regards
>> Shawn Lin
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 

  reply	other threads:[~2017-06-29  0:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170626191854.58253-1-klaus.goger@theobroma-systems.com>
     [not found] ` <20170626191854.58253-5-klaus.goger@theobroma-systems.com>
2017-06-28 10:26   ` [PATCH 4/4] arm64: dts: add RK3399-Q7 (Puma) SoM Heiko Stübner
2017-06-28 10:26     ` Heiko Stübner
2017-06-28 10:26     ` Heiko Stübner
2017-06-28 10:40     ` Dr. Philipp Tomsich
2017-06-28 10:40       ` Dr. Philipp Tomsich
2017-06-28 10:40       ` Dr. Philipp Tomsich
2017-06-28 10:49       ` Heiko Stuebner
2017-06-28 10:49         ` Heiko Stuebner
2017-06-28 10:49         ` Heiko Stuebner
2017-06-28 12:41     ` Shawn Lin
2017-06-28 12:41       ` Shawn Lin
2017-06-28 12:41       ` Shawn Lin
2017-06-28 14:01       ` Klaus Goger
2017-06-28 14:01         ` Klaus Goger
2017-06-28 14:01         ` Klaus Goger
2017-06-29  0:14         ` Shawn Lin [this message]
2017-06-29  0:14           ` Shawn Lin
2017-06-29  0:14           ` Shawn Lin
2017-06-30 22:13   ` Heiko Stuebner
2017-06-30 22:13     ` Heiko Stuebner
2017-06-30 22:13     ` Heiko Stuebner

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=8319b665-dd0d-36fc-999d-f4ae1afbd38b@rock-chips.com \
    --to=shawn.lin@rock-chips.com \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=kever.yang@rock-chips.com \
    --cc=klaus.goger@theobroma-systems.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=philipp.tomsich@theobroma-systems.com \
    --cc=robh+dt@kernel.org \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.