[RFCv2 0/3] OMAP SSI driver

[RFCv2 0/3] OMAP SSI driver

[Sebastian Reichel]

Hi,

Here is the second round of the OMAP SSI driver patches.

In this round I added/fixed:
- Usage of runtime PM
  Previously runtime PM was only used to enable/disable the involved
  clocks. Now the driver makes use of resume/suspend callbacks, which
  simplified its code (the driver did its own reference counting).
- Removal of deprecated IRQF_DISABLED flag from irq requests
- HWMOD: set SSI parent to L4-Core instead of L3
  I checked the public OMAP3 TRM, which assigns the address space used
  by the driver as reserved L4-Core address space.
- HWMOD: removed data, which will be specified via Device Tree
- Change omap_ssi_port.wktest and omap_ssi_port.wkin_cken from
  "unsigned int" to "bool"
- Change omap_ssi_port.wk_refcount from "int" to "unsigned int"
- Convert __raw_read* to read*_relaxed / write*_relaxed
- Removal of involved platform and board code
- Split driver into omap_ssi.c and omap_ssi_port.c
  This changes helps in making the DT interface cleaner.
- Creation & Documentation of DT bindings

TODO:
- Central Message Queue
  I did not yet implement a central message queue in the HSI framework.
  I would prefer to do this after SSI is working in the mainline kernel,
  since that makes testing easier.
- HSI client registration via DT
  This needs changes in the HSI framework, which currently assumes,
  that clients are registered via board support code. This is more
  or less independent of the controller and should be added in an
  independent patchset IMHO.

Version 1 (*) of the patchset: https://lkml.org/lkml/2013/8/11/67

(*) There have been patchsets send out by Carlos before my RFCv1,
    see RFCv1 for details.

-- Sebastian

Sebastian Reichel (3):
  ARM: OMAP2+: hwmod-data: Add SSI information
  ARM: OMAP2+: HSI: Introduce OMAP SSI driver
  ARM: dts: N900: Add SSI information

 Documentation/devicetree/bindings/hsi/omap_ssi.txt |   73 ++
 arch/arm/boot/dts/omap3-n900.dts                   |    8 +
 arch/arm/boot/dts/omap34xx.dtsi                    |   49 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |   48 +
 drivers/hsi/Kconfig                                |    1 +
 drivers/hsi/Makefile                               |    1 +
 drivers/hsi/controllers/Kconfig                    |   20 +
 drivers/hsi/controllers/Makefile                   |    6 +
 drivers/hsi/controllers/omap_ssi.c                 |  585 +++++++++
 drivers/hsi/controllers/omap_ssi.h                 |  167 +++
 drivers/hsi/controllers/omap_ssi_port.c            | 1346 ++++++++++++++++++++
 drivers/hsi/controllers/omap_ssi_regs.h            |  172 +++
 12 files changed, 2476 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hsi/omap_ssi.txt
 create mode 100644 drivers/hsi/controllers/Kconfig
 create mode 100644 drivers/hsi/controllers/Makefile
 create mode 100644 drivers/hsi/controllers/omap_ssi.c
 create mode 100644 drivers/hsi/controllers/omap_ssi.h
 create mode 100644 drivers/hsi/controllers/omap_ssi_port.c
 create mode 100644 drivers/hsi/controllers/omap_ssi_regs.h

-- 
1.8.4.rc3

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

[Javier Martinez Canillas]

