On 9 May 2012 17:07, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote: > >> +- gpios: The gpio specifier for clock, mosi and miso interface lines (in no >> + particular order). The format of the gpio specifier depends on the gpio >> + controller. > > This seems odd... This isn't a bitbanging controller, and surely the > driver will need to know which signal is which? I suspect this is > actually for pinmux rather than to identify the signals but that should > at least be made clear and really should be being done using the pinmux > API. The driver retrieves the list of gpio's that it is allowed to use. The gpio numbers for miso, mosi and clk are mandatory but the order in which they are specified is not important since the driver never needs to which gpio is which interface line. I agree the pinmux api should be used here, but the call to pinmux api would be a incremental change here, not changing the code this patch is adding. > >> + - samsung,spi-cs-gpio: A gpio specifier that specifies the gpio line used as >> + the slave select line by the spi controller. The format of the gpio >> + specifier depends on the gpio controller. > > We should really have a binding for this at the SPI level (and ideally > some code to manage setting the GPIO too) - it's pretty common to use a > GPIO as /CS. The existing implementations vary in the way the nCS gpio lines are specified. For some controllers, the nCS gpio's are included in the spi device node whereas in this implementation, the nCS gpio is listed in the spi slave device node. Thanks, Thomas. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |