Hello, On Wednesday, June 02, 2010 11:00 AM Jassi Brar wrote:
> On Wed, Jun 2, 2010 at 3:00 PM, Marek Szyprowski > <[email protected]> wrote: > > On Tuesday, June 01, 2010 5:00 PM Grant Likely wrote: > >> On Tue, Jun 1, 2010 at 5:48 AM, Marek Szyprowski > >> <[email protected]> wrote: > >> I'm not convinced this is the best approach. I did look at it, but > >> decided not to merge it yet. It adds code to the hottest path in the > >> spi-gpio driver (not that this driver will ever be fast, but on > >> bit-banged gpio, every instruction counts). > > > > If this is really a problem I can remove the 'if (SPI_{MOSI,MISO}_GPIO != > > SPI_GPIO_NO_{MOSI,MISO})' checks. If we assume that the upper level of > the > > spi framework works correctly, these functions shouldn't be called if > > the pin is set to NO_GPIO (the master device has SPI_MASTER_NO_{TX,RX} > flags > > set). Ok. I've did a research and that SPI_{MOSI,MISO}_GPIO != SPI_GPIO_NO_{MOSI,MISO} checks cannot be easily removed, because in each loop both getmiso() and setmosi() are called by the bitbang_txrx_be_* functions. I also understand that this part of code is really hot and should be optimized as much as possible. > As I pointed in the last thread, such peculiar platforms had better > assign some virtual gpio > for such non-existent miso/mosi, rather than imposing these extra > checks on most of the normal platforms. Creating a virtual gpio bank only for this case is also an overhead imho. GPIO SPI masters without RX line will be used by more than one machine, so some kind of a generic driver is imho needed. Notice that the spi_s3c24xx_gpio.c driver already silently handles such NO_RX transfers and machines that use it depends on such behavior. I expect that this driver will be soon removed in favor of generic spi_gpio driver, once plat-s3c24xx will be finally converted to use generic gpio lib. What do you think about duplicating spi_gpio driver with my proposed changes as spi_gpio_adv? The original spi_gpio driver won't be modified at all, so no performance lose will happen for machines that use it. For new machines the developers will be able to select weather they need a high speed transfers or a driver that supports some rarely used features. The other possibility would be to create a new version of the bitbang_txrx_be_* functions for NO_TX and NO_RX cases. Then the proper function can be assigned in spi_gpio_probe(). However this would increase the size of spi_gpio driver significantly. Best regards -- Marek Szyprowski Samsung Poland R&D Center ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
