| Message ID | 1379277856-24571-4-git-send-email-sre@debian.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@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 = <300000>; /* 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>; > + #size-cells = <1>; > + ranges; > + > + ssi_port1: 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"; > + }; > + > + ssi_port2: ssi-port@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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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?
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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Sebastian Reichel <sre@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-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@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
* 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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@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 = <300000>; /* 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>; + #size-cells = <1>; + ranges; + + ssi_port1: 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"; + }; + + ssi_port2: ssi-port@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"; + }; + }; + }; };
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