rockchip: rk3288-evb: dts: remove 'vmmc' from emmc node

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.

This make U-Boot can boot into kernel even if the pmic driver is broken.

The rk3288-evb dts may be used in many boards using rockchip reference schematic but with little change, so we hope it can be more robust to boot into next stage.

Signed-off-by Kever Yang <[email protected]>

---

Changes in v2:
- only update for rk3288-evb, remove change for other boards.

arch/arm/dts/rk3288-evb.dtsi | 2 --

1 file changed, 2 deletions(-)

arch/arm/dts/rk3288-evb.dtsi +0 -2

index ce75bd5d28..04902c0bd3 100644
@@ -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";
 };
 

Signature · 1 line

2.18.0

+Tom

Quoted 9 lines · Kever Yang

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.

This make U-Boot can boot into kernel even if the pmic driver is broken.

If the PMIC driver is broken, we should fix the PMIC driver. I would feel more comfortable w/o this statement.

Quoted 3 lines

The rk3288-evb dts may be used in many boards using rockchip reference schematic but with little change, so we hope it can be more robust to boot into next stage.

Again, this is not how the DTS should be used. I believe that Heiko, Fabio and I had already highlighted this in comments to the earlier thread.

I am willing to move ahead with these and simply merge them, if either Tom or Simon agree that they are fine with a DTS that describes one board and is then used for incompatible (if they were compatible, this change wasn’t needed) boards...

Quoted 1 line

Signed-off-by Kever Yang <[email protected]>

Reviewed-by Philipp Tomsich <[email protected]>

Quoted 24 lines

---

Changes in v2:
- only update for rk3288-evb, remove change for other boards.

arch/arm/dts/rk3288-evb.dtsi | 2 --

1 file changed, 2 deletions(-)

arch/arm/dts/rk3288-evb.dtsi +0 -2

index ce75bd5d28..04902c0bd3 100644
@@ -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";
 };
 

Signature · 1 line

2.18.0

Hi Philipp,

Quoted 11 lines · Philipp Tomsich

+Tom

Quoted 9 lines · Kever Yang

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.

This make U-Boot can boot into kernel even if the pmic driver is broken.

Quoted 8 lines

If the PMIC driver is broken, we should fix the PMIC driver. I would feel more comfortable w/o this statement.

Quoted 3 lines

The rk3288-evb dts may be used in many boards using rockchip reference schematic but with little change, so we hope it can be more robust to boot into next stage.

Again, this is not how the DTS should be used. I believe that Heiko, Fabio and I had already highlighted this in comments to the earlier thread.

Not sure if you have read my previous mail for answer all your comments,

I do agree DTS should represent the hardware, but please note that the DTS is no kind of standard, and people always choose what they need and add those part in there dts, but not always add all the property and everyone use the same model. I would say there are many boards does not have this 'vmmc-supply’ in there emmc node.

Kever,

Quoted 25 lines · Kever Yang

Hi Philipp,

Quoted 11 lines · Philipp Tomsich

+Tom

Quoted 9 lines · Kever Yang

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.

This make U-Boot can boot into kernel even if the pmic driver is broken.

Quoted 8 lines

If the PMIC driver is broken, we should fix the PMIC driver. I would feel more comfortable w/o this statement.

Quoted 3 lines

The rk3288-evb dts may be used in many boards using rockchip reference schematic but with little change, so we hope it can be more robust to boot into next stage.

Again, this is not how the DTS should be used. I believe that Heiko, Fabio and I had already highlighted this in comments to the earlier thread.

Quoted 7 lines

Not sure if you have read my previous mail for answer all your comments,

I do agree DTS should represent the hardware, but please note that the DTS is no kind of standard, and people always choose what they need and add those part in there dts, but not always add all the property and everyone use the same model. I would say there are many boards does not have this 'vmmc-supply’ in there emmc node.

That is exactly the reason why I bumped the decision up the stairs (to Tom and/or Simon): what you are saying makes sense to me (viewed through your eyes and from your specific usecase), but it directly contradicts how the DTS usage is intended.

In other words: Tom (as the top-level decision maker) or Simon (who owns the device-model and therefore will also have an opinion on DTS usage) should make the final call.

Quoted 33 lines · Philipp Tomsich

Kever,

Quoted 24 lines · Kever Yang

Hi Philipp,

Quoted 11 lines · Philipp Tomsich

+Tom

Quoted 9 lines · Kever Yang

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.

This make U-Boot can boot into kernel even if the pmic driver is broken.

Quoted 8 lines

If the PMIC driver is broken, we should fix the PMIC driver. I would feel more comfortable w/o this statement.

Quoted 3 lines

The rk3288-evb dts may be used in many boards using rockchip reference schematic but with little change, so we hope it can be more robust to boot into next stage.

Again, this is not how the DTS should be used. I believe that Heiko, Fabio and I had already highlighted this in comments to the earlier thread.