On Sun, Sep 15, 2013 at 10:44 PM, Sebastian Reichel <sre@debian.org> wrote:
> Add SSI device tree data for OMAP34xx and Nokia N900.
>
> Signed-off-by: Sebastian Reichel <sre@debian.org>
> ---
>  Documentation/devicetree/bindings/hsi/omap_ssi.txt | 73 ++++++++++++++++++++++
>  arch/arm/boot/dts/omap3-n900.dts                   |  8 +++
>  arch/arm/boot/dts/omap34xx.dtsi                    | 49 +++++++++++++++
>  3 files changed, 130 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hsi/omap_ssi.txt
>
> diff --git a/Documentation/devicetree/bindings/hsi/omap_ssi.txt b/Documentation/devicetree/bindings/hsi/omap_ssi.txt
> new file mode 100644
> index 0000000..e3597eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hsi/omap_ssi.txt
> @@ -0,0 +1,73 @@
> +OMAP SSI controller bindings
> +
> +Required properties:
> +- compatible:          Should be set to the following value
> +                        ti,omap3-ssi (applicable to OMAP34xx devices)
> +- ti,hwmods:           Name of the hwmod associated to the controller, which
> +                       is "ssi".
> +- reg:                 Contains SSI register address range (base address and
> +                       length).
> +- reg-names:           Contains the names of the address ranges. It's
> +                        expected, that "sys" and "gdd" address ranges are
> +                       provided.
> +- interrupts:          Contains the interrupt information for the controller.
> +- interrupt-names:      Contains the names of the interrupts. It's expected,
> +                       that "gdd_mpu" is provided.
> +- ranges               Required as an empty node
> +- #address-cells       Should be set to <1>
> +- #size-cells          Should be set to <1>
> +
> +Each port is represented as a sub-node of the ti,omap3-ssi device.
> +
> +Required Port sub-node properties:
> +- compatible:          Should be set to the following value
> +                        ti,omap3-ssi-port (applicable to OMAP34xx devices)
> +- reg:                 Contains port's register address range (base address
> +                       and length).
> +- reg-names:           Contains the names of the address ranges. It's
> +                        expected, that "tx" and "rx" address ranges are
> +                       provided.
> +- interrupt-parent     Should be a phandle for the interrupt controller
> +- 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.
> +- 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.
> +
> +Example for Nokia N900:
> +
> +ssi-controller at 48058000 {
> +       compatible = "ti,omap3-ssi";
> +       ti,hwmods = "ssi";
> +
> +       reg = <0x48058000 0x1000>,
> +             <0x48059000 0x1000>;
> +       reg-names = "sys",
> +                   "gdd";
> +
> +       interrupts = <55>;
> +       interrupt-names = "gdd_mpu";
> +
> +       #address-cells = <1>;
> +       #size-cells = <1>;
> +       ranges;
> +
> +       ssi-port at 0 {
> +               compatible = "ti,omap3-ssi-port";
> +
> +               reg = <0x4805a000 0x800>,
> +                     <0x4805a800 0x800>;
> +               reg-names = "tx",
> +                           "rx";
> +
> +               interrupt-parent = <&intc>;
> +               interrupts = <51>,
> +                            <52>;
> +               interrupt-names = "mpu_irq0",
> +                                 "mpu_irq1";
> +
> +               ti,ssi-cawake-gpio = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */
> +       }
> +}
> diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> index 0582356..cc4a3e2 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -186,6 +186,14 @@
>         power = <50>;
>  };
>
> +&ssi_port1 {
> +       ti,ssi-cawake-gpio = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */
> +};
> +
> +&ssi_port2 {
> +       status = "disabled";
> +};
> +
>  &uart1 {
>         pinctrl-names = "default";
>         pinctrl-0 = <&uart1_pins>;
> diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
> index 5355d61..393b7a7 100644
> --- a/arch/arm/boot/dts/omap34xx.dtsi
> +++ b/arch/arm/boot/dts/omap34xx.dtsi
> @@ -25,4 +25,53 @@
>                         clock-latency = <300000>; /* From legacy driver */
>                 };
>         };
> +
> +       ocp {
> +               ssi: ssi-controller at 48058000 {
> +                       compatible = "ti,omap3-ssi";
> +                       ti,hwmods = "ssi";
> +
> +                       reg = <0x48058000 0x1000>,
> +                             <0x48059000 0x1000>;
> +                       reg-names = "sys",
> +                                   "gdd";
> +
> +                       interrupts = <55>;
> +                       interrupt-names = "gdd_mpu";
> +
> +                       #address-cells = <1>;
> +                       #size-cells = <1>;
> +                       ranges;
> +
> +                       ssi_port1: ssi-port at 0 {
> +                               compatible = "ti,omap3-ssi-port";
> +
> +                               reg = <0x4805a000 0x800>,
> +                                     <0x4805a800 0x800>;
> +                               reg-names = "tx",
> +                                           "rx";
> +
> +                               interrupt-parent = <&intc>;
> +                               interrupts = <51>,
> +                                            <52>;
> +                               interrupt-names = "mpu_irq0",
> +                                                 "mpu_irq1";
> +                       };
> +
> +                       ssi_port2: ssi-port at 1 {
> +                               compatible = "ti,omap3-ssi-port";
> +
> +                               reg = <0x4805b000 0x800>,
> +                                     <0x4805b800 0x800>;
> +                               reg-names = "tx",
> +                                           "rx";
> +
> +                               interrupt-parent = <&intc>;
> +                               interrupts = <53>,
> +                                            <54>;
> +                               interrupt-names = "mpu_irq0",
> +                                                 "mpu_irq1";
> +                       };
> +               };
> +       };
>  };
> --
> 1.8.4.rc3

