| Message ID | 1432042454-19234-3-git-send-email-javier.martinez@collabora.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 19.05.2015 22:34, Javier Martinez Canillas wrote: > From: Simon Glass <sjg@chromium.org> > > Peach Pit and Pi machines have a SPI flash memory that is used to > store firmware and different system parameters and data. > > Add information about the SPI flash chip so that user-space tools > can access it. > > Signed-off-by: Simon Glass <sjg@chromium.org> > Reviewed-by: Doug Anderson <dianders@chromium.org> > Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> I assume this can go through samsung-soc tree (after documenting new compatible)? The exynos5800-peach-pi.dts and exynos5420-peach-pit.dts have a lot of common nodes. I wonder if there is a common part which could have its own dtsi? Like exynos4412-odroid-common.dtsi? Best regards, Krzysztof
Hello Krzysztof, On 05/20/2015 05:37 AM, Krzysztof Kozlowski wrote: > On 19.05.2015 22:34, Javier Martinez Canillas wrote: >> From: Simon Glass <sjg@chromium.org> >> >> Peach Pit and Pi machines have a SPI flash memory that is used to >> store firmware and different system parameters and data. >> >> Add information about the SPI flash chip so that user-space tools >> can access it. >> >> Signed-off-by: Simon Glass <sjg@chromium.org> >> Reviewed-by: Doug Anderson <dianders@chromium.org> >> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> > > Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> > > I assume this can go through samsung-soc tree (after documenting new > compatible)? > Yes, I mentioned in the cover letter that patch #1 should go through the spi tree and #2-4 through the linux-samsung tree. I can split in two series once I post as proper patches to make it more clear. > The exynos5800-peach-pi.dts and exynos5420-peach-pit.dts have a lot of > common nodes. I wonder if there is a common part which could have its > own dtsi? Like exynos4412-odroid-common.dtsi? > We discussed in the past about having a common .dtsi [0]. I'm not a huge fan of a common .dtsi and I prefer to instead split common dts fragments in a .dtsi that can be included in different dts. That also better reflects what happens at the hw level IMHO since a board may reuse a IP block. Doug Anderson seems to agree with me [1]. > Best regards, > Krzysztof > Best regards, Javier [0]: https://lkml.org/lkml/2014/6/26/271 [1]: https://lkml.org/lkml/2014/6/26/555
On 20.05.2015 19:17, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 05/20/2015 05:37 AM, Krzysztof Kozlowski wrote: >> On 19.05.2015 22:34, Javier Martinez Canillas wrote: >>> From: Simon Glass <sjg@chromium.org> >>> >>> Peach Pit and Pi machines have a SPI flash memory that is used to >>> store firmware and different system parameters and data. >>> >>> Add information about the SPI flash chip so that user-space tools >>> can access it. >>> >>> Signed-off-by: Simon Glass <sjg@chromium.org> >>> Reviewed-by: Doug Anderson <dianders@chromium.org> >>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> >> >> Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> >> >> I assume this can go through samsung-soc tree (after documenting new >> compatible)? >> > > Yes, I mentioned in the cover letter that patch #1 should go through > the spi tree and #2-4 through the linux-samsung tree. I can split in > two series once I post as proper patches to make it more clear. It is fine, don't split it. It is good to see the usage of binding in the same patchset. > >> The exynos5800-peach-pi.dts and exynos5420-peach-pit.dts have a lot of >> common nodes. I wonder if there is a common part which could have its >> own dtsi? Like exynos4412-odroid-common.dtsi? >> > > We discussed in the past about having a common .dtsi [0]. I'm not a > huge fan of a common .dtsi and I prefer to instead split common dts > fragments in a .dtsi that can be included in different dts. > > That also better reflects what happens at the hw level IMHO since a > board may reuse a IP block. Doug Anderson seems to agree with me [1]. Seems reasonable. Best regards, Krzysztof
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts index 146e71118a72..8e88088d6815 100644 --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts @@ -892,6 +892,13 @@ samsung,pin-drv = <2>; }; + spi_flash_cs: spi-flash-cs { + samsung,pins = "gpa2-5"; + samsung,pin-function = <1>; + samsung,pin-pud = <0>; + samsung,pin-drv = <3>; + }; + usb300_vbus_en: usb300-vbus-en { samsung,pins = "gph0-0"; samsung,pin-function = <1>; @@ -921,6 +928,25 @@ clock-names = "rtc", "rtc_src"; }; +&spi_1 { + status = "okay"; + samsung,spi-src-clk = <0>; + num-cs = <1>; + cs-gpios = <&gpa2 5 0>; + + spidev@0 { + compatible = "google,spi-flash"; + reg = <0>; + spi-max-frequency = <50000000>; + pinctrl-names = "default"; + pinctrl-0 = <&spi_flash_cs>; + + controller-data { + samsung,spi-feedback-delay = <2>; + }; + }; +}; + &spi_2 { status = "okay"; num-cs = <1>; diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts index 02eb8b15374f..f2b89991b224 100644 --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts @@ -855,6 +855,13 @@ samsung,pin-drv = <2>; }; + spi_flash_cs: spi-flash-cs { + samsung,pins = "gpa2-5"; + samsung,pin-function = <1>; + samsung,pin-pud = <0>; + samsung,pin-drv = <3>; + }; + usb300_vbus_en: usb300-vbus-en { samsung,pins = "gph0-0"; samsung,pin-function = <1>; @@ -884,6 +891,25 @@ clock-names = "rtc", "rtc_src"; }; +&spi_1 { + status = "okay"; + samsung,spi-src-clk = <0>; + num-cs = <1>; + cs-gpios = <&gpa2 5 0>; + + spidev@0 { + compatible = "google,spi-flash"; + reg = <0>; + spi-max-frequency = <50000000>; + pinctrl-names = "default"; + pinctrl-0 = <&spi_flash_cs>; + + controller-data { + samsung,spi-feedback-delay = <2>; + }; + }; +}; + &spi_2 { status = "okay"; num-cs = <1>;