spi_mpc8xxx.c: chip select polarity problem

[Grant Likely]

On Thu, Nov 26, 2009 at 12:01 PM, Anton Vorontsov
<avorontsov at ru.mvista.com> wrote:
> On Thu, Nov 26, 2009 at 11:50:05AM -0700, Grant Likely wrote:
>> On Thu, Nov 26, 2009 at 11:41 AM, Anton Vorontsov
>> <avorontsov at ru.mvista.com> wrote:
>> > On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote:
>> > [...]
>> >> The spi-cs-high property is defined in
>> >> Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was
>> >> a mistake
>> >
>> > Yup.
>> >
>> >> Currently the spi-cs-high property is parsed in the
>> >> of_register_spi_devices() function, but the CS polarity needs to be
>> >> known before registering devices.  It needs to be factored out into
>> >> another utility function callable by spi bus drivers so that it can
>> >> get polarity data at probe time.
>> >
>> > Untill we have this, Torsten's patch is a real improvement, and
>> > works for non-broken hw/fw.
>> >
>> > So I think it should be applied.
>>
>> I disagree since it only band-aids the problem and uglifies the driver
>> in the process.  In the immediate term the driver needs to be changed
>> to read the spi-cs-high property out of the child nodes before
>> registering the devices.
>
> Hm. I thought we agreed that spi-cs-high is not good? Why do you
> encourage using it then? We'll have to uglify the driver with
> legacy device-tree handling code.

spi-cs-high is definitely not a complete solution, but it isn't
actively evil either.  Plus it is documented and (presumably) in
active use. so support for it should not be dropped.

Regardless, there needs to be a library function for parsing all the
SPI child nodes and returning the active state for each GPIO chip
select.  All the code for parsing the old spi-cs-high properties can
be contained in the same place as a new yet-to-be-defined bus node cs
polarity property.  The rework to the driver itself is not ugly.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.