>-----Original Message-----
>From: Mike Frysinger [mailto:[email protected]]
>Sent: Thursday, November 19, 2009 12:11 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 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
>the 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
:-)
>-mike
>
_______________________________________________
Linux-kernel-commits mailing list
[email protected]
https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