Hi Sebastian,

Is the Synchronous Serial Interface (SSI)  only supported by
OMAP34xx/OMAP35xx SoC and not by OMAP36xx/OMAP37xx SoC?

I'm asking this since if SSI is supported by both we should add the
device nodes in omap3.dtsi instead of omap34xx.dtsi.

I thought that all OMAP3 SoC supported SSI and all OMAP4 SoC supported
HSI but I guess I was wrong...

Thanks a lot and best regards,
Javier

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

[Nishanth Menon]

On 22:44-20130915, Sebastian Reichel wrote:
> Add SSI device tree data for OMAP34xx and Nokia N900.
> 
> Signed-off-by: Sebastian Reichel <sre@debian.org>
> ---
>  Documentation/devicetree/bindings/hsi/omap_ssi.txt | 73 ++++++++++++++++++++++
>  arch/arm/boot/dts/omap3-n900.dts                   |  8 +++
>  arch/arm/boot/dts/omap34xx.dtsi                    | 49 +++++++++++++++
>  3 files changed, 130 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hsi/omap_ssi.txt
> 
> diff --git a/Documentation/devicetree/bindings/hsi/omap_ssi.txt b/Documentation/devicetree/bindings/hsi/omap_ssi.txt
> new file mode 100644
> index 0000000..e3597eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hsi/omap_ssi.txt
> @@ -0,0 +1,73 @@
> +OMAP SSI controller bindings
> +
> +Required properties:
> +- compatible:		Should be set to the following value
> +                        ti,omap3-ssi (applicable to OMAP34xx devices)
> +- ti,hwmods:		Name of the hwmod associated to the controller, which
> +			is "ssi".
> +- reg:			Contains SSI register address range (base address and
> +			length).
> +- reg-names:		Contains the names of the address ranges. It's
> +                        expected, that "sys" and "gdd" address ranges are
> +			provided.
> +- interrupts: 		Contains the interrupt information for the controller.
> +- interrupt-names:      Contains the names of the interrupts. It's expected,
> +			that "gdd_mpu" is provided.
> +- ranges		Required as an empty node
> +- #address-cells	Should be set to <1>
> +- #size-cells		Should be set to <1>
> +
> +Each port is represented as a sub-node of the ti,omap3-ssi device.
> +
> +Required Port sub-node properties:
> +- compatible:		Should be set to the following value
> +                        ti,omap3-ssi-port (applicable to OMAP34xx devices)
> +- reg:			Contains port's register address range (base address
> +			and length).
> +- reg-names:		Contains the names of the address ranges. It's
> +                        expected, that "tx" and "rx" address ranges are
> +			provided.
> +- interrupt-parent	Should be a phandle for the interrupt controller
> +- 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.
> +- 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.
> +
This belongs to patch which introduces SSI driver, no?
-- 
Regards,
Nishanth Menon

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

[Sebastian Reichel]

Hi,

> Is the Synchronous Serial Interface (SSI)  only supported by
> OMAP34xx/OMAP35xx SoC and not by OMAP36xx/OMAP37xx SoC?
> 
> I'm asking this since if SSI is supported by both we should add the
> device nodes in omap3.dtsi instead of omap34xx.dtsi.
> 
> I thought that all OMAP3 SoC supported SSI and all OMAP4 SoC supported
> HSI but I guess I was wrong...

I just do not know. Information about the SSI core is not included
in the public OMAP TRM. It only lists the memory space as reserved.

Thus I only included it in OMAP34xx, which is used in Nokia N900 and
must support SSI.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130916/f2c6d2d9/attachment-0001.sig>

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

[Javier Martinez Canillas]

