>-----Original Message----- >From: Mike Frysinger [mailto:[email protected]] >Sent: Thursday, November 19, 2009 12:46 PM >To: Song, Barry >Cc: [email protected]; >[email protected] >Subject: Re: [Linux-kernel-commits] [7841] trunk: bug [#5689], >don't set select num as 0 while using gpio cs > >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. For gpio cs, I don't think it should be a issue for bfin spi driver. It should be a generic problem for all spi controller drivers since anyone can use gpio as cs. Use generic gpio api to control the high/low level, these codes can be common for all spi master. Devices only need to assign gpio number in arch. Work about gpio cs in spi_bfin5xx is better to be done in a common framework. It provides common interfaces to handle gpio chip-select.
>-mike > _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
