On Mon, Aug 20, 2012 at 4:22 PM, Rob Herring [off-list ref] wrote:

On 08/20/2012 06:39 AM, Alexandre Pereira da Silva wrote:

quoted

+- pl022,hierarchy : master or slave interface

Is attaching a master and using the pl022 as a slave really a supported
use case?

No not currently. People doing this crazy stuff need to have
the kernel with the hard real-time patches and lightening response
first. But it's in the platform data because it's a feature supported by
the hardware.

The DT spi bindings are really designed for a master node with
N slave nodes. So there is more general question of how to describe a
spi controller as a slave. It's not really one I care to answer as the
Linux spi framework isn't designed to act as a slave.

Currently the code should hardwire this to master and not define
a binding for it I think.

quoted

+- pl022,slave-tx-disable : disconnect tx line in slave mode

Applies also to this, then.

quoted

+- pl022,com-mode : polling, interrupt or dma
+- pl022,rx-level-trig : Rx FIFO watermark level
+- pl022,tx-level-trig : Tx FIFO watermark level
+- pl022,ctrl-len : Microwire interface: Control length
+- pl022,wait-state : Microwire interface: Wait state
+- pl022,duplex : Microwire interface: Full/Half duplex

Most of these properties aren't used anywhere in the kernel other than
u300 and I'm not sure what to purpose of dummy_chip_info is.

It is used for loopback-testing of the PL022. They're probably
not necessary there either.

Perhaps
Linus has some input? I think either they can be decided by the spi
controller (com-mode, fifo watermark) or should be standard properties
(microwire settings). I would argue they should be removed if the spi
framework doesn't have support in a standard way.

Uncertain about this, others would need to comment.
At some point there has been a chip needing these to be set
to some magic values.

Yours,
Linus Walleij