On Mon, Sep 16, 2013 at 5:01 PM, Sebastian Reichel <sre@debian.org> wrote:
> Hi,
>
>> Is the Synchronous Serial Interface (SSI)  only supported by
>> OMAP34xx/OMAP35xx SoC and not by OMAP36xx/OMAP37xx SoC?
>>
>> I'm asking this since if SSI is supported by both we should add the
>> device nodes in omap3.dtsi instead of omap34xx.dtsi.
>>
>> I thought that all OMAP3 SoC supported SSI and all OMAP4 SoC supported
>> HSI but I guess I was wrong...
>
> I just do not know. Information about the SSI core is not included
> in the public OMAP TRM. It only lists the memory space as reserved.
>
> Thus I only included it in OMAP34xx, which is used in Nokia N900 and
> must support SSI.
>

I see... hopefully someone from TI can shed some light on this.

> -- Sebastian
>

Best regards,
Javier

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

[Aaro Koskinen]

Hi,

On Mon, Sep 16, 2013 at 05:01:47PM +0200, Sebastian Reichel wrote:
> > Is the Synchronous Serial Interface (SSI)  only supported by
> > OMAP34xx/OMAP35xx SoC and not by OMAP36xx/OMAP37xx SoC?
> > 
> > I'm asking this since if SSI is supported by both we should add the
> > device nodes in omap3.dtsi instead of omap34xx.dtsi.
> > 
> > I thought that all OMAP3 SoC supported SSI and all OMAP4 SoC supported
> > HSI but I guess I was wrong...
> 
> I just do not know. Information about the SSI core is not included
> in the public OMAP TRM. It only lists the memory space as reserved.
> 
> Thus I only included it in OMAP34xx, which is used in Nokia N900 and
> must support SSI.

I think N9 and N950 (OMAP3630) are using pretty much the same driver.

A.

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

[Sebastian Reichel]

On Mon, Sep 16, 2013 at 09:10:32PM +0300, Aaro Koskinen wrote:
> On Mon, Sep 16, 2013 at 05:01:47PM +0200, Sebastian Reichel wrote:
> > > Is the Synchronous Serial Interface (SSI)  only supported by
> > > OMAP34xx/OMAP35xx SoC and not by OMAP36xx/OMAP37xx SoC?
> > > 
> > > I'm asking this since if SSI is supported by both we should add the
> > > device nodes in omap3.dtsi instead of omap34xx.dtsi.
> > > 
> > > I thought that all OMAP3 SoC supported SSI and all OMAP4 SoC supported
> > > HSI but I guess I was wrong...
> > 
> > I just do not know. Information about the SSI core is not included
> > in the public OMAP TRM. It only lists the memory space as reserved.
> > 
> > Thus I only included it in OMAP34xx, which is used in Nokia N900 and
> > must support SSI.
> 
> I think N9 and N950 (OMAP3630) are using pretty much the same driver.

OK. I've checked the N950 kernel from [0] and it uses the same data.
I will move the data from omap34xx.dtsi to omap3.dtsi in the next
RFC.

Thanks for the hint.

[0] https://github.com/nemomobile/kernel-adaptation-n950-n9/

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130916/ff330637/attachment.sig>

[RFCv2 2/3] ARM: OMAP2+: HSI: Introduce OMAP SSI driver

[Tony Lindgren]

* Sebastian Reichel <sre@debian.org> [130915 13:56]:
> This patch adds an OMAP SSI driver to the HSI framework.

Thanks for working on this.
 
> +config OMAP_SSI
> +	tristate "OMAP SSI hardware driver"
> +	depends on ARCH_OMAP && HSI
> +	default n
> +	---help---
> +	  SSI is a legacy version of HSI. It is usually used to connect
> +	  an application engine with a cellular modem.
> +	  If you say Y here, you will enable the OMAP SSI hardware driver.

You can drop the "default n" line here, it's the default.

> +/* TODO: HACK: define omap_pm_get_dev_context_loss_count, because it is defined
> + * in arch/arm/mach-omap2/omap-pm.h and thus not available via #include */
> +int omap_pm_get_dev_context_loss_count(struct device *dev);

You can drop this and related calls completely and rely on some
SSI configuration registers instead to detect if context was lost.

