On Fri, Oct 22, 2010 at 3:33 AM, Mike Frysinger <vap...@gentoo.org> wrote: > On Fri, Oct 22, 2010 at 03:25, Grant Likely wrote: >> On Fri, Oct 22, 2010 at 02:41:12AM -0400, Mike Frysinger wrote: >>> On Fri, Oct 22, 2010 at 02:30, Grant Likely wrote: >>> > On Fri, Oct 22, 2010 at 02:01:47AM -0400, Mike Frysinger wrote: >>> >> From: Michael Hennerich <michael.henner...@analog.com> >>> >> >>> >> The gpiolib code does not allow people to do gpio_request() on a GPIO >>> >> once it has already been requested. So make sure we only request the >>> >> pin on the first setup of a SPI device. Otherwise, if you attempts to >>> >> reconfigure a SPI device on the fly (like change bit sizes), the setup >>> >> function incorrectly fails. >>> > >>> > Doesn't that mean that the gpio pin be requested at device probe time >>> > instead of in a function that can be repeatedly called? >>> >>> not sure what you mean. this is a pin specific to a spi slave device. >>> there is no "spi probe" function for spi slave devices, only the "spi >>> setup" function. >> >> The spi master device is responsible for managing its own cs lines, >> and it should know what they are at bfin_spi_probe time. Looking at >> commit d3cc71f7 which reworked the cs_gpio bits, I see that the >> blackfin driver places the gpio information with the slave instance. >> >> One could be argue that the spi_slave can be considered the owner of >> spi ss lines, but that runs counter to current conventions, and >> counter to how I want to implement common infrastructure for handling >> gpio slave select lines. >> >> I see that this patch is a bug fix, and the driver already implements >> bad behaviour, so I have little choice but to pick it up. However, it >> is only a band-aid solution and in the long term it should be >> refactored to store the gpio slave-select lines with the spi_master >> device (probably after some common gpio-slave-select infrastructure is >> put in place). > > i disagree. if any GPIO at all may be used as a CS, how could the SPI > master driver have any idea at all what GPIO a slave might choose to > use ? or who is to say that the GPIO in question is available when > the SPI bus master registers itself if the GPIO sits on a GPIO > expander board (e.g. i2c) and not the SOC ? > > this is information that only the SPI client knows about and that the > slave device is binding to. putting slave information into the master > resources makes no sense to me.
The arguement can be made in either direction. From one perspective, the GPIO is a property of the SPI controller because that is what is responsible for fiddling with the bit (evidenced by the fact that the GPIO number is being stored in controller data). From another perspective it could be seen as a property of the spi_device. However, at some point a convention needs to be chosen, and the SPI layer has tended towards SS lines being a property of the SPI controller; regardless of whether or not it happens to be a GPIO line. It isn't a critical issue now, but it will become more important when the GPIO SS line handling is generalized so that the individual drivers can be simplified. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
