From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Subject: Re: [PATCH v3] spi: orion.c: Add direct access mode Date: Wed, 13 Apr 2016 13:40:00 +0200 Message-ID: <570E3010.10309@denx.de> References: <1460030811-13787-1-git-send-email-sr@denx.de> <20160411105740.GB3351@sirena.org.uk> <570CDF5F.9070106@denx.de> <20160412192736.GC14664@sirena.org.uk> <570DD967.8010703@denx.de> <20160413055946.GH14664@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Thomas Petazzoni , Gregory CLEMENT , Andrew Lunn , Arnd Bergmann To: Mark Brown Return-path: In-Reply-To: <20160413055946.GH14664-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> Sender: linux-spi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: On 13.04.2016 07:59, Mark Brown wrote: > On Wed, Apr 13, 2016 at 07:30:15AM +0200, Stefan Roese wrote: >> On 12.04.2016 21:27, Mark Brown wrote: > >>> Writing something in the DT won't magically configure anything in the >>> hardware which is (as I said) the bit I'm missing. > >> The MBus driver (drivers/bus/mvebu-mbus.c) takes care of the MBus >> window mapping. This is done, if the board dts files has one (or >> multiple) entries for the SPI device(s) added to the 'ranges' >> property of the 'soc' node. > > I'm still unclear how mapping the windows in results in connecting the > windows to the SPI block. This is a hardware (SoC) specific mapping. For example the Armada XP lists in "Table 6: CPU Interface Mbus Decoding Units IDs and Attributes" of its Functional Specification Manual, that the SPI controller has the "Target Unit ID" 0x1. And that "Attributes[7:0]" need to get configured to these values for the SPI controller SPI chip-selects: 0x5E = SPI0 CS1 request 0x9E = SPI0 CS2 request 0xDE = SPI0 CS3 request 0x1F = SPI0 CS4 request 0x5F = SPI0 CS5 request 0x9F = SPI0 CS6 request 0xDF = SPI0 CS7 request 0x1A = SPI1 CS0 request 0x5A = SPI1 CS1 request 0x9A = SPI1 CS2 request 0xDA = SPI1 CS3 request 0x1B = SPI1 CS4 request 0x5B = SPI1 CS5 request 0x9B = SPI1 CS6 request 0xDB = SPI1 CS7 request Because of this, I've added these values to the Armada XP-370 dtsi file: spi0: spi@10600 { - reg = ; + reg = ; /* CS7 */ ... spi1: spi@10680 { - reg = ; + reg = ; /* CS7 */ The first value of the MBUS_ID macro representing the 'target' from the manual and the 2nd one the 'attribute'. These 'target' and 'attribute' values may vary between different Marvell SoCs. Please take a look at Documentation/devicetree/bindings/bus/mvebu-mbus.txt as this describes the mbus driver and its bindings and usage quite good. > It also seems like we need to document what > the meaning of the reg properties of the device is, it's all very well > saying that there's a generic MBus binding but we still need to say how > the device will interpret the MBus windows that it has (assuming they > are configured to specific hardware functions transparently). Should I add something to the bindings documentation of the orion-spi driver? With an example of how this direct mode can is enabled on a specific board for e.g. SPI0-DEV1? Or what do you think is missing in the mbus bindings documentation I mentioned above? Thanks, Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html