[RFCv2 3/3] ARM: dts: N900: Add SSI information

[Stephen Warren]

On 09/23/2013 05:46 PM, Sebastian Reichel wrote:
> Hi,
> 
> On Mon, Sep 23, 2013 at 02:35:35PM -0600, Stephen Warren wrote:
>> On 09/15/2013 02:44 PM, Sebastian Reichel wrote:
>>> Add SSI device tree data for OMAP34xx and Nokia N900.

...
>>> +- ti,hwmods:		Name of the hwmod associated to the controller,
>>> which +			is "ssi".
>> 
>> I don't think we should add any more of that, for new bindings.
> 
> That basically means not adding new drivers until hwmod is
> completly removed, since no new drivers not using DT are accepted
> anymore.
> 
> hwmod still holds some information, which are not yet mapped to
> DT.

Tony, is defining hwmod properties for new OMAP bindings what everyone
is currently doing? I'm not sure how that will work with a stable DT
ABI...

I wonder if it makes sense not to define the ti,hwmods property in the
binding document (so it doesn't become part of the ABI), but put it
into the DTS file simply to make the current Linux code work? I'm not
sure if that's any better though.

>>> +Required Port sub-node properties: +- compatible:		Should be
>>> set to the following value +
>>> ti,omap3-ssi-port (applicable to OMAP34xx devices)
>> 
>> Hmm. Is it really the case that there is 1 controller with n
>> ports?
> 
> Yes with n=2.
> 
>> Are the ports really dependent upon some shared resource?
> 
> Yes and runtime power management.
> 
>> Couldn't the ports be represented as separate top-level SSI 
>> controllers?
> 
> Maybe with some phandles. The current layout is cleaner IMHO. The
> ports are part of the controller and actually most boards only use
> one of them.
> 
> In the original driver only the controller hat platform data with
> memory areas called "port1_rx" etc.

If the HW block really does include 2 ports, then representing it as a
single node in DT is fine; I was just making sure.

>>> +- interrupts:		Contains the interrupt information for the
>>> port. +- interrupt-names:	Contains the names of the interrupts.
>>> It's expected, +			that "mpu_irq0" and "mpu_irq1" are
>>> provided.
>> 
>> What exactly are those interrupts? "MPU" sounds like an external 
>> micro-controller/processor...
>> 
>>> +- ti,ssi-cawake-gpio:	Defines which GPIO pin is used to
>>> signify CAWAKE +			events for the port. This is an optional
>>> board-specific +			property. If it's missing the port will not
>>> be +			enabled.
>> 
>> That also sounds like something that's a higher-level protocol,
>> rather than whatever low-level transport "SSI" implements. Should
>> this be part of a child node that represents the device attached
>> to the SSI controller?
> 
> Both the interrupts and the cawake-gpio are used as irqs for 
> starting data transfers. As far as I understand it none of them are
> specific to the attached device.

But are the interrupts and GPIO actually part of the HSI protocol
itself, or something layered on top? While your particular board has
them wired up, is it strictly necessary for all boards using HSI to
have those IRQs/GPIOs?

>> Does the SSI controller (or its ports) not need any clocks,
>> resets, regulators, ...?
> 
> The only other stuff needed is taken care of by hwmod, which can be
> seen in this patch:
> 
> https://lkml.org/lkml/2013/9/15/97

It would be best to completely define the DT binding so that all
required clocks etc. are already present in the DT. That way, the DT
ABI won't change once people stop using hwmods. Tony, is that possible
on OMAP at present, irrespective of whether those e.g. clock
properties will actually be used by Linux?