* [U-Boot] [PATCH] rockchip: rk3288: dts: remove 'vmmc' from emmc node @ 2018-12-03 3:59 Kever Yang 2018-12-03 11:27 ` Fabio Estevam 0 siblings, 1 reply; 6+ messages in thread From: Kever Yang @ 2018-12-03 3:59 UTC (permalink / raw) To: u-boot The U-Boot eMMC does not need to care about the power for Rockchip SoC, because if the board is using eMMC, the power will default on (for bootrom), and we do not do power management for it like kernel, so the 'vmmc', 'vqmmc' is only useful for SD in U-Boot. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> --- arch/arm/dts/rk3288-evb.dtsi | 2 -- arch/arm/dts/rk3288-firefly.dtsi | 2 -- arch/arm/dts/rk3288-miqi.dtsi | 2 -- arch/arm/dts/rk3288-popmetal.dtsi | 2 -- 4 files changed, 8 deletions(-) diff --git a/arch/arm/dts/rk3288-evb.dtsi b/arch/arm/dts/rk3288-evb.dtsi index ce75bd5d28..04902c0bd3 100644 --- a/arch/arm/dts/rk3288-evb.dtsi +++ b/arch/arm/dts/rk3288-evb.dtsi @@ -150,8 +150,6 @@ num-slots = <1>; pinctrl-names = "default"; pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_pwr>, <&emmc_bus8>; - vmmc-supply = <&vcc_io>; - vqmmc-supply = <&vcc_flash>; status = "okay"; }; diff --git a/arch/arm/dts/rk3288-firefly.dtsi b/arch/arm/dts/rk3288-firefly.dtsi index 2239ab9f59..596b274e81 100644 --- a/arch/arm/dts/rk3288-firefly.dtsi +++ b/arch/arm/dts/rk3288-firefly.dtsi @@ -138,8 +138,6 @@ num-slots = <1>; pinctrl-names = "default"; pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_pwr>, <&emmc_bus8>; - vmmc-supply = <&vcc_io>; - vqmmc-supply = <&vcc_flash>; status = "okay"; }; diff --git a/arch/arm/dts/rk3288-miqi.dtsi b/arch/arm/dts/rk3288-miqi.dtsi index 432f744beb..4be2abdd26 100644 --- a/arch/arm/dts/rk3288-miqi.dtsi +++ b/arch/arm/dts/rk3288-miqi.dtsi @@ -102,8 +102,6 @@ num-slots = <1>; pinctrl-names = "default"; pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_pwr>, <&emmc_bus8>; - vmmc-supply = <&vcc_io>; - vqmmc-supply = <&vcc_flash>; status = "okay"; }; diff --git a/arch/arm/dts/rk3288-popmetal.dtsi b/arch/arm/dts/rk3288-popmetal.dtsi index 63785eb55e..4aab701d5e 100644 --- a/arch/arm/dts/rk3288-popmetal.dtsi +++ b/arch/arm/dts/rk3288-popmetal.dtsi @@ -171,8 +171,6 @@ num-slots = <1>; pinctrl-names = "default"; pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_pwr &emmc_bus8>; - vmmc-supply = <&vcc_io>; - vqmmc-supply = <&vcc_flash>; status = "okay"; }; -- 2.18.0 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* [U-Boot] [PATCH] rockchip: rk3288: dts: remove 'vmmc' from emmc node 2018-12-03 3:59 [U-Boot] [PATCH] rockchip: rk3288: dts: remove 'vmmc' from emmc node Kever Yang @ 2018-12-03 11:27 ` Fabio Estevam 2018-12-04 7:06 ` Kever Yang 0 siblings, 1 reply; 6+ messages in thread From: Fabio Estevam @ 2018-12-03 11:27 UTC (permalink / raw) To: u-boot Hi Kever, On Mon, Dec 3, 2018 at 2:00 AM Kever Yang <kever.yang@rock-chips.com> wrote: > > The U-Boot eMMC does not need to care about the power for Rockchip > SoC, because if the board is using eMMC, the power will default on > (for bootrom), and we do not do power management for it like kernel, > so the 'vmmc', 'vqmmc' is only useful for SD in U-Boot. Devicetree should represent the hardware and should not rely on details of BootROM / kernel / U-Boot. If these supplies are present in the hardware, they should be represented in the devicetree. What is the exact issue you are trying to solve? ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCH] rockchip: rk3288: dts: remove 'vmmc' from emmc node 2018-12-03 11:27 ` Fabio Estevam @ 2018-12-04 7:06 ` Kever Yang 2018-12-04 9:35 ` Philipp Tomsich 0 siblings, 1 reply; 6+ messages in thread From: Kever Yang @ 2018-12-04 7:06 UTC (permalink / raw) To: u-boot Hi Fabio, On 12/03/2018 07:27 PM, Fabio Estevam wrote: > Hi Kever, > > On Mon, Dec 3, 2018 at 2:00 AM Kever Yang <kever.yang@rock-chips.com> wrote: >> The U-Boot eMMC does not need to care about the power for Rockchip >> SoC, because if the board is using eMMC, the power will default on >> (for bootrom), and we do not do power management for it like kernel, >> so the 'vmmc', 'vqmmc' is only useful for SD in U-Boot. > Devicetree should represent the hardware and should not rely on > details of BootROM / kernel / U-Boot. > > If these supplies are present in the hardware, they should be > represented in the devicetree. > > What is the exact issue you are trying to solve? The U-Boot will fail to boot if eMMC driver try to enable the regulator with error return. These two nodes makes the eMMC driver need depends on pmic/regulator driver works good. My case is I have two similar boards, but have different pmic or pmic config, then only the one with correct config can boot successful. I know you would ask me to commit a new dts with correct pmic config, but please note that there are much much more boards then what the upstream already have. We are not possible to add every board, and I don't think we have to. After sync with rockchip eMMC maintainer, we think if a board wants eMMC as main storage, the power will default on, only the SD is the one need to take care about default power. The basic functionality of a boot loader is to load next stage firmware to RAM and boot into it, the only driver mucs work is eMMC(if this is main storage), so that the CPU and eMMC works then we can boot into kernel even if the pmic driver is broken. I understand the Device tree 'should' represent the hardware, but you 'should' know every program has different requirement to dts, many nodes are U-Boot only, and many nodes are kernel only. In this case, I choose not to use these two nodes in U-Boot. Thanks, - Kever > ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCH] rockchip: rk3288: dts: remove 'vmmc' from emmc node 2018-12-04 7:06 ` Kever Yang @ 2018-12-04 9:35 ` Philipp Tomsich 2018-12-04 14:49 ` Heiko Stuebner 0 siblings, 1 reply; 6+ messages in thread From: Philipp Tomsich @ 2018-12-04 9:35 UTC (permalink / raw) To: u-boot Kever, > On 04.12.2018, at 08:06, Kever Yang <kever.yang@rock-chips.com> wrote: > > Hi Fabio, > > > On 12/03/2018 07:27 PM, Fabio Estevam wrote: >> Hi Kever, >> >> On Mon, Dec 3, 2018 at 2:00 AM Kever Yang <kever.yang@rock-chips.com> wrote: >>> The U-Boot eMMC does not need to care about the power for Rockchip >>> SoC, because if the board is using eMMC, the power will default on >>> (for bootrom), and we do not do power management for it like kernel, >>> so the 'vmmc', 'vqmmc' is only useful for SD in U-Boot. >> Devicetree should represent the hardware and should not rely on >> details of BootROM / kernel / U-Boot. >> >> If these supplies are present in the hardware, they should be >> represented in the devicetree. >> >> What is the exact issue you are trying to solve? > > The U-Boot will fail to boot if eMMC driver try to enable the regulator > with error return. > These two nodes makes the eMMC driver need depends on pmic/regulator driver > works good. > My case is I have two similar boards, but have different pmic or pmic > config, > then only the one with correct config can boot successful. > I know you would ask me to commit a new dts with correct pmic config, > but please > note that there are much much more boards then what the upstream already > have. > We are not possible to add every board, and I don't think we have to. These boards should have their own DTS, as that’s the main function of the DTS (i.e. to describe the actual hardware). Why is it not possible to add these boards? Thanks, Philipp. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCH] rockchip: rk3288: dts: remove 'vmmc' from emmc node 2018-12-04 9:35 ` Philipp Tomsich @ 2018-12-04 14:49 ` Heiko Stuebner 2018-12-05 2:13 ` Kever Yang 0 siblings, 1 reply; 6+ messages in thread From: Heiko Stuebner @ 2018-12-04 14:49 UTC (permalink / raw) To: u-boot Am Dienstag, 4. Dezember 2018, 10:35:48 CET schrieb Philipp Tomsich: > Kever, > > > On 04.12.2018, at 08:06, Kever Yang <kever.yang@rock-chips.com> wrote: > > > > Hi Fabio, > > > > > > On 12/03/2018 07:27 PM, Fabio Estevam wrote: > >> Hi Kever, > >> > >> On Mon, Dec 3, 2018 at 2:00 AM Kever Yang <kever.yang@rock-chips.com> wrote: > >>> The U-Boot eMMC does not need to care about the power for Rockchip > >>> SoC, because if the board is using eMMC, the power will default on > >>> (for bootrom), and we do not do power management for it like kernel, > >>> so the 'vmmc', 'vqmmc' is only useful for SD in U-Boot. > >> Devicetree should represent the hardware and should not rely on > >> details of BootROM / kernel / U-Boot. > >> > >> If these supplies are present in the hardware, they should be > >> represented in the devicetree. > >> > >> What is the exact issue you are trying to solve? > > > > The U-Boot will fail to boot if eMMC driver try to enable the regulator > > with error return. > > These two nodes makes the eMMC driver need depends on pmic/regulator driver > > works good. > > My case is I have two similar boards, but have different pmic or pmic > > config, > > then only the one with correct config can boot successful. > > I know you would ask me to commit a new dts with correct pmic config, > > but please > > note that there are much much more boards then what the upstream already > > have. > > We are not possible to add every board, and I don't think we have to. > > These boards should have their own DTS, as that’s the main function of > the DTS (i.e. to describe the actual hardware). > > Why is it not possible to add these boards? I'd also like to have each board represented correctly. I think the main issue for Kever is, that each marketed device (hundreds?) is largely following a reference design for the soc with smallish per- board changes for their relevant features. So I guess the hope is that it will save effort if there is common devicetree/board. While these largely similar dts are somewhat of a concern, on the kernel- side I try to only allow shared files for boards of the same vendor ... aka when it really is safe to assume that everybody knows what really is shared like the Vamrs Ficus+Rock960 or of course the Google-Gru series of devices. Heiko ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCH] rockchip: rk3288: dts: remove 'vmmc' from emmc node 2018-12-04 14:49 ` Heiko Stuebner @ 2018-12-05 2:13 ` Kever Yang 0 siblings, 0 replies; 6+ messages in thread From: Kever Yang @ 2018-12-05 2:13 UTC (permalink / raw) To: u-boot Hi Heiko and Philipp, On 12/04/2018 10:49 PM, Heiko Stuebner wrote: > Am Dienstag, 4. Dezember 2018, 10:35:48 CET schrieb Philipp Tomsich: >> Kever, >> >>> On 04.12.2018, at 08:06, Kever Yang <kever.yang@rock-chips.com> wrote: >>> >>> Hi Fabio, >>> >>> >>> On 12/03/2018 07:27 PM, Fabio Estevam wrote: >>>> Hi Kever, >>>> >>>> On Mon, Dec 3, 2018 at 2:00 AM Kever Yang <kever.yang@rock-chips.com> wrote: >>>>> The U-Boot eMMC does not need to care about the power for Rockchip >>>>> SoC, because if the board is using eMMC, the power will default on >>>>> (for bootrom), and we do not do power management for it like kernel, >>>>> so the 'vmmc', 'vqmmc' is only useful for SD in U-Boot. >>>> Devicetree should represent the hardware and should not rely on >>>> details of BootROM / kernel / U-Boot. >>>> >>>> If these supplies are present in the hardware, they should be >>>> represented in the devicetree. >>>> >>>> What is the exact issue you are trying to solve? >>> The U-Boot will fail to boot if eMMC driver try to enable the regulator >>> with error return. >>> These two nodes makes the eMMC driver need depends on pmic/regulator driver >>> works good. >>> My case is I have two similar boards, but have different pmic or pmic >>> config, >>> then only the one with correct config can boot successful. >>> I know you would ask me to commit a new dts with correct pmic config, >>> but please >>> note that there are much much more boards then what the upstream already >>> have. >>> We are not possible to add every board, and I don't think we have to. >> These boards should have their own DTS, as that’s the main function of >> the DTS (i.e. to describe the actual hardware). >> >> Why is it not possible to add these boards? Theobroma system only have very few boards, so you think every board must have its own dts, because you can maintain all of them. But I can be sure that rk3288 have more than 100 boards, maybe around thousands of them, but only very few boards will send their dts upstream, and many board vendor even don't want to touch the U-Boot. I would update the patch and only touch the evb, and I would like this dts more easy to boot into kernel even if there are some kind of error happen in U-Boot, how do you think? So, no body care about the robust of the U-Boot: The basic functionality of a boot loader is to load next stage firmware to RAM and boot into it, the only driver mucs work is eMMC(if this is main storage), so that the CPU and eMMC works then we can boot into kernel even if the pmic driver is broken. > I'd also like to have each board represented correctly. > > I think the main issue for Kever is, that each marketed device (hundreds?) > is largely following a reference design for the soc with smallish per- > board changes for their relevant features. So I guess the hope is that > it will save effort if there is common devicetree/board. Yes, I add a feature to re-use the kernel dtb and share a per chip common dts for Rockchip private U-Boot, because there are too much cases, and I want the eMMC driver to be more stand alone so that not be affect by other module like pmic. > While these largely similar dts are somewhat of a concern, on the kernel- > side I try to only allow shared files for boards of the same vendor ... aka > when it really is safe to assume that everybody knows what really is shared > like the Vamrs Ficus+Rock960 or of course the Google-Gru series of devices. As I have said, there are much more boards out of mainline and your method can only resolve those already upstream. Thanks, - Kever > > Heiko > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-12-05 2:13 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-12-03 3:59 [U-Boot] [PATCH] rockchip: rk3288: dts: remove 'vmmc' from emmc node Kever Yang 2018-12-03 11:27 ` Fabio Estevam 2018-12-04 7:06 ` Kever Yang 2018-12-04 9:35 ` Philipp Tomsich 2018-12-04 14:49 ` Heiko Stuebner 2018-12-05 2:13 ` Kever Yang
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.