Re: [PATCH] spi: bcm2835: transform native-cs to gpio-cs on first spi_setup

[Martin Sperl <kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>]

On 2015-04-06 20:10, Mark Brown wrote:
> People adding things to the standard kernel (presumably people push
> their board support in there) would still have to work out which
> chip select corresponds to which GPIO and write that mapping into
> their DT with the corresponding loss of legibility there, and of
> course there's the cost of modifying existing users.
>
> It *would* be nice if the mapping to which pin has which function
> were pushed into the pinctrl driver (and then possibly into the DT
> for it) but generally this seems like something we should be doing
> more of not less of.
>
The foundation gets to a point of using device-tree overlays to minimize
this kind of manual changes - the default still would include CS0=GPIO8
and CS1=GPIO7. If someone needs more CS, then the extra CS needs to get
configured in an overlay overriding those pins - so not a huge
difference

If we add "cs_gpios = <&gpio 8 0> <&gpio 7 0>" to the dtsi or assume it
is native, where this code essentially does what is needed to translate
it to the above.

Just tell me if we need spi_bus_lock on the "change" path to avoid
unpleasant behavior and I will create a patch incorporating that.
Spi_setup can sleep, so we can wait for the bus to become idle before
such a change...

Alternatively we could also add something like:
     int initial_chip_select_setup(int cs, int cspol);
as a method in spi_master that the framework would call prior to
registering all spi_devices with spi_device_register.

In the code for the spi-bcm2835 we can run the native-CS to GPIO
translation.

I could create a patch that handles this.

If you like it as is, merge it.
--
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