The reason for that is that the context loss count should be
implemented in Linux generic way if needed at all and we can leave
out a dependency to that.

If there's a chance that the context is only partially lost,
then of course something else is needed. So far I have not
hit that issue for MMC or serial at least, but you'd have to
test this with off-idle to verify it.

Regards,

Tony

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

[Stephen Warren]

On 09/15/2013 02:44 PM, Sebastian Reichel wrote:
> Add SSI device tree data for OMAP34xx and Nokia N900.

What is an "SSI" device, ...

> diff --git a/Documentation/devicetree/bindings/hsi/omap_ssi.txt b/Documentation/devicetree/bindings/hsi/omap_ssi.txt

... and what is the "HSI" subsystem?

> +OMAP SSI controller bindings
> +
> +Required properties:
> +- compatible:		Should be set to the following value
> +                        ti,omap3-ssi (applicable to OMAP34xx devices)

I think that'd be better phrased as:

	Should include "ti,omap3-ssi".

The binding should not preclude other compatibel values being present
(e.g. a SoC-specific compatible value, to allow SoC-specific quirks to
be enabled later).

> +- 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.

> +- reg:			Contains SSI register address range (base address and
> +			length).
> +- reg-names:		Contains the names of the address ranges. It's
> +                        expected, that "sys" and "gdd" address ranges are
> +			provided.

Why two entries in reg-names but only one in reg?

I think it'd be better to write:

reg-names:	Contains the values "sys" and "gdd".
reg:		Contains a register specifier for each entry in
		reg-names.

A similar re-ordering/-wording would apply to interrupts/interrupt-names.

> +- ranges		Required as an empty node

s/node/property/

Why must ranges be empty? As long as the content correctly represents
the bus setup, why does the content matter at all. How about:

ranges		Represents the bus address mapping between the main
		controller node and the child nodes below.

> +Each port is represented as a sub-node of the ti,omap3-ssi device.
> +
> +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? Are
the ports really dependent upon some shared resource? Couldn't the ports
be represented as separate top-level SSI controllers?

> +- 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?

Does the SSI controller (or its ports) not need any clocks, resets,
regulators, ...?

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

[Sebastian Reichel]

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.
> 
> What is an "SSI" device, ...

Synchronous Serial Interface (SSI), which is an interface from
the OMAP3 for modem connection. It's a legacy variant of
High-speed Synchronous Serial Interface (HSI). This in turn
is a standard from MIPI:

http://www.mipi.org/specifications/high-speed-synchronous-serial-interface-hsi

> 
> > diff --git a/Documentation/devicetree/bindings/hsi/omap_ssi.txt b/Documentation/devicetree/bindings/hsi/omap_ssi.txt
> 
> ... and what is the "HSI" subsystem?

A framework for HSI devices living in drivers/hsi.

> > +OMAP SSI controller bindings
> > +
> > +Required properties:
> > +- compatible:		Should be set to the following value
> > +                        ti,omap3-ssi (applicable to OMAP34xx devices)
> 
> I think that'd be better phrased as:
> 
> 	Should include "ti,omap3-ssi".
> 
> The binding should not preclude other compatibel values being present
> (e.g. a SoC-specific compatible value, to allow SoC-specific quirks to
> be enabled later).

Right. Will be fixed in the next RFC.

> > +- 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.

> > +- reg:			Contains SSI register address range (base address and
> > +			length).
> > +- reg-names:		Contains the names of the address ranges. It's
> > +                        expected, that "sys" and "gdd" address ranges are
> > +			provided.
> 
> Why two entries in reg-names but only one in reg?
> 
> I think it'd be better to write:
> 
> reg-names:	Contains the values "sys" and "gdd".
> reg:		Contains a register specifier for each entry in
> 		reg-names.
> 
> A similar re-ordering/-wording would apply to interrupts/interrupt-names.

OK. Will be fixed in the next RFC.

> > +- ranges		Required as an empty node
> 
> s/node/property/
> 
> Why must ranges be empty? As long as the content correctly represents
> the bus setup, why does the content matter at all. How about:
> 
> ranges		Represents the bus address mapping between the main
> 		controller node and the child nodes below.

OK. Will be fixed in the next RFC.

> > +Each port is represented as a sub-node of the ti,omap3-ssi device.
> > +
> > +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.

