Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
Hi Tony,
On Wed, Nov 20, 2013 at 05:38:59PM -0800, Tony Lindgren wrote:
> * Sebastian Reichel [130915 13:56]:
> > +
> > +Example for Nokia N900:
> > +
> > +ssi-controller@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@0 {
> > + compatible = "ti,omap3-ssi-port";
> > +
> > + reg = <0x4805a000 0x800>,
> > + <0x4805a800 0x800>;
> > + reg-names = "tx",
> > + "rx";
> > +
> > + interrupt-parent = <>;
> > + interrupts = <51>,
> > +<52>;
> > + interrupt-names = "mpu_irq0",
> > + "mpu_irq1";
> > +
> > + ti,ssi-cawake-gpio = < 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
signature.asc
Description: Digital signature
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
* Sebastian Reichel [130915 13:56]:
> +
> +Example for Nokia N900:
> +
> +ssi-controller@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@0 {
> + compatible = "ti,omap3-ssi-port";
> +
> + reg = <0x4805a000 0x800>,
> + <0x4805a800 0x800>;
> + reg-names = "tx",
> + "rx";
> +
> + interrupt-parent = <>;
> + interrupts = <51>,
> + <52>;
> + interrupt-names = "mpu_irq0",
> + "mpu_irq1";
> +
> + ti,ssi-cawake-gpio = < 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
* Sebastian Reichel s...@debian.org [130915 13:56]:
+
+Example for Nokia N900:
+
+ssi-controller@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@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
Hi Tony,
On Wed, Nov 20, 2013 at 05:38:59PM -0800, Tony Lindgren wrote:
* Sebastian Reichel s...@debian.org [130915 13:56]:
+
+Example for Nokia N900:
+
+ssi-controller@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@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
signature.asc
Description: Digital signature
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
* Stephen Warren [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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
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? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
* Stephen Warren swar...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
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: > > rangesRepresents 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
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
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, ...? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
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, ...? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
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: rangesRepresents 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
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
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 signature.asc Description: Digital signature
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
On Mon, Sep 16, 2013 at 5:01 PM, Sebastian Reichel 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
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 signature.asc Description: Digital signature
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
On 22:44-20130915, Sebastian Reichel wrote: > Add SSI device tree data for OMAP34xx and Nokia N900. > > Signed-off-by: Sebastian Reichel > --- > 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 000..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-cellsShould 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
On Sun, Sep 15, 2013 at 10:44 PM, Sebastian Reichel wrote:
> Add SSI device tree data for OMAP34xx and Nokia N900.
>
> Signed-off-by: Sebastian Reichel
> ---
> 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 000..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@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@0 {
> + compatible = "ti,omap3-ssi-port";
> +
> + reg = <0x4805a000 0x800>,
> + <0x4805a800 0x800>;
> + reg-names = "tx",
> + "rx";
> +
> + interrupt-parent = <>;
> + interrupts = <51>,
> +<52>;
> + interrupt-names = "mpu_irq0",
> + "mpu_irq1";
> +
> + ti,ssi-cawake-gpio = < 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>;
> };
>
> +_port1 {
> + ti,ssi-cawake-gpio = < 23 GPIO_ACTIVE_HIGH>; /* 151 */
> +};
> +
> +_port2 {
> + status = "disabled";
> +};
> +
> {
> pinctrl-names = "default";
> pinctrl-0 = <_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 = <30>; /* From legacy driver */
> };
> };
> +
> + ocp {
> + ssi: ssi-controller@48058000 {
> + compatible = "ti,omap3-ssi";
> + ti,hwmods = "ssi";
> +
> + reg = <0x48058000 0x1000>,
> + <0x48059000 0x1000>;
> + reg-names = "sys",
> + "gdd";
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
On Sun, Sep 15, 2013 at 10:44 PM, Sebastian Reichel s...@debian.org wrote:
Add SSI device tree data for OMAP34xx and Nokia N900.
Signed-off-by: Sebastian Reichel s...@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 000..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@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@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 = 30; /* From legacy driver */
};
};
+
+ ocp {
+ ssi: ssi-controller@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;
+
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
On 22:44-20130915, Sebastian Reichel wrote: Add SSI device tree data for OMAP34xx and Nokia N900. Signed-off-by: Sebastian Reichel s...@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 000..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-cellsShould 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
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 signature.asc Description: Digital signature
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
On Mon, Sep 16, 2013 at 5:01 PM, Sebastian Reichel s...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
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 signature.asc Description: Digital signature