Quoted 7 lines

Not sure if you have read my previous mail for answer all your comments,

I do agree DTS should represent the hardware, but please note that the DTS is no kind of standard, and people always choose what they need and add those part in there dts, but not always add all the property and everyone use the same model. I would say there are many boards does not have this 'vmmc-supply’ in there emmc node.

Quoted 7 lines

That is exactly the reason why I bumped the decision up the stairs (to Tom and/or Simon): what you are saying makes sense to me (viewed through your eyes and from your specific usecase), but it directly contradicts how the DTS usage is intended.

In other words: Tom (as the top-level decision maker) or Simon (who owns the device-model and therefore will also have an opinion on DTS usage) should make the final call.

My answer is that I would strongly suspect that over in linux "we have N different close-enough boards using this one DTS" isn't acceptable. You make a dtsi and include it from the board and things that aren't common don't go into the dtsi. And yes, when starting off everyone (myself included) copies the reference platform dts and then changes it as needed, and sometimes misses a thing or two. But no, I don't think we want a wrong dts and I'm pretty sure the kernel really wouldn't want wrong dts files and the general goal is that excluding the -u-boot.dtsi files, ours are copies of the kernel.

Hi Tom,

Quoted 41 lines · Tom Rini

Quoted 33 lines · Philipp Tomsich

Kever,

Quoted 24 lines · Kever Yang

Hi Philipp,

Quoted 11 lines · Philipp Tomsich

+Tom

Quoted 9 lines · Kever Yang

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.

This make U-Boot can boot into kernel even if the pmic driver is broken.

Quoted 8 lines

If the PMIC driver is broken, we should fix the PMIC driver. I would feel more comfortable w/o this statement.

Quoted 3 lines

The rk3288-evb dts may be used in many boards using rockchip reference schematic but with little change, so we hope it can be more robust to boot into next stage.

Again, this is not how the DTS should be used. I believe that Heiko, Fabio and I had already highlighted this in comments to the earlier thread.

Quoted 7 lines

Not sure if you have read my previous mail for answer all your comments,

I do agree DTS should represent the hardware, but please note that the DTS is no kind of standard, and people always choose what they need and add those part in there dts, but not always add all the property and everyone use the same model. I would say there are many boards does not have this 'vmmc-supply’ in there emmc node.

Quoted 7 lines

That is exactly the reason why I bumped the decision up the stairs (to Tom and/or Simon): what you are saying makes sense to me (viewed through your eyes and from your specific usecase), but it directly contradicts how the DTS usage is intended.

In other words: Tom (as the top-level decision maker) or Simon (who owns the device-model and therefore will also have an opinion on DTS usage) should make the final call.

Quoted 9 lines

My answer is that I would strongly suspect that over in linux "we have N different close-enough boards using this one DTS" isn't acceptable. You make a dtsi and include it from the board and things that aren't common don't go into the dtsi. And yes, when starting off everyone (myself included) copies the reference platform dts and then changes it as needed, and sometimes misses a thing or two. But no, I don't think we want a wrong dts and I'm pretty sure the kernel really wouldn't want wrong dts files and the general goal is that excluding the -u-boot.dtsi files, ours are copies of the kernel.

I don't think this is a "wrong dts" after my patch, these two nodes are not mark
as required property in kernel, so many dts emmc node does not have it. I check the latest kernel dtsi in arch/arm/boot/dts/rk3288-evb.dtsi [1], the emmc node do not have 'vmmc' and 'vqmmc' while the SD node have, which just like description in my commit message.

Well, I don't know why U-Boot project is so difficult to accept a reasonable patch now, I don't
want to make you unhappy, but make 'every board must have its own dts' in U-Boot to make
every developer to join U-Boot does not make sense to me. The kernel need different
dts for different board because they need to use/control those different feature, but U-Boot
is not the case, U-Boot should work if the storage driver works.

Quoted 54 lines · Kever Yang

Hi Tom,

Quoted 50 lines · Tom Rini

Quoted 33 lines · Philipp Tomsich

Kever,

Quoted 24 lines · Kever Yang

Hi Philipp,

Quoted 11 lines · Philipp Tomsich

+Tom

Quoted 9 lines · Kever Yang

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.

This make U-Boot can boot into kernel even if the pmic driver is broken.

Quoted 8 lines

If the PMIC driver is broken, we should fix the PMIC driver. I would feel more comfortable w/o this statement.

Quoted 3 lines

The rk3288-evb dts may be used in many boards using rockchip reference schematic but with little change, so we hope it can be more robust to boot into next stage.

Again, this is not how the DTS should be used. I believe that Heiko, Fabio and I had already highlighted this in comments to the earlier thread.

Quoted 7 lines

Not sure if you have read my previous mail for answer all your comments,

