On Wed, Nov 18, 2009 at 23:20, Song, Barry wrote: >From: Mike Frysinger [mailto:[email protected]] >>On Wed, Nov 18, 2009 at 21:00, Song, Barry wrote: >>>From: Mike Frysinger [mailto:[email protected]] >>>>On Wed, Nov 18, 2009 at 02:34, Song, Barry wrote: >>>>> bfin5xx_spi_master.num_chipselect in its board. I maybe delete >>>>> MAX_GPIO_CS, and change >>>>> .num_chipselect = MAX_CTRL_CS + MAX_GPIO_CS, >>>>> To >>>>> .num_chipselect = MAX_CTRL_CS + MAX_BLACKFIN_GPIOS, >>>>> on our board. >>>> >>>> i dont know why you would do that. i dont know why you need to know >>>> the limit anyways ... if the cs is below MAX_CTRL_CS, then it's a >>>> dedicated cs. if it's not, then it's a gpio. run the setup code like >>>> normal and if gpio_request() fails (like it can do anyways if it's >>>> already taken), then the SPI master will clean up after things and >>>> return an error. >>> >>> I don't think it is a good way in fact. Spi core compares >>> he devices' cs with MAX cs of SPI master. >> >>which really doesnt matter. the spi core does it to simplify error >>checking for all masters. it isnt a hard requirement as our code >>already falls back to gpio_request(). >> >>> To support what you said, MAX int type need be given to SPI >>controllers. I don't think it makes sense. >> >>except that as soon as .cs_gpio is combined into .cs, we already have >>this problem and using MAX_BLACKFIN_GPIOS artificially limits it. >>whether we use MAX_BLACKFIN_GPIOS or ARCH_NR_GPIOS really doesnt >>matter in this regard. >> >>as i'm sure you've seen, the gpiolib code sets a default limit of 256 >>which easily fits into a u16 even after adding the # of valid hardware >>cs's. > > It is not a big issue to me. If you prefer the way, it may change it directly > :-)
i wouldnt care as much if we didnt have ADI devices that added GPIOs via GPIOLIB, or the BF538/9 where the weird port e gpios are only available via GPIOLIB. also, there is the semi-related issue of our code atm accepting invalid cs's on BF538/9 for SPI1 and SPI2. while its SPI0 has normal 7 cs's, SPI1/SPI2 only has 1 cs. any ideas on how to address this ? or just pretend it isnt an issue and people who try to use CS2+ with SPI1/SPI2 are just dumb -- it's not like there's any pins to hook things up. -mike _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
