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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