I do agree DTS should represent the hardware, but please note that the DTS is no kind of standard, and people always choose what they need and add those part in there dts, but not always add all the property and everyone use the same model. I would say there are many boards does not have this 'vmmc-supply’ in there emmc node.

Quoted 7 lines

That is exactly the reason why I bumped the decision up the stairs (to Tom and/or Simon): what you are saying makes sense to me (viewed through your eyes and from your specific usecase), but it directly contradicts how the DTS usage is intended.

In other words: Tom (as the top-level decision maker) or Simon (who owns the device-model and therefore will also have an opinion on DTS usage) should make the final call.

My answer is that I would strongly suspect that over in linux "we have N different close-enough boards using this one DTS" isn't acceptable. You make a dtsi and include it from the board and things that aren't common don't go into the dtsi. And yes, when starting off everyone (myself included) copies the reference platform dts and then changes it as needed, and sometimes misses a thing or two. But no, I don't think we want a wrong dts and I'm pretty sure the kernel really wouldn't want wrong dts files and the general goal is that excluding the -u-boot.dtsi files, ours are copies of the kernel.

Quoted 6 lines

I don't think this is a "wrong dts" after my patch, these two nodes are not mark
as required property in kernel, so many dts emmc node does not have it. I check the latest kernel dtsi in arch/arm/boot/dts/rk3288-evb.dtsi [1], the emmc node do not have 'vmmc' and 'vqmmc' while the SD node have, which just like description in my commit message.

OK. So this would fall into the category of "sync with upstream dts" then, right? That is what we want.

Quoted 9 lines

Well, I don't know why U-Boot project is so difficult to accept a reasonable patch now, I don't
want to make you unhappy, but make 'every board must have its own dts' in U-Boot to make
every developer to join U-Boot does not make sense to me. The kernel need different
dts for different board because they need to use/control those different feature, but U-Boot
is not the case, U-Boot should work if the storage driver works.

Well, here's the thing. If you want U-Boot to then load and pass the correct DTB to the kernel, we need per-board tweaks to the code anyhow to find and load that DTB (see the various "findfdt" environment scripts for example). If you want to rework things so that you have a "generic" type board under U-Boot that's more clearly not tied to any specific board but instead runs on many, that might help clear things up too. Hope this helps!

Quoted 55 lines · Tom Rini

Quoted 54 lines · Kever Yang

Hi Tom,

Quoted 50 lines · Tom Rini

Quoted 33 lines · Philipp Tomsich

Kever,

Quoted 24 lines · Kever Yang

Hi Philipp,

Quoted 11 lines · Philipp Tomsich

+Tom

Quoted 9 lines · Kever Yang

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.

This make U-Boot can boot into kernel even if the pmic driver is broken.

Quoted 8 lines

If the PMIC driver is broken, we should fix the PMIC driver. I would feel more comfortable w/o this statement.

Quoted 3 lines

The rk3288-evb dts may be used in many boards using rockchip reference schematic but with little change, so we hope it can be more robust to boot into next stage.

Again, this is not how the DTS should be used. I believe that Heiko, Fabio and I had already highlighted this in comments to the earlier thread.

Quoted 7 lines

Not sure if you have read my previous mail for answer all your comments,

I do agree DTS should represent the hardware, but please note that the DTS is no kind of standard, and people always choose what they need and add those part in there dts, but not always add all the property and everyone use the same model. I would say there are many boards does not have this 'vmmc-supply’ in there emmc node.

Quoted 7 lines

That is exactly the reason why I bumped the decision up the stairs (to Tom and/or Simon): what you are saying makes sense to me (viewed through your eyes and from your specific usecase), but it directly contradicts how the DTS usage is intended.

In other words: Tom (as the top-level decision maker) or Simon (who owns the device-model and therefore will also have an opinion on DTS usage) should make the final call.

My answer is that I would strongly suspect that over in linux "we have N different close-enough boards using this one DTS" isn't acceptable. You make a dtsi and include it from the board and things that aren't common don't go into the dtsi. And yes, when starting off everyone (myself included) copies the reference platform dts and then changes it as needed, and sometimes misses a thing or two. But no, I don't think we want a wrong dts and I'm pretty sure the kernel really wouldn't want wrong dts files and the general goal is that excluding the -u-boot.dtsi files, ours are copies of the kernel.

Quoted 8 lines

Quoted 6 lines

I don't think this is a "wrong dts" after my patch, these two nodes are not mark
as required property in kernel, so many dts emmc node does not have it. I check the latest kernel dtsi in arch/arm/boot/dts/rk3288-evb.dtsi [1], the emmc node do not have 'vmmc' and 'vqmmc' while the SD node have, which just like description in my commit message.

OK. So this would fall into the category of "sync with upstream dts" then, right? That is what we want.

OK, Got it, 'sync with upstream dts' is a good and acceptable commit message
rather than the real reason why we need the patch.

Philipp,
Do you need me to send out a patch with update the commit message?