* [PATCH 0/6] OMAP Mailbox framework adoption & DT support
@ 2014-06-25 1:47 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jassi Brar, Dave Gerlach, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Suman Anna
Hi,
The first 3 patches in this series adds the DT bindings and the DT-parse
support to the OMAP mailbox driver. The last 3 patches make the changes
to adopt to the v7 version of mailbox framework from Jassi Brar [1]. I
have posted all the patches together since both touch the bindings and
dictate the usage for the OMAP mailbox clients. The current OMAP mailbox
clients - omap remoteproc and tidspbridge have also been converted to use
the new api.
The DT-support patches incorporates feedback from the last DT adoption
series [2], with the following main changes:
- Leverages more compatible strings
- Dropped the properties "ti,mbox-num-users" and "ti,mbox-num-fifos";
with these values retrieved through driver match data and compatible
strings
- Dropped the properties "ti,mbox-names" and "ti,mbox-data" that were
used to represent the sub-mailbox devices, which are now represented
as child nodes of the respective mailbox controller device node.
The series depends on the OMAP mailbox cleanup series [3] and the OMAP
mailbox DT/hwmod cleanup series [4].
The following shows the boot/validation logs on various OMAP platforms:
OMAP2 (SDP2430) : http://slexy.org/view/s20VHd3CIc
OMAP3 (BeagleXM) : http://slexy.org/view/s204yxxE7Q
OMAP4 (PandaBoard) : http://slexy.org/view/s20GDw9Lxq
OMAP5 (OMAP5 uEVM) : http://slexy.org/view/s201gZlzSB
DRA7 (DRA7 EVM) : http://slexy.org/view/s2CPnJ1Boz
AM33xx (BeagleBone Black) : http://slexy.org/view/s20WvIuITK
AM43xx (AM437x GP EVM) : http://slexy.org/view/s213DqnSg5
[1] https://lkml.org/lkml/2014/6/12/470
[2] http://marc.info/?l=linux-omap&m=137582560717973&w=2
[3] http://marc.info/?l=linux-omap&m=140365705821115&w=2
[4] http://marc.info/?l=linux-omap&m=140365833121612&w=2
Suman Anna (6):
Documentation: dt: add omap mailbox bindings
mailbox/omap: add support for parsing dt devices
ARM: dts: OMAP2+: Add sub mailboxes device node information
mailbox/omap: adapt to the new mailbox framework
ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes
mailbox/omap: add a custom of_xlate function
.../devicetree/bindings/mailbox/omap-mailbox.txt | 104 ++++
arch/arm/boot/dts/am33xx.dtsi | 5 +
arch/arm/boot/dts/am4372.dtsi | 5 +
arch/arm/boot/dts/dra7.dtsi | 13 +
arch/arm/boot/dts/omap2420.dtsi | 9 +
arch/arm/boot/dts/omap2430.dtsi | 5 +
arch/arm/boot/dts/omap3.dtsi | 5 +
arch/arm/boot/dts/omap4.dtsi | 9 +
arch/arm/boot/dts/omap5.dtsi | 9 +
drivers/mailbox/omap-mailbox.c | 544 ++++++++++++++-------
drivers/remoteproc/omap_remoteproc.c | 54 +-
drivers/staging/tidspbridge/core/_tiomap.h | 3 +-
drivers/staging/tidspbridge/core/io_sm.c | 7 +-
drivers/staging/tidspbridge/core/tiomap3430.c | 22 +-
drivers/staging/tidspbridge/core/tiomap_io.c | 7 +-
.../tidspbridge/include/dspbridge/host_os.h | 1 +
.../staging/tidspbridge/include/dspbridge/io_sm.h | 8 +-
include/linux/omap-mailbox.h | 15 +-
18 files changed, 598 insertions(+), 227 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
--
2.0.0
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 0/6] OMAP Mailbox framework adoption & DT support
@ 2014-06-25 1:47 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jassi Brar, Dave Gerlach, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Suman Anna
Hi,
The first 3 patches in this series adds the DT bindings and the DT-parse
support to the OMAP mailbox driver. The last 3 patches make the changes
to adopt to the v7 version of mailbox framework from Jassi Brar [1]. I
have posted all the patches together since both touch the bindings and
dictate the usage for the OMAP mailbox clients. The current OMAP mailbox
clients - omap remoteproc and tidspbridge have also been converted to use
the new api.
The DT-support patches incorporates feedback from the last DT adoption
series [2], with the following main changes:
- Leverages more compatible strings
- Dropped the properties "ti,mbox-num-users" and "ti,mbox-num-fifos";
with these values retrieved through driver match data and compatible
strings
- Dropped the properties "ti,mbox-names" and "ti,mbox-data" that were
used to represent the sub-mailbox devices, which are now represented
as child nodes of the respective mailbox controller device node.
The series depends on the OMAP mailbox cleanup series [3] and the OMAP
mailbox DT/hwmod cleanup series [4].
The following shows the boot/validation logs on various OMAP platforms:
OMAP2 (SDP2430) : http://slexy.org/view/s20VHd3CIc
OMAP3 (BeagleXM) : http://slexy.org/view/s204yxxE7Q
OMAP4 (PandaBoard) : http://slexy.org/view/s20GDw9Lxq
OMAP5 (OMAP5 uEVM) : http://slexy.org/view/s201gZlzSB
DRA7 (DRA7 EVM) : http://slexy.org/view/s2CPnJ1Boz
AM33xx (BeagleBone Black) : http://slexy.org/view/s20WvIuITK
AM43xx (AM437x GP EVM) : http://slexy.org/view/s213DqnSg5
[1] https://lkml.org/lkml/2014/6/12/470
[2] http://marc.info/?l=linux-omap&m=137582560717973&w=2
[3] http://marc.info/?l=linux-omap&m=140365705821115&w=2
[4] http://marc.info/?l=linux-omap&m=140365833121612&w=2
Suman Anna (6):
Documentation: dt: add omap mailbox bindings
mailbox/omap: add support for parsing dt devices
ARM: dts: OMAP2+: Add sub mailboxes device node information
mailbox/omap: adapt to the new mailbox framework
ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes
mailbox/omap: add a custom of_xlate function
.../devicetree/bindings/mailbox/omap-mailbox.txt | 104 ++++
arch/arm/boot/dts/am33xx.dtsi | 5 +
arch/arm/boot/dts/am4372.dtsi | 5 +
arch/arm/boot/dts/dra7.dtsi | 13 +
arch/arm/boot/dts/omap2420.dtsi | 9 +
arch/arm/boot/dts/omap2430.dtsi | 5 +
arch/arm/boot/dts/omap3.dtsi | 5 +
arch/arm/boot/dts/omap4.dtsi | 9 +
arch/arm/boot/dts/omap5.dtsi | 9 +
drivers/mailbox/omap-mailbox.c | 544 ++++++++++++++-------
drivers/remoteproc/omap_remoteproc.c | 54 +-
drivers/staging/tidspbridge/core/_tiomap.h | 3 +-
drivers/staging/tidspbridge/core/io_sm.c | 7 +-
drivers/staging/tidspbridge/core/tiomap3430.c | 22 +-
drivers/staging/tidspbridge/core/tiomap_io.c | 7 +-
.../tidspbridge/include/dspbridge/host_os.h | 1 +
.../staging/tidspbridge/include/dspbridge/io_sm.h | 8 +-
include/linux/omap-mailbox.h | 15 +-
18 files changed, 598 insertions(+), 227 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
--
2.0.0
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 0/6] OMAP Mailbox framework adoption & DT support
@ 2014-06-25 1:47 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The first 3 patches in this series adds the DT bindings and the DT-parse
support to the OMAP mailbox driver. The last 3 patches make the changes
to adopt to the v7 version of mailbox framework from Jassi Brar [1]. I
have posted all the patches together since both touch the bindings and
dictate the usage for the OMAP mailbox clients. The current OMAP mailbox
clients - omap remoteproc and tidspbridge have also been converted to use
the new api.
The DT-support patches incorporates feedback from the last DT adoption
series [2], with the following main changes:
- Leverages more compatible strings
- Dropped the properties "ti,mbox-num-users" and "ti,mbox-num-fifos";
with these values retrieved through driver match data and compatible
strings
- Dropped the properties "ti,mbox-names" and "ti,mbox-data" that were
used to represent the sub-mailbox devices, which are now represented
as child nodes of the respective mailbox controller device node.
The series depends on the OMAP mailbox cleanup series [3] and the OMAP
mailbox DT/hwmod cleanup series [4].
The following shows the boot/validation logs on various OMAP platforms:
OMAP2 (SDP2430) : http://slexy.org/view/s20VHd3CIc
OMAP3 (BeagleXM) : http://slexy.org/view/s204yxxE7Q
OMAP4 (PandaBoard) : http://slexy.org/view/s20GDw9Lxq
OMAP5 (OMAP5 uEVM) : http://slexy.org/view/s201gZlzSB
DRA7 (DRA7 EVM) : http://slexy.org/view/s2CPnJ1Boz
AM33xx (BeagleBone Black) : http://slexy.org/view/s20WvIuITK
AM43xx (AM437x GP EVM) : http://slexy.org/view/s213DqnSg5
[1] https://lkml.org/lkml/2014/6/12/470
[2] http://marc.info/?l=linux-omap&m=137582560717973&w=2
[3] http://marc.info/?l=linux-omap&m=140365705821115&w=2
[4] http://marc.info/?l=linux-omap&m=140365833121612&w=2
Suman Anna (6):
Documentation: dt: add omap mailbox bindings
mailbox/omap: add support for parsing dt devices
ARM: dts: OMAP2+: Add sub mailboxes device node information
mailbox/omap: adapt to the new mailbox framework
ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes
mailbox/omap: add a custom of_xlate function
.../devicetree/bindings/mailbox/omap-mailbox.txt | 104 ++++
arch/arm/boot/dts/am33xx.dtsi | 5 +
arch/arm/boot/dts/am4372.dtsi | 5 +
arch/arm/boot/dts/dra7.dtsi | 13 +
arch/arm/boot/dts/omap2420.dtsi | 9 +
arch/arm/boot/dts/omap2430.dtsi | 5 +
arch/arm/boot/dts/omap3.dtsi | 5 +
arch/arm/boot/dts/omap4.dtsi | 9 +
arch/arm/boot/dts/omap5.dtsi | 9 +
drivers/mailbox/omap-mailbox.c | 544 ++++++++++++++-------
drivers/remoteproc/omap_remoteproc.c | 54 +-
drivers/staging/tidspbridge/core/_tiomap.h | 3 +-
drivers/staging/tidspbridge/core/io_sm.c | 7 +-
drivers/staging/tidspbridge/core/tiomap3430.c | 22 +-
drivers/staging/tidspbridge/core/tiomap_io.c | 7 +-
.../tidspbridge/include/dspbridge/host_os.h | 1 +
.../staging/tidspbridge/include/dspbridge/io_sm.h | 8 +-
include/linux/omap-mailbox.h | 15 +-
18 files changed, 598 insertions(+), 227 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
--
2.0.0
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 1/6] Documentation: dt: add omap mailbox bindings
2014-06-25 1:47 ` Suman Anna
(?)
@ 2014-06-25 1:47 ` Suman Anna
-1 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jassi Brar, Dave Gerlach, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Suman Anna, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala
Add the device tree bindings document for OMAP2+ mailbox.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
.../devicetree/bindings/mailbox/omap-mailbox.txt | 104 +++++++++++++++++++++
1 file changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
new file mode 100644
index 0000000..307c4bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -0,0 +1,104 @@
+OMAP2+ Mailbox Driver
+=====================
+
+The OMAP mailbox hardware facilitates communication between different processors
+using a queued mailbox interrupt mechanism. The IP block is external to the
+various processor subsystems and is connected on an interconnect bus. The
+communication is achieved through a set of registers for message storage and
+interrupt configuration registers.
+
+Each mailbox IP block has a certain number of h/w fifo queues and output
+interrupt lines. An output interrupt line is routed to an interrupt controller
+within a processor subsystem, and there can be more than one line going to a
+specific processor's interrupt controller. The interrupt line connections are
+fixed for an instance and are dictated by the IP integration into the SoC
+(excluding the SoCs that have a Interrupt Crossbar IP). Each interrupt line is
+programmable through a set of interrupt configuration registers, and have a rx
+and tx interrupt source per h/w fifo. Communication between different processors
+is achieved through the appropriate programming of the rx and tx interrupt
+sources on the appropriate interrupt lines.
+
+The number of h/w fifo queues and interrupt lines dictate the usable registers.
+All the current OMAP SoCs except for the newest DRA7xx SoC has a single IP
+instance. DRA7xx has multiple instances with different number of h/w fifo queues
+and interrupt lines between different instances. The interrupt lines can also be
+routed to different processor sub-systems on DRA7xx as they are routed through
+the Crossbar, a kind of interrupt router/multiplexer.
+
+Mailbox Device Node:
+====================
+A Mailbox device node is used to represent a Mailbox IP instance within a SoC.
+The sub-mailboxes are represented as child node of this parent node.
+
+Required properties:
+--------------------
+- compatible: Should be one of the following,
+ "ti,omap2-mailbox" for OMAP2420, OMAP2430 SoCs
+ "ti,omap3-mailbox" for OMAP3430, OMAP3630 SoCs
+ "ti,am3352-mailbox" for AM33xx SoCs
+ "ti,am4372-mailbox" for AM43xx SoCs
+ "ti,omap4-mailbox" for OMAP44xx, OMAP54xx SoCs and
+ DRA7xx Mailbox1 instance
+ "ti,dra7-mailbox" for DRA7xx (except for Mailbox1
+ instance)
+- reg: Contains the mailbox register address range (base
+ address and length)
+- interrupts: Contains the interrupt information for the mailbox
+ device. The format is dependent on which interrupt
+ controller the OMAP device uses
+- ti,hwmods: Name of the hwmod associated with the mailbox
+
+Child Nodes:
+============
+A child node is used for representing the actual sub-mailbox device that is
+used for the communication between the host processor and a remote processor.
+Each child node should have a unique node name.
+
+Required properties:
+--------------------
+- ti,mbox-tx: sub-mailbox descriptor property defining a Tx fifo
+- ti,mbox-rx: sub-mailbox descriptor property defining a Rx fifo
+
+Sub-mailbox Descriptor Data
+---------------------------
+Each of the above ti,mbox-tx and ti,mbox-rx properties should have 3 cells of
+data that represent the following:
+ Cell #1 (fifo_id) - mailbox fifo id used either for transmitting
+ (ti,mbox-tx) or for receiving (ti,mbox-rx)
+ Cell #2 (irq_id) - irq identifier index number to use from the parent's
+ interrupts data. Should be 0 for most of the cases, a
+ positive index value is seen only on mailboxes that have
+ multiple interrupt lines connected to the MPU processor.
+ Cell #3 (usr_id) - mailbox user id for identifying the interrupt line
+ associated with generating a tx/rx fifo interrupt.
+
+Example:
+--------
+
+/* OMAP4 */
+mailbox: mailbox@4a0f4000 {
+ compatible = "ti,omap4-mailbox";
+ reg = <0x4a0f4000 0x200>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+ ti,hwmods = "mailbox";
+ mbox_ipu: mbox_ipu {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <1 0 0>;
+ };
+ mbox_dsp: mbox_dsp {
+ ti,mbox-tx = <3 0 0>;
+ ti,mbox-rx = <2 0 0>;
+ };
+};
+
+/* AM33xx */
+mailbox: mailbox@480C8000 {
+ compatible = "ti,am3352-mailbox";
+ reg = <0x480C8000 0x200>;
+ interrupts = <77>;
+ ti,hwmods = "mailbox";
+ mbox_wkupm3: wkup_m3 {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <0 0 3>;
+ };
+};
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 1/6] Documentation: dt: add omap mailbox bindings
@ 2014-06-25 1:47 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jassi Brar, Dave Gerlach, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Suman Anna, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala
Add the device tree bindings document for OMAP2+ mailbox.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
.../devicetree/bindings/mailbox/omap-mailbox.txt | 104 +++++++++++++++++++++
1 file changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
new file mode 100644
index 0000000..307c4bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -0,0 +1,104 @@
+OMAP2+ Mailbox Driver
+=====================
+
+The OMAP mailbox hardware facilitates communication between different processors
+using a queued mailbox interrupt mechanism. The IP block is external to the
+various processor subsystems and is connected on an interconnect bus. The
+communication is achieved through a set of registers for message storage and
+interrupt configuration registers.
+
+Each mailbox IP block has a certain number of h/w fifo queues and output
+interrupt lines. An output interrupt line is routed to an interrupt controller
+within a processor subsystem, and there can be more than one line going to a
+specific processor's interrupt controller. The interrupt line connections are
+fixed for an instance and are dictated by the IP integration into the SoC
+(excluding the SoCs that have a Interrupt Crossbar IP). Each interrupt line is
+programmable through a set of interrupt configuration registers, and have a rx
+and tx interrupt source per h/w fifo. Communication between different processors
+is achieved through the appropriate programming of the rx and tx interrupt
+sources on the appropriate interrupt lines.
+
+The number of h/w fifo queues and interrupt lines dictate the usable registers.
+All the current OMAP SoCs except for the newest DRA7xx SoC has a single IP
+instance. DRA7xx has multiple instances with different number of h/w fifo queues
+and interrupt lines between different instances. The interrupt lines can also be
+routed to different processor sub-systems on DRA7xx as they are routed through
+the Crossbar, a kind of interrupt router/multiplexer.
+
+Mailbox Device Node:
+====================
+A Mailbox device node is used to represent a Mailbox IP instance within a SoC.
+The sub-mailboxes are represented as child node of this parent node.
+
+Required properties:
+--------------------
+- compatible: Should be one of the following,
+ "ti,omap2-mailbox" for OMAP2420, OMAP2430 SoCs
+ "ti,omap3-mailbox" for OMAP3430, OMAP3630 SoCs
+ "ti,am3352-mailbox" for AM33xx SoCs
+ "ti,am4372-mailbox" for AM43xx SoCs
+ "ti,omap4-mailbox" for OMAP44xx, OMAP54xx SoCs and
+ DRA7xx Mailbox1 instance
+ "ti,dra7-mailbox" for DRA7xx (except for Mailbox1
+ instance)
+- reg: Contains the mailbox register address range (base
+ address and length)
+- interrupts: Contains the interrupt information for the mailbox
+ device. The format is dependent on which interrupt
+ controller the OMAP device uses
+- ti,hwmods: Name of the hwmod associated with the mailbox
+
+Child Nodes:
+============
+A child node is used for representing the actual sub-mailbox device that is
+used for the communication between the host processor and a remote processor.
+Each child node should have a unique node name.
+
+Required properties:
+--------------------
+- ti,mbox-tx: sub-mailbox descriptor property defining a Tx fifo
+- ti,mbox-rx: sub-mailbox descriptor property defining a Rx fifo
+
+Sub-mailbox Descriptor Data
+---------------------------
+Each of the above ti,mbox-tx and ti,mbox-rx properties should have 3 cells of
+data that represent the following:
+ Cell #1 (fifo_id) - mailbox fifo id used either for transmitting
+ (ti,mbox-tx) or for receiving (ti,mbox-rx)
+ Cell #2 (irq_id) - irq identifier index number to use from the parent's
+ interrupts data. Should be 0 for most of the cases, a
+ positive index value is seen only on mailboxes that have
+ multiple interrupt lines connected to the MPU processor.
+ Cell #3 (usr_id) - mailbox user id for identifying the interrupt line
+ associated with generating a tx/rx fifo interrupt.
+
+Example:
+--------
+
+/* OMAP4 */
+mailbox: mailbox@4a0f4000 {
+ compatible = "ti,omap4-mailbox";
+ reg = <0x4a0f4000 0x200>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+ ti,hwmods = "mailbox";
+ mbox_ipu: mbox_ipu {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <1 0 0>;
+ };
+ mbox_dsp: mbox_dsp {
+ ti,mbox-tx = <3 0 0>;
+ ti,mbox-rx = <2 0 0>;
+ };
+};
+
+/* AM33xx */
+mailbox: mailbox@480C8000 {
+ compatible = "ti,am3352-mailbox";
+ reg = <0x480C8000 0x200>;
+ interrupts = <77>;
+ ti,hwmods = "mailbox";
+ mbox_wkupm3: wkup_m3 {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <0 0 3>;
+ };
+};
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 1/6] Documentation: dt: add omap mailbox bindings
@ 2014-06-25 1:47 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: linux-arm-kernel
Add the device tree bindings document for OMAP2+ mailbox.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
.../devicetree/bindings/mailbox/omap-mailbox.txt | 104 +++++++++++++++++++++
1 file changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
new file mode 100644
index 0000000..307c4bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -0,0 +1,104 @@
+OMAP2+ Mailbox Driver
+=====================
+
+The OMAP mailbox hardware facilitates communication between different processors
+using a queued mailbox interrupt mechanism. The IP block is external to the
+various processor subsystems and is connected on an interconnect bus. The
+communication is achieved through a set of registers for message storage and
+interrupt configuration registers.
+
+Each mailbox IP block has a certain number of h/w fifo queues and output
+interrupt lines. An output interrupt line is routed to an interrupt controller
+within a processor subsystem, and there can be more than one line going to a
+specific processor's interrupt controller. The interrupt line connections are
+fixed for an instance and are dictated by the IP integration into the SoC
+(excluding the SoCs that have a Interrupt Crossbar IP). Each interrupt line is
+programmable through a set of interrupt configuration registers, and have a rx
+and tx interrupt source per h/w fifo. Communication between different processors
+is achieved through the appropriate programming of the rx and tx interrupt
+sources on the appropriate interrupt lines.
+
+The number of h/w fifo queues and interrupt lines dictate the usable registers.
+All the current OMAP SoCs except for the newest DRA7xx SoC has a single IP
+instance. DRA7xx has multiple instances with different number of h/w fifo queues
+and interrupt lines between different instances. The interrupt lines can also be
+routed to different processor sub-systems on DRA7xx as they are routed through
+the Crossbar, a kind of interrupt router/multiplexer.
+
+Mailbox Device Node:
+====================
+A Mailbox device node is used to represent a Mailbox IP instance within a SoC.
+The sub-mailboxes are represented as child node of this parent node.
+
+Required properties:
+--------------------
+- compatible: Should be one of the following,
+ "ti,omap2-mailbox" for OMAP2420, OMAP2430 SoCs
+ "ti,omap3-mailbox" for OMAP3430, OMAP3630 SoCs
+ "ti,am3352-mailbox" for AM33xx SoCs
+ "ti,am4372-mailbox" for AM43xx SoCs
+ "ti,omap4-mailbox" for OMAP44xx, OMAP54xx SoCs and
+ DRA7xx Mailbox1 instance
+ "ti,dra7-mailbox" for DRA7xx (except for Mailbox1
+ instance)
+- reg: Contains the mailbox register address range (base
+ address and length)
+- interrupts: Contains the interrupt information for the mailbox
+ device. The format is dependent on which interrupt
+ controller the OMAP device uses
+- ti,hwmods: Name of the hwmod associated with the mailbox
+
+Child Nodes:
+============
+A child node is used for representing the actual sub-mailbox device that is
+used for the communication between the host processor and a remote processor.
+Each child node should have a unique node name.
+
+Required properties:
+--------------------
+- ti,mbox-tx: sub-mailbox descriptor property defining a Tx fifo
+- ti,mbox-rx: sub-mailbox descriptor property defining a Rx fifo
+
+Sub-mailbox Descriptor Data
+---------------------------
+Each of the above ti,mbox-tx and ti,mbox-rx properties should have 3 cells of
+data that represent the following:
+ Cell #1 (fifo_id) - mailbox fifo id used either for transmitting
+ (ti,mbox-tx) or for receiving (ti,mbox-rx)
+ Cell #2 (irq_id) - irq identifier index number to use from the parent's
+ interrupts data. Should be 0 for most of the cases, a
+ positive index value is seen only on mailboxes that have
+ multiple interrupt lines connected to the MPU processor.
+ Cell #3 (usr_id) - mailbox user id for identifying the interrupt line
+ associated with generating a tx/rx fifo interrupt.
+
+Example:
+--------
+
+/* OMAP4 */
+mailbox: mailbox at 4a0f4000 {
+ compatible = "ti,omap4-mailbox";
+ reg = <0x4a0f4000 0x200>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+ ti,hwmods = "mailbox";
+ mbox_ipu: mbox_ipu {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <1 0 0>;
+ };
+ mbox_dsp: mbox_dsp {
+ ti,mbox-tx = <3 0 0>;
+ ti,mbox-rx = <2 0 0>;
+ };
+};
+
+/* AM33xx */
+mailbox: mailbox at 480C8000 {
+ compatible = "ti,am3352-mailbox";
+ reg = <0x480C8000 0x200>;
+ interrupts = <77>;
+ ti,hwmods = "mailbox";
+ mbox_wkupm3: wkup_m3 {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <0 0 3>;
+ };
+};
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 2/6] mailbox/omap: add support for parsing dt devices
2014-06-25 1:47 ` Suman Anna
(?)
@ 2014-06-25 1:47 ` Suman Anna
-1 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jassi Brar, Dave Gerlach, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Suman Anna, Jassi Brar, Rob Herring
Logic has been added to the OMAP2+ mailbox code to parse the
mailbox dt nodes and construct the different sub-mailboxes
associated with the instance. The DT representation of the
sub-mailbox devices is different from legacy platform data
representation to allow flexibility of interrupt configuration
between Tx and Rx fifos (to also possibly allow simplex devices
in the future). The DT representation gathers similar information
that was being passed previously through the platform data, except
for the number of fifos, interrupts and interrupt type information,
which are gathered through driver compatible match data.
The non-DT support has to be maintained for now to not break
OMAP3 legacy boot, and the legacy-style code will be cleaned
up once OMAP3 is also converted to DT-boot only.
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/mailbox/omap-mailbox.c | 201 ++++++++++++++++++++++++++++++++++++-----
1 file changed, 177 insertions(+), 24 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index a27e00e..c61435b 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -31,6 +31,7 @@
#include <linux/err.h>
#include <linux/notifier.h>
#include <linux/module.h>
+#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/platform_data/mailbox-omap.h>
@@ -94,6 +95,24 @@ struct omap_mbox_device {
struct list_head elem;
};
+struct omap_mbox_fifo_info {
+ int tx_id;
+ int tx_usr;
+ int tx_irq;
+
+ int rx_id;
+ int rx_usr;
+ int rx_irq;
+
+ const char *name;
+};
+
+struct omap_mbox_device_data {
+ u32 num_users;
+ u32 num_fifos;
+ u32 intr_type;
+};
+
struct omap_mbox {
const char *name;
int irq;
@@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
return 0;
}
+static const struct omap_mbox_device_data omap2_data = {
+ .num_users = 4,
+ .num_fifos = 6,
+ .intr_type = MBOX_INTR_CFG_TYPE1,
+};
+
+static const struct omap_mbox_device_data omap3_data = {
+ .num_users = 2,
+ .num_fifos = 2,
+ .intr_type = MBOX_INTR_CFG_TYPE1,
+};
+
+static const struct omap_mbox_device_data am335x_data = {
+ .num_users = 4,
+ .num_fifos = 8,
+ .intr_type = MBOX_INTR_CFG_TYPE2,
+};
+
+static const struct omap_mbox_device_data omap4_data = {
+ .num_users = 3,
+ .num_fifos = 8,
+ .intr_type = MBOX_INTR_CFG_TYPE2,
+};
+
+static const struct omap_mbox_device_data dra7_data = {
+ .num_users = 4,
+ .num_fifos = 12,
+ .intr_type = MBOX_INTR_CFG_TYPE2,
+};
+
+static const struct of_device_id omap_mailbox_of_match[] = {
+ {
+ .compatible = "ti,omap2-mailbox",
+ .data = &omap2_data,
+ },
+ {
+ .compatible = "ti,omap3-mailbox",
+ .data = &omap3_data,
+ },
+ {
+ .compatible = "ti,am3352-mailbox",
+ .data = &am335x_data,
+ },
+ {
+ .compatible = "ti,omap4-mailbox",
+ .data = &omap4_data,
+ },
+ {
+ .compatible = "ti,am4372-mailbox",
+ .data = &am335x_data,
+ },
+ {
+ .compatible = "ti,dra7-mailbox",
+ .data = &dra7_data,
+ },
+ {
+ /* end */
+ },
+};
+MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
+
static int omap_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
int ret;
struct omap_mbox **list, *mbox, *mboxblk;
struct omap_mbox_pdata *pdata = pdev->dev.platform_data;
- struct omap_mbox_dev_info *info;
+ struct omap_mbox_dev_info *info = NULL;
+ struct omap_mbox_device_data *data;
+ struct omap_mbox_fifo_info *finfo, *finfoblk;
struct omap_mbox_device *mdev;
struct omap_mbox_fifo *fifo;
- u32 intr_type;
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *child;
+ const struct of_device_id *match;
+ u32 intr_type, info_count;
+ u32 num_users, num_fifos;
+ u32 tmp[3];
u32 l;
int i;
- if (!pdata || !pdata->info_cnt || !pdata->info) {
+ if (!node && (!pdata || !pdata->info_cnt || !pdata->info)) {
pr_err("%s: platform not supported\n", __func__);
return -ENODEV;
}
+ if (node) {
+ match = of_match_device(omap_mailbox_of_match, &pdev->dev);
+ if (!match)
+ return -ENODEV;
+ data = (struct omap_mbox_device_data *)match->data;
+
+ info_count = of_get_available_child_count(node);
+ if (!info_count) {
+ dev_err(&pdev->dev, "no available mbox devices found\n");
+ return -ENODEV;
+ }
+
+ intr_type = data->intr_type;
+ num_users = data->num_users;
+ num_fifos = data->num_fifos;
+ } else { /* non-DT device creation */
+ info_count = pdata->info_cnt;
+ info = pdata->info;
+ intr_type = pdata->intr_type;
+ num_users = pdata->num_users;
+ num_fifos = pdata->num_fifos;
+ }
+
+ finfoblk = devm_kzalloc(&pdev->dev, info_count * sizeof(*finfoblk),
+ GFP_KERNEL);
+ if (!finfoblk)
+ return -ENOMEM;
+
+ finfo = finfoblk;
+ child = NULL;
+ for (i = 0; i < info_count; i++, finfo++) {
+ if (!node) {
+ finfo->tx_id = info->tx_id;
+ finfo->rx_id = info->rx_id;
+ finfo->tx_usr = info->usr_id;
+ finfo->tx_irq = info->irq_id;
+ finfo->rx_usr = info->usr_id;
+ finfo->rx_irq = info->irq_id;
+ finfo->name = info->name;
+ info++;
+ } else {
+ child = of_get_next_available_child(node, child);
+ ret = of_property_read_u32_array(child, "ti,mbox-tx",
+ tmp, ARRAY_SIZE(tmp));
+ if (ret)
+ return ret;
+ finfo->tx_id = tmp[0];
+ finfo->tx_irq = tmp[1];
+ finfo->tx_usr = tmp[2];
+
+ ret = of_property_read_u32_array(child, "ti,mbox-rx",
+ tmp, ARRAY_SIZE(tmp));
+ if (ret)
+ return ret;
+ finfo->rx_id = tmp[0];
+ finfo->rx_irq = tmp[1];
+ finfo->rx_usr = tmp[2];
+
+ finfo->name = child->name;
+ }
+ if (finfo->tx_id >= num_fifos || finfo->rx_id >= num_fifos ||
+ finfo->tx_usr >= num_users || finfo->rx_usr >= num_users)
+ return -EINVAL;
+ }
+
mdev = devm_kzalloc(&pdev->dev, sizeof(*mdev), GFP_KERNEL);
if (!mdev)
return -ENOMEM;
@@ -615,41 +767,40 @@ static int omap_mbox_probe(struct platform_device *pdev)
return PTR_ERR(mdev->mbox_base);
/* allocate one extra for marking end of list */
- list = devm_kzalloc(&pdev->dev, (pdata->info_cnt + 1) * sizeof(*list),
+ list = devm_kzalloc(&pdev->dev, (info_count + 1) * sizeof(*list),
GFP_KERNEL);
if (!list)
return -ENOMEM;
- mboxblk = devm_kzalloc(&pdev->dev, pdata->info_cnt * sizeof(*mbox),
+ mboxblk = devm_kzalloc(&pdev->dev, info_count * sizeof(*mbox),
GFP_KERNEL);
if (!mboxblk)
return -ENOMEM;
- info = pdata->info;
- intr_type = pdata->intr_type;
mbox = mboxblk;
- for (i = 0; i < pdata->info_cnt; i++, info++) {
+ finfo = finfoblk;
+ for (i = 0; i < info_count; i++, finfo++) {
fifo = &mbox->tx_fifo;
- fifo->msg = MAILBOX_MESSAGE(info->tx_id);
- fifo->fifo_stat = MAILBOX_FIFOSTATUS(info->tx_id);
- fifo->intr_bit = MAILBOX_IRQ_NOTFULL(info->tx_id);
- fifo->irqenable = MAILBOX_IRQENABLE(intr_type, info->usr_id);
- fifo->irqstatus = MAILBOX_IRQSTATUS(intr_type, info->usr_id);
- fifo->irqdisable = MAILBOX_IRQDISABLE(intr_type, info->usr_id);
+ fifo->msg = MAILBOX_MESSAGE(finfo->tx_id);
+ fifo->fifo_stat = MAILBOX_FIFOSTATUS(finfo->tx_id);
+ fifo->intr_bit = MAILBOX_IRQ_NOTFULL(finfo->tx_id);
+ fifo->irqenable = MAILBOX_IRQENABLE(intr_type, finfo->tx_usr);
+ fifo->irqstatus = MAILBOX_IRQSTATUS(intr_type, finfo->tx_usr);
+ fifo->irqdisable = MAILBOX_IRQDISABLE(intr_type, finfo->tx_usr);
fifo = &mbox->rx_fifo;
- fifo->msg = MAILBOX_MESSAGE(info->rx_id);
- fifo->msg_stat = MAILBOX_MSGSTATUS(info->rx_id);
- fifo->intr_bit = MAILBOX_IRQ_NEWMSG(info->rx_id);
- fifo->irqenable = MAILBOX_IRQENABLE(intr_type, info->usr_id);
- fifo->irqstatus = MAILBOX_IRQSTATUS(intr_type, info->usr_id);
- fifo->irqdisable = MAILBOX_IRQDISABLE(intr_type, info->usr_id);
+ fifo->msg = MAILBOX_MESSAGE(finfo->rx_id);
+ fifo->msg_stat = MAILBOX_MSGSTATUS(finfo->rx_id);
+ fifo->intr_bit = MAILBOX_IRQ_NEWMSG(finfo->rx_id);
+ fifo->irqenable = MAILBOX_IRQENABLE(intr_type, finfo->rx_usr);
+ fifo->irqstatus = MAILBOX_IRQSTATUS(intr_type, finfo->rx_usr);
+ fifo->irqdisable = MAILBOX_IRQDISABLE(intr_type, finfo->rx_usr);
mbox->intr_type = intr_type;
mbox->parent = mdev;
- mbox->name = info->name;
- mbox->irq = platform_get_irq(pdev, info->irq_id);
+ mbox->name = finfo->name;
+ mbox->irq = platform_get_irq(pdev, finfo->tx_irq);
if (mbox->irq < 0)
return mbox->irq;
list[i] = mbox++;
@@ -657,8 +808,8 @@ static int omap_mbox_probe(struct platform_device *pdev)
mutex_init(&mdev->cfg_lock);
mdev->dev = &pdev->dev;
- mdev->num_users = pdata->num_users;
- mdev->num_fifos = pdata->num_fifos;
+ mdev->num_users = num_users;
+ mdev->num_fifos = num_fifos;
mdev->mboxes = list;
ret = omap_mbox_register(mdev);
if (ret)
@@ -684,6 +835,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
if (ret < 0)
goto unregister;
+ devm_kfree(&pdev->dev, finfoblk);
return 0;
unregister:
@@ -708,6 +860,7 @@ static struct platform_driver omap_mbox_driver = {
.driver = {
.name = "omap-mailbox",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(omap_mailbox_of_match),
},
};
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-06-25 1:47 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jassi Brar, Dave Gerlach, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Suman Anna, Jassi Brar, Rob Herring
Logic has been added to the OMAP2+ mailbox code to parse the
mailbox dt nodes and construct the different sub-mailboxes
associated with the instance. The DT representation of the
sub-mailbox devices is different from legacy platform data
representation to allow flexibility of interrupt configuration
between Tx and Rx fifos (to also possibly allow simplex devices
in the future). The DT representation gathers similar information
that was being passed previously through the platform data, except
for the number of fifos, interrupts and interrupt type information,
which are gathered through driver compatible match data.
The non-DT support has to be maintained for now to not break
OMAP3 legacy boot, and the legacy-style code will be cleaned
up once OMAP3 is also converted to DT-boot only.
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/mailbox/omap-mailbox.c | 201 ++++++++++++++++++++++++++++++++++++-----
1 file changed, 177 insertions(+), 24 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index a27e00e..c61435b 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -31,6 +31,7 @@
#include <linux/err.h>
#include <linux/notifier.h>
#include <linux/module.h>
+#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/platform_data/mailbox-omap.h>
@@ -94,6 +95,24 @@ struct omap_mbox_device {
struct list_head elem;
};
+struct omap_mbox_fifo_info {
+ int tx_id;
+ int tx_usr;
+ int tx_irq;
+
+ int rx_id;
+ int rx_usr;
+ int rx_irq;
+
+ const char *name;
+};
+
+struct omap_mbox_device_data {
+ u32 num_users;
+ u32 num_fifos;
+ u32 intr_type;
+};
+
struct omap_mbox {
const char *name;
int irq;
@@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
return 0;
}
+static const struct omap_mbox_device_data omap2_data = {
+ .num_users = 4,
+ .num_fifos = 6,
+ .intr_type = MBOX_INTR_CFG_TYPE1,
+};
+
+static const struct omap_mbox_device_data omap3_data = {
+ .num_users = 2,
+ .num_fifos = 2,
+ .intr_type = MBOX_INTR_CFG_TYPE1,
+};
+
+static const struct omap_mbox_device_data am335x_data = {
+ .num_users = 4,
+ .num_fifos = 8,
+ .intr_type = MBOX_INTR_CFG_TYPE2,
+};
+
+static const struct omap_mbox_device_data omap4_data = {
+ .num_users = 3,
+ .num_fifos = 8,
+ .intr_type = MBOX_INTR_CFG_TYPE2,
+};
+
+static const struct omap_mbox_device_data dra7_data = {
+ .num_users = 4,
+ .num_fifos = 12,
+ .intr_type = MBOX_INTR_CFG_TYPE2,
+};
+
+static const struct of_device_id omap_mailbox_of_match[] = {
+ {
+ .compatible = "ti,omap2-mailbox",
+ .data = &omap2_data,
+ },
+ {
+ .compatible = "ti,omap3-mailbox",
+ .data = &omap3_data,
+ },
+ {
+ .compatible = "ti,am3352-mailbox",
+ .data = &am335x_data,
+ },
+ {
+ .compatible = "ti,omap4-mailbox",
+ .data = &omap4_data,
+ },
+ {
+ .compatible = "ti,am4372-mailbox",
+ .data = &am335x_data,
+ },
+ {
+ .compatible = "ti,dra7-mailbox",
+ .data = &dra7_data,
+ },
+ {
+ /* end */
+ },
+};
+MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
+
static int omap_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
int ret;
struct omap_mbox **list, *mbox, *mboxblk;
struct omap_mbox_pdata *pdata = pdev->dev.platform_data;
- struct omap_mbox_dev_info *info;
+ struct omap_mbox_dev_info *info = NULL;
+ struct omap_mbox_device_data *data;
+ struct omap_mbox_fifo_info *finfo, *finfoblk;
struct omap_mbox_device *mdev;
struct omap_mbox_fifo *fifo;
- u32 intr_type;
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *child;
+ const struct of_device_id *match;
+ u32 intr_type, info_count;
+ u32 num_users, num_fifos;
+ u32 tmp[3];
u32 l;
int i;
- if (!pdata || !pdata->info_cnt || !pdata->info) {
+ if (!node && (!pdata || !pdata->info_cnt || !pdata->info)) {
pr_err("%s: platform not supported\n", __func__);
return -ENODEV;
}
+ if (node) {
+ match = of_match_device(omap_mailbox_of_match, &pdev->dev);
+ if (!match)
+ return -ENODEV;
+ data = (struct omap_mbox_device_data *)match->data;
+
+ info_count = of_get_available_child_count(node);
+ if (!info_count) {
+ dev_err(&pdev->dev, "no available mbox devices found\n");
+ return -ENODEV;
+ }
+
+ intr_type = data->intr_type;
+ num_users = data->num_users;
+ num_fifos = data->num_fifos;
+ } else { /* non-DT device creation */
+ info_count = pdata->info_cnt;
+ info = pdata->info;
+ intr_type = pdata->intr_type;
+ num_users = pdata->num_users;
+ num_fifos = pdata->num_fifos;
+ }
+
+ finfoblk = devm_kzalloc(&pdev->dev, info_count * sizeof(*finfoblk),
+ GFP_KERNEL);
+ if (!finfoblk)
+ return -ENOMEM;
+
+ finfo = finfoblk;
+ child = NULL;
+ for (i = 0; i < info_count; i++, finfo++) {
+ if (!node) {
+ finfo->tx_id = info->tx_id;
+ finfo->rx_id = info->rx_id;
+ finfo->tx_usr = info->usr_id;
+ finfo->tx_irq = info->irq_id;
+ finfo->rx_usr = info->usr_id;
+ finfo->rx_irq = info->irq_id;
+ finfo->name = info->name;
+ info++;
+ } else {
+ child = of_get_next_available_child(node, child);
+ ret = of_property_read_u32_array(child, "ti,mbox-tx",
+ tmp, ARRAY_SIZE(tmp));
+ if (ret)
+ return ret;
+ finfo->tx_id = tmp[0];
+ finfo->tx_irq = tmp[1];
+ finfo->tx_usr = tmp[2];
+
+ ret = of_property_read_u32_array(child, "ti,mbox-rx",
+ tmp, ARRAY_SIZE(tmp));
+ if (ret)
+ return ret;
+ finfo->rx_id = tmp[0];
+ finfo->rx_irq = tmp[1];
+ finfo->rx_usr = tmp[2];
+
+ finfo->name = child->name;
+ }
+ if (finfo->tx_id >= num_fifos || finfo->rx_id >= num_fifos ||
+ finfo->tx_usr >= num_users || finfo->rx_usr >= num_users)
+ return -EINVAL;
+ }
+
mdev = devm_kzalloc(&pdev->dev, sizeof(*mdev), GFP_KERNEL);
if (!mdev)
return -ENOMEM;
@@ -615,41 +767,40 @@ static int omap_mbox_probe(struct platform_device *pdev)
return PTR_ERR(mdev->mbox_base);
/* allocate one extra for marking end of list */
- list = devm_kzalloc(&pdev->dev, (pdata->info_cnt + 1) * sizeof(*list),
+ list = devm_kzalloc(&pdev->dev, (info_count + 1) * sizeof(*list),
GFP_KERNEL);
if (!list)
return -ENOMEM;
- mboxblk = devm_kzalloc(&pdev->dev, pdata->info_cnt * sizeof(*mbox),
+ mboxblk = devm_kzalloc(&pdev->dev, info_count * sizeof(*mbox),
GFP_KERNEL);
if (!mboxblk)
return -ENOMEM;
- info = pdata->info;
- intr_type = pdata->intr_type;
mbox = mboxblk;
- for (i = 0; i < pdata->info_cnt; i++, info++) {
+ finfo = finfoblk;
+ for (i = 0; i < info_count; i++, finfo++) {
fifo = &mbox->tx_fifo;
- fifo->msg = MAILBOX_MESSAGE(info->tx_id);
- fifo->fifo_stat = MAILBOX_FIFOSTATUS(info->tx_id);
- fifo->intr_bit = MAILBOX_IRQ_NOTFULL(info->tx_id);
- fifo->irqenable = MAILBOX_IRQENABLE(intr_type, info->usr_id);
- fifo->irqstatus = MAILBOX_IRQSTATUS(intr_type, info->usr_id);
- fifo->irqdisable = MAILBOX_IRQDISABLE(intr_type, info->usr_id);
+ fifo->msg = MAILBOX_MESSAGE(finfo->tx_id);
+ fifo->fifo_stat = MAILBOX_FIFOSTATUS(finfo->tx_id);
+ fifo->intr_bit = MAILBOX_IRQ_NOTFULL(finfo->tx_id);
+ fifo->irqenable = MAILBOX_IRQENABLE(intr_type, finfo->tx_usr);
+ fifo->irqstatus = MAILBOX_IRQSTATUS(intr_type, finfo->tx_usr);
+ fifo->irqdisable = MAILBOX_IRQDISABLE(intr_type, finfo->tx_usr);
fifo = &mbox->rx_fifo;
- fifo->msg = MAILBOX_MESSAGE(info->rx_id);
- fifo->msg_stat = MAILBOX_MSGSTATUS(info->rx_id);
- fifo->intr_bit = MAILBOX_IRQ_NEWMSG(info->rx_id);
- fifo->irqenable = MAILBOX_IRQENABLE(intr_type, info->usr_id);
- fifo->irqstatus = MAILBOX_IRQSTATUS(intr_type, info->usr_id);
- fifo->irqdisable = MAILBOX_IRQDISABLE(intr_type, info->usr_id);
+ fifo->msg = MAILBOX_MESSAGE(finfo->rx_id);
+ fifo->msg_stat = MAILBOX_MSGSTATUS(finfo->rx_id);
+ fifo->intr_bit = MAILBOX_IRQ_NEWMSG(finfo->rx_id);
+ fifo->irqenable = MAILBOX_IRQENABLE(intr_type, finfo->rx_usr);
+ fifo->irqstatus = MAILBOX_IRQSTATUS(intr_type, finfo->rx_usr);
+ fifo->irqdisable = MAILBOX_IRQDISABLE(intr_type, finfo->rx_usr);
mbox->intr_type = intr_type;
mbox->parent = mdev;
- mbox->name = info->name;
- mbox->irq = platform_get_irq(pdev, info->irq_id);
+ mbox->name = finfo->name;
+ mbox->irq = platform_get_irq(pdev, finfo->tx_irq);
if (mbox->irq < 0)
return mbox->irq;
list[i] = mbox++;
@@ -657,8 +808,8 @@ static int omap_mbox_probe(struct platform_device *pdev)
mutex_init(&mdev->cfg_lock);
mdev->dev = &pdev->dev;
- mdev->num_users = pdata->num_users;
- mdev->num_fifos = pdata->num_fifos;
+ mdev->num_users = num_users;
+ mdev->num_fifos = num_fifos;
mdev->mboxes = list;
ret = omap_mbox_register(mdev);
if (ret)
@@ -684,6 +835,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
if (ret < 0)
goto unregister;
+ devm_kfree(&pdev->dev, finfoblk);
return 0;
unregister:
@@ -708,6 +860,7 @@ static struct platform_driver omap_mbox_driver = {
.driver = {
.name = "omap-mailbox",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(omap_mailbox_of_match),
},
};
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-06-25 1:47 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: linux-arm-kernel
Logic has been added to the OMAP2+ mailbox code to parse the
mailbox dt nodes and construct the different sub-mailboxes
associated with the instance. The DT representation of the
sub-mailbox devices is different from legacy platform data
representation to allow flexibility of interrupt configuration
between Tx and Rx fifos (to also possibly allow simplex devices
in the future). The DT representation gathers similar information
that was being passed previously through the platform data, except
for the number of fifos, interrupts and interrupt type information,
which are gathered through driver compatible match data.
The non-DT support has to be maintained for now to not break
OMAP3 legacy boot, and the legacy-style code will be cleaned
up once OMAP3 is also converted to DT-boot only.
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/mailbox/omap-mailbox.c | 201 ++++++++++++++++++++++++++++++++++++-----
1 file changed, 177 insertions(+), 24 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index a27e00e..c61435b 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -31,6 +31,7 @@
#include <linux/err.h>
#include <linux/notifier.h>
#include <linux/module.h>
+#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/platform_data/mailbox-omap.h>
@@ -94,6 +95,24 @@ struct omap_mbox_device {
struct list_head elem;
};
+struct omap_mbox_fifo_info {
+ int tx_id;
+ int tx_usr;
+ int tx_irq;
+
+ int rx_id;
+ int rx_usr;
+ int rx_irq;
+
+ const char *name;
+};
+
+struct omap_mbox_device_data {
+ u32 num_users;
+ u32 num_fifos;
+ u32 intr_type;
+};
+
struct omap_mbox {
const char *name;
int irq;
@@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
return 0;
}
+static const struct omap_mbox_device_data omap2_data = {
+ .num_users = 4,
+ .num_fifos = 6,
+ .intr_type = MBOX_INTR_CFG_TYPE1,
+};
+
+static const struct omap_mbox_device_data omap3_data = {
+ .num_users = 2,
+ .num_fifos = 2,
+ .intr_type = MBOX_INTR_CFG_TYPE1,
+};
+
+static const struct omap_mbox_device_data am335x_data = {
+ .num_users = 4,
+ .num_fifos = 8,
+ .intr_type = MBOX_INTR_CFG_TYPE2,
+};
+
+static const struct omap_mbox_device_data omap4_data = {
+ .num_users = 3,
+ .num_fifos = 8,
+ .intr_type = MBOX_INTR_CFG_TYPE2,
+};
+
+static const struct omap_mbox_device_data dra7_data = {
+ .num_users = 4,
+ .num_fifos = 12,
+ .intr_type = MBOX_INTR_CFG_TYPE2,
+};
+
+static const struct of_device_id omap_mailbox_of_match[] = {
+ {
+ .compatible = "ti,omap2-mailbox",
+ .data = &omap2_data,
+ },
+ {
+ .compatible = "ti,omap3-mailbox",
+ .data = &omap3_data,
+ },
+ {
+ .compatible = "ti,am3352-mailbox",
+ .data = &am335x_data,
+ },
+ {
+ .compatible = "ti,omap4-mailbox",
+ .data = &omap4_data,
+ },
+ {
+ .compatible = "ti,am4372-mailbox",
+ .data = &am335x_data,
+ },
+ {
+ .compatible = "ti,dra7-mailbox",
+ .data = &dra7_data,
+ },
+ {
+ /* end */
+ },
+};
+MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
+
static int omap_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
int ret;
struct omap_mbox **list, *mbox, *mboxblk;
struct omap_mbox_pdata *pdata = pdev->dev.platform_data;
- struct omap_mbox_dev_info *info;
+ struct omap_mbox_dev_info *info = NULL;
+ struct omap_mbox_device_data *data;
+ struct omap_mbox_fifo_info *finfo, *finfoblk;
struct omap_mbox_device *mdev;
struct omap_mbox_fifo *fifo;
- u32 intr_type;
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *child;
+ const struct of_device_id *match;
+ u32 intr_type, info_count;
+ u32 num_users, num_fifos;
+ u32 tmp[3];
u32 l;
int i;
- if (!pdata || !pdata->info_cnt || !pdata->info) {
+ if (!node && (!pdata || !pdata->info_cnt || !pdata->info)) {
pr_err("%s: platform not supported\n", __func__);
return -ENODEV;
}
+ if (node) {
+ match = of_match_device(omap_mailbox_of_match, &pdev->dev);
+ if (!match)
+ return -ENODEV;
+ data = (struct omap_mbox_device_data *)match->data;
+
+ info_count = of_get_available_child_count(node);
+ if (!info_count) {
+ dev_err(&pdev->dev, "no available mbox devices found\n");
+ return -ENODEV;
+ }
+
+ intr_type = data->intr_type;
+ num_users = data->num_users;
+ num_fifos = data->num_fifos;
+ } else { /* non-DT device creation */
+ info_count = pdata->info_cnt;
+ info = pdata->info;
+ intr_type = pdata->intr_type;
+ num_users = pdata->num_users;
+ num_fifos = pdata->num_fifos;
+ }
+
+ finfoblk = devm_kzalloc(&pdev->dev, info_count * sizeof(*finfoblk),
+ GFP_KERNEL);
+ if (!finfoblk)
+ return -ENOMEM;
+
+ finfo = finfoblk;
+ child = NULL;
+ for (i = 0; i < info_count; i++, finfo++) {
+ if (!node) {
+ finfo->tx_id = info->tx_id;
+ finfo->rx_id = info->rx_id;
+ finfo->tx_usr = info->usr_id;
+ finfo->tx_irq = info->irq_id;
+ finfo->rx_usr = info->usr_id;
+ finfo->rx_irq = info->irq_id;
+ finfo->name = info->name;
+ info++;
+ } else {
+ child = of_get_next_available_child(node, child);
+ ret = of_property_read_u32_array(child, "ti,mbox-tx",
+ tmp, ARRAY_SIZE(tmp));
+ if (ret)
+ return ret;
+ finfo->tx_id = tmp[0];
+ finfo->tx_irq = tmp[1];
+ finfo->tx_usr = tmp[2];
+
+ ret = of_property_read_u32_array(child, "ti,mbox-rx",
+ tmp, ARRAY_SIZE(tmp));
+ if (ret)
+ return ret;
+ finfo->rx_id = tmp[0];
+ finfo->rx_irq = tmp[1];
+ finfo->rx_usr = tmp[2];
+
+ finfo->name = child->name;
+ }
+ if (finfo->tx_id >= num_fifos || finfo->rx_id >= num_fifos ||
+ finfo->tx_usr >= num_users || finfo->rx_usr >= num_users)
+ return -EINVAL;
+ }
+
mdev = devm_kzalloc(&pdev->dev, sizeof(*mdev), GFP_KERNEL);
if (!mdev)
return -ENOMEM;
@@ -615,41 +767,40 @@ static int omap_mbox_probe(struct platform_device *pdev)
return PTR_ERR(mdev->mbox_base);
/* allocate one extra for marking end of list */
- list = devm_kzalloc(&pdev->dev, (pdata->info_cnt + 1) * sizeof(*list),
+ list = devm_kzalloc(&pdev->dev, (info_count + 1) * sizeof(*list),
GFP_KERNEL);
if (!list)
return -ENOMEM;
- mboxblk = devm_kzalloc(&pdev->dev, pdata->info_cnt * sizeof(*mbox),
+ mboxblk = devm_kzalloc(&pdev->dev, info_count * sizeof(*mbox),
GFP_KERNEL);
if (!mboxblk)
return -ENOMEM;
- info = pdata->info;
- intr_type = pdata->intr_type;
mbox = mboxblk;
- for (i = 0; i < pdata->info_cnt; i++, info++) {
+ finfo = finfoblk;
+ for (i = 0; i < info_count; i++, finfo++) {
fifo = &mbox->tx_fifo;
- fifo->msg = MAILBOX_MESSAGE(info->tx_id);
- fifo->fifo_stat = MAILBOX_FIFOSTATUS(info->tx_id);
- fifo->intr_bit = MAILBOX_IRQ_NOTFULL(info->tx_id);
- fifo->irqenable = MAILBOX_IRQENABLE(intr_type, info->usr_id);
- fifo->irqstatus = MAILBOX_IRQSTATUS(intr_type, info->usr_id);
- fifo->irqdisable = MAILBOX_IRQDISABLE(intr_type, info->usr_id);
+ fifo->msg = MAILBOX_MESSAGE(finfo->tx_id);
+ fifo->fifo_stat = MAILBOX_FIFOSTATUS(finfo->tx_id);
+ fifo->intr_bit = MAILBOX_IRQ_NOTFULL(finfo->tx_id);
+ fifo->irqenable = MAILBOX_IRQENABLE(intr_type, finfo->tx_usr);
+ fifo->irqstatus = MAILBOX_IRQSTATUS(intr_type, finfo->tx_usr);
+ fifo->irqdisable = MAILBOX_IRQDISABLE(intr_type, finfo->tx_usr);
fifo = &mbox->rx_fifo;
- fifo->msg = MAILBOX_MESSAGE(info->rx_id);
- fifo->msg_stat = MAILBOX_MSGSTATUS(info->rx_id);
- fifo->intr_bit = MAILBOX_IRQ_NEWMSG(info->rx_id);
- fifo->irqenable = MAILBOX_IRQENABLE(intr_type, info->usr_id);
- fifo->irqstatus = MAILBOX_IRQSTATUS(intr_type, info->usr_id);
- fifo->irqdisable = MAILBOX_IRQDISABLE(intr_type, info->usr_id);
+ fifo->msg = MAILBOX_MESSAGE(finfo->rx_id);
+ fifo->msg_stat = MAILBOX_MSGSTATUS(finfo->rx_id);
+ fifo->intr_bit = MAILBOX_IRQ_NEWMSG(finfo->rx_id);
+ fifo->irqenable = MAILBOX_IRQENABLE(intr_type, finfo->rx_usr);
+ fifo->irqstatus = MAILBOX_IRQSTATUS(intr_type, finfo->rx_usr);
+ fifo->irqdisable = MAILBOX_IRQDISABLE(intr_type, finfo->rx_usr);
mbox->intr_type = intr_type;
mbox->parent = mdev;
- mbox->name = info->name;
- mbox->irq = platform_get_irq(pdev, info->irq_id);
+ mbox->name = finfo->name;
+ mbox->irq = platform_get_irq(pdev, finfo->tx_irq);
if (mbox->irq < 0)
return mbox->irq;
list[i] = mbox++;
@@ -657,8 +808,8 @@ static int omap_mbox_probe(struct platform_device *pdev)
mutex_init(&mdev->cfg_lock);
mdev->dev = &pdev->dev;
- mdev->num_users = pdata->num_users;
- mdev->num_fifos = pdata->num_fifos;
+ mdev->num_users = num_users;
+ mdev->num_fifos = num_fifos;
mdev->mboxes = list;
ret = omap_mbox_register(mdev);
if (ret)
@@ -684,6 +835,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
if (ret < 0)
goto unregister;
+ devm_kfree(&pdev->dev, finfoblk);
return 0;
unregister:
@@ -708,6 +860,7 @@ static struct platform_driver omap_mbox_driver = {
.driver = {
.name = "omap-mailbox",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(omap_mailbox_of_match),
},
};
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 3/6] ARM: dts: OMAP2+: Add sub mailboxes device node information
2014-06-25 1:47 ` Suman Anna
@ 2014-06-25 1:47 ` Suman Anna
-1 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jassi Brar, Dave Gerlach, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Suman Anna, Benoît Cousson, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
The sub-mailbox devices are added to the Mailbox DT nodes on
OMAP2420, OMAP2430, OMAP3, AM33xx, AM43xx, OMAP4 and OMAP5
family of SoCs. This data represents the same mailboxes that
used to be represented in hwmod attribute data previously.
The node name is chosen based on the .name field of
omap_mbox_dev_info structure used in the hwmod data.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/am33xx.dtsi | 4 ++++
arch/arm/boot/dts/am4372.dtsi | 4 ++++
arch/arm/boot/dts/omap2420.dtsi | 8 ++++++++
arch/arm/boot/dts/omap2430.dtsi | 4 ++++
arch/arm/boot/dts/omap3.dtsi | 4 ++++
arch/arm/boot/dts/omap4.dtsi | 8 ++++++++
arch/arm/boot/dts/omap5.dtsi | 8 ++++++++
7 files changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 1da3bcf..8c5abc7 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -352,6 +352,10 @@
reg = <0x480C8000 0x200>;
interrupts = <77>;
ti,hwmods = "mailbox";
+ mbox_wkupm3: wkup_m3 {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <0 0 3>;
+ };
};
timer1: timer@44e31000 {
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 390cbb53..668b404 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -166,6 +166,10 @@
reg = <0x480C8000 0x200>;
interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mailbox";
+ mbox_wkupm3: wkup_m3 {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <0 0 3>;
+ };
};
timer1: timer@44e31000 {
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index e83b046..f3e6d0f 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -157,6 +157,14 @@
interrupts = <26>, <34>;
interrupt-names = "dsp", "iva";
ti,hwmods = "mailbox";
+ mbox_dsp: dsp {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <1 0 0>;
+ };
+ mbox_iva: iva {
+ ti,mbox-tx = <2 1 3>;
+ ti,mbox-rx = <3 1 3>;
+ };
};
timer1: timer@48028000 {
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c4e8013..13deb71 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -247,6 +247,10 @@
reg = <0x48094000 0x200>;
interrupts = <26>;
ti,hwmods = "mailbox";
+ mbox_dsp: dsp {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <1 0 0>;
+ };
};
timer1: timer@49018000 {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index b2891a9..3524adf 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -332,6 +332,10 @@
ti,hwmods = "mailbox";
reg = <0x48094000 0x200>;
interrupts = <26>;
+ mbox_dsp: dsp {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <1 0 0>;
+ };
};
mcspi1: spi@48098000 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 55bec30..19dc11d 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -654,6 +654,14 @@
reg = <0x4a0f4000 0x200>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mailbox";
+ mbox_ipu: mbox_ipu {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <1 0 0>;
+ };
+ mbox_dsp: mbox_dsp {
+ ti,mbox-tx = <3 0 0>;
+ ti,mbox-rx = <2 0 0>;
+ };
};
timer1: timer@4a318000 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3bfda16..ce54c13 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -641,6 +641,14 @@
reg = <0x4a0f4000 0x200>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mailbox";
+ mbox_ipu: mbox_ipu {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <1 0 0>;
+ };
+ mbox_dsp: mbox_dsp {
+ ti,mbox-tx = <3 0 0>;
+ ti,mbox-rx = <2 0 0>;
+ };
};
timer1: timer@4ae18000 {
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 3/6] ARM: dts: OMAP2+: Add sub mailboxes device node information
@ 2014-06-25 1:47 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: linux-arm-kernel
The sub-mailbox devices are added to the Mailbox DT nodes on
OMAP2420, OMAP2430, OMAP3, AM33xx, AM43xx, OMAP4 and OMAP5
family of SoCs. This data represents the same mailboxes that
used to be represented in hwmod attribute data previously.
The node name is chosen based on the .name field of
omap_mbox_dev_info structure used in the hwmod data.
Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/am33xx.dtsi | 4 ++++
arch/arm/boot/dts/am4372.dtsi | 4 ++++
arch/arm/boot/dts/omap2420.dtsi | 8 ++++++++
arch/arm/boot/dts/omap2430.dtsi | 4 ++++
arch/arm/boot/dts/omap3.dtsi | 4 ++++
arch/arm/boot/dts/omap4.dtsi | 8 ++++++++
arch/arm/boot/dts/omap5.dtsi | 8 ++++++++
7 files changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 1da3bcf..8c5abc7 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -352,6 +352,10 @@
reg = <0x480C8000 0x200>;
interrupts = <77>;
ti,hwmods = "mailbox";
+ mbox_wkupm3: wkup_m3 {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <0 0 3>;
+ };
};
timer1: timer at 44e31000 {
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 390cbb53..668b404 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -166,6 +166,10 @@
reg = <0x480C8000 0x200>;
interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mailbox";
+ mbox_wkupm3: wkup_m3 {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <0 0 3>;
+ };
};
timer1: timer at 44e31000 {
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index e83b046..f3e6d0f 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -157,6 +157,14 @@
interrupts = <26>, <34>;
interrupt-names = "dsp", "iva";
ti,hwmods = "mailbox";
+ mbox_dsp: dsp {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <1 0 0>;
+ };
+ mbox_iva: iva {
+ ti,mbox-tx = <2 1 3>;
+ ti,mbox-rx = <3 1 3>;
+ };
};
timer1: timer at 48028000 {
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c4e8013..13deb71 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -247,6 +247,10 @@
reg = <0x48094000 0x200>;
interrupts = <26>;
ti,hwmods = "mailbox";
+ mbox_dsp: dsp {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <1 0 0>;
+ };
};
timer1: timer at 49018000 {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index b2891a9..3524adf 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -332,6 +332,10 @@
ti,hwmods = "mailbox";
reg = <0x48094000 0x200>;
interrupts = <26>;
+ mbox_dsp: dsp {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <1 0 0>;
+ };
};
mcspi1: spi at 48098000 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 55bec30..19dc11d 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -654,6 +654,14 @@
reg = <0x4a0f4000 0x200>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mailbox";
+ mbox_ipu: mbox_ipu {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <1 0 0>;
+ };
+ mbox_dsp: mbox_dsp {
+ ti,mbox-tx = <3 0 0>;
+ ti,mbox-rx = <2 0 0>;
+ };
};
timer1: timer at 4a318000 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3bfda16..ce54c13 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -641,6 +641,14 @@
reg = <0x4a0f4000 0x200>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mailbox";
+ mbox_ipu: mbox_ipu {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <1 0 0>;
+ };
+ mbox_dsp: mbox_dsp {
+ ti,mbox-tx = <3 0 0>;
+ ti,mbox-rx = <2 0 0>;
+ };
};
timer1: timer at 4ae18000 {
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 4/6] mailbox/omap: adapt to the new mailbox framework
2014-06-25 1:47 ` Suman Anna
(?)
@ 2014-06-25 1:47 ` Suman Anna
-1 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jassi Brar, Dave Gerlach, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Suman Anna, Jassi Brar, Ohad Ben-Cohen,
Omar Ramirez Luna, Greg Kroah-Hartman
The OMAP mailbox driver and its existing clients (remoteproc
for OMAP4+ and TI DSP/Bridge for OMAP3) are adapted to use
the generic mailbox framework.
The main changes for the adaptation are:
- The tasklet used for Tx is replaced with the state machine from
the generic mailbox framework. The workqueue used for processing
the received messages stays intact for minimizing the effects on
the OMAP mailbox clients.
- The existing exported client API, omap_mbox_get, omap_mbox_put and
omap_mbox_send_msg are deleted, as the framework provides equivalent
functionality. A OMAP-specific omap_mbox_request_channel is added
though to support non-DT way of requesting mailboxes for OMAP3.
- The OMAP mailbox driver is integrated with the mailbox framework
through the proper implementations of mbox_chan_ops, except for
.last_tx_done and .peek_data. The OMAP mailbox driver does not need
these ops, as it is completely interrupt driven.
- The new framework does not support multiple clients operating on a
single channel, so the reference counting logic is simplified.
- The remoteproc and tidspbridge drivers (current clients) are adapted
to use the new API. The notifier callbacks used within these clients
are replaced with the regular callbacks from the newer framework.
- The exported OMAP mailbox API are limited to omap_mbox_save_ctx,
omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq,
with the signature modified to take in the new mbox_chan handle instead
of the OMAP specific omap_mbox handle. The first 2 will be removed when
the OMAP mailbox driver is adapted to runtime_pm. The other exported
API omap_mbox_request_channel is identical in signature to the framework
API mbox_request_channel, and will be removed once OMAP3 becomes DT-boot
only.
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Omar Ramirez Luna <omar.ramirez@copitl.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/mailbox/omap-mailbox.c | 320 +++++++++++----------
drivers/remoteproc/omap_remoteproc.c | 54 ++--
drivers/staging/tidspbridge/core/_tiomap.h | 3 +-
drivers/staging/tidspbridge/core/io_sm.c | 7 +-
drivers/staging/tidspbridge/core/tiomap3430.c | 22 +-
drivers/staging/tidspbridge/core/tiomap_io.c | 7 +-
.../tidspbridge/include/dspbridge/host_os.h | 1 +
.../staging/tidspbridge/include/dspbridge/io_sm.h | 8 +-
include/linux/omap-mailbox.h | 15 +-
9 files changed, 234 insertions(+), 203 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index c61435b..d71e84f 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -29,13 +29,14 @@
#include <linux/slab.h>
#include <linux/kfifo.h>
#include <linux/err.h>
-#include <linux/notifier.h>
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/platform_data/mailbox-omap.h>
#include <linux/omap-mailbox.h>
+#include <linux/mailbox_controller.h>
+#include <linux/mailbox_client.h>
#define MAILBOX_REVISION 0x000
#define MAILBOX_MESSAGE(m) (0x040 + 4 * (m))
@@ -80,7 +81,6 @@ struct omap_mbox_queue {
spinlock_t lock;
struct kfifo fifo;
struct work_struct work;
- struct tasklet_struct tasklet;
struct omap_mbox *mbox;
bool full;
};
@@ -92,6 +92,7 @@ struct omap_mbox_device {
u32 num_users;
u32 num_fifos;
struct omap_mbox **mboxes;
+ struct mbox_controller controller;
struct list_head elem;
};
@@ -116,15 +117,14 @@ struct omap_mbox_device_data {
struct omap_mbox {
const char *name;
int irq;
- struct omap_mbox_queue *txq, *rxq;
+ struct omap_mbox_queue *rxq;
struct device *dev;
struct omap_mbox_device *parent;
struct omap_mbox_fifo tx_fifo;
struct omap_mbox_fifo rx_fifo;
u32 ctx[OMAP4_MBOX_NR_REGS];
u32 intr_type;
- int use_count;
- struct blocking_notifier_head notifier;
+ struct mbox_chan *chan;
};
/* global variables for the mailbox devices */
@@ -135,6 +135,14 @@ static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
module_param(mbox_kfifo_size, uint, S_IRUGO);
MODULE_PARM_DESC(mbox_kfifo_size, "Size of omap's mailbox kfifo (bytes)");
+static struct omap_mbox *mbox_chan_to_omap_mbox(struct mbox_chan *chan)
+{
+ if (!chan || !chan->con_priv)
+ return NULL;
+
+ return (struct omap_mbox *)chan->con_priv;
+}
+
static inline
unsigned int mbox_read_reg(struct omap_mbox_device *mdev, size_t ofs)
{
@@ -200,41 +208,14 @@ static int is_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
return (int)(enable & status & bit);
}
-/*
- * message sender
- */
-int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
-{
- struct omap_mbox_queue *mq = mbox->txq;
- int ret = 0, len;
-
- spin_lock_bh(&mq->lock);
-
- if (kfifo_avail(&mq->fifo) < sizeof(msg)) {
- ret = -ENOMEM;
- goto out;
- }
-
- if (kfifo_is_empty(&mq->fifo) && !mbox_fifo_full(mbox)) {
- mbox_fifo_write(mbox, msg);
- goto out;
- }
-
- len = kfifo_in(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
- WARN_ON(len != sizeof(msg));
-
- tasklet_schedule(&mbox->txq->tasklet);
-
-out:
- spin_unlock_bh(&mq->lock);
- return ret;
-}
-EXPORT_SYMBOL(omap_mbox_msg_send);
-
-void omap_mbox_save_ctx(struct omap_mbox *mbox)
+void omap_mbox_save_ctx(struct mbox_chan *chan)
{
int i;
int nr_regs;
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+
+ if (WARN_ON(!mbox))
+ return;
if (mbox->intr_type)
nr_regs = OMAP4_MBOX_NR_REGS;
@@ -249,10 +230,14 @@ void omap_mbox_save_ctx(struct omap_mbox *mbox)
}
EXPORT_SYMBOL(omap_mbox_save_ctx);
-void omap_mbox_restore_ctx(struct omap_mbox *mbox)
+void omap_mbox_restore_ctx(struct mbox_chan *chan)
{
int i;
int nr_regs;
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+
+ if (WARN_ON(!mbox))
+ return;
if (mbox->intr_type)
nr_regs = OMAP4_MBOX_NR_REGS;
@@ -260,14 +245,13 @@ void omap_mbox_restore_ctx(struct omap_mbox *mbox)
nr_regs = MBOX_NR_REGS;
for (i = 0; i < nr_regs; i++) {
mbox_write_reg(mbox->parent, mbox->ctx[i], i * sizeof(u32));
-
dev_dbg(mbox->dev, "%s: [%02x] %08x\n", __func__,
i, mbox->ctx[i]);
}
}
EXPORT_SYMBOL(omap_mbox_restore_ctx);
-void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+static void _omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
u32 l;
struct omap_mbox_fifo *fifo = (irq == IRQ_TX) ?
@@ -279,9 +263,8 @@ void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
l |= bit;
mbox_write_reg(mbox->parent, l, irqenable);
}
-EXPORT_SYMBOL(omap_mbox_enable_irq);
-void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+static void _omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
struct omap_mbox_fifo *fifo = (irq == IRQ_TX) ?
&mbox->tx_fifo : &mbox->rx_fifo;
@@ -297,28 +280,28 @@ void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
mbox_write_reg(mbox->parent, bit, irqdisable);
}
-EXPORT_SYMBOL(omap_mbox_disable_irq);
-static void mbox_tx_tasklet(unsigned long tx_data)
+void omap_mbox_enable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq)
{
- struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
- struct omap_mbox_queue *mq = mbox->txq;
- mbox_msg_t msg;
- int ret;
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
- while (kfifo_len(&mq->fifo)) {
- if (mbox_fifo_full(mbox)) {
- omap_mbox_enable_irq(mbox, IRQ_TX);
- break;
- }
+ if (WARN_ON(!mbox))
+ return;
+
+ _omap_mbox_enable_irq(mbox, irq);
+}
+EXPORT_SYMBOL(omap_mbox_enable_irq);
- ret = kfifo_out(&mq->fifo, (unsigned char *)&msg,
- sizeof(msg));
- WARN_ON(ret != sizeof(msg));
+void omap_mbox_disable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq)
+{
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
- mbox_fifo_write(mbox, msg);
- }
+ if (WARN_ON(!mbox))
+ return;
+
+ _omap_mbox_disable_irq(mbox, irq);
}
+EXPORT_SYMBOL(omap_mbox_disable_irq);
/*
* Message receiver(workqueue)
@@ -334,12 +317,11 @@ static void mbox_rx_work(struct work_struct *work)
len = kfifo_out(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
WARN_ON(len != sizeof(msg));
- blocking_notifier_call_chain(&mq->mbox->notifier, len,
- (void *)msg);
+ mbox_chan_received_data(mq->mbox->chan, (void *)msg);
spin_lock_irq(&mq->lock);
if (mq->full) {
mq->full = false;
- omap_mbox_enable_irq(mq->mbox, IRQ_RX);
+ _omap_mbox_enable_irq(mq->mbox, IRQ_RX);
}
spin_unlock_irq(&mq->lock);
}
@@ -350,9 +332,9 @@ static void mbox_rx_work(struct work_struct *work)
*/
static void __mbox_tx_interrupt(struct omap_mbox *mbox)
{
- omap_mbox_disable_irq(mbox, IRQ_TX);
+ _omap_mbox_disable_irq(mbox, IRQ_TX);
ack_mbox_irq(mbox, IRQ_TX);
- tasklet_schedule(&mbox->txq->tasklet);
+ mbox_chan_txdone(mbox->chan, 0);
}
static void __mbox_rx_interrupt(struct omap_mbox *mbox)
@@ -363,7 +345,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(&mq->fifo) < sizeof(msg))) {
- omap_mbox_disable_irq(mbox, IRQ_RX);
+ _omap_mbox_disable_irq(mbox, IRQ_RX);
mq->full = true;
goto nomem;
}
@@ -394,11 +376,13 @@ static irqreturn_t mbox_interrupt(int irq, void *p)
}
static struct omap_mbox_queue *mbox_queue_alloc(struct omap_mbox *mbox,
- void (*work) (struct work_struct *),
- void (*tasklet)(unsigned long))
+ void (*work)(struct work_struct *))
{
struct omap_mbox_queue *mq;
+ if (!work)
+ return NULL;
+
mq = kzalloc(sizeof(struct omap_mbox_queue), GFP_KERNEL);
if (!mq)
return NULL;
@@ -408,12 +392,9 @@ static struct omap_mbox_queue *mbox_queue_alloc(struct omap_mbox *mbox,
if (kfifo_alloc(&mq->fifo, mbox_kfifo_size, GFP_KERNEL))
goto error;
- if (work)
- INIT_WORK(&mq->work, work);
-
- if (tasklet)
- tasklet_init(&mq->tasklet, tasklet, (unsigned long)mbox);
+ INIT_WORK(&mq->work, work);
return mq;
+
error:
kfree(mq);
return NULL;
@@ -429,71 +410,35 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
{
int ret = 0;
struct omap_mbox_queue *mq;
- struct omap_mbox_device *mdev = mbox->parent;
- mutex_lock(&mdev->cfg_lock);
- ret = pm_runtime_get_sync(mdev->dev);
- if (unlikely(ret < 0))
- goto fail_startup;
-
- if (!mbox->use_count++) {
- mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
- if (!mq) {
- ret = -ENOMEM;
- goto fail_alloc_txq;
- }
- mbox->txq = mq;
+ mq = mbox_queue_alloc(mbox, mbox_rx_work);
+ if (!mq)
+ return -ENOMEM;
+ mbox->rxq = mq;
+ mq->mbox = mbox;
+
+ ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED,
+ mbox->name, mbox);
+ if (unlikely(ret)) {
+ pr_err("failed to register mailbox interrupt:%d\n", ret);
+ goto fail_request_irq;
+ }
- mq = mbox_queue_alloc(mbox, mbox_rx_work, NULL);
- if (!mq) {
- ret = -ENOMEM;
- goto fail_alloc_rxq;
- }
- mbox->rxq = mq;
- mq->mbox = mbox;
- ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED,
- mbox->name, mbox);
- if (unlikely(ret)) {
- pr_err("failed to register mailbox interrupt:%d\n",
- ret);
- goto fail_request_irq;
- }
+ _omap_mbox_enable_irq(mbox, IRQ_RX);
- omap_mbox_enable_irq(mbox, IRQ_RX);
- }
- mutex_unlock(&mdev->cfg_lock);
return 0;
fail_request_irq:
mbox_queue_free(mbox->rxq);
-fail_alloc_rxq:
- mbox_queue_free(mbox->txq);
-fail_alloc_txq:
- pm_runtime_put_sync(mdev->dev);
- mbox->use_count--;
-fail_startup:
- mutex_unlock(&mdev->cfg_lock);
return ret;
}
static void omap_mbox_fini(struct omap_mbox *mbox)
{
- struct omap_mbox_device *mdev = mbox->parent;
-
- mutex_lock(&mdev->cfg_lock);
-
- if (!--mbox->use_count) {
- omap_mbox_disable_irq(mbox, IRQ_RX);
- free_irq(mbox->irq, mbox);
- tasklet_kill(&mbox->txq->tasklet);
- flush_work(&mbox->rxq->work);
- mbox_queue_free(mbox->txq);
- mbox_queue_free(mbox->rxq);
- }
-
- pm_runtime_put_sync(mdev->dev);
-
- mutex_unlock(&mdev->cfg_lock);
+ _omap_mbox_disable_irq(mbox, IRQ_RX);
+ free_irq(mbox->irq, mbox);
+ flush_work(&mbox->rxq->work);
+ mbox_queue_free(mbox->rxq);
}
static struct omap_mbox *omap_mbox_device_find(struct omap_mbox_device *mdev,
@@ -515,42 +460,54 @@ static struct omap_mbox *omap_mbox_device_find(struct omap_mbox_device *mdev,
return mbox;
}
-struct omap_mbox *omap_mbox_get(const char *name, struct notifier_block *nb)
+struct mbox_chan *omap_mbox_request_channel(struct mbox_client *cl)
{
+ struct device *dev = cl->dev;
struct omap_mbox *mbox = NULL;
struct omap_mbox_device *mdev;
+ struct mbox_chan *chan;
+ unsigned long flags;
int ret;
+ if (!dev)
+ return ERR_PTR(-ENODEV);
+
+ if (dev->of_node) {
+ pr_err("%s: please use mbox_request_channel(), this API is supported only for OMAP non-DT usage\n",
+ __func__);
+ return ERR_PTR(-ENODEV);
+ }
+
mutex_lock(&omap_mbox_devices_lock);
list_for_each_entry(mdev, &omap_mbox_devices, elem) {
- mbox = omap_mbox_device_find(mdev, name);
+ mbox = omap_mbox_device_find(mdev, cl->chan_name);
if (mbox)
break;
}
mutex_unlock(&omap_mbox_devices_lock);
- if (!mbox)
+ if (!mbox || !mbox->chan)
return ERR_PTR(-ENOENT);
- if (nb)
- blocking_notifier_chain_register(&mbox->notifier, nb);
+ chan = mbox->chan;
+ spin_lock_irqsave(&chan->lock, flags);
+ chan->msg_free = 0;
+ chan->msg_count = 0;
+ chan->active_req = NULL;
+ chan->cl = cl;
+ init_completion(&chan->tx_complete);
+ spin_unlock_irqrestore(&chan->lock, flags);
- ret = omap_mbox_startup(mbox);
+ ret = chan->mbox->ops->startup(chan);
if (ret) {
- blocking_notifier_chain_unregister(&mbox->notifier, nb);
- return ERR_PTR(-ENODEV);
+ pr_err("Unable to startup the chan (%d)\n", ret);
+ mbox_free_channel(chan);
+ chan = ERR_PTR(ret);
}
- return mbox;
+ return chan;
}
-EXPORT_SYMBOL(omap_mbox_get);
-
-void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb)
-{
- blocking_notifier_chain_unregister(&mbox->notifier, nb);
- omap_mbox_fini(mbox);
-}
-EXPORT_SYMBOL(omap_mbox_put);
+EXPORT_SYMBOL(omap_mbox_request_channel);
static struct class omap_mbox_class = { .name = "mbox", };
@@ -566,25 +523,25 @@ static int omap_mbox_register(struct omap_mbox_device *mdev)
mboxes = mdev->mboxes;
for (i = 0; mboxes[i]; i++) {
struct omap_mbox *mbox = mboxes[i];
- mbox->dev = device_create(&omap_mbox_class,
- mdev->dev, 0, mbox, "%s", mbox->name);
+ mbox->dev = device_create(&omap_mbox_class, mdev->dev,
+ 0, mbox, "%s", mbox->name);
if (IS_ERR(mbox->dev)) {
ret = PTR_ERR(mbox->dev);
goto err_out;
}
-
- BLOCKING_INIT_NOTIFIER_HEAD(&mbox->notifier);
}
mutex_lock(&omap_mbox_devices_lock);
list_add(&mdev->elem, &omap_mbox_devices);
mutex_unlock(&omap_mbox_devices_lock);
- return 0;
+ ret = mbox_controller_register(&mdev->controller);
err_out:
- while (i--)
- device_unregister(mboxes[i]->dev);
+ if (ret) {
+ while (i--)
+ device_unregister(mboxes[i]->dev);
+ }
return ret;
}
@@ -600,12 +557,64 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
list_del(&mdev->elem);
mutex_unlock(&omap_mbox_devices_lock);
+ mbox_controller_unregister(&mdev->controller);
+
mboxes = mdev->mboxes;
for (i = 0; mboxes[i]; i++)
device_unregister(mboxes[i]->dev);
return 0;
}
+static int omap_mbox_chan_startup(struct mbox_chan *chan)
+{
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ struct omap_mbox_device *mdev = mbox->parent;
+ int ret = 0;
+
+ mutex_lock(&mdev->cfg_lock);
+ pm_runtime_get_sync(mdev->dev);
+ ret = omap_mbox_startup(mbox);
+ if (ret)
+ pm_runtime_put_sync(mdev->dev);
+ mutex_unlock(&mdev->cfg_lock);
+ return ret;
+}
+
+static void omap_mbox_chan_shutdown(struct mbox_chan *chan)
+{
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ struct omap_mbox_device *mdev = mbox->parent;
+
+ mutex_lock(&mdev->cfg_lock);
+ omap_mbox_fini(mbox);
+ pm_runtime_put_sync(mdev->dev);
+ mutex_unlock(&mdev->cfg_lock);
+}
+
+static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
+{
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ int ret = -EBUSY;
+
+ if (!mbox)
+ return -EINVAL;
+
+ if (!mbox_fifo_full(mbox)) {
+ mbox_fifo_write(mbox, (mbox_msg_t)data);
+ ret = 0;
+ }
+
+ /* always enable the interrupt */
+ _omap_mbox_enable_irq(mbox, IRQ_TX);
+ return ret;
+}
+
+static struct mbox_chan_ops omap_mbox_chan_ops = {
+ .startup = omap_mbox_chan_startup,
+ .send_data = omap_mbox_chan_send_data,
+ .shutdown = omap_mbox_chan_shutdown,
+};
+
static const struct omap_mbox_device_data omap2_data = {
.num_users = 4,
.num_fifos = 6,
@@ -671,6 +680,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
int ret;
+ struct mbox_chan *chnls;
struct omap_mbox **list, *mbox, *mboxblk;
struct omap_mbox_pdata *pdata = pdev->dev.platform_data;
struct omap_mbox_dev_info *info = NULL;
@@ -772,6 +782,11 @@ static int omap_mbox_probe(struct platform_device *pdev)
if (!list)
return -ENOMEM;
+ chnls = devm_kzalloc(&pdev->dev, (info_count + 1) * sizeof(*chnls),
+ GFP_KERNEL);
+ if (!chnls)
+ return -ENOMEM;
+
mboxblk = devm_kzalloc(&pdev->dev, info_count * sizeof(*mbox),
GFP_KERNEL);
if (!mboxblk)
@@ -803,6 +818,8 @@ static int omap_mbox_probe(struct platform_device *pdev)
mbox->irq = platform_get_irq(pdev, finfo->tx_irq);
if (mbox->irq < 0)
return mbox->irq;
+ mbox->chan = &chnls[i];
+ chnls[i].con_priv = mbox;
list[i] = mbox++;
}
@@ -811,6 +828,13 @@ static int omap_mbox_probe(struct platform_device *pdev)
mdev->num_users = num_users;
mdev->num_fifos = num_fifos;
mdev->mboxes = list;
+
+ /* OMAP does not have a Tx-Done IRQ, but rather a Tx-Ready IRQ */
+ mdev->controller.txdone_irq = true;
+ mdev->controller.dev = mdev->dev;
+ mdev->controller.ops = &omap_mbox_chan_ops;
+ mdev->controller.chans = chnls;
+ mdev->controller.num_chans = info_count;
ret = omap_mbox_register(mdev);
if (ret)
return ret;
diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 5168972..0a87e57 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -27,6 +27,7 @@
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/remoteproc.h>
+#include <linux/mailbox_client.h>
#include <linux/omap-mailbox.h>
#include <linux/platform_data/remoteproc-omap.h>
@@ -36,20 +37,19 @@
/**
* struct omap_rproc - omap remote processor state
- * @mbox: omap mailbox handle
- * @nb: notifier block that will be invoked on inbound mailbox messages
+ * @mbox: mailbox channel handle
+ * @client: mailbox client to request the mailbox channel
* @rproc: rproc handle
*/
struct omap_rproc {
- struct omap_mbox *mbox;
- struct notifier_block nb;
+ struct mbox_chan *mbox;
+ struct mbox_client client;
struct rproc *rproc;
};
/**
* omap_rproc_mbox_callback() - inbound mailbox message handler
- * @this: notifier block
- * @index: unused
+ * @client: mailbox client pointer used for requesting the mailbox channel
* @data: mailbox payload
*
* This handler is invoked by omap's mailbox driver whenever a mailbox
@@ -61,13 +61,13 @@ struct omap_rproc {
* that indicates different events. Those values are deliberately very
* big so they don't coincide with virtqueue indices.
*/
-static int omap_rproc_mbox_callback(struct notifier_block *this,
- unsigned long index, void *data)
+static void omap_rproc_mbox_callback(struct mbox_client *client, void *data)
{
- mbox_msg_t msg = (mbox_msg_t) data;
- struct omap_rproc *oproc = container_of(this, struct omap_rproc, nb);
+ struct omap_rproc *oproc = container_of(client, struct omap_rproc,
+ client);
struct device *dev = oproc->rproc->dev.parent;
const char *name = oproc->rproc->name;
+ u32 msg = (u32)data;
dev_dbg(dev, "mbox msg: 0x%x\n", msg);
@@ -84,8 +84,6 @@ static int omap_rproc_mbox_callback(struct notifier_block *this,
if (rproc_vq_interrupt(oproc->rproc, msg) == IRQ_NONE)
dev_dbg(dev, "no message was found in vqid %d\n", msg);
}
-
- return NOTIFY_DONE;
}
/* kick a virtqueue */
@@ -96,8 +94,8 @@ static void omap_rproc_kick(struct rproc *rproc, int vqid)
int ret;
/* send the index of the triggered virtqueue in the mailbox payload */
- ret = omap_mbox_msg_send(oproc->mbox, vqid);
- if (ret)
+ ret = mbox_send_message(oproc->mbox, (void *)vqid);
+ if (ret < 0)
dev_err(dev, "omap_mbox_msg_send failed: %d\n", ret);
}
@@ -115,17 +113,25 @@ static int omap_rproc_start(struct rproc *rproc)
struct platform_device *pdev = to_platform_device(dev);
struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
int ret;
+ struct mbox_client *client = &oproc->client;
+ char client_name[32];
if (pdata->set_bootaddr)
pdata->set_bootaddr(rproc->bootaddr);
- oproc->nb.notifier_call = omap_rproc_mbox_callback;
+ client->dev = dev;
+ client->tx_done = NULL;
+ client->rx_callback = omap_rproc_mbox_callback;
+ client->tx_block = false;
+ client->knows_txdone = false;
+ sprintf(client_name, "%s", pdata->mbox_name);
+ client->chan_name = client_name;
- /* every omap rproc is assigned a mailbox instance for messaging */
- oproc->mbox = omap_mbox_get(pdata->mbox_name, &oproc->nb);
+ oproc->mbox = omap_mbox_request_channel(client);
if (IS_ERR(oproc->mbox)) {
- ret = PTR_ERR(oproc->mbox);
- dev_err(dev, "omap_mbox_get failed: %d\n", ret);
+ ret = -EBUSY;
+ dev_err(dev, "mbox_request_channel failed: %ld\n",
+ PTR_ERR(oproc->mbox));
return ret;
}
@@ -136,9 +142,9 @@ static int omap_rproc_start(struct rproc *rproc)
* Note that the reply will _not_ arrive immediately: this message
* will wait in the mailbox fifo until the remote processor is booted.
*/
- ret = omap_mbox_msg_send(oproc->mbox, RP_MBOX_ECHO_REQUEST);
- if (ret) {
- dev_err(dev, "omap_mbox_get failed: %d\n", ret);
+ ret = mbox_send_message(oproc->mbox, (void *)RP_MBOX_ECHO_REQUEST);
+ if (ret < 0) {
+ dev_err(dev, "mbox_send_message failed: %d\n", ret);
goto put_mbox;
}
@@ -151,7 +157,7 @@ static int omap_rproc_start(struct rproc *rproc)
return 0;
put_mbox:
- omap_mbox_put(oproc->mbox, &oproc->nb);
+ mbox_free_channel(oproc->mbox);
return ret;
}
@@ -168,7 +174,7 @@ static int omap_rproc_stop(struct rproc *rproc)
if (ret)
return ret;
- omap_mbox_put(oproc->mbox, &oproc->nb);
+ mbox_free_channel(oproc->mbox);
return 0;
}
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h b/drivers/staging/tidspbridge/core/_tiomap.h
index 65971b7..2b8390f 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -338,7 +338,8 @@ struct bridge_dev_context {
u32 dsp_start_add; /* API Boot vector */
u32 internal_size; /* Internal memory size */
- struct omap_mbox *mbox; /* Mail box handle */
+ struct mbox_client client; /* Mailbox Client */
+ struct mbox_chan *mbox; /* Mailbox handle */
struct cfg_hostres *resources; /* Host Resources */
diff --git a/drivers/staging/tidspbridge/core/io_sm.c b/drivers/staging/tidspbridge/core/io_sm.c
index c2829aa..4b6673a 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -908,7 +908,7 @@ func_end:
* Calls the Bridge's CHNL_ISR to determine if this interrupt is ours, then
* schedules a DPC to dispatch I/O.
*/
-int io_mbox_msg(struct notifier_block *self, unsigned long len, void *msg)
+void io_mbox_msg(struct mbox_client *client, void *msg)
{
struct io_mgr *pio_mgr;
struct dev_object *dev_obj;
@@ -917,8 +917,8 @@ int io_mbox_msg(struct notifier_block *self, unsigned long len, void *msg)
dev_obj = dev_get_first();
dev_get_io_mgr(dev_obj, &pio_mgr);
- if (!pio_mgr)
- return NOTIFY_BAD;
+ if (WARN_ON(!pio_mgr))
+ return;
pio_mgr->intr_val = (u16)((u32)msg);
if (pio_mgr->intr_val & MBX_PM_CLASS)
@@ -932,7 +932,6 @@ int io_mbox_msg(struct notifier_block *self, unsigned long len, void *msg)
spin_unlock_irqrestore(&pio_mgr->dpc_lock, flags);
tasklet_schedule(&pio_mgr->dpc_tasklet);
}
- return NOTIFY_OK;
}
/*
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c b/drivers/staging/tidspbridge/core/tiomap3430.c
index 8945b4e..5f6287c 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -212,10 +212,6 @@ static struct bridge_drv_interface drv_interface_fxns = {
bridge_msg_set_queue_id,
};
-static struct notifier_block dsp_mbox_notifier = {
- .notifier_call = io_mbox_msg,
-};
-
static inline void flush_all(struct bridge_dev_context *dev_context)
{
if (dev_context->brd_state == BRD_DSP_HIBERNATION ||
@@ -378,6 +374,8 @@ static int bridge_brd_start(struct bridge_dev_context *dev_ctxt,
u32 wdt_en = 0;
struct omap_dsp_platform_data *pdata =
omap_dspbridge_dev->dev.platform_data;
+ struct mbox_client *client = &dev_context->client;
+ char mbox_user_name[32];
/* The device context contains all the mmu setup info from when the
* last dsp base image was loaded. The first entry is always
@@ -544,11 +542,17 @@ static int bridge_brd_start(struct bridge_dev_context *dev_ctxt,
* Enable Mailbox events and also drain any pending
* stale messages.
*/
- dev_context->mbox = omap_mbox_get("dsp", &dsp_mbox_notifier);
+ client->dev = &omap_dspbridge_dev->dev;
+ client->tx_done = NULL;
+ client->rx_callback = io_mbox_msg;
+ client->tx_block = false;
+ client->knows_txdone = false;
+ sprintf(mbox_user_name, "dsp");
+ client->chan_name = mbox_user_name;
+ dev_context->mbox = omap_mbox_request_channel(client);
if (IS_ERR(dev_context->mbox)) {
- dev_context->mbox = NULL;
- pr_err("%s: Failed to get dsp mailbox handle\n",
- __func__);
+ pr_err("%s: Failed to get dsp mailbox handle, ret = %ld\n",
+ __func__, PTR_ERR(dev_context->mbox));
status = -EPERM;
}
@@ -680,7 +684,7 @@ static int bridge_brd_stop(struct bridge_dev_context *dev_ctxt)
/* Disable the mailbox interrupts */
if (dev_context->mbox) {
omap_mbox_disable_irq(dev_context->mbox, IRQ_RX);
- omap_mbox_put(dev_context->mbox, &dsp_mbox_notifier);
+ mbox_free_channel(dev_context->mbox);
dev_context->mbox = NULL;
}
/* Reset IVA2 clocks*/
diff --git a/drivers/staging/tidspbridge/core/tiomap_io.c b/drivers/staging/tidspbridge/core/tiomap_io.c
index f53ed98..fe86035 100644
--- a/drivers/staging/tidspbridge/core/tiomap_io.c
+++ b/drivers/staging/tidspbridge/core/tiomap_io.c
@@ -427,10 +427,9 @@ int sm_interrupt_dsp(struct bridge_dev_context *dev_context, u16 mb_val)
dsp_clock_enable_all(dev_context->dsp_per_clks);
}
- status = omap_mbox_msg_send(dev_context->mbox, mb_val);
-
- if (status) {
- pr_err("omap_mbox_msg_send Fail and status = %d\n", status);
+ status = mbox_send_message(dev_context->mbox, (void *)((u32)mb_val));
+ if (status < 0) {
+ pr_err("mbox_send_message failed, status = %d\n", status);
status = -EPERM;
}
diff --git a/drivers/staging/tidspbridge/include/dspbridge/host_os.h b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
index d1441db..8ddef2b 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/host_os.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
@@ -42,6 +42,7 @@
#include <linux/platform_device.h>
#include <linux/clk.h>
#include <linux/omap-mailbox.h>
+#include <linux/mailbox_client.h>
#include <linux/pagemap.h>
#include <asm/cacheflush.h>
#include <linux/dma-mapping.h>
diff --git a/drivers/staging/tidspbridge/include/dspbridge/io_sm.h b/drivers/staging/tidspbridge/include/dspbridge/io_sm.h
index 903ff12..b185d6e 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/io_sm.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/io_sm.h
@@ -80,13 +80,11 @@ extern void io_dpc(unsigned long ref_data);
* Determine if this message is ours, then schedules a DPC to
* dispatch I/O.
* Parameters:
- * self: Pointer to its own notifier_block struct.
- * len: Length of message.
- * msg: Message code received.
+ * client: Mailbox Client handle registered with the mailbox core.
+ * msg: Message code received.
* Returns:
- * NOTIFY_OK if handled; NOTIFY_BAD otherwise.
*/
-int io_mbox_msg(struct notifier_block *self, unsigned long len, void *msg);
+void io_mbox_msg(struct mbox_client *client, void *msg);
/*
* ======== io_request_chnl ========
diff --git a/include/linux/omap-mailbox.h b/include/linux/omap-mailbox.h
index f8322d9..fee452c 100644
--- a/include/linux/omap-mailbox.h
+++ b/include/linux/omap-mailbox.h
@@ -10,20 +10,19 @@
#define OMAP_MAILBOX_H
typedef u32 mbox_msg_t;
-struct omap_mbox;
typedef int __bitwise omap_mbox_irq_t;
#define IRQ_TX ((__force omap_mbox_irq_t) 1)
#define IRQ_RX ((__force omap_mbox_irq_t) 2)
-int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
+struct mbox_chan;
+struct mbox_client;
-struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
-void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
+struct mbox_chan *omap_mbox_request_channel(struct mbox_client *cl);
-void omap_mbox_save_ctx(struct omap_mbox *mbox);
-void omap_mbox_restore_ctx(struct omap_mbox *mbox);
-void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
-void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
+void omap_mbox_save_ctx(struct mbox_chan *chan);
+void omap_mbox_restore_ctx(struct mbox_chan *chan);
+void omap_mbox_enable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq);
+void omap_mbox_disable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq);
#endif /* OMAP_MAILBOX_H */
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 4/6] mailbox/omap: adapt to the new mailbox framework
@ 2014-06-25 1:47 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: Ohad Ben-Cohen, devicetree, Dave Gerlach, Greg Kroah-Hartman,
Jassi Brar, linux-kernel, Jassi Brar, Omar Ramirez Luna,
linux-omap, linux-arm-kernel
The OMAP mailbox driver and its existing clients (remoteproc
for OMAP4+ and TI DSP/Bridge for OMAP3) are adapted to use
the generic mailbox framework.
The main changes for the adaptation are:
- The tasklet used for Tx is replaced with the state machine from
the generic mailbox framework. The workqueue used for processing
the received messages stays intact for minimizing the effects on
the OMAP mailbox clients.
- The existing exported client API, omap_mbox_get, omap_mbox_put and
omap_mbox_send_msg are deleted, as the framework provides equivalent
functionality. A OMAP-specific omap_mbox_request_channel is added
though to support non-DT way of requesting mailboxes for OMAP3.
- The OMAP mailbox driver is integrated with the mailbox framework
through the proper implementations of mbox_chan_ops, except for
.last_tx_done and .peek_data. The OMAP mailbox driver does not need
these ops, as it is completely interrupt driven.
- The new framework does not support multiple clients operating on a
single channel, so the reference counting logic is simplified.
- The remoteproc and tidspbridge drivers (current clients) are adapted
to use the new API. The notifier callbacks used within these clients
are replaced with the regular callbacks from the newer framework.
- The exported OMAP mailbox API are limited to omap_mbox_save_ctx,
omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq,
with the signature modified to take in the new mbox_chan handle instead
of the OMAP specific omap_mbox handle. The first 2 will be removed when
the OMAP mailbox driver is adapted to runtime_pm. The other exported
API omap_mbox_request_channel is identical in signature to the framework
API mbox_request_channel, and will be removed once OMAP3 becomes DT-boot
only.
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Omar Ramirez Luna <omar.ramirez@copitl.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/mailbox/omap-mailbox.c | 320 +++++++++++----------
drivers/remoteproc/omap_remoteproc.c | 54 ++--
drivers/staging/tidspbridge/core/_tiomap.h | 3 +-
drivers/staging/tidspbridge/core/io_sm.c | 7 +-
drivers/staging/tidspbridge/core/tiomap3430.c | 22 +-
drivers/staging/tidspbridge/core/tiomap_io.c | 7 +-
.../tidspbridge/include/dspbridge/host_os.h | 1 +
.../staging/tidspbridge/include/dspbridge/io_sm.h | 8 +-
include/linux/omap-mailbox.h | 15 +-
9 files changed, 234 insertions(+), 203 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index c61435b..d71e84f 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -29,13 +29,14 @@
#include <linux/slab.h>
#include <linux/kfifo.h>
#include <linux/err.h>
-#include <linux/notifier.h>
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/platform_data/mailbox-omap.h>
#include <linux/omap-mailbox.h>
+#include <linux/mailbox_controller.h>
+#include <linux/mailbox_client.h>
#define MAILBOX_REVISION 0x000
#define MAILBOX_MESSAGE(m) (0x040 + 4 * (m))
@@ -80,7 +81,6 @@ struct omap_mbox_queue {
spinlock_t lock;
struct kfifo fifo;
struct work_struct work;
- struct tasklet_struct tasklet;
struct omap_mbox *mbox;
bool full;
};
@@ -92,6 +92,7 @@ struct omap_mbox_device {
u32 num_users;
u32 num_fifos;
struct omap_mbox **mboxes;
+ struct mbox_controller controller;
struct list_head elem;
};
@@ -116,15 +117,14 @@ struct omap_mbox_device_data {
struct omap_mbox {
const char *name;
int irq;
- struct omap_mbox_queue *txq, *rxq;
+ struct omap_mbox_queue *rxq;
struct device *dev;
struct omap_mbox_device *parent;
struct omap_mbox_fifo tx_fifo;
struct omap_mbox_fifo rx_fifo;
u32 ctx[OMAP4_MBOX_NR_REGS];
u32 intr_type;
- int use_count;
- struct blocking_notifier_head notifier;
+ struct mbox_chan *chan;
};
/* global variables for the mailbox devices */
@@ -135,6 +135,14 @@ static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
module_param(mbox_kfifo_size, uint, S_IRUGO);
MODULE_PARM_DESC(mbox_kfifo_size, "Size of omap's mailbox kfifo (bytes)");
+static struct omap_mbox *mbox_chan_to_omap_mbox(struct mbox_chan *chan)
+{
+ if (!chan || !chan->con_priv)
+ return NULL;
+
+ return (struct omap_mbox *)chan->con_priv;
+}
+
static inline
unsigned int mbox_read_reg(struct omap_mbox_device *mdev, size_t ofs)
{
@@ -200,41 +208,14 @@ static int is_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
return (int)(enable & status & bit);
}
-/*
- * message sender
- */
-int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
-{
- struct omap_mbox_queue *mq = mbox->txq;
- int ret = 0, len;
-
- spin_lock_bh(&mq->lock);
-
- if (kfifo_avail(&mq->fifo) < sizeof(msg)) {
- ret = -ENOMEM;
- goto out;
- }
-
- if (kfifo_is_empty(&mq->fifo) && !mbox_fifo_full(mbox)) {
- mbox_fifo_write(mbox, msg);
- goto out;
- }
-
- len = kfifo_in(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
- WARN_ON(len != sizeof(msg));
-
- tasklet_schedule(&mbox->txq->tasklet);
-
-out:
- spin_unlock_bh(&mq->lock);
- return ret;
-}
-EXPORT_SYMBOL(omap_mbox_msg_send);
-
-void omap_mbox_save_ctx(struct omap_mbox *mbox)
+void omap_mbox_save_ctx(struct mbox_chan *chan)
{
int i;
int nr_regs;
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+
+ if (WARN_ON(!mbox))
+ return;
if (mbox->intr_type)
nr_regs = OMAP4_MBOX_NR_REGS;
@@ -249,10 +230,14 @@ void omap_mbox_save_ctx(struct omap_mbox *mbox)
}
EXPORT_SYMBOL(omap_mbox_save_ctx);
-void omap_mbox_restore_ctx(struct omap_mbox *mbox)
+void omap_mbox_restore_ctx(struct mbox_chan *chan)
{
int i;
int nr_regs;
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+
+ if (WARN_ON(!mbox))
+ return;
if (mbox->intr_type)
nr_regs = OMAP4_MBOX_NR_REGS;
@@ -260,14 +245,13 @@ void omap_mbox_restore_ctx(struct omap_mbox *mbox)
nr_regs = MBOX_NR_REGS;
for (i = 0; i < nr_regs; i++) {
mbox_write_reg(mbox->parent, mbox->ctx[i], i * sizeof(u32));
-
dev_dbg(mbox->dev, "%s: [%02x] %08x\n", __func__,
i, mbox->ctx[i]);
}
}
EXPORT_SYMBOL(omap_mbox_restore_ctx);
-void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+static void _omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
u32 l;
struct omap_mbox_fifo *fifo = (irq == IRQ_TX) ?
@@ -279,9 +263,8 @@ void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
l |= bit;
mbox_write_reg(mbox->parent, l, irqenable);
}
-EXPORT_SYMBOL(omap_mbox_enable_irq);
-void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+static void _omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
struct omap_mbox_fifo *fifo = (irq == IRQ_TX) ?
&mbox->tx_fifo : &mbox->rx_fifo;
@@ -297,28 +280,28 @@ void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
mbox_write_reg(mbox->parent, bit, irqdisable);
}
-EXPORT_SYMBOL(omap_mbox_disable_irq);
-static void mbox_tx_tasklet(unsigned long tx_data)
+void omap_mbox_enable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq)
{
- struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
- struct omap_mbox_queue *mq = mbox->txq;
- mbox_msg_t msg;
- int ret;
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
- while (kfifo_len(&mq->fifo)) {
- if (mbox_fifo_full(mbox)) {
- omap_mbox_enable_irq(mbox, IRQ_TX);
- break;
- }
+ if (WARN_ON(!mbox))
+ return;
+
+ _omap_mbox_enable_irq(mbox, irq);
+}
+EXPORT_SYMBOL(omap_mbox_enable_irq);
- ret = kfifo_out(&mq->fifo, (unsigned char *)&msg,
- sizeof(msg));
- WARN_ON(ret != sizeof(msg));
+void omap_mbox_disable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq)
+{
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
- mbox_fifo_write(mbox, msg);
- }
+ if (WARN_ON(!mbox))
+ return;
+
+ _omap_mbox_disable_irq(mbox, irq);
}
+EXPORT_SYMBOL(omap_mbox_disable_irq);
/*
* Message receiver(workqueue)
@@ -334,12 +317,11 @@ static void mbox_rx_work(struct work_struct *work)
len = kfifo_out(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
WARN_ON(len != sizeof(msg));
- blocking_notifier_call_chain(&mq->mbox->notifier, len,
- (void *)msg);
+ mbox_chan_received_data(mq->mbox->chan, (void *)msg);
spin_lock_irq(&mq->lock);
if (mq->full) {
mq->full = false;
- omap_mbox_enable_irq(mq->mbox, IRQ_RX);
+ _omap_mbox_enable_irq(mq->mbox, IRQ_RX);
}
spin_unlock_irq(&mq->lock);
}
@@ -350,9 +332,9 @@ static void mbox_rx_work(struct work_struct *work)
*/
static void __mbox_tx_interrupt(struct omap_mbox *mbox)
{
- omap_mbox_disable_irq(mbox, IRQ_TX);
+ _omap_mbox_disable_irq(mbox, IRQ_TX);
ack_mbox_irq(mbox, IRQ_TX);
- tasklet_schedule(&mbox->txq->tasklet);
+ mbox_chan_txdone(mbox->chan, 0);
}
static void __mbox_rx_interrupt(struct omap_mbox *mbox)
@@ -363,7 +345,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(&mq->fifo) < sizeof(msg))) {
- omap_mbox_disable_irq(mbox, IRQ_RX);
+ _omap_mbox_disable_irq(mbox, IRQ_RX);
mq->full = true;
goto nomem;
}
@@ -394,11 +376,13 @@ static irqreturn_t mbox_interrupt(int irq, void *p)
}
static struct omap_mbox_queue *mbox_queue_alloc(struct omap_mbox *mbox,
- void (*work) (struct work_struct *),
- void (*tasklet)(unsigned long))
+ void (*work)(struct work_struct *))
{
struct omap_mbox_queue *mq;
+ if (!work)
+ return NULL;
+
mq = kzalloc(sizeof(struct omap_mbox_queue), GFP_KERNEL);
if (!mq)
return NULL;
@@ -408,12 +392,9 @@ static struct omap_mbox_queue *mbox_queue_alloc(struct omap_mbox *mbox,
if (kfifo_alloc(&mq->fifo, mbox_kfifo_size, GFP_KERNEL))
goto error;
- if (work)
- INIT_WORK(&mq->work, work);
-
- if (tasklet)
- tasklet_init(&mq->tasklet, tasklet, (unsigned long)mbox);
+ INIT_WORK(&mq->work, work);
return mq;
+
error:
kfree(mq);
return NULL;
@@ -429,71 +410,35 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
{
int ret = 0;
struct omap_mbox_queue *mq;
- struct omap_mbox_device *mdev = mbox->parent;
- mutex_lock(&mdev->cfg_lock);
- ret = pm_runtime_get_sync(mdev->dev);
- if (unlikely(ret < 0))
- goto fail_startup;
-
- if (!mbox->use_count++) {
- mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
- if (!mq) {
- ret = -ENOMEM;
- goto fail_alloc_txq;
- }
- mbox->txq = mq;
+ mq = mbox_queue_alloc(mbox, mbox_rx_work);
+ if (!mq)
+ return -ENOMEM;
+ mbox->rxq = mq;
+ mq->mbox = mbox;
+
+ ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED,
+ mbox->name, mbox);
+ if (unlikely(ret)) {
+ pr_err("failed to register mailbox interrupt:%d\n", ret);
+ goto fail_request_irq;
+ }
- mq = mbox_queue_alloc(mbox, mbox_rx_work, NULL);
- if (!mq) {
- ret = -ENOMEM;
- goto fail_alloc_rxq;
- }
- mbox->rxq = mq;
- mq->mbox = mbox;
- ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED,
- mbox->name, mbox);
- if (unlikely(ret)) {
- pr_err("failed to register mailbox interrupt:%d\n",
- ret);
- goto fail_request_irq;
- }
+ _omap_mbox_enable_irq(mbox, IRQ_RX);
- omap_mbox_enable_irq(mbox, IRQ_RX);
- }
- mutex_unlock(&mdev->cfg_lock);
return 0;
fail_request_irq:
mbox_queue_free(mbox->rxq);
-fail_alloc_rxq:
- mbox_queue_free(mbox->txq);
-fail_alloc_txq:
- pm_runtime_put_sync(mdev->dev);
- mbox->use_count--;
-fail_startup:
- mutex_unlock(&mdev->cfg_lock);
return ret;
}
static void omap_mbox_fini(struct omap_mbox *mbox)
{
- struct omap_mbox_device *mdev = mbox->parent;
-
- mutex_lock(&mdev->cfg_lock);
-
- if (!--mbox->use_count) {
- omap_mbox_disable_irq(mbox, IRQ_RX);
- free_irq(mbox->irq, mbox);
- tasklet_kill(&mbox->txq->tasklet);
- flush_work(&mbox->rxq->work);
- mbox_queue_free(mbox->txq);
- mbox_queue_free(mbox->rxq);
- }
-
- pm_runtime_put_sync(mdev->dev);
-
- mutex_unlock(&mdev->cfg_lock);
+ _omap_mbox_disable_irq(mbox, IRQ_RX);
+ free_irq(mbox->irq, mbox);
+ flush_work(&mbox->rxq->work);
+ mbox_queue_free(mbox->rxq);
}
static struct omap_mbox *omap_mbox_device_find(struct omap_mbox_device *mdev,
@@ -515,42 +460,54 @@ static struct omap_mbox *omap_mbox_device_find(struct omap_mbox_device *mdev,
return mbox;
}
-struct omap_mbox *omap_mbox_get(const char *name, struct notifier_block *nb)
+struct mbox_chan *omap_mbox_request_channel(struct mbox_client *cl)
{
+ struct device *dev = cl->dev;
struct omap_mbox *mbox = NULL;
struct omap_mbox_device *mdev;
+ struct mbox_chan *chan;
+ unsigned long flags;
int ret;
+ if (!dev)
+ return ERR_PTR(-ENODEV);
+
+ if (dev->of_node) {
+ pr_err("%s: please use mbox_request_channel(), this API is supported only for OMAP non-DT usage\n",
+ __func__);
+ return ERR_PTR(-ENODEV);
+ }
+
mutex_lock(&omap_mbox_devices_lock);
list_for_each_entry(mdev, &omap_mbox_devices, elem) {
- mbox = omap_mbox_device_find(mdev, name);
+ mbox = omap_mbox_device_find(mdev, cl->chan_name);
if (mbox)
break;
}
mutex_unlock(&omap_mbox_devices_lock);
- if (!mbox)
+ if (!mbox || !mbox->chan)
return ERR_PTR(-ENOENT);
- if (nb)
- blocking_notifier_chain_register(&mbox->notifier, nb);
+ chan = mbox->chan;
+ spin_lock_irqsave(&chan->lock, flags);
+ chan->msg_free = 0;
+ chan->msg_count = 0;
+ chan->active_req = NULL;
+ chan->cl = cl;
+ init_completion(&chan->tx_complete);
+ spin_unlock_irqrestore(&chan->lock, flags);
- ret = omap_mbox_startup(mbox);
+ ret = chan->mbox->ops->startup(chan);
if (ret) {
- blocking_notifier_chain_unregister(&mbox->notifier, nb);
- return ERR_PTR(-ENODEV);
+ pr_err("Unable to startup the chan (%d)\n", ret);
+ mbox_free_channel(chan);
+ chan = ERR_PTR(ret);
}
- return mbox;
+ return chan;
}
-EXPORT_SYMBOL(omap_mbox_get);
-
-void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb)
-{
- blocking_notifier_chain_unregister(&mbox->notifier, nb);
- omap_mbox_fini(mbox);
-}
-EXPORT_SYMBOL(omap_mbox_put);
+EXPORT_SYMBOL(omap_mbox_request_channel);
static struct class omap_mbox_class = { .name = "mbox", };
@@ -566,25 +523,25 @@ static int omap_mbox_register(struct omap_mbox_device *mdev)
mboxes = mdev->mboxes;
for (i = 0; mboxes[i]; i++) {
struct omap_mbox *mbox = mboxes[i];
- mbox->dev = device_create(&omap_mbox_class,
- mdev->dev, 0, mbox, "%s", mbox->name);
+ mbox->dev = device_create(&omap_mbox_class, mdev->dev,
+ 0, mbox, "%s", mbox->name);
if (IS_ERR(mbox->dev)) {
ret = PTR_ERR(mbox->dev);
goto err_out;
}
-
- BLOCKING_INIT_NOTIFIER_HEAD(&mbox->notifier);
}
mutex_lock(&omap_mbox_devices_lock);
list_add(&mdev->elem, &omap_mbox_devices);
mutex_unlock(&omap_mbox_devices_lock);
- return 0;
+ ret = mbox_controller_register(&mdev->controller);
err_out:
- while (i--)
- device_unregister(mboxes[i]->dev);
+ if (ret) {
+ while (i--)
+ device_unregister(mboxes[i]->dev);
+ }
return ret;
}
@@ -600,12 +557,64 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
list_del(&mdev->elem);
mutex_unlock(&omap_mbox_devices_lock);
+ mbox_controller_unregister(&mdev->controller);
+
mboxes = mdev->mboxes;
for (i = 0; mboxes[i]; i++)
device_unregister(mboxes[i]->dev);
return 0;
}
+static int omap_mbox_chan_startup(struct mbox_chan *chan)
+{
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ struct omap_mbox_device *mdev = mbox->parent;
+ int ret = 0;
+
+ mutex_lock(&mdev->cfg_lock);
+ pm_runtime_get_sync(mdev->dev);
+ ret = omap_mbox_startup(mbox);
+ if (ret)
+ pm_runtime_put_sync(mdev->dev);
+ mutex_unlock(&mdev->cfg_lock);
+ return ret;
+}
+
+static void omap_mbox_chan_shutdown(struct mbox_chan *chan)
+{
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ struct omap_mbox_device *mdev = mbox->parent;
+
+ mutex_lock(&mdev->cfg_lock);
+ omap_mbox_fini(mbox);
+ pm_runtime_put_sync(mdev->dev);
+ mutex_unlock(&mdev->cfg_lock);
+}
+
+static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
+{
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ int ret = -EBUSY;
+
+ if (!mbox)
+ return -EINVAL;
+
+ if (!mbox_fifo_full(mbox)) {
+ mbox_fifo_write(mbox, (mbox_msg_t)data);
+ ret = 0;
+ }
+
+ /* always enable the interrupt */
+ _omap_mbox_enable_irq(mbox, IRQ_TX);
+ return ret;
+}
+
+static struct mbox_chan_ops omap_mbox_chan_ops = {
+ .startup = omap_mbox_chan_startup,
+ .send_data = omap_mbox_chan_send_data,
+ .shutdown = omap_mbox_chan_shutdown,
+};
+
static const struct omap_mbox_device_data omap2_data = {
.num_users = 4,
.num_fifos = 6,
@@ -671,6 +680,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
int ret;
+ struct mbox_chan *chnls;
struct omap_mbox **list, *mbox, *mboxblk;
struct omap_mbox_pdata *pdata = pdev->dev.platform_data;
struct omap_mbox_dev_info *info = NULL;
@@ -772,6 +782,11 @@ static int omap_mbox_probe(struct platform_device *pdev)
if (!list)
return -ENOMEM;
+ chnls = devm_kzalloc(&pdev->dev, (info_count + 1) * sizeof(*chnls),
+ GFP_KERNEL);
+ if (!chnls)
+ return -ENOMEM;
+
mboxblk = devm_kzalloc(&pdev->dev, info_count * sizeof(*mbox),
GFP_KERNEL);
if (!mboxblk)
@@ -803,6 +818,8 @@ static int omap_mbox_probe(struct platform_device *pdev)
mbox->irq = platform_get_irq(pdev, finfo->tx_irq);
if (mbox->irq < 0)
return mbox->irq;
+ mbox->chan = &chnls[i];
+ chnls[i].con_priv = mbox;
list[i] = mbox++;
}
@@ -811,6 +828,13 @@ static int omap_mbox_probe(struct platform_device *pdev)
mdev->num_users = num_users;
mdev->num_fifos = num_fifos;
mdev->mboxes = list;
+
+ /* OMAP does not have a Tx-Done IRQ, but rather a Tx-Ready IRQ */
+ mdev->controller.txdone_irq = true;
+ mdev->controller.dev = mdev->dev;
+ mdev->controller.ops = &omap_mbox_chan_ops;
+ mdev->controller.chans = chnls;
+ mdev->controller.num_chans = info_count;
ret = omap_mbox_register(mdev);
if (ret)
return ret;
diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 5168972..0a87e57 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -27,6 +27,7 @@
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/remoteproc.h>
+#include <linux/mailbox_client.h>
#include <linux/omap-mailbox.h>
#include <linux/platform_data/remoteproc-omap.h>
@@ -36,20 +37,19 @@
/**
* struct omap_rproc - omap remote processor state
- * @mbox: omap mailbox handle
- * @nb: notifier block that will be invoked on inbound mailbox messages
+ * @mbox: mailbox channel handle
+ * @client: mailbox client to request the mailbox channel
* @rproc: rproc handle
*/
struct omap_rproc {
- struct omap_mbox *mbox;
- struct notifier_block nb;
+ struct mbox_chan *mbox;
+ struct mbox_client client;
struct rproc *rproc;
};
/**
* omap_rproc_mbox_callback() - inbound mailbox message handler
- * @this: notifier block
- * @index: unused
+ * @client: mailbox client pointer used for requesting the mailbox channel
* @data: mailbox payload
*
* This handler is invoked by omap's mailbox driver whenever a mailbox
@@ -61,13 +61,13 @@ struct omap_rproc {
* that indicates different events. Those values are deliberately very
* big so they don't coincide with virtqueue indices.
*/
-static int omap_rproc_mbox_callback(struct notifier_block *this,
- unsigned long index, void *data)
+static void omap_rproc_mbox_callback(struct mbox_client *client, void *data)
{
- mbox_msg_t msg = (mbox_msg_t) data;
- struct omap_rproc *oproc = container_of(this, struct omap_rproc, nb);
+ struct omap_rproc *oproc = container_of(client, struct omap_rproc,
+ client);
struct device *dev = oproc->rproc->dev.parent;
const char *name = oproc->rproc->name;
+ u32 msg = (u32)data;
dev_dbg(dev, "mbox msg: 0x%x\n", msg);
@@ -84,8 +84,6 @@ static int omap_rproc_mbox_callback(struct notifier_block *this,
if (rproc_vq_interrupt(oproc->rproc, msg) == IRQ_NONE)
dev_dbg(dev, "no message was found in vqid %d\n", msg);
}
-
- return NOTIFY_DONE;
}
/* kick a virtqueue */
@@ -96,8 +94,8 @@ static void omap_rproc_kick(struct rproc *rproc, int vqid)
int ret;
/* send the index of the triggered virtqueue in the mailbox payload */
- ret = omap_mbox_msg_send(oproc->mbox, vqid);
- if (ret)
+ ret = mbox_send_message(oproc->mbox, (void *)vqid);
+ if (ret < 0)
dev_err(dev, "omap_mbox_msg_send failed: %d\n", ret);
}
@@ -115,17 +113,25 @@ static int omap_rproc_start(struct rproc *rproc)
struct platform_device *pdev = to_platform_device(dev);
struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
int ret;
+ struct mbox_client *client = &oproc->client;
+ char client_name[32];
if (pdata->set_bootaddr)
pdata->set_bootaddr(rproc->bootaddr);
- oproc->nb.notifier_call = omap_rproc_mbox_callback;
+ client->dev = dev;
+ client->tx_done = NULL;
+ client->rx_callback = omap_rproc_mbox_callback;
+ client->tx_block = false;
+ client->knows_txdone = false;
+ sprintf(client_name, "%s", pdata->mbox_name);
+ client->chan_name = client_name;
- /* every omap rproc is assigned a mailbox instance for messaging */
- oproc->mbox = omap_mbox_get(pdata->mbox_name, &oproc->nb);
+ oproc->mbox = omap_mbox_request_channel(client);
if (IS_ERR(oproc->mbox)) {
- ret = PTR_ERR(oproc->mbox);
- dev_err(dev, "omap_mbox_get failed: %d\n", ret);
+ ret = -EBUSY;
+ dev_err(dev, "mbox_request_channel failed: %ld\n",
+ PTR_ERR(oproc->mbox));
return ret;
}
@@ -136,9 +142,9 @@ static int omap_rproc_start(struct rproc *rproc)
* Note that the reply will _not_ arrive immediately: this message
* will wait in the mailbox fifo until the remote processor is booted.
*/
- ret = omap_mbox_msg_send(oproc->mbox, RP_MBOX_ECHO_REQUEST);
- if (ret) {
- dev_err(dev, "omap_mbox_get failed: %d\n", ret);
+ ret = mbox_send_message(oproc->mbox, (void *)RP_MBOX_ECHO_REQUEST);
+ if (ret < 0) {
+ dev_err(dev, "mbox_send_message failed: %d\n", ret);
goto put_mbox;
}
@@ -151,7 +157,7 @@ static int omap_rproc_start(struct rproc *rproc)
return 0;
put_mbox:
- omap_mbox_put(oproc->mbox, &oproc->nb);
+ mbox_free_channel(oproc->mbox);
return ret;
}
@@ -168,7 +174,7 @@ static int omap_rproc_stop(struct rproc *rproc)
if (ret)
return ret;
- omap_mbox_put(oproc->mbox, &oproc->nb);
+ mbox_free_channel(oproc->mbox);
return 0;
}
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h b/drivers/staging/tidspbridge/core/_tiomap.h
index 65971b7..2b8390f 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -338,7 +338,8 @@ struct bridge_dev_context {
u32 dsp_start_add; /* API Boot vector */
u32 internal_size; /* Internal memory size */
- struct omap_mbox *mbox; /* Mail box handle */
+ struct mbox_client client; /* Mailbox Client */
+ struct mbox_chan *mbox; /* Mailbox handle */
struct cfg_hostres *resources; /* Host Resources */
diff --git a/drivers/staging/tidspbridge/core/io_sm.c b/drivers/staging/tidspbridge/core/io_sm.c
index c2829aa..4b6673a 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -908,7 +908,7 @@ func_end:
* Calls the Bridge's CHNL_ISR to determine if this interrupt is ours, then
* schedules a DPC to dispatch I/O.
*/
-int io_mbox_msg(struct notifier_block *self, unsigned long len, void *msg)
+void io_mbox_msg(struct mbox_client *client, void *msg)
{
struct io_mgr *pio_mgr;
struct dev_object *dev_obj;
@@ -917,8 +917,8 @@ int io_mbox_msg(struct notifier_block *self, unsigned long len, void *msg)
dev_obj = dev_get_first();
dev_get_io_mgr(dev_obj, &pio_mgr);
- if (!pio_mgr)
- return NOTIFY_BAD;
+ if (WARN_ON(!pio_mgr))
+ return;
pio_mgr->intr_val = (u16)((u32)msg);
if (pio_mgr->intr_val & MBX_PM_CLASS)
@@ -932,7 +932,6 @@ int io_mbox_msg(struct notifier_block *self, unsigned long len, void *msg)
spin_unlock_irqrestore(&pio_mgr->dpc_lock, flags);
tasklet_schedule(&pio_mgr->dpc_tasklet);
}
- return NOTIFY_OK;
}
/*
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c b/drivers/staging/tidspbridge/core/tiomap3430.c
index 8945b4e..5f6287c 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -212,10 +212,6 @@ static struct bridge_drv_interface drv_interface_fxns = {
bridge_msg_set_queue_id,
};
-static struct notifier_block dsp_mbox_notifier = {
- .notifier_call = io_mbox_msg,
-};
-
static inline void flush_all(struct bridge_dev_context *dev_context)
{
if (dev_context->brd_state == BRD_DSP_HIBERNATION ||
@@ -378,6 +374,8 @@ static int bridge_brd_start(struct bridge_dev_context *dev_ctxt,
u32 wdt_en = 0;
struct omap_dsp_platform_data *pdata =
omap_dspbridge_dev->dev.platform_data;
+ struct mbox_client *client = &dev_context->client;
+ char mbox_user_name[32];
/* The device context contains all the mmu setup info from when the
* last dsp base image was loaded. The first entry is always
@@ -544,11 +542,17 @@ static int bridge_brd_start(struct bridge_dev_context *dev_ctxt,
* Enable Mailbox events and also drain any pending
* stale messages.
*/
- dev_context->mbox = omap_mbox_get("dsp", &dsp_mbox_notifier);
+ client->dev = &omap_dspbridge_dev->dev;
+ client->tx_done = NULL;
+ client->rx_callback = io_mbox_msg;
+ client->tx_block = false;
+ client->knows_txdone = false;
+ sprintf(mbox_user_name, "dsp");
+ client->chan_name = mbox_user_name;
+ dev_context->mbox = omap_mbox_request_channel(client);
if (IS_ERR(dev_context->mbox)) {
- dev_context->mbox = NULL;
- pr_err("%s: Failed to get dsp mailbox handle\n",
- __func__);
+ pr_err("%s: Failed to get dsp mailbox handle, ret = %ld\n",
+ __func__, PTR_ERR(dev_context->mbox));
status = -EPERM;
}
@@ -680,7 +684,7 @@ static int bridge_brd_stop(struct bridge_dev_context *dev_ctxt)
/* Disable the mailbox interrupts */
if (dev_context->mbox) {
omap_mbox_disable_irq(dev_context->mbox, IRQ_RX);
- omap_mbox_put(dev_context->mbox, &dsp_mbox_notifier);
+ mbox_free_channel(dev_context->mbox);
dev_context->mbox = NULL;
}
/* Reset IVA2 clocks*/
diff --git a/drivers/staging/tidspbridge/core/tiomap_io.c b/drivers/staging/tidspbridge/core/tiomap_io.c
index f53ed98..fe86035 100644
--- a/drivers/staging/tidspbridge/core/tiomap_io.c
+++ b/drivers/staging/tidspbridge/core/tiomap_io.c
@@ -427,10 +427,9 @@ int sm_interrupt_dsp(struct bridge_dev_context *dev_context, u16 mb_val)
dsp_clock_enable_all(dev_context->dsp_per_clks);
}
- status = omap_mbox_msg_send(dev_context->mbox, mb_val);
-
- if (status) {
- pr_err("omap_mbox_msg_send Fail and status = %d\n", status);
+ status = mbox_send_message(dev_context->mbox, (void *)((u32)mb_val));
+ if (status < 0) {
+ pr_err("mbox_send_message failed, status = %d\n", status);
status = -EPERM;
}
diff --git a/drivers/staging/tidspbridge/include/dspbridge/host_os.h b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
index d1441db..8ddef2b 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/host_os.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
@@ -42,6 +42,7 @@
#include <linux/platform_device.h>
#include <linux/clk.h>
#include <linux/omap-mailbox.h>
+#include <linux/mailbox_client.h>
#include <linux/pagemap.h>
#include <asm/cacheflush.h>
#include <linux/dma-mapping.h>
diff --git a/drivers/staging/tidspbridge/include/dspbridge/io_sm.h b/drivers/staging/tidspbridge/include/dspbridge/io_sm.h
index 903ff12..b185d6e 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/io_sm.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/io_sm.h
@@ -80,13 +80,11 @@ extern void io_dpc(unsigned long ref_data);
* Determine if this message is ours, then schedules a DPC to
* dispatch I/O.
* Parameters:
- * self: Pointer to its own notifier_block struct.
- * len: Length of message.
- * msg: Message code received.
+ * client: Mailbox Client handle registered with the mailbox core.
+ * msg: Message code received.
* Returns:
- * NOTIFY_OK if handled; NOTIFY_BAD otherwise.
*/
-int io_mbox_msg(struct notifier_block *self, unsigned long len, void *msg);
+void io_mbox_msg(struct mbox_client *client, void *msg);
/*
* ======== io_request_chnl ========
diff --git a/include/linux/omap-mailbox.h b/include/linux/omap-mailbox.h
index f8322d9..fee452c 100644
--- a/include/linux/omap-mailbox.h
+++ b/include/linux/omap-mailbox.h
@@ -10,20 +10,19 @@
#define OMAP_MAILBOX_H
typedef u32 mbox_msg_t;
-struct omap_mbox;
typedef int __bitwise omap_mbox_irq_t;
#define IRQ_TX ((__force omap_mbox_irq_t) 1)
#define IRQ_RX ((__force omap_mbox_irq_t) 2)
-int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
+struct mbox_chan;
+struct mbox_client;
-struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
-void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
+struct mbox_chan *omap_mbox_request_channel(struct mbox_client *cl);
-void omap_mbox_save_ctx(struct omap_mbox *mbox);
-void omap_mbox_restore_ctx(struct omap_mbox *mbox);
-void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
-void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
+void omap_mbox_save_ctx(struct mbox_chan *chan);
+void omap_mbox_restore_ctx(struct mbox_chan *chan);
+void omap_mbox_enable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq);
+void omap_mbox_disable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq);
#endif /* OMAP_MAILBOX_H */
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 4/6] mailbox/omap: adapt to the new mailbox framework
@ 2014-06-25 1:47 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: linux-arm-kernel
The OMAP mailbox driver and its existing clients (remoteproc
for OMAP4+ and TI DSP/Bridge for OMAP3) are adapted to use
the generic mailbox framework.
The main changes for the adaptation are:
- The tasklet used for Tx is replaced with the state machine from
the generic mailbox framework. The workqueue used for processing
the received messages stays intact for minimizing the effects on
the OMAP mailbox clients.
- The existing exported client API, omap_mbox_get, omap_mbox_put and
omap_mbox_send_msg are deleted, as the framework provides equivalent
functionality. A OMAP-specific omap_mbox_request_channel is added
though to support non-DT way of requesting mailboxes for OMAP3.
- The OMAP mailbox driver is integrated with the mailbox framework
through the proper implementations of mbox_chan_ops, except for
.last_tx_done and .peek_data. The OMAP mailbox driver does not need
these ops, as it is completely interrupt driven.
- The new framework does not support multiple clients operating on a
single channel, so the reference counting logic is simplified.
- The remoteproc and tidspbridge drivers (current clients) are adapted
to use the new API. The notifier callbacks used within these clients
are replaced with the regular callbacks from the newer framework.
- The exported OMAP mailbox API are limited to omap_mbox_save_ctx,
omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq,
with the signature modified to take in the new mbox_chan handle instead
of the OMAP specific omap_mbox handle. The first 2 will be removed when
the OMAP mailbox driver is adapted to runtime_pm. The other exported
API omap_mbox_request_channel is identical in signature to the framework
API mbox_request_channel, and will be removed once OMAP3 becomes DT-boot
only.
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Omar Ramirez Luna <omar.ramirez@copitl.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/mailbox/omap-mailbox.c | 320 +++++++++++----------
drivers/remoteproc/omap_remoteproc.c | 54 ++--
drivers/staging/tidspbridge/core/_tiomap.h | 3 +-
drivers/staging/tidspbridge/core/io_sm.c | 7 +-
drivers/staging/tidspbridge/core/tiomap3430.c | 22 +-
drivers/staging/tidspbridge/core/tiomap_io.c | 7 +-
.../tidspbridge/include/dspbridge/host_os.h | 1 +
.../staging/tidspbridge/include/dspbridge/io_sm.h | 8 +-
include/linux/omap-mailbox.h | 15 +-
9 files changed, 234 insertions(+), 203 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index c61435b..d71e84f 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -29,13 +29,14 @@
#include <linux/slab.h>
#include <linux/kfifo.h>
#include <linux/err.h>
-#include <linux/notifier.h>
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/platform_data/mailbox-omap.h>
#include <linux/omap-mailbox.h>
+#include <linux/mailbox_controller.h>
+#include <linux/mailbox_client.h>
#define MAILBOX_REVISION 0x000
#define MAILBOX_MESSAGE(m) (0x040 + 4 * (m))
@@ -80,7 +81,6 @@ struct omap_mbox_queue {
spinlock_t lock;
struct kfifo fifo;
struct work_struct work;
- struct tasklet_struct tasklet;
struct omap_mbox *mbox;
bool full;
};
@@ -92,6 +92,7 @@ struct omap_mbox_device {
u32 num_users;
u32 num_fifos;
struct omap_mbox **mboxes;
+ struct mbox_controller controller;
struct list_head elem;
};
@@ -116,15 +117,14 @@ struct omap_mbox_device_data {
struct omap_mbox {
const char *name;
int irq;
- struct omap_mbox_queue *txq, *rxq;
+ struct omap_mbox_queue *rxq;
struct device *dev;
struct omap_mbox_device *parent;
struct omap_mbox_fifo tx_fifo;
struct omap_mbox_fifo rx_fifo;
u32 ctx[OMAP4_MBOX_NR_REGS];
u32 intr_type;
- int use_count;
- struct blocking_notifier_head notifier;
+ struct mbox_chan *chan;
};
/* global variables for the mailbox devices */
@@ -135,6 +135,14 @@ static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
module_param(mbox_kfifo_size, uint, S_IRUGO);
MODULE_PARM_DESC(mbox_kfifo_size, "Size of omap's mailbox kfifo (bytes)");
+static struct omap_mbox *mbox_chan_to_omap_mbox(struct mbox_chan *chan)
+{
+ if (!chan || !chan->con_priv)
+ return NULL;
+
+ return (struct omap_mbox *)chan->con_priv;
+}
+
static inline
unsigned int mbox_read_reg(struct omap_mbox_device *mdev, size_t ofs)
{
@@ -200,41 +208,14 @@ static int is_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
return (int)(enable & status & bit);
}
-/*
- * message sender
- */
-int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
-{
- struct omap_mbox_queue *mq = mbox->txq;
- int ret = 0, len;
-
- spin_lock_bh(&mq->lock);
-
- if (kfifo_avail(&mq->fifo) < sizeof(msg)) {
- ret = -ENOMEM;
- goto out;
- }
-
- if (kfifo_is_empty(&mq->fifo) && !mbox_fifo_full(mbox)) {
- mbox_fifo_write(mbox, msg);
- goto out;
- }
-
- len = kfifo_in(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
- WARN_ON(len != sizeof(msg));
-
- tasklet_schedule(&mbox->txq->tasklet);
-
-out:
- spin_unlock_bh(&mq->lock);
- return ret;
-}
-EXPORT_SYMBOL(omap_mbox_msg_send);
-
-void omap_mbox_save_ctx(struct omap_mbox *mbox)
+void omap_mbox_save_ctx(struct mbox_chan *chan)
{
int i;
int nr_regs;
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+
+ if (WARN_ON(!mbox))
+ return;
if (mbox->intr_type)
nr_regs = OMAP4_MBOX_NR_REGS;
@@ -249,10 +230,14 @@ void omap_mbox_save_ctx(struct omap_mbox *mbox)
}
EXPORT_SYMBOL(omap_mbox_save_ctx);
-void omap_mbox_restore_ctx(struct omap_mbox *mbox)
+void omap_mbox_restore_ctx(struct mbox_chan *chan)
{
int i;
int nr_regs;
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+
+ if (WARN_ON(!mbox))
+ return;
if (mbox->intr_type)
nr_regs = OMAP4_MBOX_NR_REGS;
@@ -260,14 +245,13 @@ void omap_mbox_restore_ctx(struct omap_mbox *mbox)
nr_regs = MBOX_NR_REGS;
for (i = 0; i < nr_regs; i++) {
mbox_write_reg(mbox->parent, mbox->ctx[i], i * sizeof(u32));
-
dev_dbg(mbox->dev, "%s: [%02x] %08x\n", __func__,
i, mbox->ctx[i]);
}
}
EXPORT_SYMBOL(omap_mbox_restore_ctx);
-void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+static void _omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
u32 l;
struct omap_mbox_fifo *fifo = (irq == IRQ_TX) ?
@@ -279,9 +263,8 @@ void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
l |= bit;
mbox_write_reg(mbox->parent, l, irqenable);
}
-EXPORT_SYMBOL(omap_mbox_enable_irq);
-void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+static void _omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
struct omap_mbox_fifo *fifo = (irq == IRQ_TX) ?
&mbox->tx_fifo : &mbox->rx_fifo;
@@ -297,28 +280,28 @@ void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
mbox_write_reg(mbox->parent, bit, irqdisable);
}
-EXPORT_SYMBOL(omap_mbox_disable_irq);
-static void mbox_tx_tasklet(unsigned long tx_data)
+void omap_mbox_enable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq)
{
- struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
- struct omap_mbox_queue *mq = mbox->txq;
- mbox_msg_t msg;
- int ret;
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
- while (kfifo_len(&mq->fifo)) {
- if (mbox_fifo_full(mbox)) {
- omap_mbox_enable_irq(mbox, IRQ_TX);
- break;
- }
+ if (WARN_ON(!mbox))
+ return;
+
+ _omap_mbox_enable_irq(mbox, irq);
+}
+EXPORT_SYMBOL(omap_mbox_enable_irq);
- ret = kfifo_out(&mq->fifo, (unsigned char *)&msg,
- sizeof(msg));
- WARN_ON(ret != sizeof(msg));
+void omap_mbox_disable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq)
+{
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
- mbox_fifo_write(mbox, msg);
- }
+ if (WARN_ON(!mbox))
+ return;
+
+ _omap_mbox_disable_irq(mbox, irq);
}
+EXPORT_SYMBOL(omap_mbox_disable_irq);
/*
* Message receiver(workqueue)
@@ -334,12 +317,11 @@ static void mbox_rx_work(struct work_struct *work)
len = kfifo_out(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
WARN_ON(len != sizeof(msg));
- blocking_notifier_call_chain(&mq->mbox->notifier, len,
- (void *)msg);
+ mbox_chan_received_data(mq->mbox->chan, (void *)msg);
spin_lock_irq(&mq->lock);
if (mq->full) {
mq->full = false;
- omap_mbox_enable_irq(mq->mbox, IRQ_RX);
+ _omap_mbox_enable_irq(mq->mbox, IRQ_RX);
}
spin_unlock_irq(&mq->lock);
}
@@ -350,9 +332,9 @@ static void mbox_rx_work(struct work_struct *work)
*/
static void __mbox_tx_interrupt(struct omap_mbox *mbox)
{
- omap_mbox_disable_irq(mbox, IRQ_TX);
+ _omap_mbox_disable_irq(mbox, IRQ_TX);
ack_mbox_irq(mbox, IRQ_TX);
- tasklet_schedule(&mbox->txq->tasklet);
+ mbox_chan_txdone(mbox->chan, 0);
}
static void __mbox_rx_interrupt(struct omap_mbox *mbox)
@@ -363,7 +345,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(&mq->fifo) < sizeof(msg))) {
- omap_mbox_disable_irq(mbox, IRQ_RX);
+ _omap_mbox_disable_irq(mbox, IRQ_RX);
mq->full = true;
goto nomem;
}
@@ -394,11 +376,13 @@ static irqreturn_t mbox_interrupt(int irq, void *p)
}
static struct omap_mbox_queue *mbox_queue_alloc(struct omap_mbox *mbox,
- void (*work) (struct work_struct *),
- void (*tasklet)(unsigned long))
+ void (*work)(struct work_struct *))
{
struct omap_mbox_queue *mq;
+ if (!work)
+ return NULL;
+
mq = kzalloc(sizeof(struct omap_mbox_queue), GFP_KERNEL);
if (!mq)
return NULL;
@@ -408,12 +392,9 @@ static struct omap_mbox_queue *mbox_queue_alloc(struct omap_mbox *mbox,
if (kfifo_alloc(&mq->fifo, mbox_kfifo_size, GFP_KERNEL))
goto error;
- if (work)
- INIT_WORK(&mq->work, work);
-
- if (tasklet)
- tasklet_init(&mq->tasklet, tasklet, (unsigned long)mbox);
+ INIT_WORK(&mq->work, work);
return mq;
+
error:
kfree(mq);
return NULL;
@@ -429,71 +410,35 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
{
int ret = 0;
struct omap_mbox_queue *mq;
- struct omap_mbox_device *mdev = mbox->parent;
- mutex_lock(&mdev->cfg_lock);
- ret = pm_runtime_get_sync(mdev->dev);
- if (unlikely(ret < 0))
- goto fail_startup;
-
- if (!mbox->use_count++) {
- mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
- if (!mq) {
- ret = -ENOMEM;
- goto fail_alloc_txq;
- }
- mbox->txq = mq;
+ mq = mbox_queue_alloc(mbox, mbox_rx_work);
+ if (!mq)
+ return -ENOMEM;
+ mbox->rxq = mq;
+ mq->mbox = mbox;
+
+ ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED,
+ mbox->name, mbox);
+ if (unlikely(ret)) {
+ pr_err("failed to register mailbox interrupt:%d\n", ret);
+ goto fail_request_irq;
+ }
- mq = mbox_queue_alloc(mbox, mbox_rx_work, NULL);
- if (!mq) {
- ret = -ENOMEM;
- goto fail_alloc_rxq;
- }
- mbox->rxq = mq;
- mq->mbox = mbox;
- ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED,
- mbox->name, mbox);
- if (unlikely(ret)) {
- pr_err("failed to register mailbox interrupt:%d\n",
- ret);
- goto fail_request_irq;
- }
+ _omap_mbox_enable_irq(mbox, IRQ_RX);
- omap_mbox_enable_irq(mbox, IRQ_RX);
- }
- mutex_unlock(&mdev->cfg_lock);
return 0;
fail_request_irq:
mbox_queue_free(mbox->rxq);
-fail_alloc_rxq:
- mbox_queue_free(mbox->txq);
-fail_alloc_txq:
- pm_runtime_put_sync(mdev->dev);
- mbox->use_count--;
-fail_startup:
- mutex_unlock(&mdev->cfg_lock);
return ret;
}
static void omap_mbox_fini(struct omap_mbox *mbox)
{
- struct omap_mbox_device *mdev = mbox->parent;
-
- mutex_lock(&mdev->cfg_lock);
-
- if (!--mbox->use_count) {
- omap_mbox_disable_irq(mbox, IRQ_RX);
- free_irq(mbox->irq, mbox);
- tasklet_kill(&mbox->txq->tasklet);
- flush_work(&mbox->rxq->work);
- mbox_queue_free(mbox->txq);
- mbox_queue_free(mbox->rxq);
- }
-
- pm_runtime_put_sync(mdev->dev);
-
- mutex_unlock(&mdev->cfg_lock);
+ _omap_mbox_disable_irq(mbox, IRQ_RX);
+ free_irq(mbox->irq, mbox);
+ flush_work(&mbox->rxq->work);
+ mbox_queue_free(mbox->rxq);
}
static struct omap_mbox *omap_mbox_device_find(struct omap_mbox_device *mdev,
@@ -515,42 +460,54 @@ static struct omap_mbox *omap_mbox_device_find(struct omap_mbox_device *mdev,
return mbox;
}
-struct omap_mbox *omap_mbox_get(const char *name, struct notifier_block *nb)
+struct mbox_chan *omap_mbox_request_channel(struct mbox_client *cl)
{
+ struct device *dev = cl->dev;
struct omap_mbox *mbox = NULL;
struct omap_mbox_device *mdev;
+ struct mbox_chan *chan;
+ unsigned long flags;
int ret;
+ if (!dev)
+ return ERR_PTR(-ENODEV);
+
+ if (dev->of_node) {
+ pr_err("%s: please use mbox_request_channel(), this API is supported only for OMAP non-DT usage\n",
+ __func__);
+ return ERR_PTR(-ENODEV);
+ }
+
mutex_lock(&omap_mbox_devices_lock);
list_for_each_entry(mdev, &omap_mbox_devices, elem) {
- mbox = omap_mbox_device_find(mdev, name);
+ mbox = omap_mbox_device_find(mdev, cl->chan_name);
if (mbox)
break;
}
mutex_unlock(&omap_mbox_devices_lock);
- if (!mbox)
+ if (!mbox || !mbox->chan)
return ERR_PTR(-ENOENT);
- if (nb)
- blocking_notifier_chain_register(&mbox->notifier, nb);
+ chan = mbox->chan;
+ spin_lock_irqsave(&chan->lock, flags);
+ chan->msg_free = 0;
+ chan->msg_count = 0;
+ chan->active_req = NULL;
+ chan->cl = cl;
+ init_completion(&chan->tx_complete);
+ spin_unlock_irqrestore(&chan->lock, flags);
- ret = omap_mbox_startup(mbox);
+ ret = chan->mbox->ops->startup(chan);
if (ret) {
- blocking_notifier_chain_unregister(&mbox->notifier, nb);
- return ERR_PTR(-ENODEV);
+ pr_err("Unable to startup the chan (%d)\n", ret);
+ mbox_free_channel(chan);
+ chan = ERR_PTR(ret);
}
- return mbox;
+ return chan;
}
-EXPORT_SYMBOL(omap_mbox_get);
-
-void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb)
-{
- blocking_notifier_chain_unregister(&mbox->notifier, nb);
- omap_mbox_fini(mbox);
-}
-EXPORT_SYMBOL(omap_mbox_put);
+EXPORT_SYMBOL(omap_mbox_request_channel);
static struct class omap_mbox_class = { .name = "mbox", };
@@ -566,25 +523,25 @@ static int omap_mbox_register(struct omap_mbox_device *mdev)
mboxes = mdev->mboxes;
for (i = 0; mboxes[i]; i++) {
struct omap_mbox *mbox = mboxes[i];
- mbox->dev = device_create(&omap_mbox_class,
- mdev->dev, 0, mbox, "%s", mbox->name);
+ mbox->dev = device_create(&omap_mbox_class, mdev->dev,
+ 0, mbox, "%s", mbox->name);
if (IS_ERR(mbox->dev)) {
ret = PTR_ERR(mbox->dev);
goto err_out;
}
-
- BLOCKING_INIT_NOTIFIER_HEAD(&mbox->notifier);
}
mutex_lock(&omap_mbox_devices_lock);
list_add(&mdev->elem, &omap_mbox_devices);
mutex_unlock(&omap_mbox_devices_lock);
- return 0;
+ ret = mbox_controller_register(&mdev->controller);
err_out:
- while (i--)
- device_unregister(mboxes[i]->dev);
+ if (ret) {
+ while (i--)
+ device_unregister(mboxes[i]->dev);
+ }
return ret;
}
@@ -600,12 +557,64 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
list_del(&mdev->elem);
mutex_unlock(&omap_mbox_devices_lock);
+ mbox_controller_unregister(&mdev->controller);
+
mboxes = mdev->mboxes;
for (i = 0; mboxes[i]; i++)
device_unregister(mboxes[i]->dev);
return 0;
}
+static int omap_mbox_chan_startup(struct mbox_chan *chan)
+{
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ struct omap_mbox_device *mdev = mbox->parent;
+ int ret = 0;
+
+ mutex_lock(&mdev->cfg_lock);
+ pm_runtime_get_sync(mdev->dev);
+ ret = omap_mbox_startup(mbox);
+ if (ret)
+ pm_runtime_put_sync(mdev->dev);
+ mutex_unlock(&mdev->cfg_lock);
+ return ret;
+}
+
+static void omap_mbox_chan_shutdown(struct mbox_chan *chan)
+{
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ struct omap_mbox_device *mdev = mbox->parent;
+
+ mutex_lock(&mdev->cfg_lock);
+ omap_mbox_fini(mbox);
+ pm_runtime_put_sync(mdev->dev);
+ mutex_unlock(&mdev->cfg_lock);
+}
+
+static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
+{
+ struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ int ret = -EBUSY;
+
+ if (!mbox)
+ return -EINVAL;
+
+ if (!mbox_fifo_full(mbox)) {
+ mbox_fifo_write(mbox, (mbox_msg_t)data);
+ ret = 0;
+ }
+
+ /* always enable the interrupt */
+ _omap_mbox_enable_irq(mbox, IRQ_TX);
+ return ret;
+}
+
+static struct mbox_chan_ops omap_mbox_chan_ops = {
+ .startup = omap_mbox_chan_startup,
+ .send_data = omap_mbox_chan_send_data,
+ .shutdown = omap_mbox_chan_shutdown,
+};
+
static const struct omap_mbox_device_data omap2_data = {
.num_users = 4,
.num_fifos = 6,
@@ -671,6 +680,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
int ret;
+ struct mbox_chan *chnls;
struct omap_mbox **list, *mbox, *mboxblk;
struct omap_mbox_pdata *pdata = pdev->dev.platform_data;
struct omap_mbox_dev_info *info = NULL;
@@ -772,6 +782,11 @@ static int omap_mbox_probe(struct platform_device *pdev)
if (!list)
return -ENOMEM;
+ chnls = devm_kzalloc(&pdev->dev, (info_count + 1) * sizeof(*chnls),
+ GFP_KERNEL);
+ if (!chnls)
+ return -ENOMEM;
+
mboxblk = devm_kzalloc(&pdev->dev, info_count * sizeof(*mbox),
GFP_KERNEL);
if (!mboxblk)
@@ -803,6 +818,8 @@ static int omap_mbox_probe(struct platform_device *pdev)
mbox->irq = platform_get_irq(pdev, finfo->tx_irq);
if (mbox->irq < 0)
return mbox->irq;
+ mbox->chan = &chnls[i];
+ chnls[i].con_priv = mbox;
list[i] = mbox++;
}
@@ -811,6 +828,13 @@ static int omap_mbox_probe(struct platform_device *pdev)
mdev->num_users = num_users;
mdev->num_fifos = num_fifos;
mdev->mboxes = list;
+
+ /* OMAP does not have a Tx-Done IRQ, but rather a Tx-Ready IRQ */
+ mdev->controller.txdone_irq = true;
+ mdev->controller.dev = mdev->dev;
+ mdev->controller.ops = &omap_mbox_chan_ops;
+ mdev->controller.chans = chnls;
+ mdev->controller.num_chans = info_count;
ret = omap_mbox_register(mdev);
if (ret)
return ret;
diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 5168972..0a87e57 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -27,6 +27,7 @@
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/remoteproc.h>
+#include <linux/mailbox_client.h>
#include <linux/omap-mailbox.h>
#include <linux/platform_data/remoteproc-omap.h>
@@ -36,20 +37,19 @@
/**
* struct omap_rproc - omap remote processor state
- * @mbox: omap mailbox handle
- * @nb: notifier block that will be invoked on inbound mailbox messages
+ * @mbox: mailbox channel handle
+ * @client: mailbox client to request the mailbox channel
* @rproc: rproc handle
*/
struct omap_rproc {
- struct omap_mbox *mbox;
- struct notifier_block nb;
+ struct mbox_chan *mbox;
+ struct mbox_client client;
struct rproc *rproc;
};
/**
* omap_rproc_mbox_callback() - inbound mailbox message handler
- * @this: notifier block
- * @index: unused
+ * @client: mailbox client pointer used for requesting the mailbox channel
* @data: mailbox payload
*
* This handler is invoked by omap's mailbox driver whenever a mailbox
@@ -61,13 +61,13 @@ struct omap_rproc {
* that indicates different events. Those values are deliberately very
* big so they don't coincide with virtqueue indices.
*/
-static int omap_rproc_mbox_callback(struct notifier_block *this,
- unsigned long index, void *data)
+static void omap_rproc_mbox_callback(struct mbox_client *client, void *data)
{
- mbox_msg_t msg = (mbox_msg_t) data;
- struct omap_rproc *oproc = container_of(this, struct omap_rproc, nb);
+ struct omap_rproc *oproc = container_of(client, struct omap_rproc,
+ client);
struct device *dev = oproc->rproc->dev.parent;
const char *name = oproc->rproc->name;
+ u32 msg = (u32)data;
dev_dbg(dev, "mbox msg: 0x%x\n", msg);
@@ -84,8 +84,6 @@ static int omap_rproc_mbox_callback(struct notifier_block *this,
if (rproc_vq_interrupt(oproc->rproc, msg) == IRQ_NONE)
dev_dbg(dev, "no message was found in vqid %d\n", msg);
}
-
- return NOTIFY_DONE;
}
/* kick a virtqueue */
@@ -96,8 +94,8 @@ static void omap_rproc_kick(struct rproc *rproc, int vqid)
int ret;
/* send the index of the triggered virtqueue in the mailbox payload */
- ret = omap_mbox_msg_send(oproc->mbox, vqid);
- if (ret)
+ ret = mbox_send_message(oproc->mbox, (void *)vqid);
+ if (ret < 0)
dev_err(dev, "omap_mbox_msg_send failed: %d\n", ret);
}
@@ -115,17 +113,25 @@ static int omap_rproc_start(struct rproc *rproc)
struct platform_device *pdev = to_platform_device(dev);
struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
int ret;
+ struct mbox_client *client = &oproc->client;
+ char client_name[32];
if (pdata->set_bootaddr)
pdata->set_bootaddr(rproc->bootaddr);
- oproc->nb.notifier_call = omap_rproc_mbox_callback;
+ client->dev = dev;
+ client->tx_done = NULL;
+ client->rx_callback = omap_rproc_mbox_callback;
+ client->tx_block = false;
+ client->knows_txdone = false;
+ sprintf(client_name, "%s", pdata->mbox_name);
+ client->chan_name = client_name;
- /* every omap rproc is assigned a mailbox instance for messaging */
- oproc->mbox = omap_mbox_get(pdata->mbox_name, &oproc->nb);
+ oproc->mbox = omap_mbox_request_channel(client);
if (IS_ERR(oproc->mbox)) {
- ret = PTR_ERR(oproc->mbox);
- dev_err(dev, "omap_mbox_get failed: %d\n", ret);
+ ret = -EBUSY;
+ dev_err(dev, "mbox_request_channel failed: %ld\n",
+ PTR_ERR(oproc->mbox));
return ret;
}
@@ -136,9 +142,9 @@ static int omap_rproc_start(struct rproc *rproc)
* Note that the reply will _not_ arrive immediately: this message
* will wait in the mailbox fifo until the remote processor is booted.
*/
- ret = omap_mbox_msg_send(oproc->mbox, RP_MBOX_ECHO_REQUEST);
- if (ret) {
- dev_err(dev, "omap_mbox_get failed: %d\n", ret);
+ ret = mbox_send_message(oproc->mbox, (void *)RP_MBOX_ECHO_REQUEST);
+ if (ret < 0) {
+ dev_err(dev, "mbox_send_message failed: %d\n", ret);
goto put_mbox;
}
@@ -151,7 +157,7 @@ static int omap_rproc_start(struct rproc *rproc)
return 0;
put_mbox:
- omap_mbox_put(oproc->mbox, &oproc->nb);
+ mbox_free_channel(oproc->mbox);
return ret;
}
@@ -168,7 +174,7 @@ static int omap_rproc_stop(struct rproc *rproc)
if (ret)
return ret;
- omap_mbox_put(oproc->mbox, &oproc->nb);
+ mbox_free_channel(oproc->mbox);
return 0;
}
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h b/drivers/staging/tidspbridge/core/_tiomap.h
index 65971b7..2b8390f 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -338,7 +338,8 @@ struct bridge_dev_context {
u32 dsp_start_add; /* API Boot vector */
u32 internal_size; /* Internal memory size */
- struct omap_mbox *mbox; /* Mail box handle */
+ struct mbox_client client; /* Mailbox Client */
+ struct mbox_chan *mbox; /* Mailbox handle */
struct cfg_hostres *resources; /* Host Resources */
diff --git a/drivers/staging/tidspbridge/core/io_sm.c b/drivers/staging/tidspbridge/core/io_sm.c
index c2829aa..4b6673a 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -908,7 +908,7 @@ func_end:
* Calls the Bridge's CHNL_ISR to determine if this interrupt is ours, then
* schedules a DPC to dispatch I/O.
*/
-int io_mbox_msg(struct notifier_block *self, unsigned long len, void *msg)
+void io_mbox_msg(struct mbox_client *client, void *msg)
{
struct io_mgr *pio_mgr;
struct dev_object *dev_obj;
@@ -917,8 +917,8 @@ int io_mbox_msg(struct notifier_block *self, unsigned long len, void *msg)
dev_obj = dev_get_first();
dev_get_io_mgr(dev_obj, &pio_mgr);
- if (!pio_mgr)
- return NOTIFY_BAD;
+ if (WARN_ON(!pio_mgr))
+ return;
pio_mgr->intr_val = (u16)((u32)msg);
if (pio_mgr->intr_val & MBX_PM_CLASS)
@@ -932,7 +932,6 @@ int io_mbox_msg(struct notifier_block *self, unsigned long len, void *msg)
spin_unlock_irqrestore(&pio_mgr->dpc_lock, flags);
tasklet_schedule(&pio_mgr->dpc_tasklet);
}
- return NOTIFY_OK;
}
/*
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c b/drivers/staging/tidspbridge/core/tiomap3430.c
index 8945b4e..5f6287c 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -212,10 +212,6 @@ static struct bridge_drv_interface drv_interface_fxns = {
bridge_msg_set_queue_id,
};
-static struct notifier_block dsp_mbox_notifier = {
- .notifier_call = io_mbox_msg,
-};
-
static inline void flush_all(struct bridge_dev_context *dev_context)
{
if (dev_context->brd_state == BRD_DSP_HIBERNATION ||
@@ -378,6 +374,8 @@ static int bridge_brd_start(struct bridge_dev_context *dev_ctxt,
u32 wdt_en = 0;
struct omap_dsp_platform_data *pdata =
omap_dspbridge_dev->dev.platform_data;
+ struct mbox_client *client = &dev_context->client;
+ char mbox_user_name[32];
/* The device context contains all the mmu setup info from when the
* last dsp base image was loaded. The first entry is always
@@ -544,11 +542,17 @@ static int bridge_brd_start(struct bridge_dev_context *dev_ctxt,
* Enable Mailbox events and also drain any pending
* stale messages.
*/
- dev_context->mbox = omap_mbox_get("dsp", &dsp_mbox_notifier);
+ client->dev = &omap_dspbridge_dev->dev;
+ client->tx_done = NULL;
+ client->rx_callback = io_mbox_msg;
+ client->tx_block = false;
+ client->knows_txdone = false;
+ sprintf(mbox_user_name, "dsp");
+ client->chan_name = mbox_user_name;
+ dev_context->mbox = omap_mbox_request_channel(client);
if (IS_ERR(dev_context->mbox)) {
- dev_context->mbox = NULL;
- pr_err("%s: Failed to get dsp mailbox handle\n",
- __func__);
+ pr_err("%s: Failed to get dsp mailbox handle, ret = %ld\n",
+ __func__, PTR_ERR(dev_context->mbox));
status = -EPERM;
}
@@ -680,7 +684,7 @@ static int bridge_brd_stop(struct bridge_dev_context *dev_ctxt)
/* Disable the mailbox interrupts */
if (dev_context->mbox) {
omap_mbox_disable_irq(dev_context->mbox, IRQ_RX);
- omap_mbox_put(dev_context->mbox, &dsp_mbox_notifier);
+ mbox_free_channel(dev_context->mbox);
dev_context->mbox = NULL;
}
/* Reset IVA2 clocks*/
diff --git a/drivers/staging/tidspbridge/core/tiomap_io.c b/drivers/staging/tidspbridge/core/tiomap_io.c
index f53ed98..fe86035 100644
--- a/drivers/staging/tidspbridge/core/tiomap_io.c
+++ b/drivers/staging/tidspbridge/core/tiomap_io.c
@@ -427,10 +427,9 @@ int sm_interrupt_dsp(struct bridge_dev_context *dev_context, u16 mb_val)
dsp_clock_enable_all(dev_context->dsp_per_clks);
}
- status = omap_mbox_msg_send(dev_context->mbox, mb_val);
-
- if (status) {
- pr_err("omap_mbox_msg_send Fail and status = %d\n", status);
+ status = mbox_send_message(dev_context->mbox, (void *)((u32)mb_val));
+ if (status < 0) {
+ pr_err("mbox_send_message failed, status = %d\n", status);
status = -EPERM;
}
diff --git a/drivers/staging/tidspbridge/include/dspbridge/host_os.h b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
index d1441db..8ddef2b 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/host_os.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
@@ -42,6 +42,7 @@
#include <linux/platform_device.h>
#include <linux/clk.h>
#include <linux/omap-mailbox.h>
+#include <linux/mailbox_client.h>
#include <linux/pagemap.h>
#include <asm/cacheflush.h>
#include <linux/dma-mapping.h>
diff --git a/drivers/staging/tidspbridge/include/dspbridge/io_sm.h b/drivers/staging/tidspbridge/include/dspbridge/io_sm.h
index 903ff12..b185d6e 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/io_sm.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/io_sm.h
@@ -80,13 +80,11 @@ extern void io_dpc(unsigned long ref_data);
* Determine if this message is ours, then schedules a DPC to
* dispatch I/O.
* Parameters:
- * self: Pointer to its own notifier_block struct.
- * len: Length of message.
- * msg: Message code received.
+ * client: Mailbox Client handle registered with the mailbox core.
+ * msg: Message code received.
* Returns:
- * NOTIFY_OK if handled; NOTIFY_BAD otherwise.
*/
-int io_mbox_msg(struct notifier_block *self, unsigned long len, void *msg);
+void io_mbox_msg(struct mbox_client *client, void *msg);
/*
* ======== io_request_chnl ========
diff --git a/include/linux/omap-mailbox.h b/include/linux/omap-mailbox.h
index f8322d9..fee452c 100644
--- a/include/linux/omap-mailbox.h
+++ b/include/linux/omap-mailbox.h
@@ -10,20 +10,19 @@
#define OMAP_MAILBOX_H
typedef u32 mbox_msg_t;
-struct omap_mbox;
typedef int __bitwise omap_mbox_irq_t;
#define IRQ_TX ((__force omap_mbox_irq_t) 1)
#define IRQ_RX ((__force omap_mbox_irq_t) 2)
-int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
+struct mbox_chan;
+struct mbox_client;
-struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
-void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
+struct mbox_chan *omap_mbox_request_channel(struct mbox_client *cl);
-void omap_mbox_save_ctx(struct omap_mbox *mbox);
-void omap_mbox_restore_ctx(struct omap_mbox *mbox);
-void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
-void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
+void omap_mbox_save_ctx(struct mbox_chan *chan);
+void omap_mbox_restore_ctx(struct mbox_chan *chan);
+void omap_mbox_enable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq);
+void omap_mbox_disable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq);
#endif /* OMAP_MAILBOX_H */
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 5/6] ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes
2014-06-25 1:47 ` Suman Anna
@ 2014-06-25 1:47 ` Suman Anna
-1 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jassi Brar, Dave Gerlach, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Suman Anna, Benoît Cousson, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
The '#mbox-cells' property is added to all the OMAP mailbox
nodes. This property is mandatory with the new mailbox framework.
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/am33xx.dtsi | 1 +
arch/arm/boot/dts/am4372.dtsi | 1 +
arch/arm/boot/dts/dra7.dtsi | 13 +++++++++++++
arch/arm/boot/dts/omap2420.dtsi | 1 +
arch/arm/boot/dts/omap2430.dtsi | 1 +
arch/arm/boot/dts/omap3.dtsi | 1 +
arch/arm/boot/dts/omap4.dtsi | 1 +
arch/arm/boot/dts/omap5.dtsi | 1 +
8 files changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 8c5abc7..6f8f7cf 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -352,6 +352,7 @@
reg = <0x480C8000 0x200>;
interrupts = <77>;
ti,hwmods = "mailbox";
+ #mbox-cells = <1>;
mbox_wkupm3: wkup_m3 {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <0 0 3>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 668b404..7c9ee39 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -166,6 +166,7 @@
reg = <0x480C8000 0x200>;
interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mailbox";
+ #mbox-cells = <1>;
mbox_wkupm3: wkup_m3 {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <0 0 3>;
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8d7626f..ec7a0f2 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -342,6 +342,7 @@
compatible = "ti,omap4-mailbox";
reg = <0x4a0f4000 0x200>;
ti,hwmods = "mailbox1";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -349,6 +350,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x4883a000 0x200>;
ti,hwmods = "mailbox2";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -356,6 +358,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x4883c000 0x200>;
ti,hwmods = "mailbox3";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -363,6 +366,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x4883e000 0x200>;
ti,hwmods = "mailbox4";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -370,6 +374,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48840000 0x200>;
ti,hwmods = "mailbox5";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -377,6 +382,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48842000 0x200>;
ti,hwmods = "mailbox6";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -384,6 +390,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48844000 0x200>;
ti,hwmods = "mailbox7";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -391,6 +398,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48846000 0x200>;
ti,hwmods = "mailbox8";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -398,6 +406,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x4885e000 0x200>;
ti,hwmods = "mailbox9";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -405,6 +414,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48860000 0x200>;
ti,hwmods = "mailbox10";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -412,6 +422,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48862000 0x200>;
ti,hwmods = "mailbox11";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -419,6 +430,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48864000 0x200>;
ti,hwmods = "mailbox12";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -426,6 +438,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48802000 0x200>;
ti,hwmods = "mailbox13";
+ #mbox-cells = <1>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index f3e6d0f..85c792c 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -157,6 +157,7 @@
interrupts = <26>, <34>;
interrupt-names = "dsp", "iva";
ti,hwmods = "mailbox";
+ #mbox-cells = <1>;
mbox_dsp: dsp {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <1 0 0>;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 13deb71..fa966c3 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -247,6 +247,7 @@
reg = <0x48094000 0x200>;
interrupts = <26>;
ti,hwmods = "mailbox";
+ #mbox-cells = <1>;
mbox_dsp: dsp {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <1 0 0>;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 3524adf..9ba3eb8 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -332,6 +332,7 @@
ti,hwmods = "mailbox";
reg = <0x48094000 0x200>;
interrupts = <26>;
+ #mbox-cells = <1>;
mbox_dsp: dsp {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <1 0 0>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 19dc11d..f0f3d14 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -654,6 +654,7 @@
reg = <0x4a0f4000 0x200>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mailbox";
+ #mbox-cells = <1>;
mbox_ipu: mbox_ipu {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <1 0 0>;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index ce54c13..3ecc150 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -641,6 +641,7 @@
reg = <0x4a0f4000 0x200>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mailbox";
+ #mbox-cells = <1>;
mbox_ipu: mbox_ipu {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <1 0 0>;
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 5/6] ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes
@ 2014-06-25 1:47 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: linux-arm-kernel
The '#mbox-cells' property is added to all the OMAP mailbox
nodes. This property is mandatory with the new mailbox framework.
Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/am33xx.dtsi | 1 +
arch/arm/boot/dts/am4372.dtsi | 1 +
arch/arm/boot/dts/dra7.dtsi | 13 +++++++++++++
arch/arm/boot/dts/omap2420.dtsi | 1 +
arch/arm/boot/dts/omap2430.dtsi | 1 +
arch/arm/boot/dts/omap3.dtsi | 1 +
arch/arm/boot/dts/omap4.dtsi | 1 +
arch/arm/boot/dts/omap5.dtsi | 1 +
8 files changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 8c5abc7..6f8f7cf 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -352,6 +352,7 @@
reg = <0x480C8000 0x200>;
interrupts = <77>;
ti,hwmods = "mailbox";
+ #mbox-cells = <1>;
mbox_wkupm3: wkup_m3 {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <0 0 3>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 668b404..7c9ee39 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -166,6 +166,7 @@
reg = <0x480C8000 0x200>;
interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mailbox";
+ #mbox-cells = <1>;
mbox_wkupm3: wkup_m3 {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <0 0 3>;
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8d7626f..ec7a0f2 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -342,6 +342,7 @@
compatible = "ti,omap4-mailbox";
reg = <0x4a0f4000 0x200>;
ti,hwmods = "mailbox1";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -349,6 +350,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x4883a000 0x200>;
ti,hwmods = "mailbox2";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -356,6 +358,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x4883c000 0x200>;
ti,hwmods = "mailbox3";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -363,6 +366,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x4883e000 0x200>;
ti,hwmods = "mailbox4";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -370,6 +374,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48840000 0x200>;
ti,hwmods = "mailbox5";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -377,6 +382,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48842000 0x200>;
ti,hwmods = "mailbox6";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -384,6 +390,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48844000 0x200>;
ti,hwmods = "mailbox7";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -391,6 +398,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48846000 0x200>;
ti,hwmods = "mailbox8";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -398,6 +406,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x4885e000 0x200>;
ti,hwmods = "mailbox9";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -405,6 +414,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48860000 0x200>;
ti,hwmods = "mailbox10";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -412,6 +422,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48862000 0x200>;
ti,hwmods = "mailbox11";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -419,6 +430,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48864000 0x200>;
ti,hwmods = "mailbox12";
+ #mbox-cells = <1>;
status = "disabled";
};
@@ -426,6 +438,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48802000 0x200>;
ti,hwmods = "mailbox13";
+ #mbox-cells = <1>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index f3e6d0f..85c792c 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -157,6 +157,7 @@
interrupts = <26>, <34>;
interrupt-names = "dsp", "iva";
ti,hwmods = "mailbox";
+ #mbox-cells = <1>;
mbox_dsp: dsp {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <1 0 0>;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 13deb71..fa966c3 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -247,6 +247,7 @@
reg = <0x48094000 0x200>;
interrupts = <26>;
ti,hwmods = "mailbox";
+ #mbox-cells = <1>;
mbox_dsp: dsp {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <1 0 0>;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 3524adf..9ba3eb8 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -332,6 +332,7 @@
ti,hwmods = "mailbox";
reg = <0x48094000 0x200>;
interrupts = <26>;
+ #mbox-cells = <1>;
mbox_dsp: dsp {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <1 0 0>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 19dc11d..f0f3d14 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -654,6 +654,7 @@
reg = <0x4a0f4000 0x200>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mailbox";
+ #mbox-cells = <1>;
mbox_ipu: mbox_ipu {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <1 0 0>;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index ce54c13..3ecc150 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -641,6 +641,7 @@
reg = <0x4a0f4000 0x200>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mailbox";
+ #mbox-cells = <1>;
mbox_ipu: mbox_ipu {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <1 0 0>;
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 6/6] mailbox/omap: add a custom of_xlate function
2014-06-25 1:47 ` Suman Anna
(?)
@ 2014-06-25 1:47 ` Suman Anna
-1 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jassi Brar, Dave Gerlach, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Suman Anna, Jassi Brar
The mailbox framework currently does not support using the
channel phandles directly in the mbox property of client nodes,
and also expects a minimum value of 1 for the #mbox-cells in the
mailbox controller device node. Implement a custom of_xlate function
for the OMAP mailbox driver that allows phandles for the pargs
specifier instead of indexing to avoid any channel registration
order dependencies.
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/mailbox/omap-mailbox.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index d71e84f..4847466 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -676,6 +676,28 @@ static const struct of_device_id omap_mailbox_of_match[] = {
};
MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
+static struct mbox_chan *omap_mbox_of_xlate(struct mbox_controller *controller,
+ const struct of_phandle_args *sp)
+{
+ phandle phandle = sp->args[0];
+ struct device_node *node;
+ struct omap_mbox_device *mdev;
+ struct omap_mbox *mbox;
+
+ node = of_find_node_by_phandle(phandle);
+ if (!node) {
+ pr_err("could not find node phandle 0x%x\n", phandle);
+ return NULL;
+ }
+
+ mdev = container_of(controller, struct omap_mbox_device, controller);
+ if (WARN_ON(!mdev))
+ return NULL;
+
+ mbox = omap_mbox_device_find(mdev, node->name);
+ return mbox ? mbox->chan : NULL;
+}
+
static int omap_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
@@ -835,6 +857,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
mdev->controller.ops = &omap_mbox_chan_ops;
mdev->controller.chans = chnls;
mdev->controller.num_chans = info_count;
+ mdev->controller.of_xlate = omap_mbox_of_xlate;
ret = omap_mbox_register(mdev);
if (ret)
return ret;
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 6/6] mailbox/omap: add a custom of_xlate function
@ 2014-06-25 1:47 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jassi Brar, Dave Gerlach, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Suman Anna, Jassi Brar
The mailbox framework currently does not support using the
channel phandles directly in the mbox property of client nodes,
and also expects a minimum value of 1 for the #mbox-cells in the
mailbox controller device node. Implement a custom of_xlate function
for the OMAP mailbox driver that allows phandles for the pargs
specifier instead of indexing to avoid any channel registration
order dependencies.
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/mailbox/omap-mailbox.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index d71e84f..4847466 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -676,6 +676,28 @@ static const struct of_device_id omap_mailbox_of_match[] = {
};
MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
+static struct mbox_chan *omap_mbox_of_xlate(struct mbox_controller *controller,
+ const struct of_phandle_args *sp)
+{
+ phandle phandle = sp->args[0];
+ struct device_node *node;
+ struct omap_mbox_device *mdev;
+ struct omap_mbox *mbox;
+
+ node = of_find_node_by_phandle(phandle);
+ if (!node) {
+ pr_err("could not find node phandle 0x%x\n", phandle);
+ return NULL;
+ }
+
+ mdev = container_of(controller, struct omap_mbox_device, controller);
+ if (WARN_ON(!mdev))
+ return NULL;
+
+ mbox = omap_mbox_device_find(mdev, node->name);
+ return mbox ? mbox->chan : NULL;
+}
+
static int omap_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
@@ -835,6 +857,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
mdev->controller.ops = &omap_mbox_chan_ops;
mdev->controller.chans = chnls;
mdev->controller.num_chans = info_count;
+ mdev->controller.of_xlate = omap_mbox_of_xlate;
ret = omap_mbox_register(mdev);
if (ret)
return ret;
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 6/6] mailbox/omap: add a custom of_xlate function
@ 2014-06-25 1:47 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 1:47 UTC (permalink / raw)
To: linux-arm-kernel
The mailbox framework currently does not support using the
channel phandles directly in the mbox property of client nodes,
and also expects a minimum value of 1 for the #mbox-cells in the
mailbox controller device node. Implement a custom of_xlate function
for the OMAP mailbox driver that allows phandles for the pargs
specifier instead of indexing to avoid any channel registration
order dependencies.
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/mailbox/omap-mailbox.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index d71e84f..4847466 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -676,6 +676,28 @@ static const struct of_device_id omap_mailbox_of_match[] = {
};
MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
+static struct mbox_chan *omap_mbox_of_xlate(struct mbox_controller *controller,
+ const struct of_phandle_args *sp)
+{
+ phandle phandle = sp->args[0];
+ struct device_node *node;
+ struct omap_mbox_device *mdev;
+ struct omap_mbox *mbox;
+
+ node = of_find_node_by_phandle(phandle);
+ if (!node) {
+ pr_err("could not find node phandle 0x%x\n", phandle);
+ return NULL;
+ }
+
+ mdev = container_of(controller, struct omap_mbox_device, controller);
+ if (WARN_ON(!mdev))
+ return NULL;
+
+ mbox = omap_mbox_device_find(mdev, node->name);
+ return mbox ? mbox->chan : NULL;
+}
+
static int omap_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
@@ -835,6 +857,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
mdev->controller.ops = &omap_mbox_chan_ops;
mdev->controller.chans = chnls;
mdev->controller.num_chans = info_count;
+ mdev->controller.of_xlate = omap_mbox_of_xlate;
ret = omap_mbox_register(mdev);
if (ret)
return ret;
--
2.0.0
^ permalink raw reply related [flat|nested] 53+ messages in thread
* Re: [PATCH 6/6] mailbox/omap: add a custom of_xlate function
2014-06-25 1:47 ` Suman Anna
@ 2014-06-25 8:39 ` Arnd Bergmann
-1 siblings, 0 replies; 53+ messages in thread
From: Arnd Bergmann @ 2014-06-25 8:39 UTC (permalink / raw)
To: Suman Anna
Cc: Tony Lindgren, Jassi Brar, Dave Gerlach, linux-kernel,
linux-omap, devicetree, linux-arm-kernel, Jassi Brar
On Tuesday 24 June 2014 20:47:58 Suman Anna wrote:
> +static struct mbox_chan *omap_mbox_of_xlate(struct mbox_controller *controller,
> + const struct of_phandle_args *sp)
> +{
> + phandle phandle = sp->args[0];
> + struct device_node *node;
> + struct omap_mbox_device *mdev;
> + struct omap_mbox *mbox;
> +
> + node = of_find_node_by_phandle(phandle);
> + if (!node) {
> + pr_err("could not find node phandle 0x%x\n", phandle);
> + return NULL;
> + }
> +
> + mdev = container_of(controller, struct omap_mbox_device, controller);
> + if (WARN_ON(!mdev))
> + return NULL;
> +
> + mbox = omap_mbox_device_find(mdev, node->name);
> + return mbox ? mbox->chan : NULL;
>
Wouldn't it be easier to change the omap_mbox_device_find() function to
take a phandle argument directly? You shouldn't have to walk all
nodes in the system, or match it by name if you already have the
device node.
Also, the xlate function is normally the place where you read out
the other arguments and set them as members in your omap_mbox
structure.
Arnd
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 6/6] mailbox/omap: add a custom of_xlate function
@ 2014-06-25 8:39 ` Arnd Bergmann
0 siblings, 0 replies; 53+ messages in thread
From: Arnd Bergmann @ 2014-06-25 8:39 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 24 June 2014 20:47:58 Suman Anna wrote:
> +static struct mbox_chan *omap_mbox_of_xlate(struct mbox_controller *controller,
> + const struct of_phandle_args *sp)
> +{
> + phandle phandle = sp->args[0];
> + struct device_node *node;
> + struct omap_mbox_device *mdev;
> + struct omap_mbox *mbox;
> +
> + node = of_find_node_by_phandle(phandle);
> + if (!node) {
> + pr_err("could not find node phandle 0x%x\n", phandle);
> + return NULL;
> + }
> +
> + mdev = container_of(controller, struct omap_mbox_device, controller);
> + if (WARN_ON(!mdev))
> + return NULL;
> +
> + mbox = omap_mbox_device_find(mdev, node->name);
> + return mbox ? mbox->chan : NULL;
>
Wouldn't it be easier to change the omap_mbox_device_find() function to
take a phandle argument directly? You shouldn't have to walk all
nodes in the system, or match it by name if you already have the
device node.
Also, the xlate function is normally the place where you read out
the other arguments and set them as members in your omap_mbox
structure.
Arnd
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 6/6] mailbox/omap: add a custom of_xlate function
2014-06-25 8:39 ` Arnd Bergmann
(?)
@ 2014-06-25 16:32 ` Suman Anna
-1 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 16:32 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Tony Lindgren, Jassi Brar, Dave Gerlach, linux-kernel,
linux-omap, devicetree, linux-arm-kernel, Jassi Brar
Hi Arnd,
On 06/25/2014 03:39 AM, Arnd Bergmann wrote:
> On Tuesday 24 June 2014 20:47:58 Suman Anna wrote:
>> +static struct mbox_chan *omap_mbox_of_xlate(struct mbox_controller *controller,
>> + const struct of_phandle_args *sp)
>> +{
>> + phandle phandle = sp->args[0];
>> + struct device_node *node;
>> + struct omap_mbox_device *mdev;
>> + struct omap_mbox *mbox;
>> +
>> + node = of_find_node_by_phandle(phandle);
>> + if (!node) {
>> + pr_err("could not find node phandle 0x%x\n", phandle);
>> + return NULL;
>> + }
>> +
>> + mdev = container_of(controller, struct omap_mbox_device, controller);
>> + if (WARN_ON(!mdev))
>> + return NULL;
>> +
>> + mbox = omap_mbox_device_find(mdev, node->name);
>> + return mbox ? mbox->chan : NULL;
>>
>
> Wouldn't it be easier to change the omap_mbox_device_find() function to
> take a phandle argument directly? You shouldn't have to walk all
> nodes in the system, or match it by name if you already have the
> device node.
The omap_mbox_device_find() function is also used on the non-DT mailbox
client path (for OMAP3) at the moment where we don't have the device
node pointers. I am merely reusing the function for the DT lookup path,
and once I remove the non-DT support, I can surely do the matching logic
just based on the device node pointer. I just chose to minimize the
changes to the omap_mbox_device_find() to do both variants now when I
know that I am gonna remove the non-DT part (name lookup) later on.
The current expected DT usage model for the OMAP mailbox client is (with
the v7 mailbox framework)
mbox = <&controller_phandle &channel_phandle>
So, this is not walking through all the nodes in the system, only the
channel/sub-mailbox nodes present on the particular controller node.
Surely, it can done as mbox = <&channel_phandle> as the parent
controller node relationship is inherent, but this requires changes to
the mailbox framework, and I am not sure if every platform
implementation would implement the child channels as their own nodes.
>
> Also, the xlate function is normally the place where you read out
> the other arguments and set them as members in your omap_mbox
> structure.
The current flow for the xlate function is during the
mailbox_request_channel. The channels themselves would have been
registered during the controller node probe, so this is merely a lookup
for the correct channel. Should we be renaming the xlate function, if
the behavior is not what one expects out of a standard xlate?
regards
Suman
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 6/6] mailbox/omap: add a custom of_xlate function
@ 2014-06-25 16:32 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 16:32 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Tony Lindgren, Jassi Brar, Dave Gerlach, linux-kernel,
linux-omap, devicetree, linux-arm-kernel, Jassi Brar
Hi Arnd,
On 06/25/2014 03:39 AM, Arnd Bergmann wrote:
> On Tuesday 24 June 2014 20:47:58 Suman Anna wrote:
>> +static struct mbox_chan *omap_mbox_of_xlate(struct mbox_controller *controller,
>> + const struct of_phandle_args *sp)
>> +{
>> + phandle phandle = sp->args[0];
>> + struct device_node *node;
>> + struct omap_mbox_device *mdev;
>> + struct omap_mbox *mbox;
>> +
>> + node = of_find_node_by_phandle(phandle);
>> + if (!node) {
>> + pr_err("could not find node phandle 0x%x\n", phandle);
>> + return NULL;
>> + }
>> +
>> + mdev = container_of(controller, struct omap_mbox_device, controller);
>> + if (WARN_ON(!mdev))
>> + return NULL;
>> +
>> + mbox = omap_mbox_device_find(mdev, node->name);
>> + return mbox ? mbox->chan : NULL;
>>
>
> Wouldn't it be easier to change the omap_mbox_device_find() function to
> take a phandle argument directly? You shouldn't have to walk all
> nodes in the system, or match it by name if you already have the
> device node.
The omap_mbox_device_find() function is also used on the non-DT mailbox
client path (for OMAP3) at the moment where we don't have the device
node pointers. I am merely reusing the function for the DT lookup path,
and once I remove the non-DT support, I can surely do the matching logic
just based on the device node pointer. I just chose to minimize the
changes to the omap_mbox_device_find() to do both variants now when I
know that I am gonna remove the non-DT part (name lookup) later on.
The current expected DT usage model for the OMAP mailbox client is (with
the v7 mailbox framework)
mbox = <&controller_phandle &channel_phandle>
So, this is not walking through all the nodes in the system, only the
channel/sub-mailbox nodes present on the particular controller node.
Surely, it can done as mbox = <&channel_phandle> as the parent
controller node relationship is inherent, but this requires changes to
the mailbox framework, and I am not sure if every platform
implementation would implement the child channels as their own nodes.
>
> Also, the xlate function is normally the place where you read out
> the other arguments and set them as members in your omap_mbox
> structure.
The current flow for the xlate function is during the
mailbox_request_channel. The channels themselves would have been
registered during the controller node probe, so this is merely a lookup
for the correct channel. Should we be renaming the xlate function, if
the behavior is not what one expects out of a standard xlate?
regards
Suman
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 6/6] mailbox/omap: add a custom of_xlate function
@ 2014-06-25 16:32 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-25 16:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
On 06/25/2014 03:39 AM, Arnd Bergmann wrote:
> On Tuesday 24 June 2014 20:47:58 Suman Anna wrote:
>> +static struct mbox_chan *omap_mbox_of_xlate(struct mbox_controller *controller,
>> + const struct of_phandle_args *sp)
>> +{
>> + phandle phandle = sp->args[0];
>> + struct device_node *node;
>> + struct omap_mbox_device *mdev;
>> + struct omap_mbox *mbox;
>> +
>> + node = of_find_node_by_phandle(phandle);
>> + if (!node) {
>> + pr_err("could not find node phandle 0x%x\n", phandle);
>> + return NULL;
>> + }
>> +
>> + mdev = container_of(controller, struct omap_mbox_device, controller);
>> + if (WARN_ON(!mdev))
>> + return NULL;
>> +
>> + mbox = omap_mbox_device_find(mdev, node->name);
>> + return mbox ? mbox->chan : NULL;
>>
>
> Wouldn't it be easier to change the omap_mbox_device_find() function to
> take a phandle argument directly? You shouldn't have to walk all
> nodes in the system, or match it by name if you already have the
> device node.
The omap_mbox_device_find() function is also used on the non-DT mailbox
client path (for OMAP3) at the moment where we don't have the device
node pointers. I am merely reusing the function for the DT lookup path,
and once I remove the non-DT support, I can surely do the matching logic
just based on the device node pointer. I just chose to minimize the
changes to the omap_mbox_device_find() to do both variants now when I
know that I am gonna remove the non-DT part (name lookup) later on.
The current expected DT usage model for the OMAP mailbox client is (with
the v7 mailbox framework)
mbox = <&controller_phandle &channel_phandle>
So, this is not walking through all the nodes in the system, only the
channel/sub-mailbox nodes present on the particular controller node.
Surely, it can done as mbox = <&channel_phandle> as the parent
controller node relationship is inherent, but this requires changes to
the mailbox framework, and I am not sure if every platform
implementation would implement the child channels as their own nodes.
>
> Also, the xlate function is normally the place where you read out
> the other arguments and set them as members in your omap_mbox
> structure.
The current flow for the xlate function is during the
mailbox_request_channel. The channels themselves would have been
registered during the controller node probe, so this is merely a lookup
for the correct channel. Should we be renaming the xlate function, if
the behavior is not what one expects out of a standard xlate?
regards
Suman
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
2014-06-25 1:47 ` Suman Anna
@ 2014-06-28 17:07 ` Pavel Machek
-1 siblings, 0 replies; 53+ messages in thread
From: Pavel Machek @ 2014-06-28 17:07 UTC (permalink / raw)
To: Suman Anna
Cc: Tony Lindgren, Jassi Brar, Dave Gerlach, linux-kernel,
linux-omap, devicetree, linux-arm-kernel, Jassi Brar,
Rob Herring
Hi!
> The non-DT support has to be maintained for now to not break
> OMAP3 legacy boot, and the legacy-style code will be cleaned
> up once OMAP3 is also converted to DT-boot only.
> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> return 0;
> }
>
> +static const struct omap_mbox_device_data omap2_data = {
> + .num_users = 4,
> + .num_fifos = 6,
> + .intr_type = MBOX_INTR_CFG_TYPE1,
> +};
> +
> +static const struct omap_mbox_device_data omap3_data = {
> + .num_users = 2,
> + .num_fifos = 2,
> + .intr_type = MBOX_INTR_CFG_TYPE1,
> +};
> +
> +static const struct omap_mbox_device_data am335x_data = {
> + .num_users = 4,
> + .num_fifos = 8,
> + .intr_type = MBOX_INTR_CFG_TYPE2,
> +};
So you use compatible strings to look up 3 integers. Would it be better to have
num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
and more flexible...
If you do that, would it be possible to have share compatible string?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-06-28 17:07 ` Pavel Machek
0 siblings, 0 replies; 53+ messages in thread
From: Pavel Machek @ 2014-06-28 17:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
> The non-DT support has to be maintained for now to not break
> OMAP3 legacy boot, and the legacy-style code will be cleaned
> up once OMAP3 is also converted to DT-boot only.
> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> return 0;
> }
>
> +static const struct omap_mbox_device_data omap2_data = {
> + .num_users = 4,
> + .num_fifos = 6,
> + .intr_type = MBOX_INTR_CFG_TYPE1,
> +};
> +
> +static const struct omap_mbox_device_data omap3_data = {
> + .num_users = 2,
> + .num_fifos = 2,
> + .intr_type = MBOX_INTR_CFG_TYPE1,
> +};
> +
> +static const struct omap_mbox_device_data am335x_data = {
> + .num_users = 4,
> + .num_fifos = 8,
> + .intr_type = MBOX_INTR_CFG_TYPE2,
> +};
So you use compatible strings to look up 3 integers. Would it be better to have
num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
and more flexible...
If you do that, would it be possible to have share compatible string?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
2014-06-28 17:07 ` Pavel Machek
(?)
@ 2014-06-30 16:00 ` Suman Anna
-1 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-30 16:00 UTC (permalink / raw)
To: Pavel Machek
Cc: Tony Lindgren, Jassi Brar, Dave Gerlach, linux-kernel,
linux-omap, devicetree, linux-arm-kernel, Jassi Brar,
Rob Herring
Hi Pavel,
On 06/28/2014 12:07 PM, Pavel Machek wrote:
> Hi!
>
>> The non-DT support has to be maintained for now to not break
>> OMAP3 legacy boot, and the legacy-style code will be cleaned
>> up once OMAP3 is also converted to DT-boot only.
>
>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
>> return 0;
>> }
>>
>> +static const struct omap_mbox_device_data omap2_data = {
>> + .num_users = 4,
>> + .num_fifos = 6,
>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>> +};
>> +
>> +static const struct omap_mbox_device_data omap3_data = {
>> + .num_users = 2,
>> + .num_fifos = 2,
>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>> +};
>> +
>> +static const struct omap_mbox_device_data am335x_data = {
>> + .num_users = 4,
>> + .num_fifos = 8,
>> + .intr_type = MBOX_INTR_CFG_TYPE2,
>> +};
>
> So you use compatible strings to look up 3 integers. Would it be better to have
> num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
> and more flexible...
>
> If you do that, would it be possible to have share compatible string?
Yeah, I have actually encoded the .num_users and .num_fifos in DT in the
previous version [1] with shared compatible strings, but dropped those
properties in favour of adding minimal custom properties to DT based on
some offline IRC comments. I have no objections either way, but there is
really nothing to be gained from minimizing compatible strings.
Tony,
Any comments on this?
regards
Suman
[1] https://patchwork.kernel.org/patch/2839662/
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-06-30 16:00 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-30 16:00 UTC (permalink / raw)
To: Pavel Machek
Cc: Tony Lindgren, Jassi Brar, Dave Gerlach, linux-kernel,
linux-omap, devicetree, linux-arm-kernel, Jassi Brar,
Rob Herring
Hi Pavel,
On 06/28/2014 12:07 PM, Pavel Machek wrote:
> Hi!
>
>> The non-DT support has to be maintained for now to not break
>> OMAP3 legacy boot, and the legacy-style code will be cleaned
>> up once OMAP3 is also converted to DT-boot only.
>
>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
>> return 0;
>> }
>>
>> +static const struct omap_mbox_device_data omap2_data = {
>> + .num_users = 4,
>> + .num_fifos = 6,
>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>> +};
>> +
>> +static const struct omap_mbox_device_data omap3_data = {
>> + .num_users = 2,
>> + .num_fifos = 2,
>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>> +};
>> +
>> +static const struct omap_mbox_device_data am335x_data = {
>> + .num_users = 4,
>> + .num_fifos = 8,
>> + .intr_type = MBOX_INTR_CFG_TYPE2,
>> +};
>
> So you use compatible strings to look up 3 integers. Would it be better to have
> num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
> and more flexible...
>
> If you do that, would it be possible to have share compatible string?
Yeah, I have actually encoded the .num_users and .num_fifos in DT in the
previous version [1] with shared compatible strings, but dropped those
properties in favour of adding minimal custom properties to DT based on
some offline IRC comments. I have no objections either way, but there is
really nothing to be gained from minimizing compatible strings.
Tony,
Any comments on this?
regards
Suman
[1] https://patchwork.kernel.org/patch/2839662/
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-06-30 16:00 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-30 16:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi Pavel,
On 06/28/2014 12:07 PM, Pavel Machek wrote:
> Hi!
>
>> The non-DT support has to be maintained for now to not break
>> OMAP3 legacy boot, and the legacy-style code will be cleaned
>> up once OMAP3 is also converted to DT-boot only.
>
>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
>> return 0;
>> }
>>
>> +static const struct omap_mbox_device_data omap2_data = {
>> + .num_users = 4,
>> + .num_fifos = 6,
>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>> +};
>> +
>> +static const struct omap_mbox_device_data omap3_data = {
>> + .num_users = 2,
>> + .num_fifos = 2,
>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>> +};
>> +
>> +static const struct omap_mbox_device_data am335x_data = {
>> + .num_users = 4,
>> + .num_fifos = 8,
>> + .intr_type = MBOX_INTR_CFG_TYPE2,
>> +};
>
> So you use compatible strings to look up 3 integers. Would it be better to have
> num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
> and more flexible...
>
> If you do that, would it be possible to have share compatible string?
Yeah, I have actually encoded the .num_users and .num_fifos in DT in the
previous version [1] with shared compatible strings, but dropped those
properties in favour of adding minimal custom properties to DT based on
some offline IRC comments. I have no objections either way, but there is
really nothing to be gained from minimizing compatible strings.
Tony,
Any comments on this?
regards
Suman
[1] https://patchwork.kernel.org/patch/2839662/
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
2014-06-30 16:00 ` Suman Anna
@ 2014-06-30 18:59 ` Pavel Machek
-1 siblings, 0 replies; 53+ messages in thread
From: Pavel Machek @ 2014-06-30 18:59 UTC (permalink / raw)
To: Suman Anna
Cc: Tony Lindgren, Jassi Brar, Dave Gerlach, linux-kernel,
linux-omap, devicetree, linux-arm-kernel, Jassi Brar,
Rob Herring
Hi!
> >> The non-DT support has to be maintained for now to not break
> >> OMAP3 legacy boot, and the legacy-style code will be cleaned
> >> up once OMAP3 is also converted to DT-boot only.
> >
> >> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> >> return 0;
> >> }
> >>
> >> +static const struct omap_mbox_device_data omap2_data = {
> >> + .num_users = 4,
> >> + .num_fifos = 6,
> >> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >> +};
> >> +
> >> +static const struct omap_mbox_device_data omap3_data = {
> >> + .num_users = 2,
> >> + .num_fifos = 2,
> >> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >> +};
> >> +
> >> +static const struct omap_mbox_device_data am335x_data = {
> >> + .num_users = 4,
> >> + .num_fifos = 8,
> >> + .intr_type = MBOX_INTR_CFG_TYPE2,
> >> +};
> >
> > So you use compatible strings to look up 3 integers. Would it be better to have
> > num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
> > and more flexible...
> >
> > If you do that, would it be possible to have share compatible string?
>
> Yeah, I have actually encoded the .num_users and .num_fifos in DT in the
> previous version [1] with shared compatible strings, but dropped those
> properties in favour of adding minimal custom properties to DT based on
> some offline IRC comments. I have no objections either way, but there is
> really nothing to be gained from minimizing compatible strings.
Actually, I'd guess best solution would be to do both: have it encoded
in device tree _and_ have separate compatible string for each version
(in case there are other differences). You'd still get rid of the
table...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-06-30 18:59 ` Pavel Machek
0 siblings, 0 replies; 53+ messages in thread
From: Pavel Machek @ 2014-06-30 18:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
> >> The non-DT support has to be maintained for now to not break
> >> OMAP3 legacy boot, and the legacy-style code will be cleaned
> >> up once OMAP3 is also converted to DT-boot only.
> >
> >> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> >> return 0;
> >> }
> >>
> >> +static const struct omap_mbox_device_data omap2_data = {
> >> + .num_users = 4,
> >> + .num_fifos = 6,
> >> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >> +};
> >> +
> >> +static const struct omap_mbox_device_data omap3_data = {
> >> + .num_users = 2,
> >> + .num_fifos = 2,
> >> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >> +};
> >> +
> >> +static const struct omap_mbox_device_data am335x_data = {
> >> + .num_users = 4,
> >> + .num_fifos = 8,
> >> + .intr_type = MBOX_INTR_CFG_TYPE2,
> >> +};
> >
> > So you use compatible strings to look up 3 integers. Would it be better to have
> > num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
> > and more flexible...
> >
> > If you do that, would it be possible to have share compatible string?
>
> Yeah, I have actually encoded the .num_users and .num_fifos in DT in the
> previous version [1] with shared compatible strings, but dropped those
> properties in favour of adding minimal custom properties to DT based on
> some offline IRC comments. I have no objections either way, but there is
> really nothing to be gained from minimizing compatible strings.
Actually, I'd guess best solution would be to do both: have it encoded
in device tree _and_ have separate compatible string for each version
(in case there are other differences). You'd still get rid of the
table...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
2014-06-30 18:59 ` Pavel Machek
(?)
@ 2014-06-30 19:34 ` Suman Anna
-1 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-30 19:34 UTC (permalink / raw)
To: Pavel Machek
Cc: Tony Lindgren, Jassi Brar, Dave Gerlach, linux-kernel,
linux-omap, devicetree, linux-arm-kernel, Jassi Brar,
Rob Herring
Hi Pavel,
>
>>>> The non-DT support has to be maintained for now to not break
>>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
>>>> up once OMAP3 is also converted to DT-boot only.
>>>
>>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
>>>> return 0;
>>>> }
>>>>
>>>> +static const struct omap_mbox_device_data omap2_data = {
>>>> + .num_users = 4,
>>>> + .num_fifos = 6,
>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>> +};
>>>> +
>>>> +static const struct omap_mbox_device_data omap3_data = {
>>>> + .num_users = 2,
>>>> + .num_fifos = 2,
>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>> +};
>>>> +
>>>> +static const struct omap_mbox_device_data am335x_data = {
>>>> + .num_users = 4,
>>>> + .num_fifos = 8,
>>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
>>>> +};
>>>
>>> So you use compatible strings to look up 3 integers. Would it be better to have
>>> num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
>>> and more flexible...
>>>
>>> If you do that, would it be possible to have share compatible string?
>>
>> Yeah, I have actually encoded the .num_users and .num_fifos in DT in the
>> previous version [1] with shared compatible strings, but dropped those
>> properties in favour of adding minimal custom properties to DT based on
>> some offline IRC comments. I have no objections either way, but there is
>> really nothing to be gained from minimizing compatible strings.
>
> Actually, I'd guess best solution would be to do both: have it encoded
> in device tree _and_ have separate compatible string for each version
> (in case there are other differences). You'd still get rid of the
> table...
Do note that the .intr_type has to with the register layout rather than
a physical property (mainly to distinguish the pre-OMAP4 IP register
layout), so I am not convinced that belongs to DT. This is the reason
why I didn't represent it in DT even in the previous version. The other
two are HW IP design parameters, so in general putting them in DT isn't
completely a bad idea, but I will wait to see if there are any further
comments on this from Tony or DT maintainers before I make changes.
regards
Suman
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-06-30 19:34 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-30 19:34 UTC (permalink / raw)
To: Pavel Machek
Cc: Tony Lindgren, Jassi Brar, Dave Gerlach, linux-kernel,
linux-omap, devicetree, linux-arm-kernel, Jassi Brar,
Rob Herring
Hi Pavel,
>
>>>> The non-DT support has to be maintained for now to not break
>>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
>>>> up once OMAP3 is also converted to DT-boot only.
>>>
>>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
>>>> return 0;
>>>> }
>>>>
>>>> +static const struct omap_mbox_device_data omap2_data = {
>>>> + .num_users = 4,
>>>> + .num_fifos = 6,
>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>> +};
>>>> +
>>>> +static const struct omap_mbox_device_data omap3_data = {
>>>> + .num_users = 2,
>>>> + .num_fifos = 2,
>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>> +};
>>>> +
>>>> +static const struct omap_mbox_device_data am335x_data = {
>>>> + .num_users = 4,
>>>> + .num_fifos = 8,
>>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
>>>> +};
>>>
>>> So you use compatible strings to look up 3 integers. Would it be better to have
>>> num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
>>> and more flexible...
>>>
>>> If you do that, would it be possible to have share compatible string?
>>
>> Yeah, I have actually encoded the .num_users and .num_fifos in DT in the
>> previous version [1] with shared compatible strings, but dropped those
>> properties in favour of adding minimal custom properties to DT based on
>> some offline IRC comments. I have no objections either way, but there is
>> really nothing to be gained from minimizing compatible strings.
>
> Actually, I'd guess best solution would be to do both: have it encoded
> in device tree _and_ have separate compatible string for each version
> (in case there are other differences). You'd still get rid of the
> table...
Do note that the .intr_type has to with the register layout rather than
a physical property (mainly to distinguish the pre-OMAP4 IP register
layout), so I am not convinced that belongs to DT. This is the reason
why I didn't represent it in DT even in the previous version. The other
two are HW IP design parameters, so in general putting them in DT isn't
completely a bad idea, but I will wait to see if there are any further
comments on this from Tony or DT maintainers before I make changes.
regards
Suman
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-06-30 19:34 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-06-30 19:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi Pavel,
>
>>>> The non-DT support has to be maintained for now to not break
>>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
>>>> up once OMAP3 is also converted to DT-boot only.
>>>
>>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
>>>> return 0;
>>>> }
>>>>
>>>> +static const struct omap_mbox_device_data omap2_data = {
>>>> + .num_users = 4,
>>>> + .num_fifos = 6,
>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>> +};
>>>> +
>>>> +static const struct omap_mbox_device_data omap3_data = {
>>>> + .num_users = 2,
>>>> + .num_fifos = 2,
>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>> +};
>>>> +
>>>> +static const struct omap_mbox_device_data am335x_data = {
>>>> + .num_users = 4,
>>>> + .num_fifos = 8,
>>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
>>>> +};
>>>
>>> So you use compatible strings to look up 3 integers. Would it be better to have
>>> num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
>>> and more flexible...
>>>
>>> If you do that, would it be possible to have share compatible string?
>>
>> Yeah, I have actually encoded the .num_users and .num_fifos in DT in the
>> previous version [1] with shared compatible strings, but dropped those
>> properties in favour of adding minimal custom properties to DT based on
>> some offline IRC comments. I have no objections either way, but there is
>> really nothing to be gained from minimizing compatible strings.
>
> Actually, I'd guess best solution would be to do both: have it encoded
> in device tree _and_ have separate compatible string for each version
> (in case there are other differences). You'd still get rid of the
> table...
Do note that the .intr_type has to with the register layout rather than
a physical property (mainly to distinguish the pre-OMAP4 IP register
layout), so I am not convinced that belongs to DT. This is the reason
why I didn't represent it in DT even in the previous version. The other
two are HW IP design parameters, so in general putting them in DT isn't
completely a bad idea, but I will wait to see if there are any further
comments on this from Tony or DT maintainers before I make changes.
regards
Suman
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
2014-06-30 19:34 ` Suman Anna
(?)
@ 2014-06-30 20:32 ` Pavel Machek
-1 siblings, 0 replies; 53+ messages in thread
From: Pavel Machek @ 2014-06-30 20:32 UTC (permalink / raw)
To: Suman Anna
Cc: Tony Lindgren, Jassi Brar, Dave Gerlach, linux-kernel,
linux-omap, devicetree, linux-arm-kernel, Jassi Brar,
Rob Herring
Hi!
> >>>> The non-DT support has to be maintained for now to not break
> >>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
> >>>> up once OMAP3 is also converted to DT-boot only.
> >>>
> >>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> >>>> return 0;
> >>>> }
> >>>>
> >>>> +static const struct omap_mbox_device_data omap2_data = {
> >>>> + .num_users = 4,
> >>>> + .num_fifos = 6,
> >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >>>> +};
> >>>> +
> >>>> +static const struct omap_mbox_device_data omap3_data = {
> >>>> + .num_users = 2,
> >>>> + .num_fifos = 2,
> >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >>>> +};
> >>>> +
> >>>> +static const struct omap_mbox_device_data am335x_data = {
> >>>> + .num_users = 4,
> >>>> + .num_fifos = 8,
> >>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
> >>>> +};
> >>>
> >>> So you use compatible strings to look up 3 integers. Would it be better to have
> >>> num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
> >>> and more flexible...
> >>>
> >>> If you do that, would it be possible to have share compatible string?
> >>
> >> Yeah, I have actually encoded the .num_users and .num_fifos in DT in the
> >> previous version [1] with shared compatible strings, but dropped those
> >> properties in favour of adding minimal custom properties to DT based on
> >> some offline IRC comments. I have no objections either way, but there is
> >> really nothing to be gained from minimizing compatible strings.
> >
> > Actually, I'd guess best solution would be to do both: have it encoded
> > in device tree _and_ have separate compatible string for each version
> > (in case there are other differences). You'd still get rid of the
> > table...
>
> Do note that the .intr_type has to with the register layout rather than
> a physical property (mainly to distinguish the pre-OMAP4 IP register
> layout), so I am not convinced that belongs to DT. This is the reason
> why I didn't represent it in DT even in the previous version. The
> other
Aha, ok, then the intr_type should be derived from
compatible-string. Or rather... you should have three
compatible-strings for the three possibilities? (And then subtype,
currently unused, in case there are more hw differences).
> two are HW IP design parameters, so in general putting them in DT isn't
> completely a bad idea, but I will wait to see if there are any further
> comments on this from Tony or DT maintainers before I make changes.
Ok, right... I'd vote for putting them into DT.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-06-30 20:32 ` Pavel Machek
0 siblings, 0 replies; 53+ messages in thread
From: Pavel Machek @ 2014-06-30 20:32 UTC (permalink / raw)
To: Suman Anna
Cc: devicetree, Dave Gerlach, Tony Lindgren, Jassi Brar,
linux-kernel, Jassi Brar, Rob Herring, linux-omap,
linux-arm-kernel
Hi!
> >>>> The non-DT support has to be maintained for now to not break
> >>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
> >>>> up once OMAP3 is also converted to DT-boot only.
> >>>
> >>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> >>>> return 0;
> >>>> }
> >>>>
> >>>> +static const struct omap_mbox_device_data omap2_data = {
> >>>> + .num_users = 4,
> >>>> + .num_fifos = 6,
> >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >>>> +};
> >>>> +
> >>>> +static const struct omap_mbox_device_data omap3_data = {
> >>>> + .num_users = 2,
> >>>> + .num_fifos = 2,
> >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >>>> +};
> >>>> +
> >>>> +static const struct omap_mbox_device_data am335x_data = {
> >>>> + .num_users = 4,
> >>>> + .num_fifos = 8,
> >>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
> >>>> +};
> >>>
> >>> So you use compatible strings to look up 3 integers. Would it be better to have
> >>> num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
> >>> and more flexible...
> >>>
> >>> If you do that, would it be possible to have share compatible string?
> >>
> >> Yeah, I have actually encoded the .num_users and .num_fifos in DT in the
> >> previous version [1] with shared compatible strings, but dropped those
> >> properties in favour of adding minimal custom properties to DT based on
> >> some offline IRC comments. I have no objections either way, but there is
> >> really nothing to be gained from minimizing compatible strings.
> >
> > Actually, I'd guess best solution would be to do both: have it encoded
> > in device tree _and_ have separate compatible string for each version
> > (in case there are other differences). You'd still get rid of the
> > table...
>
> Do note that the .intr_type has to with the register layout rather than
> a physical property (mainly to distinguish the pre-OMAP4 IP register
> layout), so I am not convinced that belongs to DT. This is the reason
> why I didn't represent it in DT even in the previous version. The
> other
Aha, ok, then the intr_type should be derived from
compatible-string. Or rather... you should have three
compatible-strings for the three possibilities? (And then subtype,
currently unused, in case there are more hw differences).
> two are HW IP design parameters, so in general putting them in DT isn't
> completely a bad idea, but I will wait to see if there are any further
> comments on this from Tony or DT maintainers before I make changes.
Ok, right... I'd vote for putting them into DT.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-06-30 20:32 ` Pavel Machek
0 siblings, 0 replies; 53+ messages in thread
From: Pavel Machek @ 2014-06-30 20:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
> >>>> The non-DT support has to be maintained for now to not break
> >>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
> >>>> up once OMAP3 is also converted to DT-boot only.
> >>>
> >>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> >>>> return 0;
> >>>> }
> >>>>
> >>>> +static const struct omap_mbox_device_data omap2_data = {
> >>>> + .num_users = 4,
> >>>> + .num_fifos = 6,
> >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >>>> +};
> >>>> +
> >>>> +static const struct omap_mbox_device_data omap3_data = {
> >>>> + .num_users = 2,
> >>>> + .num_fifos = 2,
> >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >>>> +};
> >>>> +
> >>>> +static const struct omap_mbox_device_data am335x_data = {
> >>>> + .num_users = 4,
> >>>> + .num_fifos = 8,
> >>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
> >>>> +};
> >>>
> >>> So you use compatible strings to look up 3 integers. Would it be better to have
> >>> num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
> >>> and more flexible...
> >>>
> >>> If you do that, would it be possible to have share compatible string?
> >>
> >> Yeah, I have actually encoded the .num_users and .num_fifos in DT in the
> >> previous version [1] with shared compatible strings, but dropped those
> >> properties in favour of adding minimal custom properties to DT based on
> >> some offline IRC comments. I have no objections either way, but there is
> >> really nothing to be gained from minimizing compatible strings.
> >
> > Actually, I'd guess best solution would be to do both: have it encoded
> > in device tree _and_ have separate compatible string for each version
> > (in case there are other differences). You'd still get rid of the
> > table...
>
> Do note that the .intr_type has to with the register layout rather than
> a physical property (mainly to distinguish the pre-OMAP4 IP register
> layout), so I am not convinced that belongs to DT. This is the reason
> why I didn't represent it in DT even in the previous version. The
> other
Aha, ok, then the intr_type should be derived from
compatible-string. Or rather... you should have three
compatible-strings for the three possibilities? (And then subtype,
currently unused, in case there are more hw differences).
> two are HW IP design parameters, so in general putting them in DT isn't
> completely a bad idea, but I will wait to see if there are any further
> comments on this from Tony or DT maintainers before I make changes.
Ok, right... I'd vote for putting them into DT.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
2014-06-30 20:32 ` Pavel Machek
@ 2014-07-04 6:45 ` Tony Lindgren
-1 siblings, 0 replies; 53+ messages in thread
From: Tony Lindgren @ 2014-07-04 6:45 UTC (permalink / raw)
To: Pavel Machek
Cc: Suman Anna, Jassi Brar, Dave Gerlach, linux-kernel, linux-omap,
devicetree, linux-arm-kernel, Jassi Brar, Rob Herring
* Pavel Machek <pavel@ucw.cz> [140630 13:34]:
> Hi!
>
> > >>>> The non-DT support has to be maintained for now to not break
> > >>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
> > >>>> up once OMAP3 is also converted to DT-boot only.
> > >>>
> > >>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> > >>>> return 0;
> > >>>> }
> > >>>>
> > >>>> +static const struct omap_mbox_device_data omap2_data = {
> > >>>> + .num_users = 4,
> > >>>> + .num_fifos = 6,
> > >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> > >>>> +};
> > >>>> +
> > >>>> +static const struct omap_mbox_device_data omap3_data = {
> > >>>> + .num_users = 2,
> > >>>> + .num_fifos = 2,
> > >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> > >>>> +};
> > >>>> +
> > >>>> +static const struct omap_mbox_device_data am335x_data = {
> > >>>> + .num_users = 4,
> > >>>> + .num_fifos = 8,
> > >>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
> > >>>> +};
> > >>>
> > >>> So you use compatible strings to look up 3 integers. Would it be better to have
> > >>> num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
> > >>> and more flexible...
> > >>>
> > >>> If you do that, would it be possible to have share compatible string?
> > >>
> > >> Yeah, I have actually encoded the .num_users and .num_fifos in DT in the
> > >> previous version [1] with shared compatible strings, but dropped those
> > >> properties in favour of adding minimal custom properties to DT based on
> > >> some offline IRC comments. I have no objections either way, but there is
> > >> really nothing to be gained from minimizing compatible strings.
> > >
> > > Actually, I'd guess best solution would be to do both: have it encoded
> > > in device tree _and_ have separate compatible string for each version
> > > (in case there are other differences). You'd still get rid of the
> > > table...
> >
> > Do note that the .intr_type has to with the register layout rather than
> > a physical property (mainly to distinguish the pre-OMAP4 IP register
> > layout), so I am not convinced that belongs to DT. This is the reason
> > why I didn't represent it in DT even in the previous version. The
> > other
>
> Aha, ok, then the intr_type should be derived from
> compatible-string. Or rather... you should have three
> compatible-strings for the three possibilities? (And then subtype,
> currently unused, in case there are more hw differences).
The compatible string can and should be separate for each revision
unless they are the same exacat hardware revision.
> > two are HW IP design parameters, so in general putting them in DT isn't
> > completely a bad idea, but I will wait to see if there are any further
> > comments on this from Tony or DT maintainers before I make changes.
>
> Ok, right... I'd vote for putting them into DT.
I would avoid adding custom DT properties where possible and let the
driver just initialize the right data based on the compatible flag.
That is as long as the amount of data built into the driver is minimal.
If we wanted to have some fifo property in DT, it should be Linux
generic property to avoid adding yet more custom driver specific
properties.
Regards,
Tony
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-07-04 6:45 ` Tony Lindgren
0 siblings, 0 replies; 53+ messages in thread
From: Tony Lindgren @ 2014-07-04 6:45 UTC (permalink / raw)
To: linux-arm-kernel
* Pavel Machek <pavel@ucw.cz> [140630 13:34]:
> Hi!
>
> > >>>> The non-DT support has to be maintained for now to not break
> > >>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
> > >>>> up once OMAP3 is also converted to DT-boot only.
> > >>>
> > >>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> > >>>> return 0;
> > >>>> }
> > >>>>
> > >>>> +static const struct omap_mbox_device_data omap2_data = {
> > >>>> + .num_users = 4,
> > >>>> + .num_fifos = 6,
> > >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> > >>>> +};
> > >>>> +
> > >>>> +static const struct omap_mbox_device_data omap3_data = {
> > >>>> + .num_users = 2,
> > >>>> + .num_fifos = 2,
> > >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> > >>>> +};
> > >>>> +
> > >>>> +static const struct omap_mbox_device_data am335x_data = {
> > >>>> + .num_users = 4,
> > >>>> + .num_fifos = 8,
> > >>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
> > >>>> +};
> > >>>
> > >>> So you use compatible strings to look up 3 integers. Would it be better to have
> > >>> num_users/num_fifos/intr_type directly in the device tree? That should be cleaner
> > >>> and more flexible...
> > >>>
> > >>> If you do that, would it be possible to have share compatible string?
> > >>
> > >> Yeah, I have actually encoded the .num_users and .num_fifos in DT in the
> > >> previous version [1] with shared compatible strings, but dropped those
> > >> properties in favour of adding minimal custom properties to DT based on
> > >> some offline IRC comments. I have no objections either way, but there is
> > >> really nothing to be gained from minimizing compatible strings.
> > >
> > > Actually, I'd guess best solution would be to do both: have it encoded
> > > in device tree _and_ have separate compatible string for each version
> > > (in case there are other differences). You'd still get rid of the
> > > table...
> >
> > Do note that the .intr_type has to with the register layout rather than
> > a physical property (mainly to distinguish the pre-OMAP4 IP register
> > layout), so I am not convinced that belongs to DT. This is the reason
> > why I didn't represent it in DT even in the previous version. The
> > other
>
> Aha, ok, then the intr_type should be derived from
> compatible-string. Or rather... you should have three
> compatible-strings for the three possibilities? (And then subtype,
> currently unused, in case there are more hw differences).
The compatible string can and should be separate for each revision
unless they are the same exacat hardware revision.
> > two are HW IP design parameters, so in general putting them in DT isn't
> > completely a bad idea, but I will wait to see if there are any further
> > comments on this from Tony or DT maintainers before I make changes.
>
> Ok, right... I'd vote for putting them into DT.
I would avoid adding custom DT properties where possible and let the
driver just initialize the right data based on the compatible flag.
That is as long as the amount of data built into the driver is minimal.
If we wanted to have some fifo property in DT, it should be Linux
generic property to avoid adding yet more custom driver specific
properties.
Regards,
Tony
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
2014-07-04 6:45 ` Tony Lindgren
@ 2014-07-04 8:05 ` Pavel Machek
-1 siblings, 0 replies; 53+ messages in thread
From: Pavel Machek @ 2014-07-04 8:05 UTC (permalink / raw)
To: Tony Lindgren
Cc: Suman Anna, Jassi Brar, Dave Gerlach, linux-kernel, linux-omap,
devicetree, linux-arm-kernel, Jassi Brar, Rob Herring
Hi!
> > > >>>> The non-DT support has to be maintained for now to not break
> > > >>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
> > > >>>> up once OMAP3 is also converted to DT-boot only.
> > > >>>
> > > >>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> > > >>>> return 0;
> > > >>>> }
> > > >>>>
> > > >>>> +static const struct omap_mbox_device_data omap2_data = {
> > > >>>> + .num_users = 4,
> > > >>>> + .num_fifos = 6,
> > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> > > >>>> +};
> > > >>>> +
> > > >>>> +static const struct omap_mbox_device_data omap3_data = {
> > > >>>> + .num_users = 2,
> > > >>>> + .num_fifos = 2,
> > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> > > >>>> +};
> > > >>>> +
> > > >>>> +static const struct omap_mbox_device_data am335x_data = {
> > > >>>> + .num_users = 4,
> > > >>>> + .num_fifos = 8,
> > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
> > > >>>> +};
> > > >>>
> > Aha, ok, then the intr_type should be derived from
> > compatible-string. Or rather... you should have three
> > compatible-strings for the three possibilities? (And then subtype,
> > currently unused, in case there are more hw differences).
>
> The compatible string can and should be separate for each revision
> unless they are the same exacat hardware revision.
ACK.
> > > two are HW IP design parameters, so in general putting them in DT isn't
> > > completely a bad idea, but I will wait to see if there are any further
> > > comments on this from Tony or DT maintainers before I make changes.
> >
> > Ok, right... I'd vote for putting them into DT.
>
> I would avoid adding custom DT properties where possible and let the
> driver just initialize the right data based on the compatible flag.
If these are HW IP design parameters, we can expect to see many
different combinations. Yet we know ahead of time how to handle
different parameters HW people select.
Thus IMO we should do it in the device tree.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-07-04 8:05 ` Pavel Machek
0 siblings, 0 replies; 53+ messages in thread
From: Pavel Machek @ 2014-07-04 8:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
> > > >>>> The non-DT support has to be maintained for now to not break
> > > >>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
> > > >>>> up once OMAP3 is also converted to DT-boot only.
> > > >>>
> > > >>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> > > >>>> return 0;
> > > >>>> }
> > > >>>>
> > > >>>> +static const struct omap_mbox_device_data omap2_data = {
> > > >>>> + .num_users = 4,
> > > >>>> + .num_fifos = 6,
> > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> > > >>>> +};
> > > >>>> +
> > > >>>> +static const struct omap_mbox_device_data omap3_data = {
> > > >>>> + .num_users = 2,
> > > >>>> + .num_fifos = 2,
> > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> > > >>>> +};
> > > >>>> +
> > > >>>> +static const struct omap_mbox_device_data am335x_data = {
> > > >>>> + .num_users = 4,
> > > >>>> + .num_fifos = 8,
> > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
> > > >>>> +};
> > > >>>
> > Aha, ok, then the intr_type should be derived from
> > compatible-string. Or rather... you should have three
> > compatible-strings for the three possibilities? (And then subtype,
> > currently unused, in case there are more hw differences).
>
> The compatible string can and should be separate for each revision
> unless they are the same exacat hardware revision.
ACK.
> > > two are HW IP design parameters, so in general putting them in DT isn't
> > > completely a bad idea, but I will wait to see if there are any further
> > > comments on this from Tony or DT maintainers before I make changes.
> >
> > Ok, right... I'd vote for putting them into DT.
>
> I would avoid adding custom DT properties where possible and let the
> driver just initialize the right data based on the compatible flag.
If these are HW IP design parameters, we can expect to see many
different combinations. Yet we know ahead of time how to handle
different parameters HW people select.
Thus IMO we should do it in the device tree.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-07-04 8:23 ` Tony Lindgren
0 siblings, 0 replies; 53+ messages in thread
From: Tony Lindgren @ 2014-07-04 8:23 UTC (permalink / raw)
To: Pavel Machek
Cc: Suman Anna, Jassi Brar, Dave Gerlach, linux-kernel, linux-omap,
devicetree, linux-arm-kernel, Jassi Brar, Rob Herring
* Pavel Machek <pavel@ucw.cz> [140704 01:07]:
> Hi!
>
> > > > >>>> The non-DT support has to be maintained for now to not break
> > > > >>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
> > > > >>>> up once OMAP3 is also converted to DT-boot only.
> > > > >>>
> > > > >>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> > > > >>>> return 0;
> > > > >>>> }
> > > > >>>>
> > > > >>>> +static const struct omap_mbox_device_data omap2_data = {
> > > > >>>> + .num_users = 4,
> > > > >>>> + .num_fifos = 6,
> > > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> > > > >>>> +};
> > > > >>>> +
> > > > >>>> +static const struct omap_mbox_device_data omap3_data = {
> > > > >>>> + .num_users = 2,
> > > > >>>> + .num_fifos = 2,
> > > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> > > > >>>> +};
> > > > >>>> +
> > > > >>>> +static const struct omap_mbox_device_data am335x_data = {
> > > > >>>> + .num_users = 4,
> > > > >>>> + .num_fifos = 8,
> > > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
> > > > >>>> +};
> > > > >>>
>
> > > Aha, ok, then the intr_type should be derived from
> > > compatible-string. Or rather... you should have three
> > > compatible-strings for the three possibilities? (And then subtype,
> > > currently unused, in case there are more hw differences).
> >
> > The compatible string can and should be separate for each revision
> > unless they are the same exacat hardware revision.
>
> ACK.
>
> > > > two are HW IP design parameters, so in general putting them in DT isn't
> > > > completely a bad idea, but I will wait to see if there are any further
> > > > comments on this from Tony or DT maintainers before I make changes.
> > >
> > > Ok, right... I'd vote for putting them into DT.
> >
> > I would avoid adding custom DT properties where possible and let the
> > driver just initialize the right data based on the compatible flag.
>
> If these are HW IP design parameters, we can expect to see many
> different combinations. Yet we know ahead of time how to handle
> different parameters HW people select.
>
> Thus IMO we should do it in the device tree.
Oh you mean from supporting new hardware with just .dts changes?
>From that point of view it makes sense to have them as DT properties,
so I'm fine with that.
Let's just try to use something that's generic like fifosize. No idea
how the property for num_fifos should be handled though as that
implies some knowledge in the driver which num_users have fifos?
So unless that can be described clearly in a DT property as well,
the binding might be still unusable for new hardware :)
Regards,
Tony
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-07-04 8:23 ` Tony Lindgren
0 siblings, 0 replies; 53+ messages in thread
From: Tony Lindgren @ 2014-07-04 8:23 UTC (permalink / raw)
To: Pavel Machek
Cc: Suman Anna, Jassi Brar, Dave Gerlach,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jassi Brar,
Rob Herring
* Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> [140704 01:07]:
> Hi!
>
> > > > >>>> The non-DT support has to be maintained for now to not break
> > > > >>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
> > > > >>>> up once OMAP3 is also converted to DT-boot only.
> > > > >>>
> > > > >>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> > > > >>>> return 0;
> > > > >>>> }
> > > > >>>>
> > > > >>>> +static const struct omap_mbox_device_data omap2_data = {
> > > > >>>> + .num_users = 4,
> > > > >>>> + .num_fifos = 6,
> > > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> > > > >>>> +};
> > > > >>>> +
> > > > >>>> +static const struct omap_mbox_device_data omap3_data = {
> > > > >>>> + .num_users = 2,
> > > > >>>> + .num_fifos = 2,
> > > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> > > > >>>> +};
> > > > >>>> +
> > > > >>>> +static const struct omap_mbox_device_data am335x_data = {
> > > > >>>> + .num_users = 4,
> > > > >>>> + .num_fifos = 8,
> > > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
> > > > >>>> +};
> > > > >>>
>
> > > Aha, ok, then the intr_type should be derived from
> > > compatible-string. Or rather... you should have three
> > > compatible-strings for the three possibilities? (And then subtype,
> > > currently unused, in case there are more hw differences).
> >
> > The compatible string can and should be separate for each revision
> > unless they are the same exacat hardware revision.
>
> ACK.
>
> > > > two are HW IP design parameters, so in general putting them in DT isn't
> > > > completely a bad idea, but I will wait to see if there are any further
> > > > comments on this from Tony or DT maintainers before I make changes.
> > >
> > > Ok, right... I'd vote for putting them into DT.
> >
> > I would avoid adding custom DT properties where possible and let the
> > driver just initialize the right data based on the compatible flag.
>
> If these are HW IP design parameters, we can expect to see many
> different combinations. Yet we know ahead of time how to handle
> different parameters HW people select.
>
> Thus IMO we should do it in the device tree.
Oh you mean from supporting new hardware with just .dts changes?
>From that point of view it makes sense to have them as DT properties,
so I'm fine with that.
Let's just try to use something that's generic like fifosize. No idea
how the property for num_fifos should be handled though as that
implies some knowledge in the driver which num_users have fifos?
So unless that can be described clearly in a DT property as well,
the binding might be still unusable for new hardware :)
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-07-04 8:23 ` Tony Lindgren
0 siblings, 0 replies; 53+ messages in thread
From: Tony Lindgren @ 2014-07-04 8:23 UTC (permalink / raw)
To: linux-arm-kernel
* Pavel Machek <pavel@ucw.cz> [140704 01:07]:
> Hi!
>
> > > > >>>> The non-DT support has to be maintained for now to not break
> > > > >>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
> > > > >>>> up once OMAP3 is also converted to DT-boot only.
> > > > >>>
> > > > >>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> > > > >>>> return 0;
> > > > >>>> }
> > > > >>>>
> > > > >>>> +static const struct omap_mbox_device_data omap2_data = {
> > > > >>>> + .num_users = 4,
> > > > >>>> + .num_fifos = 6,
> > > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> > > > >>>> +};
> > > > >>>> +
> > > > >>>> +static const struct omap_mbox_device_data omap3_data = {
> > > > >>>> + .num_users = 2,
> > > > >>>> + .num_fifos = 2,
> > > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> > > > >>>> +};
> > > > >>>> +
> > > > >>>> +static const struct omap_mbox_device_data am335x_data = {
> > > > >>>> + .num_users = 4,
> > > > >>>> + .num_fifos = 8,
> > > > >>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
> > > > >>>> +};
> > > > >>>
>
> > > Aha, ok, then the intr_type should be derived from
> > > compatible-string. Or rather... you should have three
> > > compatible-strings for the three possibilities? (And then subtype,
> > > currently unused, in case there are more hw differences).
> >
> > The compatible string can and should be separate for each revision
> > unless they are the same exacat hardware revision.
>
> ACK.
>
> > > > two are HW IP design parameters, so in general putting them in DT isn't
> > > > completely a bad idea, but I will wait to see if there are any further
> > > > comments on this from Tony or DT maintainers before I make changes.
> > >
> > > Ok, right... I'd vote for putting them into DT.
> >
> > I would avoid adding custom DT properties where possible and let the
> > driver just initialize the right data based on the compatible flag.
>
> If these are HW IP design parameters, we can expect to see many
> different combinations. Yet we know ahead of time how to handle
> different parameters HW people select.
>
> Thus IMO we should do it in the device tree.
Oh you mean from supporting new hardware with just .dts changes?
>From that point of view it makes sense to have them as DT properties,
so I'm fine with that.
Let's just try to use something that's generic like fifosize. No idea
how the property for num_fifos should be handled though as that
implies some knowledge in the driver which num_users have fifos?
So unless that can be described clearly in a DT property as well,
the binding might be still unusable for new hardware :)
Regards,
Tony
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-07-08 17:55 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-07-08 17:55 UTC (permalink / raw)
To: Tony Lindgren, Pavel Machek
Cc: Jassi Brar, Dave Gerlach, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Jassi Brar, Rob Herring
Hi Tony, Pavel,
On 07/04/2014 03:23 AM, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [140704 01:07]:
>> Hi!
>>
>>>>>>>>> The non-DT support has to be maintained for now to not break
>>>>>>>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
>>>>>>>>> up once OMAP3 is also converted to DT-boot only.
>>>>>>>>
>>>>>>>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
>>>>>>>>> return 0;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> +static const struct omap_mbox_device_data omap2_data = {
>>>>>>>>> + .num_users = 4,
>>>>>>>>> + .num_fifos = 6,
>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>>> +static const struct omap_mbox_device_data omap3_data = {
>>>>>>>>> + .num_users = 2,
>>>>>>>>> + .num_fifos = 2,
>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>>> +static const struct omap_mbox_device_data am335x_data = {
>>>>>>>>> + .num_users = 4,
>>>>>>>>> + .num_fifos = 8,
>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
>>>>>>>>> +};
>>>>>>>>
>>
>>>> Aha, ok, then the intr_type should be derived from
>>>> compatible-string. Or rather... you should have three
>>>> compatible-strings for the three possibilities? (And then subtype,
>>>> currently unused, in case there are more hw differences).
>>>
>>> The compatible string can and should be separate for each revision
>>> unless they are the same exacat hardware revision.
>>
>> ACK.
I checked the revision register from all SoCs. OMAP2 and OMAP3 have
different revisions compared to OMAP4+. All of OMAP4, OMAP5, DRA7,
AM335x and AM437x have the same version, but with different num-fifos
and num-users. So, I can switch back to using omap4-mailbox for all of
these SoCs only if we encode the num-fifos and num-users in DT.
>>
>>>>> two are HW IP design parameters, so in general putting them in DT isn't
>>>>> completely a bad idea, but I will wait to see if there are any further
>>>>> comments on this from Tony or DT maintainers before I make changes.
>>>>
>>>> Ok, right... I'd vote for putting them into DT.
>>>
>>> I would avoid adding custom DT properties where possible and let the
>>> driver just initialize the right data based on the compatible flag.
>>
>> If these are HW IP design parameters, we can expect to see many
>> different combinations. Yet we know ahead of time how to handle
>> different parameters HW people select.
That's right, the above OMAP4+ SoCs already demonstrate this behavior.
>>
>> Thus IMO we should do it in the device tree.
>
> Oh you mean from supporting new hardware with just .dts changes?
> From that point of view it makes sense to have them as DT properties,
> so I'm fine with that.
>
> Let's just try to use something that's generic like fifosize. No idea
> how the property for num_fifos should be handled though as that
> implies some knowledge in the driver which num_users have fifos?
The fifos are not per num_users, but rather the total number of fifos
within the IP block. The num_users will be the number of targets the IP
block can interrupt. I tried looking for generic properties, but there
weren't any that seem to fit the description. If you want generic names,
I can use num-fifos and num-users, otherwise will stick to the
names defined in the previous series.
>
> So unless that can be described clearly in a DT property as well,
> the binding might be still unusable for new hardware :)
>
I don't expect the OMAP mailbox IP to change much in the future. There
is a FIFO depth parameter as well, but that's constant in all the
current versions, and even if they change it, I can already use the
generic property for that.
Tony,
Depending on the agreement here, I may have to respin the OMAP
mailbox DT/hwmod cleanup series [1]
regards
Suman
[1] http://marc.info/?l=linux-omap&m=140365833121612&w=2
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-07-08 17:55 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-07-08 17:55 UTC (permalink / raw)
To: Tony Lindgren, Pavel Machek
Cc: Jassi Brar, Dave Gerlach, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jassi Brar,
Rob Herring
Hi Tony, Pavel,
On 07/04/2014 03:23 AM, Tony Lindgren wrote:
> * Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> [140704 01:07]:
>> Hi!
>>
>>>>>>>>> The non-DT support has to be maintained for now to not break
>>>>>>>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
>>>>>>>>> up once OMAP3 is also converted to DT-boot only.
>>>>>>>>
>>>>>>>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
>>>>>>>>> return 0;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> +static const struct omap_mbox_device_data omap2_data = {
>>>>>>>>> + .num_users = 4,
>>>>>>>>> + .num_fifos = 6,
>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>>> +static const struct omap_mbox_device_data omap3_data = {
>>>>>>>>> + .num_users = 2,
>>>>>>>>> + .num_fifos = 2,
>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>>> +static const struct omap_mbox_device_data am335x_data = {
>>>>>>>>> + .num_users = 4,
>>>>>>>>> + .num_fifos = 8,
>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
>>>>>>>>> +};
>>>>>>>>
>>
>>>> Aha, ok, then the intr_type should be derived from
>>>> compatible-string. Or rather... you should have three
>>>> compatible-strings for the three possibilities? (And then subtype,
>>>> currently unused, in case there are more hw differences).
>>>
>>> The compatible string can and should be separate for each revision
>>> unless they are the same exacat hardware revision.
>>
>> ACK.
I checked the revision register from all SoCs. OMAP2 and OMAP3 have
different revisions compared to OMAP4+. All of OMAP4, OMAP5, DRA7,
AM335x and AM437x have the same version, but with different num-fifos
and num-users. So, I can switch back to using omap4-mailbox for all of
these SoCs only if we encode the num-fifos and num-users in DT.
>>
>>>>> two are HW IP design parameters, so in general putting them in DT isn't
>>>>> completely a bad idea, but I will wait to see if there are any further
>>>>> comments on this from Tony or DT maintainers before I make changes.
>>>>
>>>> Ok, right... I'd vote for putting them into DT.
>>>
>>> I would avoid adding custom DT properties where possible and let the
>>> driver just initialize the right data based on the compatible flag.
>>
>> If these are HW IP design parameters, we can expect to see many
>> different combinations. Yet we know ahead of time how to handle
>> different parameters HW people select.
That's right, the above OMAP4+ SoCs already demonstrate this behavior.
>>
>> Thus IMO we should do it in the device tree.
>
> Oh you mean from supporting new hardware with just .dts changes?
> From that point of view it makes sense to have them as DT properties,
> so I'm fine with that.
>
> Let's just try to use something that's generic like fifosize. No idea
> how the property for num_fifos should be handled though as that
> implies some knowledge in the driver which num_users have fifos?
The fifos are not per num_users, but rather the total number of fifos
within the IP block. The num_users will be the number of targets the IP
block can interrupt. I tried looking for generic properties, but there
weren't any that seem to fit the description. If you want generic names,
I can use num-fifos and num-users, otherwise will stick to the
names defined in the previous series.
>
> So unless that can be described clearly in a DT property as well,
> the binding might be still unusable for new hardware :)
>
I don't expect the OMAP mailbox IP to change much in the future. There
is a FIFO depth parameter as well, but that's constant in all the
current versions, and even if they change it, I can already use the
generic property for that.
Tony,
Depending on the agreement here, I may have to respin the OMAP
mailbox DT/hwmod cleanup series [1]
regards
Suman
[1] http://marc.info/?l=linux-omap&m=140365833121612&w=2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-07-08 17:55 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-07-08 17:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tony, Pavel,
On 07/04/2014 03:23 AM, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [140704 01:07]:
>> Hi!
>>
>>>>>>>>> The non-DT support has to be maintained for now to not break
>>>>>>>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
>>>>>>>>> up once OMAP3 is also converted to DT-boot only.
>>>>>>>>
>>>>>>>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
>>>>>>>>> return 0;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> +static const struct omap_mbox_device_data omap2_data = {
>>>>>>>>> + .num_users = 4,
>>>>>>>>> + .num_fifos = 6,
>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>>> +static const struct omap_mbox_device_data omap3_data = {
>>>>>>>>> + .num_users = 2,
>>>>>>>>> + .num_fifos = 2,
>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>>> +static const struct omap_mbox_device_data am335x_data = {
>>>>>>>>> + .num_users = 4,
>>>>>>>>> + .num_fifos = 8,
>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
>>>>>>>>> +};
>>>>>>>>
>>
>>>> Aha, ok, then the intr_type should be derived from
>>>> compatible-string. Or rather... you should have three
>>>> compatible-strings for the three possibilities? (And then subtype,
>>>> currently unused, in case there are more hw differences).
>>>
>>> The compatible string can and should be separate for each revision
>>> unless they are the same exacat hardware revision.
>>
>> ACK.
I checked the revision register from all SoCs. OMAP2 and OMAP3 have
different revisions compared to OMAP4+. All of OMAP4, OMAP5, DRA7,
AM335x and AM437x have the same version, but with different num-fifos
and num-users. So, I can switch back to using omap4-mailbox for all of
these SoCs only if we encode the num-fifos and num-users in DT.
>>
>>>>> two are HW IP design parameters, so in general putting them in DT isn't
>>>>> completely a bad idea, but I will wait to see if there are any further
>>>>> comments on this from Tony or DT maintainers before I make changes.
>>>>
>>>> Ok, right... I'd vote for putting them into DT.
>>>
>>> I would avoid adding custom DT properties where possible and let the
>>> driver just initialize the right data based on the compatible flag.
>>
>> If these are HW IP design parameters, we can expect to see many
>> different combinations. Yet we know ahead of time how to handle
>> different parameters HW people select.
That's right, the above OMAP4+ SoCs already demonstrate this behavior.
>>
>> Thus IMO we should do it in the device tree.
>
> Oh you mean from supporting new hardware with just .dts changes?
> From that point of view it makes sense to have them as DT properties,
> so I'm fine with that.
>
> Let's just try to use something that's generic like fifosize. No idea
> how the property for num_fifos should be handled though as that
> implies some knowledge in the driver which num_users have fifos?
The fifos are not per num_users, but rather the total number of fifos
within the IP block. The num_users will be the number of targets the IP
block can interrupt. I tried looking for generic properties, but there
weren't any that seem to fit the description. If you want generic names,
I can use num-fifos and num-users, otherwise will stick to the
names defined in the previous series.
>
> So unless that can be described clearly in a DT property as well,
> the binding might be still unusable for new hardware :)
>
I don't expect the OMAP mailbox IP to change much in the future. There
is a FIFO depth parameter as well, but that's constant in all the
current versions, and even if they change it, I can already use the
generic property for that.
Tony,
Depending on the agreement here, I may have to respin the OMAP
mailbox DT/hwmod cleanup series [1]
regards
Suman
[1] http://marc.info/?l=linux-omap&m=140365833121612&w=2
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-07-09 8:29 ` Tony Lindgren
0 siblings, 0 replies; 53+ messages in thread
From: Tony Lindgren @ 2014-07-09 8:29 UTC (permalink / raw)
To: Suman Anna
Cc: Pavel Machek, Jassi Brar, Dave Gerlach, linux-kernel, linux-omap,
devicetree, linux-arm-kernel, Jassi Brar, Rob Herring
* Suman Anna <s-anna@ti.com> [140708 10:57]:
> Hi Tony, Pavel,
>
> On 07/04/2014 03:23 AM, Tony Lindgren wrote:
> > * Pavel Machek <pavel@ucw.cz> [140704 01:07]:
> >> Hi!
> >>
> >>>>>>>>> The non-DT support has to be maintained for now to not break
> >>>>>>>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
> >>>>>>>>> up once OMAP3 is also converted to DT-boot only.
> >>>>>>>>
> >>>>>>>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> >>>>>>>>> return 0;
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> +static const struct omap_mbox_device_data omap2_data = {
> >>>>>>>>> + .num_users = 4,
> >>>>>>>>> + .num_fifos = 6,
> >>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >>>>>>>>> +};
> >>>>>>>>> +
> >>>>>>>>> +static const struct omap_mbox_device_data omap3_data = {
> >>>>>>>>> + .num_users = 2,
> >>>>>>>>> + .num_fifos = 2,
> >>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >>>>>>>>> +};
> >>>>>>>>> +
> >>>>>>>>> +static const struct omap_mbox_device_data am335x_data = {
> >>>>>>>>> + .num_users = 4,
> >>>>>>>>> + .num_fifos = 8,
> >>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
> >>>>>>>>> +};
> >>>>>>>>
> >>
> >>>> Aha, ok, then the intr_type should be derived from
> >>>> compatible-string. Or rather... you should have three
> >>>> compatible-strings for the three possibilities? (And then subtype,
> >>>> currently unused, in case there are more hw differences).
> >>>
> >>> The compatible string can and should be separate for each revision
> >>> unless they are the same exacat hardware revision.
> >>
> >> ACK.
>
> I checked the revision register from all SoCs. OMAP2 and OMAP3 have
> different revisions compared to OMAP4+. All of OMAP4, OMAP5, DRA7,
> AM335x and AM437x have the same version, but with different num-fifos
> and num-users. So, I can switch back to using omap4-mailbox for all of
> these SoCs only if we encode the num-fifos and num-users in DT.
>
> >>
> >>>>> two are HW IP design parameters, so in general putting them in DT isn't
> >>>>> completely a bad idea, but I will wait to see if there are any further
> >>>>> comments on this from Tony or DT maintainers before I make changes.
> >>>>
> >>>> Ok, right... I'd vote for putting them into DT.
> >>>
> >>> I would avoid adding custom DT properties where possible and let the
> >>> driver just initialize the right data based on the compatible flag.
> >>
> >> If these are HW IP design parameters, we can expect to see many
> >> different combinations. Yet we know ahead of time how to handle
> >> different parameters HW people select.
>
> That's right, the above OMAP4+ SoCs already demonstrate this behavior.
>
> >>
> >> Thus IMO we should do it in the device tree.
> >
> > Oh you mean from supporting new hardware with just .dts changes?
> > From that point of view it makes sense to have them as DT properties,
> > so I'm fine with that.
> >
> > Let's just try to use something that's generic like fifosize. No idea
> > how the property for num_fifos should be handled though as that
> > implies some knowledge in the driver which num_users have fifos?
>
> The fifos are not per num_users, but rather the total number of fifos
> within the IP block. The num_users will be the number of targets the IP
> block can interrupt. I tried looking for generic properties, but there
> weren't any that seem to fit the description. If you want generic names,
> I can use num-fifos and num-users, otherwise will stick to the
> names defined in the previous series.
OK since we already have some .dts entries with ti,mbox-num-fifos and
ti,mbox-num-users I'd use those for now. Adding parsing for a generic
property can be done later on.
> > So unless that can be described clearly in a DT property as well,
> > the binding might be still unusable for new hardware :)
> >
>
> I don't expect the OMAP mailbox IP to change much in the future. There
> is a FIFO depth parameter as well, but that's constant in all the
> current versions, and even if they change it, I can already use the
> generic property for that.
OK
> Tony,
> Depending on the agreement here, I may have to respin the OMAP
> mailbox DT/hwmod cleanup series [1]
OK let me know.
Regards,
Tony
> [1] http://marc.info/?l=linux-omap&m=140365833121612&w=2
>
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-07-09 8:29 ` Tony Lindgren
0 siblings, 0 replies; 53+ messages in thread
From: Tony Lindgren @ 2014-07-09 8:29 UTC (permalink / raw)
To: Suman Anna
Cc: Pavel Machek, Jassi Brar, Dave Gerlach,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jassi Brar,
Rob Herring
* Suman Anna <s-anna-l0cyMroinI0@public.gmane.org> [140708 10:57]:
> Hi Tony, Pavel,
>
> On 07/04/2014 03:23 AM, Tony Lindgren wrote:
> > * Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> [140704 01:07]:
> >> Hi!
> >>
> >>>>>>>>> The non-DT support has to be maintained for now to not break
> >>>>>>>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
> >>>>>>>>> up once OMAP3 is also converted to DT-boot only.
> >>>>>>>>
> >>>>>>>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> >>>>>>>>> return 0;
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> +static const struct omap_mbox_device_data omap2_data = {
> >>>>>>>>> + .num_users = 4,
> >>>>>>>>> + .num_fifos = 6,
> >>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >>>>>>>>> +};
> >>>>>>>>> +
> >>>>>>>>> +static const struct omap_mbox_device_data omap3_data = {
> >>>>>>>>> + .num_users = 2,
> >>>>>>>>> + .num_fifos = 2,
> >>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >>>>>>>>> +};
> >>>>>>>>> +
> >>>>>>>>> +static const struct omap_mbox_device_data am335x_data = {
> >>>>>>>>> + .num_users = 4,
> >>>>>>>>> + .num_fifos = 8,
> >>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
> >>>>>>>>> +};
> >>>>>>>>
> >>
> >>>> Aha, ok, then the intr_type should be derived from
> >>>> compatible-string. Or rather... you should have three
> >>>> compatible-strings for the three possibilities? (And then subtype,
> >>>> currently unused, in case there are more hw differences).
> >>>
> >>> The compatible string can and should be separate for each revision
> >>> unless they are the same exacat hardware revision.
> >>
> >> ACK.
>
> I checked the revision register from all SoCs. OMAP2 and OMAP3 have
> different revisions compared to OMAP4+. All of OMAP4, OMAP5, DRA7,
> AM335x and AM437x have the same version, but with different num-fifos
> and num-users. So, I can switch back to using omap4-mailbox for all of
> these SoCs only if we encode the num-fifos and num-users in DT.
>
> >>
> >>>>> two are HW IP design parameters, so in general putting them in DT isn't
> >>>>> completely a bad idea, but I will wait to see if there are any further
> >>>>> comments on this from Tony or DT maintainers before I make changes.
> >>>>
> >>>> Ok, right... I'd vote for putting them into DT.
> >>>
> >>> I would avoid adding custom DT properties where possible and let the
> >>> driver just initialize the right data based on the compatible flag.
> >>
> >> If these are HW IP design parameters, we can expect to see many
> >> different combinations. Yet we know ahead of time how to handle
> >> different parameters HW people select.
>
> That's right, the above OMAP4+ SoCs already demonstrate this behavior.
>
> >>
> >> Thus IMO we should do it in the device tree.
> >
> > Oh you mean from supporting new hardware with just .dts changes?
> > From that point of view it makes sense to have them as DT properties,
> > so I'm fine with that.
> >
> > Let's just try to use something that's generic like fifosize. No idea
> > how the property for num_fifos should be handled though as that
> > implies some knowledge in the driver which num_users have fifos?
>
> The fifos are not per num_users, but rather the total number of fifos
> within the IP block. The num_users will be the number of targets the IP
> block can interrupt. I tried looking for generic properties, but there
> weren't any that seem to fit the description. If you want generic names,
> I can use num-fifos and num-users, otherwise will stick to the
> names defined in the previous series.
OK since we already have some .dts entries with ti,mbox-num-fifos and
ti,mbox-num-users I'd use those for now. Adding parsing for a generic
property can be done later on.
> > So unless that can be described clearly in a DT property as well,
> > the binding might be still unusable for new hardware :)
> >
>
> I don't expect the OMAP mailbox IP to change much in the future. There
> is a FIFO depth parameter as well, but that's constant in all the
> current versions, and even if they change it, I can already use the
> generic property for that.
OK
> Tony,
> Depending on the agreement here, I may have to respin the OMAP
> mailbox DT/hwmod cleanup series [1]
OK let me know.
Regards,
Tony
> [1] http://marc.info/?l=linux-omap&m=140365833121612&w=2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-07-09 8:29 ` Tony Lindgren
0 siblings, 0 replies; 53+ messages in thread
From: Tony Lindgren @ 2014-07-09 8:29 UTC (permalink / raw)
To: linux-arm-kernel
* Suman Anna <s-anna@ti.com> [140708 10:57]:
> Hi Tony, Pavel,
>
> On 07/04/2014 03:23 AM, Tony Lindgren wrote:
> > * Pavel Machek <pavel@ucw.cz> [140704 01:07]:
> >> Hi!
> >>
> >>>>>>>>> The non-DT support has to be maintained for now to not break
> >>>>>>>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
> >>>>>>>>> up once OMAP3 is also converted to DT-boot only.
> >>>>>>>>
> >>>>>>>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> >>>>>>>>> return 0;
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> +static const struct omap_mbox_device_data omap2_data = {
> >>>>>>>>> + .num_users = 4,
> >>>>>>>>> + .num_fifos = 6,
> >>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >>>>>>>>> +};
> >>>>>>>>> +
> >>>>>>>>> +static const struct omap_mbox_device_data omap3_data = {
> >>>>>>>>> + .num_users = 2,
> >>>>>>>>> + .num_fifos = 2,
> >>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
> >>>>>>>>> +};
> >>>>>>>>> +
> >>>>>>>>> +static const struct omap_mbox_device_data am335x_data = {
> >>>>>>>>> + .num_users = 4,
> >>>>>>>>> + .num_fifos = 8,
> >>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
> >>>>>>>>> +};
> >>>>>>>>
> >>
> >>>> Aha, ok, then the intr_type should be derived from
> >>>> compatible-string. Or rather... you should have three
> >>>> compatible-strings for the three possibilities? (And then subtype,
> >>>> currently unused, in case there are more hw differences).
> >>>
> >>> The compatible string can and should be separate for each revision
> >>> unless they are the same exacat hardware revision.
> >>
> >> ACK.
>
> I checked the revision register from all SoCs. OMAP2 and OMAP3 have
> different revisions compared to OMAP4+. All of OMAP4, OMAP5, DRA7,
> AM335x and AM437x have the same version, but with different num-fifos
> and num-users. So, I can switch back to using omap4-mailbox for all of
> these SoCs only if we encode the num-fifos and num-users in DT.
>
> >>
> >>>>> two are HW IP design parameters, so in general putting them in DT isn't
> >>>>> completely a bad idea, but I will wait to see if there are any further
> >>>>> comments on this from Tony or DT maintainers before I make changes.
> >>>>
> >>>> Ok, right... I'd vote for putting them into DT.
> >>>
> >>> I would avoid adding custom DT properties where possible and let the
> >>> driver just initialize the right data based on the compatible flag.
> >>
> >> If these are HW IP design parameters, we can expect to see many
> >> different combinations. Yet we know ahead of time how to handle
> >> different parameters HW people select.
>
> That's right, the above OMAP4+ SoCs already demonstrate this behavior.
>
> >>
> >> Thus IMO we should do it in the device tree.
> >
> > Oh you mean from supporting new hardware with just .dts changes?
> > From that point of view it makes sense to have them as DT properties,
> > so I'm fine with that.
> >
> > Let's just try to use something that's generic like fifosize. No idea
> > how the property for num_fifos should be handled though as that
> > implies some knowledge in the driver which num_users have fifos?
>
> The fifos are not per num_users, but rather the total number of fifos
> within the IP block. The num_users will be the number of targets the IP
> block can interrupt. I tried looking for generic properties, but there
> weren't any that seem to fit the description. If you want generic names,
> I can use num-fifos and num-users, otherwise will stick to the
> names defined in the previous series.
OK since we already have some .dts entries with ti,mbox-num-fifos and
ti,mbox-num-users I'd use those for now. Adding parsing for a generic
property can be done later on.
> > So unless that can be described clearly in a DT property as well,
> > the binding might be still unusable for new hardware :)
> >
>
> I don't expect the OMAP mailbox IP to change much in the future. There
> is a FIFO depth parameter as well, but that's constant in all the
> current versions, and even if they change it, I can already use the
> generic property for that.
OK
> Tony,
> Depending on the agreement here, I may have to respin the OMAP
> mailbox DT/hwmod cleanup series [1]
OK let me know.
Regards,
Tony
> [1] http://marc.info/?l=linux-omap&m=140365833121612&w=2
>
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
2014-07-09 8:29 ` Tony Lindgren
(?)
@ 2014-07-09 15:15 ` Suman Anna
-1 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-07-09 15:15 UTC (permalink / raw)
To: Tony Lindgren
Cc: Pavel Machek, Jassi Brar, Dave Gerlach, linux-kernel, linux-omap,
devicetree, linux-arm-kernel, Jassi Brar, Rob Herring
On 07/09/2014 03:29 AM, Tony Lindgren wrote:
> * Suman Anna <s-anna@ti.com> [140708 10:57]:
>> Hi Tony, Pavel,
>>
>> On 07/04/2014 03:23 AM, Tony Lindgren wrote:
>>> * Pavel Machek <pavel@ucw.cz> [140704 01:07]:
>>>> Hi!
>>>>
>>>>>>>>>>> The non-DT support has to be maintained for now to not break
>>>>>>>>>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
>>>>>>>>>>> up once OMAP3 is also converted to DT-boot only.
>>>>>>>>>>
>>>>>>>>>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
>>>>>>>>>>> return 0;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> +static const struct omap_mbox_device_data omap2_data = {
>>>>>>>>>>> + .num_users = 4,
>>>>>>>>>>> + .num_fifos = 6,
>>>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>>>>>>>>> +};
>>>>>>>>>>> +
>>>>>>>>>>> +static const struct omap_mbox_device_data omap3_data = {
>>>>>>>>>>> + .num_users = 2,
>>>>>>>>>>> + .num_fifos = 2,
>>>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>>>>>>>>> +};
>>>>>>>>>>> +
>>>>>>>>>>> +static const struct omap_mbox_device_data am335x_data = {
>>>>>>>>>>> + .num_users = 4,
>>>>>>>>>>> + .num_fifos = 8,
>>>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
>>>>>>>>>>> +};
>>>>>>>>>>
>>>>
>>>>>> Aha, ok, then the intr_type should be derived from
>>>>>> compatible-string. Or rather... you should have three
>>>>>> compatible-strings for the three possibilities? (And then subtype,
>>>>>> currently unused, in case there are more hw differences).
>>>>>
>>>>> The compatible string can and should be separate for each revision
>>>>> unless they are the same exacat hardware revision.
>>>>
>>>> ACK.
>>
>> I checked the revision register from all SoCs. OMAP2 and OMAP3 have
>> different revisions compared to OMAP4+. All of OMAP4, OMAP5, DRA7,
>> AM335x and AM437x have the same version, but with different num-fifos
>> and num-users. So, I can switch back to using omap4-mailbox for all of
>> these SoCs only if we encode the num-fifos and num-users in DT.
>>
>>>>
>>>>>>> two are HW IP design parameters, so in general putting them in DT isn't
>>>>>>> completely a bad idea, but I will wait to see if there are any further
>>>>>>> comments on this from Tony or DT maintainers before I make changes.
>>>>>>
>>>>>> Ok, right... I'd vote for putting them into DT.
>>>>>
>>>>> I would avoid adding custom DT properties where possible and let the
>>>>> driver just initialize the right data based on the compatible flag.
>>>>
>>>> If these are HW IP design parameters, we can expect to see many
>>>> different combinations. Yet we know ahead of time how to handle
>>>> different parameters HW people select.
>>
>> That's right, the above OMAP4+ SoCs already demonstrate this behavior.
>>
>>>>
>>>> Thus IMO we should do it in the device tree.
>>>
>>> Oh you mean from supporting new hardware with just .dts changes?
>>> From that point of view it makes sense to have them as DT properties,
>>> so I'm fine with that.
>>>
>>> Let's just try to use something that's generic like fifosize. No idea
>>> how the property for num_fifos should be handled though as that
>>> implies some knowledge in the driver which num_users have fifos?
>>
>> The fifos are not per num_users, but rather the total number of fifos
>> within the IP block. The num_users will be the number of targets the IP
>> block can interrupt. I tried looking for generic properties, but there
>> weren't any that seem to fit the description. If you want generic names,
>> I can use num-fifos and num-users, otherwise will stick to the
>> names defined in the previous series.
>
> OK since we already have some .dts entries with ti,mbox-num-fifos and
> ti,mbox-num-users I'd use those for now. Adding parsing for a generic
> property can be done later on.
Alright, will stick to the existing properties.
>
>>> So unless that can be described clearly in a DT property as well,
>>> the binding might be still unusable for new hardware :)
>>>
>>
>> I don't expect the OMAP mailbox IP to change much in the future. There
>> is a FIFO depth parameter as well, but that's constant in all the
>> current versions, and even if they change it, I can already use the
>> generic property for that.
>
> OK
>
>> Tony,
>> Depending on the agreement here, I may have to respin the OMAP
>> mailbox DT/hwmod cleanup series [1]
>
> OK let me know.
I will refresh both this series and the mailbox DT/hwmod cleanup with
these changes, and post the patches tomorrow.
regards
Suman
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-07-09 15:15 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-07-09 15:15 UTC (permalink / raw)
To: Tony Lindgren
Cc: Pavel Machek, Jassi Brar, Dave Gerlach, linux-kernel, linux-omap,
devicetree, linux-arm-kernel, Jassi Brar, Rob Herring
On 07/09/2014 03:29 AM, Tony Lindgren wrote:
> * Suman Anna <s-anna@ti.com> [140708 10:57]:
>> Hi Tony, Pavel,
>>
>> On 07/04/2014 03:23 AM, Tony Lindgren wrote:
>>> * Pavel Machek <pavel@ucw.cz> [140704 01:07]:
>>>> Hi!
>>>>
>>>>>>>>>>> The non-DT support has to be maintained for now to not break
>>>>>>>>>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
>>>>>>>>>>> up once OMAP3 is also converted to DT-boot only.
>>>>>>>>>>
>>>>>>>>>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
>>>>>>>>>>> return 0;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> +static const struct omap_mbox_device_data omap2_data = {
>>>>>>>>>>> + .num_users = 4,
>>>>>>>>>>> + .num_fifos = 6,
>>>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>>>>>>>>> +};
>>>>>>>>>>> +
>>>>>>>>>>> +static const struct omap_mbox_device_data omap3_data = {
>>>>>>>>>>> + .num_users = 2,
>>>>>>>>>>> + .num_fifos = 2,
>>>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>>>>>>>>> +};
>>>>>>>>>>> +
>>>>>>>>>>> +static const struct omap_mbox_device_data am335x_data = {
>>>>>>>>>>> + .num_users = 4,
>>>>>>>>>>> + .num_fifos = 8,
>>>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
>>>>>>>>>>> +};
>>>>>>>>>>
>>>>
>>>>>> Aha, ok, then the intr_type should be derived from
>>>>>> compatible-string. Or rather... you should have three
>>>>>> compatible-strings for the three possibilities? (And then subtype,
>>>>>> currently unused, in case there are more hw differences).
>>>>>
>>>>> The compatible string can and should be separate for each revision
>>>>> unless they are the same exacat hardware revision.
>>>>
>>>> ACK.
>>
>> I checked the revision register from all SoCs. OMAP2 and OMAP3 have
>> different revisions compared to OMAP4+. All of OMAP4, OMAP5, DRA7,
>> AM335x and AM437x have the same version, but with different num-fifos
>> and num-users. So, I can switch back to using omap4-mailbox for all of
>> these SoCs only if we encode the num-fifos and num-users in DT.
>>
>>>>
>>>>>>> two are HW IP design parameters, so in general putting them in DT isn't
>>>>>>> completely a bad idea, but I will wait to see if there are any further
>>>>>>> comments on this from Tony or DT maintainers before I make changes.
>>>>>>
>>>>>> Ok, right... I'd vote for putting them into DT.
>>>>>
>>>>> I would avoid adding custom DT properties where possible and let the
>>>>> driver just initialize the right data based on the compatible flag.
>>>>
>>>> If these are HW IP design parameters, we can expect to see many
>>>> different combinations. Yet we know ahead of time how to handle
>>>> different parameters HW people select.
>>
>> That's right, the above OMAP4+ SoCs already demonstrate this behavior.
>>
>>>>
>>>> Thus IMO we should do it in the device tree.
>>>
>>> Oh you mean from supporting new hardware with just .dts changes?
>>> From that point of view it makes sense to have them as DT properties,
>>> so I'm fine with that.
>>>
>>> Let's just try to use something that's generic like fifosize. No idea
>>> how the property for num_fifos should be handled though as that
>>> implies some knowledge in the driver which num_users have fifos?
>>
>> The fifos are not per num_users, but rather the total number of fifos
>> within the IP block. The num_users will be the number of targets the IP
>> block can interrupt. I tried looking for generic properties, but there
>> weren't any that seem to fit the description. If you want generic names,
>> I can use num-fifos and num-users, otherwise will stick to the
>> names defined in the previous series.
>
> OK since we already have some .dts entries with ti,mbox-num-fifos and
> ti,mbox-num-users I'd use those for now. Adding parsing for a generic
> property can be done later on.
Alright, will stick to the existing properties.
>
>>> So unless that can be described clearly in a DT property as well,
>>> the binding might be still unusable for new hardware :)
>>>
>>
>> I don't expect the OMAP mailbox IP to change much in the future. There
>> is a FIFO depth parameter as well, but that's constant in all the
>> current versions, and even if they change it, I can already use the
>> generic property for that.
>
> OK
>
>> Tony,
>> Depending on the agreement here, I may have to respin the OMAP
>> mailbox DT/hwmod cleanup series [1]
>
> OK let me know.
I will refresh both this series and the mailbox DT/hwmod cleanup with
these changes, and post the patches tomorrow.
regards
Suman
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 2/6] mailbox/omap: add support for parsing dt devices
@ 2014-07-09 15:15 ` Suman Anna
0 siblings, 0 replies; 53+ messages in thread
From: Suman Anna @ 2014-07-09 15:15 UTC (permalink / raw)
To: linux-arm-kernel
On 07/09/2014 03:29 AM, Tony Lindgren wrote:
> * Suman Anna <s-anna@ti.com> [140708 10:57]:
>> Hi Tony, Pavel,
>>
>> On 07/04/2014 03:23 AM, Tony Lindgren wrote:
>>> * Pavel Machek <pavel@ucw.cz> [140704 01:07]:
>>>> Hi!
>>>>
>>>>>>>>>>> The non-DT support has to be maintained for now to not break
>>>>>>>>>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
>>>>>>>>>>> up once OMAP3 is also converted to DT-boot only.
>>>>>>>>>>
>>>>>>>>>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
>>>>>>>>>>> return 0;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> +static const struct omap_mbox_device_data omap2_data = {
>>>>>>>>>>> + .num_users = 4,
>>>>>>>>>>> + .num_fifos = 6,
>>>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>>>>>>>>> +};
>>>>>>>>>>> +
>>>>>>>>>>> +static const struct omap_mbox_device_data omap3_data = {
>>>>>>>>>>> + .num_users = 2,
>>>>>>>>>>> + .num_fifos = 2,
>>>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE1,
>>>>>>>>>>> +};
>>>>>>>>>>> +
>>>>>>>>>>> +static const struct omap_mbox_device_data am335x_data = {
>>>>>>>>>>> + .num_users = 4,
>>>>>>>>>>> + .num_fifos = 8,
>>>>>>>>>>> + .intr_type = MBOX_INTR_CFG_TYPE2,
>>>>>>>>>>> +};
>>>>>>>>>>
>>>>
>>>>>> Aha, ok, then the intr_type should be derived from
>>>>>> compatible-string. Or rather... you should have three
>>>>>> compatible-strings for the three possibilities? (And then subtype,
>>>>>> currently unused, in case there are more hw differences).
>>>>>
>>>>> The compatible string can and should be separate for each revision
>>>>> unless they are the same exacat hardware revision.
>>>>
>>>> ACK.
>>
>> I checked the revision register from all SoCs. OMAP2 and OMAP3 have
>> different revisions compared to OMAP4+. All of OMAP4, OMAP5, DRA7,
>> AM335x and AM437x have the same version, but with different num-fifos
>> and num-users. So, I can switch back to using omap4-mailbox for all of
>> these SoCs only if we encode the num-fifos and num-users in DT.
>>
>>>>
>>>>>>> two are HW IP design parameters, so in general putting them in DT isn't
>>>>>>> completely a bad idea, but I will wait to see if there are any further
>>>>>>> comments on this from Tony or DT maintainers before I make changes.
>>>>>>
>>>>>> Ok, right... I'd vote for putting them into DT.
>>>>>
>>>>> I would avoid adding custom DT properties where possible and let the
>>>>> driver just initialize the right data based on the compatible flag.
>>>>
>>>> If these are HW IP design parameters, we can expect to see many
>>>> different combinations. Yet we know ahead of time how to handle
>>>> different parameters HW people select.
>>
>> That's right, the above OMAP4+ SoCs already demonstrate this behavior.
>>
>>>>
>>>> Thus IMO we should do it in the device tree.
>>>
>>> Oh you mean from supporting new hardware with just .dts changes?
>>> From that point of view it makes sense to have them as DT properties,
>>> so I'm fine with that.
>>>
>>> Let's just try to use something that's generic like fifosize. No idea
>>> how the property for num_fifos should be handled though as that
>>> implies some knowledge in the driver which num_users have fifos?
>>
>> The fifos are not per num_users, but rather the total number of fifos
>> within the IP block. The num_users will be the number of targets the IP
>> block can interrupt. I tried looking for generic properties, but there
>> weren't any that seem to fit the description. If you want generic names,
>> I can use num-fifos and num-users, otherwise will stick to the
>> names defined in the previous series.
>
> OK since we already have some .dts entries with ti,mbox-num-fifos and
> ti,mbox-num-users I'd use those for now. Adding parsing for a generic
> property can be done later on.
Alright, will stick to the existing properties.
>
>>> So unless that can be described clearly in a DT property as well,
>>> the binding might be still unusable for new hardware :)
>>>
>>
>> I don't expect the OMAP mailbox IP to change much in the future. There
>> is a FIFO depth parameter as well, but that's constant in all the
>> current versions, and even if they change it, I can already use the
>> generic property for that.
>
> OK
>
>> Tony,
>> Depending on the agreement here, I may have to respin the OMAP
>> mailbox DT/hwmod cleanup series [1]
>
> OK let me know.
I will refresh both this series and the mailbox DT/hwmod cleanup with
these changes, and post the patches tomorrow.
regards
Suman
^ permalink raw reply [flat|nested] 53+ messages in thread
end of thread, other threads:[~2014-07-09 15:16 UTC | newest]
Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-25 1:47 [PATCH 0/6] OMAP Mailbox framework adoption & DT support Suman Anna
2014-06-25 1:47 ` Suman Anna
2014-06-25 1:47 ` Suman Anna
2014-06-25 1:47 ` [PATCH 1/6] Documentation: dt: add omap mailbox bindings Suman Anna
2014-06-25 1:47 ` Suman Anna
2014-06-25 1:47 ` Suman Anna
2014-06-25 1:47 ` [PATCH 2/6] mailbox/omap: add support for parsing dt devices Suman Anna
2014-06-25 1:47 ` Suman Anna
2014-06-25 1:47 ` Suman Anna
2014-06-28 17:07 ` Pavel Machek
2014-06-28 17:07 ` Pavel Machek
2014-06-30 16:00 ` Suman Anna
2014-06-30 16:00 ` Suman Anna
2014-06-30 16:00 ` Suman Anna
2014-06-30 18:59 ` Pavel Machek
2014-06-30 18:59 ` Pavel Machek
2014-06-30 19:34 ` Suman Anna
2014-06-30 19:34 ` Suman Anna
2014-06-30 19:34 ` Suman Anna
2014-06-30 20:32 ` Pavel Machek
2014-06-30 20:32 ` Pavel Machek
2014-06-30 20:32 ` Pavel Machek
2014-07-04 6:45 ` Tony Lindgren
2014-07-04 6:45 ` Tony Lindgren
2014-07-04 8:05 ` Pavel Machek
2014-07-04 8:05 ` Pavel Machek
2014-07-04 8:23 ` Tony Lindgren
2014-07-04 8:23 ` Tony Lindgren
2014-07-04 8:23 ` Tony Lindgren
2014-07-08 17:55 ` Suman Anna
2014-07-08 17:55 ` Suman Anna
2014-07-08 17:55 ` Suman Anna
2014-07-09 8:29 ` Tony Lindgren
2014-07-09 8:29 ` Tony Lindgren
2014-07-09 8:29 ` Tony Lindgren
2014-07-09 15:15 ` Suman Anna
2014-07-09 15:15 ` Suman Anna
2014-07-09 15:15 ` Suman Anna
2014-06-25 1:47 ` [PATCH 3/6] ARM: dts: OMAP2+: Add sub mailboxes device node information Suman Anna
2014-06-25 1:47 ` Suman Anna
2014-06-25 1:47 ` [PATCH 4/6] mailbox/omap: adapt to the new mailbox framework Suman Anna
2014-06-25 1:47 ` Suman Anna
2014-06-25 1:47 ` Suman Anna
2014-06-25 1:47 ` [PATCH 5/6] ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes Suman Anna
2014-06-25 1:47 ` Suman Anna
2014-06-25 1:47 ` [PATCH 6/6] mailbox/omap: add a custom of_xlate function Suman Anna
2014-06-25 1:47 ` Suman Anna
2014-06-25 1:47 ` Suman Anna
2014-06-25 8:39 ` Arnd Bergmann
2014-06-25 8:39 ` Arnd Bergmann
2014-06-25 16:32 ` Suman Anna
2014-06-25 16:32 ` Suman Anna
2014-06-25 16:32 ` Suman Anna
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.