> > +- 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.

NOTE: I do not have documentation for the chip. I just ported the
old patch from Carlos Chinea (who developed the initial driver for
Nokia) to the new kernel frameworks, since I want to use the
modem of my Nokia N900.

> 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

As far as I understand it, this kind of information is not yet
supported by DT on OMAP boards. On the other hand new OMAP drivers
are not allowed to add further board code, so temporarily the
ti,hwmod hack must be used.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130924/38525852/attachment-0001.sig>

[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?

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

[Tony Lindgren]

* Stephen Warren <swarren@wwwdotorg.org> [130924 13:03]:
> 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.

There are still pieces of information in hwmod that is needed for
PM to work for things like device autoidle and reset. The plan is
to describe those with Linux generic bindings, but that's going
to take a while.

Clearly once we have those bindings, ti,hwmods is not needed and
then the problem is how to support old .dtb files..

> 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?

Unfortunately not doable yet. For v3.13 we should have the
clock bindings in place, but quite a bit of work still
remains for the remaining hwmod pieces.

Considering all this, we may be best off dropping ti,hwmods
binding completely, and populate it based on DT auxdata or
something similar. That means that old .dtb files won't
work once we populate things from DT, but at least the binding
issue would be sorted out.

If anybody has better suggestions, let me know.

Regards,

Tony

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

[Tony Lindgren]

* Sebastian Reichel <sre@debian.org> [130915 13:56]:
> +
> +Example for Nokia N900:
> +
> +ssi-controller at 48058000 {
> +	compatible = "ti,omap3-ssi";
> +	ti,hwmods = "ssi";
> +
> +	reg = <0x48058000 0x1000>,
> +	      <0x48059000 0x1000>;
> +	reg-names = "sys",
> +		    "gdd";
> +
> +	interrupts = <55>;
> +	interrupt-names = "gdd_mpu";
> +
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +	ranges;
> +
> +	ssi-port at 0 {
> +		compatible = "ti,omap3-ssi-port";
> +
> +		reg = <0x4805a000 0x800>,
> +		      <0x4805a800 0x800>;
> +		reg-names = "tx",
> +			    "rx";
> +
> +		interrupt-parent = <&intc>;
> +		interrupts = <51>,
> +			     <52>;
> +		interrupt-names = "mpu_irq0",
> +				  "mpu_irq1";
> +
> +		ti,ssi-cawake-gpio = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */
> +	}
> +}

These should be in the omap3.dtsi file and not nested but separate. I'm almost
certain that these are completely independent hardware modules and this
means they can live their own PM life independently.

So can you please do a minimal patch for omap3.dtsi that just sets up
the standard resources separately for both modules the same way we have
for other hardware modules in omap3.dtsi do?

One of them should be called ssi, no idea what the other module name should
be as those register ranges show up as reserved in the docs I have.

The other binding pieces can be added later on as they get are ready.

Regards,

Tony

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

[Sebastian Reichel]

Hi Tony,

On Wed, Nov 20, 2013 at 05:38:59PM -0800, Tony Lindgren wrote:
> * Sebastian Reichel <sre@debian.org> [130915 13:56]:
> > +
> > +Example for Nokia N900:
> > +
> > +ssi-controller at 48058000 {
> > +	compatible = "ti,omap3-ssi";
> > +	ti,hwmods = "ssi";
> > +
> > +	reg = <0x48058000 0x1000>,
> > +	      <0x48059000 0x1000>;
> > +	reg-names = "sys",
> > +		    "gdd";
> > +
> > +	interrupts = <55>;
> > +	interrupt-names = "gdd_mpu";
> > +
> > +	#address-cells = <1>;
> > +	#size-cells = <1>;
> > +	ranges;
> > +
> > +	ssi-port at 0 {
> > +		compatible = "ti,omap3-ssi-port";
> > +
> > +		reg = <0x4805a000 0x800>,
> > +		      <0x4805a800 0x800>;
> > +		reg-names = "tx",
> > +			    "rx";
> > +
> > +		interrupt-parent = <&intc>;
> > +		interrupts = <51>,
> > +			     <52>;
> > +		interrupt-names = "mpu_irq0",
> > +				  "mpu_irq1";
> > +
> > +		ti,ssi-cawake-gpio = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */
> > +	}
> > +}
> 
> These should be in the omap3.dtsi file and not nested but separate. I'm almost
> certain that these are completely independent hardware modules and this
> means they can live their own PM life independently.
>
> So can you please do a minimal patch for omap3.dtsi that just sets up
> the standard resources separately for both modules the same way we have
> for other hardware modules in omap3.dtsi do?
> 
> One of them should be called ssi, no idea what the other module name should
> be as those register ranges show up as reserved in the docs I have.

In the public documentation of the omaps all SSI related stuff is
missing and memory areas are marked as reserved. I could not find
out how to receive the NDA version, so the following is purely
speculation based on the code.

If I understand it right the HW looks like this:

+-----------------+
|    GDD (DMA)    | <- this one is currently called ssi-controller
+--------+--------+
| Port 1 | Port 2 | <- these are currently called ssi-port
+--------+--------+

I think the GDD part must be enabled while Port 1 or Port 2 is
enabled. The last RFC driver from Carlos did not even split up the
irq/memory areas into different platform devices, but just requested
all of them in one ssi platform device.

> The other binding pieces can be added later on as they get are ready.

Sure. They are almost finished btw. I was able to get a gsm network
scan.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131121/b7b8674a/attachment.sig>

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

[Tony Lindgren]

* Sebastian Reichel <sre@debian.org> [131120 18:22]:
> On Wed, Nov 20, 2013 at 05:38:59PM -0800, Tony Lindgren wrote:
> 
> In the public documentation of the omaps all SSI related stuff is
> missing and memory areas are marked as reserved. I could not find
> out how to receive the NDA version, so the following is purely
> speculation based on the code.
> 
> If I understand it right the HW looks like this:
> 
> +-----------------+
> |    GDD (DMA)    | <- this one is currently called ssi-controller
> +--------+--------+
> | Port 1 | Port 2 | <- these are currently called ssi-port
> +--------+--------+
> 
> I think the GDD part must be enabled while Port 1 or Port 2 is
> enabled. The last RFC driver from Carlos did not even split up the
> irq/memory areas into different platform devices, but just requested
> all of them in one ssi platform device.

Might be worth checking. If these blocks have the revision and SYSC
register in the beginning of their address space like all omap modules,
then they are completely separate blocks and can idle independently.

The fact that they have separate interrutps makes me think that's the
case, otherwise there would be just interrupt(s) at the ssi-controllel
level.

> > The other binding pieces can be added later on as they get are ready.
> 
> Sure. They are almost finished btw. I was able to get a gsm network
> scan.

That's great :)

Regards,

Tony

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

[Sebastian Reichel]

On Thu, Nov 21, 2013 at 12:46:55PM -0800, Tony Lindgren wrote:
> * Sebastian Reichel <sre@debian.org> [131120 18:22]:
> > On Wed, Nov 20, 2013 at 05:38:59PM -0800, Tony Lindgren wrote:
> > 
> > In the public documentation of the omaps all SSI related stuff is
> > missing and memory areas are marked as reserved. I could not find
> > out how to receive the NDA version, so the following is purely
> > speculation based on the code.
> > 
> > If I understand it right the HW looks like this:
> > 
> > +-----------------+
> > |    GDD (DMA)    | <- this one is currently called ssi-controller
> > +--------+--------+
> > | Port 1 | Port 2 | <- these are currently called ssi-port
> > +--------+--------+
> > 
> > I think the GDD part must be enabled while Port 1 or Port 2 is
> > enabled. The last RFC driver from Carlos did not even split up the
> > irq/memory areas into different platform devices, but just requested
> > all of them in one ssi platform device.
> 
> Might be worth checking. If these blocks have the revision and SYSC
> register in the beginning of their address space like all omap modules,
> then they are completely separate blocks and can idle independently.

This does not seem to be the case.
I think this is just one big IP-Core, which provides two ports.

> The fact that they have separate interrutps makes me think that's the
> case, otherwise there would be just interrupt(s) at the ssi-controllel
> level.

The original driver from Carlos had all IRQs in one big platform
device. I created the ports subdevices, since it looked cleaner
than naming resources "port1_mpu_irq0".

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131122/60f08dbe/attachment.sig>