[PATCH 5/8] gpio: 74x164: Add output pin support

[maxime.ripard@free-electrons.com (Maxime Ripard)]

Le 05/09/2012 14:54, Eric B?nard a ?crit :
> Le Wed, 5 Sep 2012 14:29:52 +0200,
> Thomas Petazzoni <thomas.petazzoni@free-electrons.com> a ?crit :
> 
>> Le Wed, 5 Sep 2012 14:22:44 +0200,
>> Eric B?nard <eric@eukrea.com> a ?crit :
>>
>>>>> OK that's exactly what I was thinking to ;-)
>>>>
>>>> Good. So, do you think it's reasonable to use the STCP as a chip-select
>>>> for this device?
>>>
>>> in your case maybe but that really depends on how the chip is wired to
>>> the CPU so I'm not sure that can be a generic choice.
>>
>> I'm not sure to see how this chip could be wired differently to the
>> CPU. The CPU must do a low-to-high transition on STCP to get the values
>> out from the internal register.
>>
>> So, in other words, we don't know how to choose between:
>>
>>  *) Keep the current solution Maxime has implemented, where we have a
>>     specific latch GPIO property in the Device Tree for this 74HC595,
>>     and the 74HC595 driver is responsible for toggling this GPIO when
>>     needed.
>>
>>  *) Use the internal SPI controller logic to control this pin as a
>>     chip-select, and therefore get rid of Maxime's code with the
>>     specific latch GPIO property in the Device Tree.
>>
> daisy chaining won't work in the second case (I may be wrong but IIRC
> the chip select will toggle at each spi_write) unless you configure the
> spi controller to send a 8x(number of 74HC595) bits word :
> 
>  	gpio_set_value(chip->chip_select, 0);
> 	for (i = chip->registers - 1; i >= 0; i--) {
> 		ret = spi_write(chip->spi,
> 				chip->buffer + i, sizeof(u8));
> 		if (ret)
> 			return ret;
> 	}
> 
>  	gpio_set_value(chip->chip_select, 1);

And what about using the spi_message structure and one single spi_sync
instead of several spi_write ? Would that work in our case ?


-- 
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com