>-----Original Message-----
>From: Mike Frysinger [mailto:[email protected]]
>Sent: Wednesday, November 18, 2009 11:03 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 02:34, Song, Barry wrote:
>>From: Mike Frysinger [mailto:[email protected]]
>>>On Wed, Nov 18, 2009 at 01:23, Song, Barry wrote:
>>>>From: Mike Frysinger [mailto:[email protected]]
>>>>>On Wed, Nov 18, 2009 at 00:46,
><[email protected]> wrote:
>>>>>> Log Message
>>>>>>
>>>>>> bug [#5689], don't set select num as 0 while using gpio cs
>>>>>>
>>>>>> fix problems pointed out by Michael and Mike
>>>>>>
>>>>>> Modified: trunk/arch/blackfin/include/asm/bfin5xx_spi.h
>>>>>>
>>>>>> -#define USE_GPIO_CS 0x8000
>>>>>> +#define MAX_CTRL_CS 8 /* cs in spi controller */
>>>>>> +#define MAX_GPIO_CS MAX_BLACKFIN_GPIOS
>>>>>
>>>>>this prevents using GPIOs that are integrated via gpiolib,
>and i dont
>>>>>think there's a problem with those. how about the bus
>driver simply
>>>>>uses return value from gpio_request() to figure out
>whether the gpio
>>>>>in question is valid ?
>>>>
>>>> Sorry. I don't know what you exactly mean. You mean GPIO between
>>>> MAX_BLACKFIN_GPIOS and ARCH_NR_GPIOS?
>>>> MAX_BLACKFIN_GPIOS should be just the number right of
>GPIOs in every
>>>> blackfin processor.
>>>
>>>that's the point -- i'm not talking about Blackfin GPIOs.
>i'm talking
>>>about GPIOs available on expander boards and usable via gpiolib. you
>>>can hook up a number of arbitrary GPIOs beyond what the processor
>>>itself supports and all of them are usable via the GPIO framework.
>>
>> If so, users can add a value to
>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.
To support what you said, MAX int type need be given to SPI controllers. I
don't think it makes sense.
>-mike
>
_______________________________________________
Linux-kernel-commits mailing list
[email protected]
https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
