Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon <hidden>
Date: 2017-01-13 16:28:45
Also in:
linux-arm-kernel, linux-mediatek, lkml
On Fri, 13 Jan 2017 17:13:55 +0100 Marek Vasut [off-list ref] wrote:
On 01/13/2017 04:12 PM, Matthias Brugger wrote:quoted
On 13/01/17 15:17, Boris Brezillon wrote:quoted
On Fri, 13 Jan 2017 15:13:29 +0800 Guochun Mao [off-list ref] wrote:quoted
Add Mediatek nor flash node. Signed-off-by: Guochun Mao <redacted> --- arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++ arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++ 2 files changed, 37 insertions(+)diff --git a/arch/arm/boot/dts/mt2701-evb.dtsb/arch/arm/boot/dts/mt2701-evb.dts index 082ca88..85e5ae8 100644--- a/arch/arm/boot/dts/mt2701-evb.dts +++ b/arch/arm/boot/dts/mt2701-evb.dts@@ -24,6 +24,31 @@ }; }; +&nor_flash { + pinctrl-names = "default"; + pinctrl-0 = <&nor_pins_default>; + status = "okay"; + flash@0 { + compatible = "jedec,spi-nor"; + reg = <0>; + }; +}; + +&pio { + nor_pins_default: nor { + pins1 { + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>, + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>, + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>, + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>, + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>, + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>; + drive-strength = <MTK_DRIVE_4mA>; + bias-pull-up; + }; + }; +}; + &uart0 { status = "okay"; };diff --git a/arch/arm/boot/dts/mt2701.dtsib/arch/arm/boot/dts/mt2701.dtsi index bdf8954..1eefce4 100644--- a/arch/arm/boot/dts/mt2701.dtsi +++ b/arch/arm/boot/dts/mt2701.dtsi@@ -227,6 +227,18 @@ status = "disabled"; }; + nor_flash: spi@11014000 { + compatible = "mediatek,mt2701-nor", + "mediatek,mt8173-nor";Why define both here? Is "mediatek,mt8173-nor" really providing a subset of the features supported by "mediatek,mt2701-nor"?I think even if the ip block is the same, we should provide both bindings, just in case in the future we find out that mt2701 has some hidden bug, feature or bug-feature. This way even if we update the driver, we stay compatible with older device tree blobs in the wild. We can drop the mt2701-nor in the bindings definition if you want.
Oh, sorry, I misunderstood. What I meant is that if you want to list/support all possible compatibles, maybe you should just put one compatible in your DT and patch your driver (+ binding doc) to define all of them.
This exactly. We should have a DT compat in the form: compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block"; Then if we find a problem in the future, we can match on the "vendor,<soc>-block" and still support the old DTs.
Not sure it's only in term of whose IP appeared first. My understanding is that it's a way to provide inheritance. For example: "<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>"; or "<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>"; BTW, which one is the oldest between mt8173 and mt2701? :-)