| Message ID | 1399035821-25096-4-git-send-email-arun.kk@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Arun, On 02.05.2014 15:03, Arun Kumar K wrote: > Adds support for google peach-pi board having the > Exynos5800 SoC. > > Signed-off-by: Arun Kumar K <arun.kk@samsung.com> > Signed-off-by: Doug Anderson <dianders@chromium.org> > --- > arch/arm/boot/dts/Makefile | 3 +- > arch/arm/boot/dts/exynos5800-peach-pi.dts | 144 +++++++++++++++++++++++++++++ > 2 files changed, 146 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/boot/dts/exynos5800-peach-pi.dts > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 35c146f..efe1573 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -76,7 +76,8 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \ > exynos5420-arndale-octa.dtb \ > exynos5420-smdk5420.dtb \ > exynos5440-sd5v1.dtb \ > - exynos5440-ssdk5440.dtb > + exynos5440-ssdk5440.dtb \ > + exynos5800-peach-pi.dtb > dtb-$(CONFIG_ARCH_HI3xxx) += hi3620-hi4511.dtb > dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \ > ecx-2000.dtb > diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts > new file mode 100644 > index 0000000..e0f8633 > --- /dev/null > +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts > @@ -0,0 +1,144 @@ > +/* > + * Google Peach Pi Rev 10+ board device tree source > + * > + * Copyright (c) 2014 Google, Inc > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +/dts-v1/; > +#include <dt-bindings/input/input.h> > +#include <dt-bindings/gpio/gpio.h> > +#include "exynos5800.dtsi" > + > +/ { > + model = "Google Peach Pi Rev 10+"; > + > + compatible = "google,pi-rev16", > + "google,pi-rev15", "google,pi-rev14", > + "google,pi-rev13", "google,pi-rev12", > + "google,pi-rev11", "google,pi-rev10", > + "google,pi", "google,peach", "samsung,exynos5800", > + "samsung,exynos5"; I can see this board using the "google,peach" compatible string, which is the same as one listed for peach-pit board. Since they are based on different SoCs, are they really compatible? > + > + memory { > + reg = <0 0>; I don't think this is a good idea, because this is basically rendering this dts file useless, unless used with a bootloader that can actually inject correct values. I believe that some generic setup could be provided in the dts, so you could at least get the board running. Otherwise looks good, so after addressing the two comments above feel free to add my Reviewed-by. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomasz, On Fri, May 2, 2014 at 10:10 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote: > Hi Arun, > > > On 02.05.2014 15:03, Arun Kumar K wrote: >> >> Adds support for google peach-pi board having the >> Exynos5800 SoC. >> >> Signed-off-by: Arun Kumar K <arun.kk@samsung.com> >> Signed-off-by: Doug Anderson <dianders@chromium.org> >> --- >> arch/arm/boot/dts/Makefile | 3 +- >> arch/arm/boot/dts/exynos5800-peach-pi.dts | 144 >> +++++++++++++++++++++++++++++ >> 2 files changed, 146 insertions(+), 1 deletion(-) >> create mode 100644 arch/arm/boot/dts/exynos5800-peach-pi.dts >> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile >> index 35c146f..efe1573 100644 >> --- a/arch/arm/boot/dts/Makefile >> +++ b/arch/arm/boot/dts/Makefile >> @@ -76,7 +76,8 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \ >> exynos5420-arndale-octa.dtb \ >> exynos5420-smdk5420.dtb \ >> exynos5440-sd5v1.dtb \ >> - exynos5440-ssdk5440.dtb >> + exynos5440-ssdk5440.dtb \ >> + exynos5800-peach-pi.dtb >> dtb-$(CONFIG_ARCH_HI3xxx) += hi3620-hi4511.dtb >> dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \ >> ecx-2000.dtb >> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts >> b/arch/arm/boot/dts/exynos5800-peach-pi.dts >> new file mode 100644 >> index 0000000..e0f8633 >> --- /dev/null >> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts >> @@ -0,0 +1,144 @@ >> +/* >> + * Google Peach Pi Rev 10+ board device tree source >> + * >> + * Copyright (c) 2014 Google, Inc >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> + */ >> + >> +/dts-v1/; >> +#include <dt-bindings/input/input.h> >> +#include <dt-bindings/gpio/gpio.h> >> +#include "exynos5800.dtsi" >> + >> +/ { >> + model = "Google Peach Pi Rev 10+"; >> + >> + compatible = "google,pi-rev16", >> + "google,pi-rev15", "google,pi-rev14", >> + "google,pi-rev13", "google,pi-rev12", >> + "google,pi-rev11", "google,pi-rev10", >> + "google,pi", "google,peach", "samsung,exynos5800", >> + "samsung,exynos5"; > > > I can see this board using the "google,peach" compatible string, which is > the same as one listed for peach-pit board. Since they are based on > different SoCs, are they really compatible? I'd like to see "google,peach" continue to be here but won't fight too strongly if it's rejected. The pit and pi boards are incredibly similar to each other. They have a 380 point difference in their processor and a few minor peripheral differences, but not a lot else. I could totally imagine some code somewhere wanting to know if this board is compatible with "google,peach" just like you can imagine code somewhere wanting to know if this is compatible with "samsung,exynos5". Potentially you could swap the order of "google,peach" and "samsung,exynos5800" though... >> + >> + memory { >> + reg = <0 0>; > > I don't think this is a good idea, because this is basically rendering this > dts file useless, unless used with a bootloader that can actually inject > correct values. I believe that some generic setup could be provided in the > dts, so you could at least get the board running. I won't say that I care a whole lot, but I think that was what was agreed upon the other day. Specifically Tom Rini of U-Boot was worried about the fact that U-Boot will read the memory node and totally clobber it. He thought there might be cases where someone might _purposely_ not want U-Boot to do that. ...I would wonder what alternate bootloader you're imagining will actually run on this board and not do this? In any case, if people don't like it then we can get rid of it IMHO. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Doug, On 02.05.2014 20:31, Doug Anderson wrote: > Tomasz, > > On Fri, May 2, 2014 at 10:10 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote: >> Hi Arun, >> >> >> On 02.05.2014 15:03, Arun Kumar K wrote: >>> >>> Adds support for google peach-pi board having the >>> Exynos5800 SoC. >>> >>> Signed-off-by: Arun Kumar K <arun.kk@samsung.com> >>> Signed-off-by: Doug Anderson <dianders@chromium.org> >>> --- >>> arch/arm/boot/dts/Makefile | 3 +- >>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 144 >>> +++++++++++++++++++++++++++++ >>> 2 files changed, 146 insertions(+), 1 deletion(-) >>> create mode 100644 arch/arm/boot/dts/exynos5800-peach-pi.dts >>> >>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile >>> index 35c146f..efe1573 100644 >>> --- a/arch/arm/boot/dts/Makefile >>> +++ b/arch/arm/boot/dts/Makefile >>> @@ -76,7 +76,8 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \ >>> exynos5420-arndale-octa.dtb \ >>> exynos5420-smdk5420.dtb \ >>> exynos5440-sd5v1.dtb \ >>> - exynos5440-ssdk5440.dtb >>> + exynos5440-ssdk5440.dtb \ >>> + exynos5800-peach-pi.dtb >>> dtb-$(CONFIG_ARCH_HI3xxx) += hi3620-hi4511.dtb >>> dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \ >>> ecx-2000.dtb >>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts >>> b/arch/arm/boot/dts/exynos5800-peach-pi.dts >>> new file mode 100644 >>> index 0000000..e0f8633 >>> --- /dev/null >>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts >>> @@ -0,0 +1,144 @@ >>> +/* >>> + * Google Peach Pi Rev 10+ board device tree source >>> + * >>> + * Copyright (c) 2014 Google, Inc >>> + * >>> + * This program is free software; you can redistribute it and/or modify >>> + * it under the terms of the GNU General Public License version 2 as >>> + * published by the Free Software Foundation. >>> + */ >>> + >>> +/dts-v1/; >>> +#include <dt-bindings/input/input.h> >>> +#include <dt-bindings/gpio/gpio.h> >>> +#include "exynos5800.dtsi" >>> + >>> +/ { >>> + model = "Google Peach Pi Rev 10+"; >>> + >>> + compatible = "google,pi-rev16", >>> + "google,pi-rev15", "google,pi-rev14", >>> + "google,pi-rev13", "google,pi-rev12", >>> + "google,pi-rev11", "google,pi-rev10", >>> + "google,pi", "google,peach", "samsung,exynos5800", >>> + "samsung,exynos5"; >> >> >> I can see this board using the "google,peach" compatible string, which is >> the same as one listed for peach-pit board. Since they are based on >> different SoCs, are they really compatible? > > I'd like to see "google,peach" continue to be here but won't fight too > strongly if it's rejected. The pit and pi boards are incredibly > similar to each other. They have a 380 point difference in their > processor and a few minor peripheral differences, but not a lot else. > > I could totally imagine some code somewhere wanting to know if this > board is compatible with "google,peach" just like you can imagine code > somewhere wanting to know if this is compatible with > "samsung,exynos5". > > Potentially you could swap the order of "google,peach" and > "samsung,exynos5800" though... > Well, if you can use the device tree of peach-pit board and boot peach-pi and vice-versa and it won't cause any hardware failures then I guess it's fine to keep this string. Not sure about the order, though, as both "google,peach" and "samsung,exynos5800" strings can't really be strictly ordered. IMHO current order is the closest to ideal, as particular family of similar boards is supposedly less generic than all boards based on particular SoC. > >>> + >>> + memory { >>> + reg = <0 0>; >> >> I don't think this is a good idea, because this is basically rendering this >> dts file useless, unless used with a bootloader that can actually inject >> correct values. I believe that some generic setup could be provided in the >> dts, so you could at least get the board running. > > I won't say that I care a whole lot, but I think that was what was > agreed upon the other day. Specifically Tom Rini of U-Boot was > worried about the fact that U-Boot will read the memory node and > totally clobber it. He thought there might be cases where someone > might _purposely_ not want U-Boot to do that. > > ...I would wonder what alternate bootloader you're imagining will > actually run on this board and not do this? People should have the freedom to choose anything they want. We have also barebox and coreboot with ARM and even Exynos5 support (in coreboot), but people might want to use something completely exotic as well and the device tree should let them do so. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 2, 2014 at 7:00 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote: > Well, if you can use the device tree of peach-pit board and boot peach-pi > and vice-versa and it won't cause any hardware failures then I guess it's > fine to keep this string. I believe you can actually make it a good portion of the way through boot, though a bunch of things (including graphics) won't work. I general I don't think it's all that different from "exynos5". >>> I don't think this is a good idea, because this is basically rendering >>> this >>> dts file useless, unless used with a bootloader that can actually inject >>> correct values. I believe that some generic setup could be provided in >>> the >>> dts, so you could at least get the board running. >> >> >> I won't say that I care a whole lot, but I think that was what was >> agreed upon the other day. Specifically Tom Rini of U-Boot was >> worried about the fact that U-Boot will read the memory node and >> totally clobber it. He thought there might be cases where someone >> might _purposely_ not want U-Boot to do that. >> >> ...I would wonder what alternate bootloader you're imagining will >> actually run on this board and not do this? > > > People should have the freedom to choose anything they want. We have also > barebox and coreboot with ARM and even Exynos5 support (in coreboot), but > people might want to use something completely exotic as well and the device > tree should let them do so. Fair enough. Unless Tom cares about this enough to throw his opinion in here, I guess our answer is that the memory node should have a sane default and we'll expect the bootloader to put something better in if it can properly probe memory. In this case I guess it would be 2GB. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/05/2014 11:17 AM, Doug Anderson wrote: > On Fri, May 2, 2014 at 7:00 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote: >> Well, if you can use the device tree of peach-pit board and boot peach-pi >> and vice-versa and it won't cause any hardware failures then I guess it's >> fine to keep this string. > > I believe you can actually make it a good portion of the way through > boot, though a bunch of things (including graphics) won't work. I > general I don't think it's all that different from "exynos5". > > >>>> I don't think this is a good idea, because this is basically rendering >>>> this >>>> dts file useless, unless used with a bootloader that can actually inject >>>> correct values. I believe that some generic setup could be provided in >>>> the >>>> dts, so you could at least get the board running. >>> >>> >>> I won't say that I care a whole lot, but I think that was what was >>> agreed upon the other day. Specifically Tom Rini of U-Boot was >>> worried about the fact that U-Boot will read the memory node and >>> totally clobber it. He thought there might be cases where someone >>> might _purposely_ not want U-Boot to do that. >>> >>> ...I would wonder what alternate bootloader you're imagining will >>> actually run on this board and not do this? >> >> >> People should have the freedom to choose anything they want. We have also >> barebox and coreboot with ARM and even Exynos5 support (in coreboot), but >> people might want to use something completely exotic as well and the device >> tree should let them do so. > > Fair enough. Unless Tom cares about this enough to throw his opinion > in here, I guess our answer is that the memory node should have a sane > default and we'll expect the bootloader to put something better in if > it can properly probe memory. > > In this case I guess it would be 2GB. So, a memory node that says a size of 0 is a valid and long standing (see PowerPC folks) way of saying "please fill in my memory node value for me" due to any number of reasons for not knowing before hand how much memory there is. Any boot loader which cannot fill in the memory node is going to have problems with the various boards (PowerPC, ARM and other) which say "my memory size is 0, I want this fixed up at run time". The problem I was raising at the ELC BoF is that today we can't just stop overwriting values in the non-zero case as many boards lie about their memory size, in non-zero ways, but no one noticed as they only tested with U-Boot which was performing the fixup.
On Mon, May 5, 2014 at 11:18 AM, Tom Rini <trini@ti.com> wrote: [...] > The problem I was raising at the ELC BoF is that today we can't just > stop overwriting values in the non-zero case as many boards lie about > their memory size, in non-zero ways, but no one noticed as they only > tested with U-Boot which was performing the fixup. So, should we conclude are we stuck being bug-compatible forever? I was hoping to add this logic to the kernel by [1], but of course this won't fly based on the argument you highlighted (as was pointed out by Uwe). [1] https://lkml.org/lkml/2014/5/7/28 Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/08/2014 05:55 PM, Bjorn Andersson wrote: > On Mon, May 5, 2014 at 11:18 AM, Tom Rini <trini@ti.com> wrote: > [...] >> The problem I was raising at the ELC BoF is that today we can't just >> stop overwriting values in the non-zero case as many boards lie about >> their memory size, in non-zero ways, but no one noticed as they only >> tested with U-Boot which was performing the fixup. > > So, should we conclude are we stuck being bug-compatible forever? > > I was hoping to add this logic to the kernel by [1], but of course > this won't fly > based on the argument you highlighted (as was pointed out by Uwe). > > [1] https://lkml.org/lkml/2014/5/7/28 Well, device tree should always win and once passed to the kernel, be correct. If you have control of the kernel but not bootloader, like Uwe says, drop the ATAG support.
On Thu, May 8, 2014 at 3:16 PM, Tom Rini <trini@ti.com> wrote: > On 05/08/2014 05:55 PM, Bjorn Andersson wrote: >> On Mon, May 5, 2014 at 11:18 AM, Tom Rini <trini@ti.com> wrote: >> [...] >>> The problem I was raising at the ELC BoF is that today we can't just >>> stop overwriting values in the non-zero case as many boards lie about >>> their memory size, in non-zero ways, but no one noticed as they only >>> tested with U-Boot which was performing the fixup. >> >> So, should we conclude are we stuck being bug-compatible forever? >> >> I was hoping to add this logic to the kernel by [1], but of course >> this won't fly >> based on the argument you highlighted (as was pointed out by Uwe). >> >> [1] https://lkml.org/lkml/2014/5/7/28 > > Well, device tree should always win and once passed to the kernel, be > correct. If you have control of the kernel but not bootloader, like Uwe > says, drop the ATAG support. Yeah, that would be all nice and dandy, except for the bootloader passing device specific parameters on the command line. Maybe I can recreate enough of the data later on to actually go with that though... Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 35c146f..efe1573 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -76,7 +76,8 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \ exynos5420-arndale-octa.dtb \ exynos5420-smdk5420.dtb \ exynos5440-sd5v1.dtb \ - exynos5440-ssdk5440.dtb + exynos5440-ssdk5440.dtb \ + exynos5800-peach-pi.dtb dtb-$(CONFIG_ARCH_HI3xxx) += hi3620-hi4511.dtb dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \ ecx-2000.dtb diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts new file mode 100644 index 0000000..e0f8633 --- /dev/null +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts @@ -0,0 +1,144 @@ +/* + * Google Peach Pi Rev 10+ board device tree source + * + * Copyright (c) 2014 Google, Inc + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +/dts-v1/; +#include <dt-bindings/input/input.h> +#include <dt-bindings/gpio/gpio.h> +#include "exynos5800.dtsi" + +/ { + model = "Google Peach Pi Rev 10+"; + + compatible = "google,pi-rev16", + "google,pi-rev15", "google,pi-rev14", + "google,pi-rev13", "google,pi-rev12", + "google,pi-rev11", "google,pi-rev10", + "google,pi", "google,peach", "samsung,exynos5800", + "samsung,exynos5"; + + memory { + reg = <0 0>; + }; + + fixed-rate-clocks { + oscclk { + compatible = "samsung,exynos5420-oscclk"; + clock-frequency = <24000000>; + }; + }; + + gpio-keys { + compatible = "gpio-keys"; + + pinctrl-names = "default"; + pinctrl-0 = <&power_key_irq>; + + power { + label = "Power"; + gpios = <&gpx1 2 GPIO_ACTIVE_LOW>; + linux,code = <KEY_POWER>; + gpio-key,wakeup; + }; + }; + + backlight { + compatible = "pwm-backlight"; + pwms = <&pwm 0 1000000 0>; + brightness-levels = <0 100 500 1000 1500 2000 2500 2800>; + default-brightness-level = <7>; + pinctrl-0 = <&pwm0_out>; + pinctrl-names = "default"; + }; +}; + +&pinctrl_0 { + tpm_irq: tpm-irq { + samsung,pins = "gpx1-0"; + samsung,pin-function = <0>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + power_key_irq: power-key-irq { + samsung,pins = "gpx1-2"; + samsung,pin-function = <0>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; +}; + +&rtc { + status = "okay"; +}; + +&serial_3 { + status = "okay"; +}; + +&mmc_0 { + status = "okay"; + num-slots = <1>; + broken-cd; + caps2-mmc-hs200-1_8v; + supports-highspeed; + non-removable; + card-detect-delay = <200>; + clock-frequency = <400000000>; + samsung,dw-mshc-ciu-div = <3>; + samsung,dw-mshc-sdr-timing = <0 4>; + samsung,dw-mshc-ddr-timing = <0 2>; + pinctrl-names = "default"; + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>; + + slot@0 { + reg = <0>; + bus-width = <8>; + }; +}; + +&mmc_2 { + status = "okay"; + num-slots = <1>; + supports-highspeed; + card-detect-delay = <200>; + clock-frequency = <400000000>; + samsung,dw-mshc-ciu-div = <3>; + samsung,dw-mshc-sdr-timing = <2 3>; + samsung,dw-mshc-ddr-timing = <1 2>; + pinctrl-names = "default"; + pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>; + + slot@0 { + reg = <0>; + bus-width = <4>; + }; +}; + +&hsi2c_9 { + status = "okay"; + clock-frequency = <400000>; + + tpm@20 { + compatible = "infineon,slb9645tt"; + reg = <0x20>; + /* Unused irq; but still need to configure the pins */ + pinctrl-names = "default"; + pinctrl-0 = <&tpm_irq>; + }; +}; + +/* + * Use longest HW watchdog in SoC (32 seconds) since the hardware + * watchdog provides no debugging information (compared to soft/hard + * lockup detectors) and so should be last resort. + */ +&watchdog { + timeout-sec = <32>; +};