Am 20.04.19 um 17:46 schrieb Martin Sperl: > >> On 20.04.2019, at 13:08, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> >> This converts the BCM2835 SPI master driver to use GPIO >> descriptors for chip select handling. >> >> The BCM2835 driver was relying on the core to drive the >> CS high/low so very small changes were needed for this >> part. If it managed to request the CS from the device tree >> node, all is pretty straight forward. >> >> However for native GPIOs this driver has a quite unorthodox >> loopback to request some GPIOs from the SoC GPIO chip by >> looking it up from the device tree using gpiochip_find() >> and then offseting hard into its numberspace. This has >> been augmented a bit by using gpiochip_request_own_desc() >> but this code really needs to be verified. If "native CS" >> is actually an SoC GPIO, why is it even done this way? >> Should this GPIO not just be defined in the device tree >> like any other CS GPIO? I'm confused. > It has been done to keep dt-backward compatibility. > > When the driver was written dt had configured native-cs. This is done in a very opaque way. The bcm2835-rpi.dtsi defines a pinmux group alt0 which init SPI pins (including native CS). So we better use spi0_gpio7 (including native CS) or even better create new groups without native CS and use them. Even worse the alt0 group is applied for all the RPi Zero, 1 and 2 boards, but not for the RPi 3 ones. > A native-cs implementation comes with lots of > limitations and some of which - especially dma mode > has some quirks with regards to native-cs (glitches, > deasserts after each finished dma transfer,...) > > The only way to make this work properly was to use > Gpio. So we better extend the current binding with cs-gpios as optional property in order to point the user the right direction. And gave the same warnings like in bcm2835-spi-aux. Stefan > > So to properly support old device-trees with native-cs > this gpio translation is needed, as we should not break > things for old dt... > > Maybe this rational helps... > > Martin >