[PATCHv2 5/5] ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes
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 bcous...@baylibre.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Suman Anna s-a...@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 e4f165a..5663ff5 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;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
mbox_wkupm3: wkup_m3 {
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 3be2a87..8619519 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;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
mbox_wkupm3: wkup_m3 {
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 99c40d4..626137f 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;
ti,mbox-num-users = 3;
ti,mbox-num-fifos = 8;
status = disabled;
@@ -351,6 +352,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4883a000 0x200;
ti,hwmods = mailbox2;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -360,6 +362,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4883c000 0x200;
ti,hwmods = mailbox3;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -369,6 +372,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4883e000 0x200;
ti,hwmods = mailbox4;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -378,6 +382,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4884 0x200;
ti,hwmods = mailbox5;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -387,6 +392,7 @@
compatible = ti,omap4-mailbox;
reg = 0x48842000 0x200;
ti,hwmods = mailbox6;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -396,6 +402,7 @@
compatible = ti,omap4-mailbox;
reg = 0x48844000 0x200;
ti,hwmods = mailbox7;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -405,6 +412,7 @@
compatible = ti,omap4-mailbox;
reg = 0x48846000 0x200;
ti,hwmods = mailbox8;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -414,6 +422,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4885e000 0x200;
ti,hwmods = mailbox9;
+ #mbox-cells = 1
[PATCHv2 4/5] mailbox/omap: adapt to the new mailbox framework
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 OMAP mailbox driver uses a custom of_xlate controller ops that
allows phandles for the pargs specifier instead of indexing to avoid
any channel registration order dependencies.
- 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 jassisinghb...@gmail.com
Cc: Ohad Ben-Cohen o...@wizery.com
Cc: Omar Ramirez Luna omar.rami...@copitl.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/mailbox/omap-mailbox.txt | 24 ++
drivers/mailbox/omap-mailbox.c | 343 -
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 +-
10 files changed, 281 insertions(+), 203 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
index 31fe01d..16379e9 100644
--- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -47,6 +47,9 @@ Required properties:
device. The format is dependent on which interrupt
controller the OMAP device uses
- ti,hwmods: Name of the hwmod associated with the mailbox
+- #mbox-cells: Common mailbox binding property to identify the number
+ of cells required for the mailbox specifier. Should be
+ 1
- ti,mbox-num-users: Number of targets (processor devices) that the mailbox
device can interrupt
- ti,mbox-num-fifos: Number of h/w fifo queues within the mailbox IP block
@@ -75,6 +78,18 @@ data that represent the following:
Cell #3 (usr_id) - mailbox user id for identifying the interrupt line
associated with generating a tx/rx fifo interrupt.
+Mailbox Users:
+==
+A device needing to communicate with a target processor device should specify
+them using the common mailbox binding properties, mbox and mbox-names
+(please see Documentation/devicetree/bindings/mailbox/mailbox.txt for details).
+Each value of mbox should contain a phandle to the mailbox controller device
+node and an args specifier that will be the phandle to the intended sub-mailbox
+child node to be used for communication. The equivalent mbox-names property
+value is used to give a name to the communication channel to be used by the
+client user.
+
+
Example:
@@ -84,6 +99,7 @@ mailbox: mailbox@4a0f4000 {
reg = 0x4a0f4000 0x200;
interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox;
+ #mbox-cells = 1;
ti,mbox-num-users = 3;
ti,mbox-num-fifos = 8;
mbox_ipu: mbox_ipu {
@@ -102,6 +118,7
[PATCHv2 1/5] Documentation: dt: add omap mailbox bindings
Add the device tree bindings document for OMAP2+ mailbox. Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/mailbox/omap-mailbox.txt | 111 + 1 file changed, 111 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 000..31fe01d --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt @@ -0,0 +1,111 @@ +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 +- ti,mbox-num-users: Number of targets (processor devices) that the mailbox + device can interrupt +- ti,mbox-num-fifos: Number of h/w fifo queues within the mailbox IP block + +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
[PATCHv2 2/5] mailbox/omap: add support for parsing dt devices
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 jassisinghb...@gmail.com
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/mailbox/omap-mailbox.c | 156 ++---
1 file changed, 132 insertions(+), 24 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index a27e00e..73eb0fb 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,18 @@ 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 {
const char *name;
int irq;
@@ -587,24 +600,118 @@ static int omap_mbox_unregister(struct omap_mbox_device
*mdev)
return 0;
}
+static const struct of_device_id omap_mailbox_of_match[] = {
+ {
+ .compatible = ti,omap2-mailbox,
+ .data = (void *)MBOX_INTR_CFG_TYPE1,
+ },
+ {
+ .compatible = ti,omap3-mailbox,
+ .data = (void *)MBOX_INTR_CFG_TYPE1,
+ },
+ {
+ .compatible = ti,omap4-mailbox,
+ .data = (void *)MBOX_INTR_CFG_TYPE2,
+ },
+ {
+ /* 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_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;
+ intr_type = (u32)match-data;
+
+ if (of_property_read_u32(node, ti,mbox-num-users,
+num_users))
+ return -ENODEV;
+
+ if (of_property_read_u32(node, ti,mbox-num-fifos,
+num_fifos))
+ return -ENODEV;
+
+ info_count = of_get_available_child_count(node);
+ if (!info_count) {
+ dev_err(pdev-dev, no available mbox devices
found\n);
+ return -ENODEV;
+ }
+ } 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
Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
On 07/09/2014 03:29 AM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [140708 10:57]:
Hi Tony, Pavel,
On 07/04/2014 03:23 AM, Tony Lindgren wrote:
* Pavel Machek pa...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
Hi Ohad, On 07/04/2014 12:01 AM, Ohad Ben-Cohen wrote: Hi Suman, On Thu, Jul 3, 2014 at 8:28 PM, Suman Anna s-a...@ti.com wrote: OK, but we would still require this function to lookup the registered device from the controller-phandle to retrieve the base_id. Can we retrieve the base_id from the parent DT node itself? Yeah, it is possible using the of_hwspin_lock_get_base_id function added in Patch8, once we convert the phandle to a device node. The platform implementations would be using this function during the registration phase to register the base id, and we have to do the DT parse/lookup again in the core. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
Hi Ohad, On 07/03/2014 11:58 PM, Ohad Ben-Cohen wrote: Hi Suman, On Thu, Jul 3, 2014 at 8:35 PM, Suman Anna s-a...@ti.com wrote: Not at the moment, with the existing platform implementations. So, if I understand you correctly, you are asking to leave out the xlate ops and make the of_hwspin_lock_simple_xlate() internal until a need for an xlate method arises. Yes, please. It seems to me this way we're reducing complexity without compromising anything. OK, will make this change and add a comment in the code in the next version. This also means, we only support a value of 1 for #hwlock-cells. When a different #hwlock-cells value shows up, someone would have to write a new xlate implementation anyway. At the same time, the xlate ops could be brought back quite easily. Since we're not imposing anything on the DT data, this doesn't affect our ability to support these scenarios in the future, but unless I'm missing a current use case, these scenarios right now seems somewhat fictional. OK, fair enough. But, that would mean DT-based client users would have to invoke two function calls to request a hwspinlock. We already have an API to get the lock id given a hwspinlock - hwspin_lock_get_id(), so I added the OF API for requesting a lock directly rather than giving an OF API for getting the lock id. This is in keeping in convention with what other drivers do normally - a regular get and an OF get. I can modify it if you still prefer the OF API for getting a global lock id, but I feel its a burden for client users. Let's discuss this. I was actually thinking of the more general use case of an heterogenous system: - driver gets the global lock id from a remote processor - driver then requests the specific lock Looking at these cases, the OF scenario only differs in the small part of fetching the lock id, and if we keep the regular request_specific API we'll have more common code between drivers. What do you think? We should also be thinking about the how to add the support for the reserved locks. Please take a look at the added RFC patches 9 through 13, specifically the reworked Patch 12 [1]. I moved away from adding a reserved property to the controller node, as it means updating both controller and client nodes. Depending on where we enforce the check (in the OF API or in the common request_specific, the behavior would change. Also, do you prefer an open property-name in client users (like I am doing at the moment) or imposing a standard property name hwlocks? Good point - I think we can start with an imposed hwlocks name, and evolve in the future as needed (again, only because we're not really imposing anything on the DT data - this is just kernel code that we could always extend as needed). OK. Actually, I didn't realize that I had already made this change as part of the reserved locks RFC patch. regards Suman [1] http://marc.info/?l=linux-omapm=139968467307977w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] remoteproc: use a flag to detect the presence of IOMMU
The remoteproc driver core currently relies on iommu_present() on
the bus the device is on, to perform MMU management. However, this
logic doesn't scale for multi-arch, especially for processors that
do not have an IOMMU. Replace this logic instead by using a h/w
capability flag for the presence of IOMMU in the rproc structure.
The individual platform implementations are required to set this
flag appropriately. The default setting is to not have an MMU.
The OMAP remoteproc driver is updated while at this, to maintain
the functionality with the IOMMU detection logic change in this
patch.
Cc: Sjur Brændeland sjur.brandel...@stericsson.com
Cc: Robert Tivy rt...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/remoteproc/omap_remoteproc.c | 6 ++
drivers/remoteproc/remoteproc_core.c | 15 ++-
include/linux/remoteproc.h | 2 ++
3 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index 5168972..858abf0 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -199,6 +199,12 @@ static int omap_rproc_probe(struct platform_device *pdev)
oproc = rproc-priv;
oproc-rproc = rproc;
+ /*
+* All existing OMAP IPU and DSP processors do have an MMU, and
+* are expected to use MMU, so this statement suffices.
+* XXX: Replace this logic if and when a need arises.
+*/
+ rproc-has_iommu = true;
platform_set_drvdata(pdev, rproc);
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 3cd85a6..11cdb11 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -94,19 +94,8 @@ static int rproc_enable_iommu(struct rproc *rproc)
struct device *dev = rproc-dev.parent;
int ret;
- /*
-* We currently use iommu_present() to decide if an IOMMU
-* setup is needed.
-*
-* This works for simple cases, but will easily fail with
-* platforms that do have an IOMMU, but not for this specific
-* rproc.
-*
-* This will be easily solved by introducing hw capabilities
-* that will be set by the remoteproc driver.
-*/
- if (!iommu_present(dev-bus)) {
- dev_dbg(dev, iommu not found\n);
+ if (!rproc-has_iommu) {
+ dev_dbg(dev, iommu not present\n);
return 0;
}
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 9e7e745..78b8a9b 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -404,6 +404,7 @@ enum rproc_crash_type {
* @table_ptr: pointer to the resource table in effect
* @cached_table: copy of the resource table
* @table_csum: checksum of the resource table
+ * @has_iommu: flag to indicate if remote processor is behind an MMU
*/
struct rproc {
struct klist_node node;
@@ -435,6 +436,7 @@ struct rproc {
struct resource_table *table_ptr;
struct resource_table *cached_table;
u32 table_csum;
+ bool has_iommu;
};
/* we currently support only two vrings per rvdev */
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] remoteproc: add support to handle internal memories
A remote processor may need to load certain firmware sections into
internal memories (eg: RAM at L1 or L2 levels) for performance or
other reasons. Introduce a new resource type (RSC_INTMEM) and add
an associated handler function to handle such memories. The handler
creates a kernel mapping for the resource's 'pa' (physical address).
Note that no iommu mapping is performed for this resource, as the
resource is primarily used to represent physical internal memories.
If the internal memory region can only be accessed through an iommu,
a devmem resource entry should be used instead.
Signed-off-by: Robert Tivy rt...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/remoteproc/remoteproc_core.c | 85 +++-
include/linux/remoteproc.h | 43 +-
2 files changed, 126 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 11cdb11..e2bd869 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -664,6 +664,84 @@ free_carv:
return ret;
}
+/**
+ * rproc_handle_intmem() - handle internal memory resource entry
+ * @rproc: rproc handle
+ * @rsc: the intmem resource entry
+ * @offset: offset of the resource data in resource table
+ * @avail: size of available data (for image validation)
+ *
+ * This function will handle firmware requests for mapping a memory region
+ * internal to a remote processor into kernel. It neither allocates any
+ * physical pages, nor performs any iommu mapping, as this resource entry
+ * is primarily used for representing physical internal memories. If the
+ * internal memory region can only be accessed through an iommu, please
+ * use a devmem resource entry.
+ *
+ * These resource entries should be grouped near the carveout entries in
+ * the firmware's resource table, as other firmware entries might request
+ * placing other data objects inside these memory regions (e.g. data/code
+ * segments, trace resource entries, ...).
+ */
+static int rproc_handle_intmem(struct rproc *rproc, struct fw_rsc_intmem *rsc,
+ int offset, int avail)
+{
+ struct rproc_mem_entry *intmem;
+ struct device *dev = rproc-dev;
+ void *va;
+ int ret;
+
+ if (sizeof(*rsc) avail) {
+ dev_err(dev, intmem rsc is truncated\n);
+ return -EINVAL;
+ }
+
+ if (rsc-version != 1) {
+ dev_err(dev, intmem rsc version %d is not supported\n,
+ rsc-version);
+ return -EINVAL;
+ }
+
+ if (rsc-reserved) {
+ dev_err(dev, intmem rsc has non zero reserved bytes\n);
+ return -EINVAL;
+ }
+
+ dev_dbg(dev, intmem rsc: da 0x%x, pa 0x%x, len 0x%x\n,
+ rsc-da, rsc-pa, rsc-len);
+
+ intmem = kzalloc(sizeof(*intmem), GFP_KERNEL);
+ if (!intmem) {
+ dev_err(dev, kzalloc carveout failed\n);
+ return -ENOMEM;
+ }
+
+ va = (__force void *)ioremap_nocache(rsc-pa, rsc-len);
+ if (!va) {
+ dev_err(dev, ioremap_nocache err: %d\n, rsc-len);
+ ret = -ENOMEM;
+ goto free_intmem;
+ }
+
+ dev_dbg(dev, intmem mapped pa 0x%x of len 0x%x into kernel va %p\n,
+ rsc-pa, rsc-len, va);
+
+ intmem-va = va;
+ intmem-len = rsc-len;
+ intmem-dma = rsc-pa;
+ intmem-da = rsc-da;
+ intmem-priv = (void *)1;/* prevents freeing */
+
+ /* reuse the rproc-carveouts list, so that loading is automatic */
+ list_add_tail(intmem-node, rproc-carveouts);
+
+ return 0;
+
+free_intmem:
+ kfree(intmem);
+ return ret;
+}
+
static int rproc_count_vrings(struct rproc *rproc, struct fw_rsc_vdev *rsc,
int offset, int avail)
{
@@ -681,6 +759,7 @@ static rproc_handle_resource_t
rproc_loading_handlers[RSC_LAST] = {
[RSC_CARVEOUT] = (rproc_handle_resource_t)rproc_handle_carveout,
[RSC_DEVMEM] = (rproc_handle_resource_t)rproc_handle_devmem,
[RSC_TRACE] = (rproc_handle_resource_t)rproc_handle_trace,
+ [RSC_INTMEM] = (rproc_handle_resource_t)rproc_handle_intmem,
[RSC_VDEV] = NULL, /* VDEVs were handled upon registrarion */
};
@@ -768,7 +847,11 @@ static void rproc_resource_cleanup(struct rproc *rproc)
/* clean up carveout allocations */
list_for_each_entry_safe(entry, tmp, rproc-carveouts, node) {
- dma_free_coherent(dev-parent, entry-len, entry-va,
entry-dma);
+ if (!entry-priv)
+ dma_free_coherent(dev-parent, entry-len, entry-va,
+ entry-dma);
+ else
+ iounmap((__force void __iomem *)entry-va);
list_del(entry-node);
kfree(entry);
}
diff --git a/include/linux
[PATCH 0/2] couple of generic remoteproc enhancements
Hi Ohad, The following are couple of generic enhancements to the remoteproc core. The changes are developed to support adding new rproc drivers for processors like the WkupM3 processor on AM335/AM437, but are generic enough to apply to non-OMAP devices as well. The first patch allows MMU-enabled processors like OMAP IPU/DSP as well as other non-MMU enabled processors on multi-arch kernel images. The second-patch was developed as part of enabling internal memory loading of firmware segments on OMAP DSPs, but will also be used by the WkupM3 remoteproc driver that Dave Gerlach is gonna submit soon. The two patches are based on 3.16-rc4 and are technically independent of each other, but submitting them together as the WkupM3 remoteproc driver would need both of them. regards Suman Suman Anna (2): remoteproc: use a flag to detect the presence of IOMMU remoteproc: add support to handle internal memories drivers/remoteproc/omap_remoteproc.c | 6 +++ drivers/remoteproc/remoteproc_core.c | 100 ++- include/linux/remoteproc.h | 45 +++- 3 files changed, 136 insertions(+), 15 deletions(-) -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
Hi Tony, Pavel,
On 07/04/2014 03:23 AM, Tony Lindgren wrote:
* Pavel Machek pa...@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-omapm=140365833121612w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Anybody working on tidspbridge?
Hi Peter, On 07/08/2014 09:36 AM, Greg KH wrote: On Tue, Jul 08, 2014 at 03:03:58PM +0200, Peter Meerwald wrote: Hello, Given the total lack of response here, I suggest just deleting the driver. No one has ever done the real work that is going to be required to get this code out of staging. It has had build errors causing it to not even be usable for some kernel versions with no one noticing, so I doubt anyone cares about it anymore here. Cc'ing some more people who might be interested. If no one offers to work on the driver in the next couple of days, I'll send a patch to remove it. I'm using the driver (with kernel 3.7) and it works reasonably well for me; removing it seems a bit harsh. Using it is different from being able to maintain the code and move it out of the staging tree. Also, 3.7 is really old and obsolete, not much we can do with that kernel version :) Are you able to work on the code and do the effort needed to get it out of the staging tree? If so, great, if not, we are going to have to delete it, sorry. I agree with Greg here. In fact, the current TODO does not do enough justice to the amount of work required to make it even work on the latest kernel. Most of the TIers who worked on this driver have moved on as Kristina would have figured with her bounced emails. So I do suggest that this driver be deleted from the kernel tree. If there are enough number of folks using it (not sure how many are out there), it can be worked on out-of-tree and brought back in a cleaner fashion rather than keeping a broken stale driver in the kernel. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
Hi Ohad, On 07/03/2014 02:00 AM, Ohad Ben-Cohen wrote: Hi Suman, On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna s-a...@ti.com wrote: I'm not sure we need this patch. This patch is needed if we use the controller-phandle + args specifier for requesting hwlocks by a client, as we need to translate controller-phandle to the corresponding hwspinlock_device. Looks like we still don't have a closure on the semantics of how clients have to request a lock in DT. You are suggesting something like hwlocks = global_lock1 global_lock2 ...; whereas this patch is built to support based on comments from DT-maintainers, hwlocks = controller-phandle lock-specifier1, controller-phandle lock-specifier2...; I'm actually ok with this suggestion and haven't suggested otherwise. OK, thanks for confirming and sorry for the misinterpretation. All I propose is that we add the base_id property to the controller node (as you have done in the subsequent patches), and then drivers will be able to infer the global lock id from the DT data by adding the controller's base_id to the lock specifier. OK, but we would still require this function to lookup the registered device from the controller-phandle to retrieve the base_id. Do note that the hwspinlock core currently only maintains the registered locks in an integrated radix tree, but not the registered hwspinlock banks themselves. regards Suman Controllers with non standard lock indexing may use an xlate() method if needed but frankly this is fictional right now. We can start without this, and add it later when needed, as this doesn't affect the DT data. With the global lock id in hand, drivers could simply use the existing hwspin_lock_request_specific API to obtain a specific lock, and then we don't need this patch. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
Hi Ohad, On 07/03/2014 02:15 AM, Ohad Ben-Cohen wrote: Hi Suman, On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna s-a...@ti.com wrote: Do we have a use case today that require the xlate() method? If not, let's remove it as we could always add it back if some new hardware shows up that needs it. The xlate() method is to support the phandle + args specifier way of requesting hwlocks, platform implementations are free to implement their own xlate functions, but the above supports the simplest case of controller + relative lock index within controller. Do we have a use case for a different implementation other than the simplest case? If not, it seems to me this will just become redundant boilerplate code (every platform will use the simple xlate method). Not at the moment, with the existing platform implementations. So, if I understand you correctly, you are asking to leave out the xlate ops and make the of_hwspin_lock_simple_xlate() internal until a need for an xlate method arises. This also means, we only support a value of 1 for #hwlock-cells. This function again is to support the phandle + args specifier way of requesting hwlocks, the hwspin_lock_request_specific() is invoked internally within this function, so we are still reusing the actual request code other than handling the DT parsing portion. If we go back to using global locks in client hwlocks property, we don't need a of_hwspin_lock_get_id(), the same can be achieved using the existing DT function, of_property_read_u32_index(). I think you may have misunderstood me, sorry. I'm ok with the phandle + args specifier. I just think we can use it, together with the base_id property, to infer the global lock id from the DT data. Aah ok, its minor code rearrangement for what you are asking - I just need to leave out invoking the request_specific invocation in the OF request specific existing function, just return the global id and let the client users call the normal request_specific API themselves. But, that would mean DT-based client users would have to invoke two function calls to request a hwspinlock. We already have an API to get the lock id given a hwspinlock - hwspin_lock_get_id(), so I added the OF API for requesting a lock directly rather than giving an OF API for getting the lock id. This is in keeping in convention with what other drivers do normally - a regular get and an OF get. I can modify it if you still prefer the OF API for getting a global lock id, but I feel its a burden for client users. Also, do you prefer an open property-name in client users (like I am doing at the moment) or imposing a standard property name hwlocks? regards Suman This is not only a must to support heterogenous multi-processing systems, it will also substantially simplify the code. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rpmsg: compute number of buffers to allocate from vrings
The buffers to be used for communication are allocated during
the rpmsg virtio driver's probe, and the number of buffers is
currently hard-coded to 512. Remove this hard-coded value, as
this can vary from one platform to another or between different
remote processors. Instead, rely on the number of buffers the
virtqueue vring is setup with in the first place.
This fixes the WARN_ON during the setup of the receive buffers
for vrings with buffers less than 512.
NOTE: The number of buffers is already assumed to be symmetrical
in each direction, and that logic is not unchanged.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/rpmsg/virtio_rpmsg_bus.c | 41 +---
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index b6135d4..e9866a6 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -41,6 +41,7 @@
* @svq: tx virtqueue
* @rbufs: kernel address of rx buffers
* @sbufs: kernel address of tx buffers
+ * @num_bufs: total number of buffers for rx and tx
* @last_sbuf: index of last tx buffer used
* @bufs_dma: dma base addr of the buffers
* @tx_lock: protects svq, sbufs and sleepers, to allow concurrent senders.
@@ -60,6 +61,7 @@ struct virtproc_info {
struct virtio_device *vdev;
struct virtqueue *rvq, *svq;
void *rbufs, *sbufs;
+ unsigned int num_bufs;
int last_sbuf;
dma_addr_t bufs_dma;
struct mutex tx_lock;
@@ -86,14 +88,14 @@ struct rpmsg_channel_info {
#define to_rpmsg_driver(d) container_of(d, struct rpmsg_driver, drv)
/*
- * We're allocating 512 buffers of 512 bytes for communications, and then
- * using the first 256 buffers for RX, and the last 256 buffers for TX.
+ * We're allocating buffers of 512 bytes each for communications. The
+ * number of buffers are computed from the number of buffers supported
+ * by the virtqueue vring and then use the first half of those buffers
+ * for RX, and the last half buffers for TX.
*
* Each buffer will have 16 bytes for the msg header and 496 bytes for
* the payload.
*
- * This will require a total space of 256KB for the buffers.
- *
* We might also want to add support for user-provided buffers in time.
* This will allow bigger buffer size flexibility, and can also be used
* to achieve zero-copy messaging.
@@ -102,9 +104,7 @@ struct rpmsg_channel_info {
* can change this without changing anything in the firmware of the remote
* processor.
*/
-#define RPMSG_NUM_BUFS (512)
#define RPMSG_BUF_SIZE (512)
-#define RPMSG_TOTAL_BUF_SPACE (RPMSG_NUM_BUFS * RPMSG_BUF_SIZE)
/*
* Local addresses are dynamically allocated on-demand.
@@ -579,7 +579,7 @@ static void *get_a_tx_buf(struct virtproc_info *vrp)
* either pick the next unused tx buffer
* (half of our buffers are used for sending messages)
*/
- if (vrp-last_sbuf RPMSG_NUM_BUFS / 2)
+ if (vrp-last_sbuf vrp-num_bufs / 2)
ret = vrp-sbufs + RPMSG_BUF_SIZE * vrp-last_sbuf++;
/* or recycle a used one */
else
@@ -948,6 +948,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
struct virtproc_info *vrp;
void *bufs_va;
int err = 0, i;
+ size_t total_buf_space;
vrp = kzalloc(sizeof(*vrp), GFP_KERNEL);
if (!vrp)
@@ -968,10 +969,19 @@ static int rpmsg_probe(struct virtio_device *vdev)
vrp-rvq = vqs[0];
vrp-svq = vqs[1];
+ /*
+* We expect equal number of buffers for each direction as per current
+* code, so throw a warning if the configuration doesn't match. This can
+* easily be adjusted if needed.
+*/
+ vrp-num_bufs = virtqueue_get_vring_size(vrp-rvq) * 2;
+ WARN_ON(virtqueue_get_vring_size(vrp-svq) != (vrp-num_bufs / 2));
+ total_buf_space = vrp-num_bufs * RPMSG_BUF_SIZE;
+
/* allocate coherent memory for the buffers */
bufs_va = dma_alloc_coherent(vdev-dev.parent-parent,
- RPMSG_TOTAL_BUF_SPACE,
- vrp-bufs_dma, GFP_KERNEL);
+total_buf_space, vrp-bufs_dma,
+GFP_KERNEL);
if (!bufs_va) {
err = -ENOMEM;
goto vqs_del;
@@ -984,10 +994,10 @@ static int rpmsg_probe(struct virtio_device *vdev)
vrp-rbufs = bufs_va;
/* and half is dedicated for TX */
- vrp-sbufs = bufs_va + RPMSG_TOTAL_BUF_SPACE / 2;
+ vrp-sbufs = bufs_va + total_buf_space / 2;
/* set up the receive buffers */
- for (i = 0; i RPMSG_NUM_BUFS / 2; i++) {
+ for (i = 0; i vrp-num_bufs / 2; i++) {
struct scatterlist sg;
void *cpu_addr = vrp-rbufs + i * RPMSG_BUF_SIZE;
@@ -1023,8 +1033,8 @@ static int rpmsg_probe(struct virtio_device
Re: [PATCHv5 06/15] hwspinlock/omap: enable module before reading SYSSTATUS register
Hi Ohad, On 07/01/2014 07:51 AM, Ohad Ben-Cohen wrote: Hi Suman, On Thu, May 1, 2014 at 3:34 AM, Suman Anna s-a...@ti.com wrote: The number of hwspinlocks are determined based on the value read from the IP block's SYSSTATUS register. However, the module may not be enabled and clocked, and the read may result in a bus error. This particular issue is seen rather easily on AM33XX, since the module wakeup is software controlled, and it is disabled out of reset. Make sure the module is enabled and clocked before reading the SYSSTATUS register. This seems like a valid fix that is independent of this patch series. Feel free to submit it separately if you want, so we can get it merged. OK, I will submit this patch and Patch 7 separately. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 05/15] hwspinlock/omap: add support for dt nodes
Hi Ohad,
On 07/01/2014 07:48 AM, Ohad Ben-Cohen wrote:
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna s-a...@ti.com wrote:
static int omap_hwspinlock_probe(struct platform_device *pdev)
{
- struct hwspinlock_pdata *pdata = pdev-dev.platform_data;
+ struct device_node *node = pdev-dev.of_node;
struct hwspinlock_device *bank;
struct hwspinlock *hwlock;
struct resource *res;
void __iomem *io_base;
int num_locks, i, ret;
+ int base_id = 0;
We shouldn't implicitly assume base_id is zero: let's explicitly
protect against potential subsequent invocations of
omap_hwspinlock_probe.
Yeah, I did this since we only had 1 instance, and used the same value
as used in the non-DT legacy code. Once I fold back Patch 8 that adds
the hwlock-base-id property, this will be assigned by reading that property.
regards
Suman
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
Hi Ohad, On 07/01/2014 07:26 AM, Ohad Ben-Cohen wrote: Hi Suman, On Thu, May 1, 2014 at 3:34 AM, Suman Anna s-a...@ti.com wrote: The hwspinlock_device structure is used for registering a bank of locks with the driver core. The structure already contains the necessary members to identify the bank of locks. The core does not maintain the hwspinlock_devices itself, but maintains only a radix tree for all the registered locks. A specific lock can be requested by users using a global lock id, and any device-specific fields can be retrieved through a reference to the hwspinlock_device in each lock. The global lock id, however, is not friendly to be requested for users using the device-tree model. The device-tree representation will typically have each of the hwspinlock devices represented as a DT node, and a specific lock can be requested using the device's phandle and a lock specifier. Add support to the core therefore to maintain all the registered hwspinlock_devices, so that a device can be looked up and a specific lock belonging to the device requested through a phandle + args approach. Signed-off-by: Suman Anna s-a...@ti.com I'm not sure we need this patch. This patch is needed if we use the controller-phandle + args specifier for requesting hwlocks by a client, as we need to translate controller-phandle to the corresponding hwspinlock_device. Looks like we still don't have a closure on the semantics of how clients have to request a lock in DT. You are suggesting something like hwlocks = global_lock1 global_lock2 ...; whereas this patch is built to support based on comments from DT-maintainers, hwlocks = controller-phandle lock-specifier1, controller-phandle lock-specifier2...; Mark, Kumar, We need your input here as DT maintainers. Some of the discussion is on the v4 cover-letter thread [1]. Kumar, Josh, How does this fit with the MSM spinlock driver? It seems to me that the global lock id can be the base_id + lock index, where the former should be a property of the parent dt node, and the latter can just be the phandle argument. Then, with the global lock id in hand, drivers could just use the existing hwspin_lock_request_specific API. If future hardware will bring a more complex scenario, we could then introduce the xlate proposal to resolve it. As long as we're not changing the dt data, and this is all handled by kernel code, Once we define dt data one way, how can we support a different mechanism later on? Are you implying that we support both controller-phandle + specifier and global-lock convention somehow through driver changes? then I'd prefer opting for less code now as long as it addresses the requirements. Please let me know if currently there is a use case that can't be addressed using this simpler model. This is just a question of DT semantics for the longer term, it can be done both ways. I have started out the series with exactly what you are suggesting here. regards Suman [1] https://lkml.org/lkml/2014/3/17/576 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
Hi Ohad, On Thu, May 1, 2014 at 3:34 AM, Suman Anna s-a...@ti.com wrote: 2. The of_hwspin_lock_simple_xlate() is a simple default translator function for hwspinlock provider implementations that use a single cell number for requesting a specific lock (relatively indexed) within a hwlock bank. Do we have a use case today that require the xlate() method? If not, let's remove it as we could always add it back if some new hardware shows up that needs it. The xlate() method is to support the phandle + args specifier way of requesting hwlocks, platform implementations are free to implement their own xlate functions, but the above supports the simplest case of controller + relative lock index within controller. As long as the dt data is unchanged, we should generally only add kernel code that we really need. 3. The of_hwspin_lock_request_specific() API can be used by hwspinlock clients to request a specific lock using the phandle + args specifier. This function relies on the implementation providing back a relative hwlock id within the bank from the args specifier. It seems to me we can just introduce a of_hwspin_lock_get_id() method which will provide the global lock id to dt users, with which they could just invoke the existing hwspin_lock_request_specific(). This way we will have more common code between dt users and users who get the lock id from a remote processor. This function again is to support the phandle + args specifier way of requesting hwlocks, the hwspin_lock_request_specific() is invoked internally within this function, so we are still reusing the actual request code other than handling the DT parsing portion. If we go back to using global locks in client hwlocks property, we don't need a of_hwspin_lock_get_id(), the same can be achieved using the existing DT function, of_property_read_u32_index(). regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] hwspinlock/omap - new SoC support
Hi Ohad, The following two patches allow the OMAP hwspinlock driver to be enabled for AM33xx, AM437x and DRA7xx SoCs. The patches are rebased onto 3.16-rc3 and are identical to those posted in the OMAP hwspinlock DT support v5 series [1][2]. Posting these separately to decouple from the DT series, as per the discussion on the lists. regards Suman [1] https://patchwork.kernel.org/patch/4096831/ [2] https://patchwork.kernel.org/patch/4096761/ Suman Anna (2): hwspinlock/omap: enable module before reading SYSSTATUS register hwspinlock/omap: enable build for AM33xx, AM43xx DRA7xx drivers/hwspinlock/Kconfig | 2 +- drivers/hwspinlock/omap_hwspinlock.c | 27 --- 2 files changed, 21 insertions(+), 8 deletions(-) -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] hwspinlock/omap: enable build for AM33xx, AM43xx DRA7xx
HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC device families as well. The IPs are identical to that of OMAP4/OMAP5, except for the number of locks. Add a depends on to the above family of SoCs to enable the build support for OMAP hwspinlock driver for any of the above SoC configs. Signed-off-by: Suman Anna s-a...@ti.com --- drivers/hwspinlock/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig index 70637d2..3612cb5 100644 --- a/drivers/hwspinlock/Kconfig +++ b/drivers/hwspinlock/Kconfig @@ -10,7 +10,7 @@ menu Hardware Spinlock drivers config HWSPINLOCK_OMAP tristate OMAP Hardware Spinlock device - depends on ARCH_OMAP4 || SOC_OMAP5 + depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || SOC_AM43XX select HWSPINLOCK help Say y here to support the OMAP Hardware Spinlock device (firstly -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] hwspinlock/omap: enable module before reading SYSSTATUS register
The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.
This particular issue is seen rather easily on AM33XX, since the
module wakeup is software controlled, and it is disabled out of
reset. Make sure the module is enabled and clocked before reading
the SYSSTATUS register.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/omap_hwspinlock.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 292869c..deb9e13 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -98,10 +98,29 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
if (!io_base)
return -ENOMEM;
+ /*
+* make sure the module is enabled and clocked before reading
+* the module SYSSTATUS register
+*/
+ pm_runtime_enable(pdev-dev);
+ ret = pm_runtime_get_sync(pdev-dev);
+ if (ret 0) {
+ pm_runtime_put_noidle(pdev-dev);
+ goto iounmap_base;
+ }
+
/* Determine number of locks */
i = readl(io_base + SYSSTATUS_OFFSET);
i = SPINLOCK_NUMLOCKS_BIT_OFFSET;
+ /*
+* runtime PM will make sure the clock of this module is
+* enabled again iff at least one lock is requested
+*/
+ ret = pm_runtime_put_sync(pdev-dev);
+ if (ret 0)
+ goto iounmap_base;
+
/* one of the four lsb's must be set, and nothing else */
if (hweight_long(i 0xf) != 1 || i 8) {
ret = -EINVAL;
@@ -121,12 +140,6 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
for (i = 0, hwlock = bank-lock[0]; i num_locks; i++, hwlock++)
hwlock-priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
- /*
-* runtime PM will make sure the clock of this module is
-* enabled iff at least one lock is requested
-*/
- pm_runtime_enable(pdev-dev);
-
ret = hwspin_lock_register(bank, pdev-dev, omap_hwspinlock_ops,
pdata-base_id, num_locks);
if (ret)
@@ -135,9 +148,9 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
return 0;
reg_fail:
- pm_runtime_disable(pdev-dev);
kfree(bank);
iounmap_base:
+ pm_runtime_disable(pdev-dev);
iounmap(io_base);
return ret;
}
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
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/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] mailbox/omap: add a custom of_xlate function
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] mailbox/omap: use devm_* interfaces
Use the various devm_ interfaces to simplify the cleanup in
probe and remove functions in OMAP2+ mailbox driver.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/mailbox/mailbox-omap2.c | 64 -
1 file changed, 19 insertions(+), 45 deletions(-)
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index 42d2b89..75fbc90 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -236,23 +236,24 @@ static int omap2_mbox_probe(struct platform_device *pdev)
}
/* allocate one extra for marking end of list */
- list = kzalloc((pdata-info_cnt + 1) * sizeof(*list), GFP_KERNEL);
+ list = devm_kzalloc(pdev-dev, (pdata-info_cnt + 1) * sizeof(*list),
+ GFP_KERNEL);
if (!list)
return -ENOMEM;
- mboxblk = mbox = kzalloc(pdata-info_cnt * sizeof(*mbox), GFP_KERNEL);
- if (!mboxblk) {
- ret = -ENOMEM;
- goto free_list;
- }
+ mboxblk = devm_kzalloc(pdev-dev, pdata-info_cnt * sizeof(*mbox),
+ GFP_KERNEL);
+ if (!mboxblk)
+ return -ENOMEM;
- privblk = priv = kzalloc(pdata-info_cnt * sizeof(*priv), GFP_KERNEL);
- if (!privblk) {
- ret = -ENOMEM;
- goto free_mboxblk;
- }
+ privblk = devm_kzalloc(pdev-dev, pdata-info_cnt * sizeof(*priv),
+ GFP_KERNEL);
+ if (!privblk)
+ return -ENOMEM;
info = pdata-info;
+ mbox = mboxblk;
+ priv = privblk;
for (i = 0; i pdata-info_cnt; i++, info++, priv++) {
priv-tx_fifo.msg = MAILBOX_MESSAGE(info-tx_id);
priv-tx_fifo.fifo_stat = MAILBOX_FIFOSTATUS(info-tx_id);
@@ -276,55 +277,28 @@ static int omap2_mbox_probe(struct platform_device *pdev)
mbox-name = info-name;
mbox-ops = omap2_mbox_ops;
mbox-irq = platform_get_irq(pdev, info-irq_id);
- if (mbox-irq 0) {
- ret = mbox-irq;
- goto free_privblk;
- }
+ if (mbox-irq 0)
+ return mbox-irq;
list[i] = mbox++;
}
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem) {
- ret = -ENOENT;
- goto free_privblk;
- }
-
- mbox_base = ioremap(mem-start, resource_size(mem));
- if (!mbox_base) {
- ret = -ENOMEM;
- goto free_privblk;
- }
+ mbox_base = devm_ioremap_resource(pdev-dev, mem);
+ if (IS_ERR(mbox_base))
+ return PTR_ERR(mbox_base);
ret = omap_mbox_register(pdev-dev, list);
if (ret)
- goto unmap_mbox;
+ return ret;
+
platform_set_drvdata(pdev, list);
return 0;
-
-unmap_mbox:
- iounmap(mbox_base);
-free_privblk:
- kfree(privblk);
-free_mboxblk:
- kfree(mboxblk);
-free_list:
- kfree(list);
- return ret;
}
static int omap2_mbox_remove(struct platform_device *pdev)
{
- struct omap_mbox2_priv *privblk;
- struct omap_mbox **list = platform_get_drvdata(pdev);
- struct omap_mbox *mboxblk = list[0];
-
- privblk = mboxblk-priv;
omap_mbox_unregister();
- iounmap(mbox_base);
- kfree(privblk);
- kfree(mboxblk);
- kfree(list);
return 0;
}
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] mailbox/omap: remove omap_mbox_type_t from mailbox ops
The type definition omap_mbox_type_t used for distinguishing
OMAP1 from OMAP2+ mailboxes is no longer needed after the
removal of OMAP1 mailbox driver, and has therefore been
cleaned up. This cleanup also eliminates the need for the
polling logic used for checking the transmit readiness.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/mailbox/mailbox-omap2.c | 1 -
drivers/mailbox/omap-mailbox.c | 22 ++
drivers/mailbox/omap-mbox.h | 5 -
3 files changed, 2 insertions(+), 26 deletions(-)
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index 75fbc90..b44e3bc 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -205,7 +205,6 @@ static void omap2_mbox_restore_ctx(struct omap_mbox *mbox)
}
static struct omap_mbox_ops omap2_mbox_ops = {
- .type = OMAP_MBOX_TYPE2,
.startup= omap2_mbox_startup,
.shutdown = omap2_mbox_shutdown,
.fifo_read = omap2_mbox_fifo_read,
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index d79a646..eab7227 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -24,7 +24,6 @@
#include linux/interrupt.h
#include linux/spinlock.h
#include linux/mutex.h
-#include linux/delay.h
#include linux/slab.h
#include linux/kfifo.h
#include linux/err.h
@@ -74,20 +73,6 @@ static inline int is_mbox_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
/*
* message sender
*/
-static int __mbox_poll_for_space(struct omap_mbox *mbox)
-{
- int ret = 0, i = 1000;
-
- while (mbox_fifo_full(mbox)) {
- if (mbox-ops-type == OMAP_MBOX_TYPE2)
- return -1;
- if (--i == 0)
- return -1;
- udelay(1);
- }
- return ret;
-}
-
int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
{
struct omap_mbox_queue *mq = mbox-txq;
@@ -100,7 +85,7 @@ int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t
msg)
goto out;
}
- if (kfifo_is_empty(mq-fifo) !__mbox_poll_for_space(mbox)) {
+ if (kfifo_is_empty(mq-fifo) !mbox_fifo_full(mbox)) {
mbox_fifo_write(mbox, msg);
goto out;
}
@@ -158,7 +143,7 @@ static void mbox_tx_tasklet(unsigned long tx_data)
int ret;
while (kfifo_len(mq-fifo)) {
- if (__mbox_poll_for_space(mbox)) {
+ if (mbox_fifo_full(mbox)) {
omap_mbox_enable_irq(mbox, IRQ_TX);
break;
}
@@ -223,9 +208,6 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
len = kfifo_in(mq-fifo, (unsigned char *)msg, sizeof(msg));
WARN_ON(len != sizeof(msg));
-
- if (mbox-ops-type == OMAP_MBOX_TYPE1)
- break;
}
/* no more messages in the fifo. clear IRQ source. */
diff --git a/drivers/mailbox/omap-mbox.h b/drivers/mailbox/omap-mbox.h
index 86d7518..fae2151 100644
--- a/drivers/mailbox/omap-mbox.h
+++ b/drivers/mailbox/omap-mbox.h
@@ -16,12 +16,7 @@
#include linux/workqueue.h
#include linux/omap-mailbox.h
-typedef int __bitwise omap_mbox_type_t;
-#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
-#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
-
struct omap_mbox_ops {
- omap_mbox_type_ttype;
int (*startup)(struct omap_mbox *mbox);
void(*shutdown)(struct omap_mbox *mbox);
/* fifo */
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] OMAP mailbox cleanup
Hi, This patch series is mainly a cleanup of the current OMAP mailbox drivers in preparation for adding DT support and adoption to the upcoming mailbox framework from Jassi Brar [1]. It removes the OMAP1 mailbox driver as there are no users for it in the kernel, and consolidates the previous OMAP mailbox framework and the OMAP2+ mailbox driver into a single OMAP mailbox driver. The last patch also allows the OMAP mailbox driver to support multiple instances of the IP (for DRA7xx, which is the first SoC in the OMAP family to have more than one System Mailbox IP). The patches are based on 3.16-rc2 and do not change any of the functional behavior on any OMAP2+ SoCs. The boot logs on various OMAP platforms with these patches are at: OMAP2 (SDP2430) : http://slexy.org/view/s20rOAReeS OMAP3 (BeagleXM) : http://slexy.org/view/s2QITyvzH9 OMAP4 (PandaBoard): http://slexy.org/view/s2X9jdZ9Wh OMAP5 (OMAP5 uEVM): http://slexy.org/view/s21hZUTYwm DRA7 (DRA7 EVM) : http://slexy.org/view/s213K7f87s AM33xx (BeagleBone Black) : http://slexy.org/view/s2vB7oxbix AM43xx (AM437x GP EVM): http://slexy.org/view/s21rMlUWMg [1] https://lkml.org/lkml/2014/6/12/470 Suman Anna (7): mailbox/omap: use devm_* interfaces mailbox/omap: remove OMAP1 mailbox driver mailbox/omap: remove omap_mbox_type_t from mailbox ops mailbox/omap: simplify the fifo assignment by using macros mailbox/omap: consolidate OMAP mailbox driver mailbox/omap: remove the private mailbox structure mailbox/omap: add a parent structure for every IP instance arch/arm/configs/omap1_defconfig | 2 - drivers/mailbox/Kconfig | 19 +- drivers/mailbox/Makefile | 6 +- drivers/mailbox/mailbox-omap1.c | 203 -- drivers/mailbox/mailbox-omap2.c | 357 --- drivers/mailbox/omap-mailbox.c | 444 +++ drivers/mailbox/omap-mbox.h | 67 -- 7 files changed, 360 insertions(+), 738 deletions(-) delete mode 100644 drivers/mailbox/mailbox-omap1.c delete mode 100644 drivers/mailbox/mailbox-omap2.c delete mode 100644 drivers/mailbox/omap-mbox.h -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] mailbox/omap: remove OMAP1 mailbox driver
There are no existing users for OMAP1 mailbox driver
in kernel. Commit ab6f775 Removing dead OMAP_DSP
has cleaned up all the dead code related to the only
possible user, including the creation of the mailbox
platform device.
Remove this stale driver so that the OMAP mailbox
driver can be simplified and streamlined better for
converting to mailbox framework.
Cc: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/configs/omap1_defconfig | 2 -
drivers/mailbox/Kconfig | 15 +--
drivers/mailbox/Makefile | 2 -
drivers/mailbox/mailbox-omap1.c | 203 ---
4 files changed, 3 insertions(+), 219 deletions(-)
delete mode 100644 drivers/mailbox/mailbox-omap1.c
diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig
index ce541bb..115cda9 100644
--- a/arch/arm/configs/omap1_defconfig
+++ b/arch/arm/configs/omap1_defconfig
@@ -26,8 +26,6 @@ CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP1=y
CONFIG_OMAP_RESET_CLOCKS=y
# CONFIG_OMAP_MUX is not set
-CONFIG_MAILBOX=y
-CONFIG_OMAP1_MBOX=y
CONFIG_OMAP_32K_TIMER=y
CONFIG_OMAP_DM_TIMER=y
CONFIG_ARCH_OMAP730=y
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index c8b5c13..1ec8f4e 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -20,17 +20,8 @@ config OMAP_MBOX
tristate
help
This option is selected by any OMAP architecture specific mailbox
- driver such as CONFIG_OMAP1_MBOX or CONFIG_OMAP2PLUS_MBOX. This
- enables the common OMAP mailbox framework code.
-
-config OMAP1_MBOX
- tristate OMAP1 Mailbox framework support
- depends on ARCH_OMAP1
- select OMAP_MBOX
- help
- Mailbox implementation for OMAP chips with hardware for
- interprocessor communication involving DSP in OMAP1. Say Y here
- if you want to use OMAP1 Mailbox framework support.
+ driver such as CONFIG_OMAP2PLUS_MBOX. This enables the common OMAP
+ mailbox framework code.
config OMAP2PLUS_MBOX
tristate OMAP2+ Mailbox framework support
@@ -44,7 +35,7 @@ config OMAP2PLUS_MBOX
config OMAP_MBOX_KFIFO_SIZE
int Mailbox kfifo default buffer size (bytes)
- depends on OMAP2PLUS_MBOX || OMAP1_MBOX
+ depends on OMAP2PLUS_MBOX
default 256
help
Specify the default size of mailbox's kfifo buffers (bytes).
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index e0facb3..d023feb 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -1,7 +1,5 @@
obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
obj-$(CONFIG_OMAP_MBOX)+= omap-mailbox.o
-obj-$(CONFIG_OMAP1_MBOX) += mailbox_omap1.o
-mailbox_omap1-objs := mailbox-omap1.o
obj-$(CONFIG_OMAP2PLUS_MBOX) += mailbox_omap2.o
mailbox_omap2-objs := mailbox-omap2.o
diff --git a/drivers/mailbox/mailbox-omap1.c b/drivers/mailbox/mailbox-omap1.c
deleted file mode 100644
index 9001b76..000
--- a/drivers/mailbox/mailbox-omap1.c
+++ /dev/null
@@ -1,203 +0,0 @@
-/*
- * Mailbox reservation modules for OMAP1
- *
- * Copyright (C) 2006-2009 Nokia Corporation
- * Written by: Hiroshi DOYU hiroshi.d...@nokia.com
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file COPYING in the main directory of this archive
- * for more details.
- */
-
-#include linux/module.h
-#include linux/interrupt.h
-#include linux/platform_device.h
-#include linux/io.h
-
-#include omap-mbox.h
-
-#define MAILBOX_ARM2DSP1 0x00
-#define MAILBOX_ARM2DSP1b 0x04
-#define MAILBOX_DSP2ARM1 0x08
-#define MAILBOX_DSP2ARM1b 0x0c
-#define MAILBOX_DSP2ARM2 0x10
-#define MAILBOX_DSP2ARM2b 0x14
-#define MAILBOX_ARM2DSP1_Flag 0x18
-#define MAILBOX_DSP2ARM1_Flag 0x1c
-#define MAILBOX_DSP2ARM2_Flag 0x20
-
-static void __iomem *mbox_base;
-
-struct omap_mbox1_fifo {
- unsigned long cmd;
- unsigned long data;
- unsigned long flag;
-};
-
-struct omap_mbox1_priv {
- struct omap_mbox1_fifo tx_fifo;
- struct omap_mbox1_fifo rx_fifo;
-};
-
-static inline int mbox_read_reg(size_t ofs)
-{
- return __raw_readw(mbox_base + ofs);
-}
-
-static inline void mbox_write_reg(u32 val, size_t ofs)
-{
- __raw_writew(val, mbox_base + ofs);
-}
-
-/* msg */
-static mbox_msg_t omap1_mbox_fifo_read(struct omap_mbox *mbox)
-{
- struct omap_mbox1_fifo *fifo =
- ((struct omap_mbox1_priv *)mbox-priv)-rx_fifo;
- mbox_msg_t msg;
-
- msg = mbox_read_reg(fifo-data);
- msg |= ((mbox_msg_t) mbox_read_reg(fifo-cmd)) 16;
-
- return msg;
-}
-
-static void
-omap1_mbox_fifo_write(struct omap_mbox *mbox, mbox_msg_t msg)
-{
- struct omap_mbox1_fifo *fifo =
- ((struct omap_mbox1_priv *)mbox-priv)-tx_fifo;
-
- mbox_write_reg
[PATCH 4/7] mailbox/omap: simplify the fifo assignment by using macros
The OMAP mailbox IP has two different type of interrupt configuration
registers between OMAP4+ SoCs and OMAP2/3 SoCs. Simplify the current
interrupt configuration by using a single macro that translates the
two variants.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/mailbox/mailbox-omap2.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index b44e3bc..2c463d6 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -25,13 +25,21 @@
#define MAILBOX_MESSAGE(m) (0x040 + 4 * (m))
#define MAILBOX_FIFOSTATUS(m) (0x080 + 4 * (m))
#define MAILBOX_MSGSTATUS(m) (0x0c0 + 4 * (m))
-#define MAILBOX_IRQSTATUS(u) (0x100 + 8 * (u))
-#define MAILBOX_IRQENABLE(u) (0x104 + 8 * (u))
+
+#define OMAP2_MAILBOX_IRQSTATUS(u) (0x100 + 8 * (u))
+#define OMAP2_MAILBOX_IRQENABLE(u) (0x104 + 8 * (u))
#define OMAP4_MAILBOX_IRQSTATUS(u) (0x104 + 0x10 * (u))
#define OMAP4_MAILBOX_IRQENABLE(u) (0x108 + 0x10 * (u))
#define OMAP4_MAILBOX_IRQENABLE_CLR(u) (0x10c + 0x10 * (u))
+#define MAILBOX_IRQSTATUS(type, u) (type ? OMAP4_MAILBOX_IRQSTATUS(u) : \
+ OMAP2_MAILBOX_IRQSTATUS(u))
+#define MAILBOX_IRQENABLE(type, u) (type ? OMAP4_MAILBOX_IRQENABLE(u) : \
+ OMAP2_MAILBOX_IRQENABLE(u))
+#define MAILBOX_IRQDISABLE(type, u)(type ? OMAP4_MAILBOX_IRQENABLE_CLR(u) \
+ : OMAP2_MAILBOX_IRQENABLE(u))
+
#define MAILBOX_IRQ_NEWMSG(m) (1 (2 * (m)))
#define MAILBOX_IRQ_NOTFULL(m) (1 (2 * (m) + 1))
@@ -227,6 +235,7 @@ static int omap2_mbox_probe(struct platform_device *pdev)
struct omap_mbox2_priv *priv, *privblk;
struct omap_mbox_pdata *pdata = pdev-dev.platform_data;
struct omap_mbox_dev_info *info;
+ u32 intr_type;
int i;
if (!pdata || !pdata-info_cnt || !pdata-info) {
@@ -251,6 +260,7 @@ static int omap2_mbox_probe(struct platform_device *pdev)
return -ENOMEM;
info = pdata-info;
+ intr_type = pdata-intr_type;
mbox = mboxblk;
priv = privblk;
for (i = 0; i pdata-info_cnt; i++, info++, priv++) {
@@ -260,17 +270,10 @@ static int omap2_mbox_probe(struct platform_device *pdev)
priv-rx_fifo.msg_stat = MAILBOX_MSGSTATUS(info-rx_id);
priv-notfull_bit = MAILBOX_IRQ_NOTFULL(info-tx_id);
priv-newmsg_bit = MAILBOX_IRQ_NEWMSG(info-rx_id);
- if (pdata-intr_type) {
- priv-irqenable = OMAP4_MAILBOX_IRQENABLE(info-usr_id);
- priv-irqstatus = OMAP4_MAILBOX_IRQSTATUS(info-usr_id);
- priv-irqdisable =
- OMAP4_MAILBOX_IRQENABLE_CLR(info-usr_id);
- } else {
- priv-irqenable = MAILBOX_IRQENABLE(info-usr_id);
- priv-irqstatus = MAILBOX_IRQSTATUS(info-usr_id);
- priv-irqdisable = MAILBOX_IRQENABLE(info-usr_id);
- }
- priv-intr_type = pdata-intr_type;
+ priv-irqenable = MAILBOX_IRQENABLE(intr_type, info-usr_id);
+ priv-irqstatus = MAILBOX_IRQSTATUS(intr_type, info-usr_id);
+ priv-irqdisable = MAILBOX_IRQDISABLE(intr_type, info-usr_id);
+ priv-intr_type = intr_type;
mbox-priv = priv;
mbox-name = info-name;
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] mailbox/omap: consolidate OMAP mailbox driver
There is no need for a separate common OMAP mailbox module
now that the OMAP1 mailbox driver has been removed. So,
consolidate the two individual OMAP mailbox modules into a
single driver. This streamlines the driver for converting
to mailbox framework.
The following are the main changes:
- collapse mailbox-omap2.c into omap-mailbox.c
- remove omap_mbox_ops and replace the ops calls with
the equivalent functionality.
- simplify the sub-mailbox startup/shutdown functionality,
the one-time operations are moved into probe, and the
pm_runtime_get_sync and pm_runtime_put_sync can be invoked
without using a configuration counter.
- move all definitions from private omap_mbox.h into the
source code, and eliminate this internal header.
- rename some variables that used the omap2_mbox prefix with
a generic omap_mbox prefix.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/mailbox/Kconfig | 8 -
drivers/mailbox/Makefile| 4 +-
drivers/mailbox/mailbox-omap2.c | 333
drivers/mailbox/omap-mailbox.c | 331 +--
drivers/mailbox/omap-mbox.h | 62
5 files changed, 283 insertions(+), 455 deletions(-)
delete mode 100644 drivers/mailbox/mailbox-omap2.c
delete mode 100644 drivers/mailbox/omap-mbox.h
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 1ec8f4e..9fd9c67 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,17 +16,9 @@ config PL320_MBOX
Management Engine, primarily for cpufreq. Say Y here if you want
to use the PL320 IPCM support.
-config OMAP_MBOX
- tristate
- help
- This option is selected by any OMAP architecture specific mailbox
- driver such as CONFIG_OMAP2PLUS_MBOX. This enables the common OMAP
- mailbox framework code.
-
config OMAP2PLUS_MBOX
tristate OMAP2+ Mailbox framework support
depends on ARCH_OMAP2PLUS
- select OMAP_MBOX
help
Mailbox implementation for OMAP family chips with hardware for
interprocessor communication involving DSP, IVA1.0 and IVA2 in
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index d023feb..6d184db 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -1,5 +1,3 @@
obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
-obj-$(CONFIG_OMAP_MBOX)+= omap-mailbox.o
-obj-$(CONFIG_OMAP2PLUS_MBOX) += mailbox_omap2.o
-mailbox_omap2-objs := mailbox-omap2.o
+obj-$(CONFIG_OMAP2PLUS_MBOX) += omap-mailbox.o
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
deleted file mode 100644
index 2c463d6..000
--- a/drivers/mailbox/mailbox-omap2.c
+++ /dev/null
@@ -1,333 +0,0 @@
-/*
- * Mailbox reservation modules for OMAP2/3
- *
- * Copyright (C) 2006-2009 Nokia Corporation
- * Written by: Hiroshi DOYU hiroshi.d...@nokia.com
- *and Paul Mundt
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file COPYING in the main directory of this archive
- * for more details.
- */
-
-#include linux/module.h
-#include linux/slab.h
-#include linux/clk.h
-#include linux/err.h
-#include linux/platform_device.h
-#include linux/io.h
-#include linux/pm_runtime.h
-#include linux/platform_data/mailbox-omap.h
-
-#include omap-mbox.h
-
-#define MAILBOX_REVISION 0x000
-#define MAILBOX_MESSAGE(m) (0x040 + 4 * (m))
-#define MAILBOX_FIFOSTATUS(m) (0x080 + 4 * (m))
-#define MAILBOX_MSGSTATUS(m) (0x0c0 + 4 * (m))
-
-#define OMAP2_MAILBOX_IRQSTATUS(u) (0x100 + 8 * (u))
-#define OMAP2_MAILBOX_IRQENABLE(u) (0x104 + 8 * (u))
-
-#define OMAP4_MAILBOX_IRQSTATUS(u) (0x104 + 0x10 * (u))
-#define OMAP4_MAILBOX_IRQENABLE(u) (0x108 + 0x10 * (u))
-#define OMAP4_MAILBOX_IRQENABLE_CLR(u) (0x10c + 0x10 * (u))
-
-#define MAILBOX_IRQSTATUS(type, u) (type ? OMAP4_MAILBOX_IRQSTATUS(u) : \
- OMAP2_MAILBOX_IRQSTATUS(u))
-#define MAILBOX_IRQENABLE(type, u) (type ? OMAP4_MAILBOX_IRQENABLE(u) : \
- OMAP2_MAILBOX_IRQENABLE(u))
-#define MAILBOX_IRQDISABLE(type, u)(type ? OMAP4_MAILBOX_IRQENABLE_CLR(u) \
- : OMAP2_MAILBOX_IRQENABLE(u))
-
-#define MAILBOX_IRQ_NEWMSG(m) (1 (2 * (m)))
-#define MAILBOX_IRQ_NOTFULL(m) (1 (2 * (m) + 1))
-
-#define MBOX_REG_SIZE 0x120
-
-#define OMAP4_MBOX_REG_SIZE0x130
-
-#define MBOX_NR_REGS (MBOX_REG_SIZE / sizeof(u32))
-#define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE / sizeof(u32))
-
-static void __iomem *mbox_base;
-
-struct omap_mbox2_fifo {
- unsigned long msg;
- unsigned long fifo_stat;
- unsigned long msg_stat;
-};
-
-struct omap_mbox2_priv {
- struct omap_mbox2_fifo tx_fifo
[PATCH 6/7] mailbox/omap: remove the private mailbox structure
The structure omap_mbox_priv is used previously to store arch
specific (OMAP1 vs OMAP2+) data, and is no longer required to be
maintained separately. Instead, absorb its elements into either
the sub-mailbox device structure, omap_mbox, or the individual
fifo descriptor structure, omap_mbox_fifo.
The newmsg_bit and notfull_bit used on Rx and Tx fifos respectively
are represented by the new intr_bit field in the fifo descriptor
structure. The interrupt configuration registers are also moved
into the fifo descriptor structure to allow the Rx and Tx fifos
to use different interrupt lines/users.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/mailbox/omap-mailbox.c | 126 -
1 file changed, 63 insertions(+), 63 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 66b02ab..d9a5039 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -69,18 +69,10 @@ struct omap_mbox_fifo {
unsigned long msg;
unsigned long fifo_stat;
unsigned long msg_stat;
-};
-
-struct omap_mbox_priv {
- struct omap_mbox_fifo tx_fifo;
- struct omap_mbox_fifo rx_fifo;
unsigned long irqenable;
unsigned long irqstatus;
- u32 newmsg_bit;
- u32 notfull_bit;
- u32 ctx[OMAP4_MBOX_NR_REGS];
unsigned long irqdisable;
- u32 intr_type;
+ u32 intr_bit;
};
struct omap_mbox_queue {
@@ -97,7 +89,10 @@ struct omap_mbox {
int irq;
struct omap_mbox_queue *txq, *rxq;
struct device *dev;
- void*priv;
+ 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;
};
@@ -124,50 +119,52 @@ static inline void mbox_write_reg(u32 val, size_t ofs)
/* Mailbox FIFO handle functions */
static mbox_msg_t mbox_fifo_read(struct omap_mbox *mbox)
{
- struct omap_mbox_fifo *fifo =
- ((struct omap_mbox_priv *)mbox-priv)-rx_fifo;
+ struct omap_mbox_fifo *fifo = mbox-rx_fifo;
return (mbox_msg_t) mbox_read_reg(fifo-msg);
}
static void mbox_fifo_write(struct omap_mbox *mbox, mbox_msg_t msg)
{
- struct omap_mbox_fifo *fifo =
- ((struct omap_mbox_priv *)mbox-priv)-tx_fifo;
+ struct omap_mbox_fifo *fifo = mbox-tx_fifo;
mbox_write_reg(msg, fifo-msg);
}
static int mbox_fifo_empty(struct omap_mbox *mbox)
{
- struct omap_mbox_fifo *fifo =
- ((struct omap_mbox_priv *)mbox-priv)-rx_fifo;
+ struct omap_mbox_fifo *fifo = mbox-rx_fifo;
return (mbox_read_reg(fifo-msg_stat) == 0);
}
static int mbox_fifo_full(struct omap_mbox *mbox)
{
- struct omap_mbox_fifo *fifo =
- ((struct omap_mbox_priv *)mbox-priv)-tx_fifo;
+ struct omap_mbox_fifo *fifo = mbox-tx_fifo;
return mbox_read_reg(fifo-fifo_stat);
}
/* Mailbox IRQ handle functions */
static void ack_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
- struct omap_mbox_priv *p = mbox-priv;
- u32 bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
+ struct omap_mbox_fifo *fifo = (irq == IRQ_TX) ?
+ mbox-tx_fifo : mbox-rx_fifo;
+ u32 bit = fifo-intr_bit;
+ u32 irqstatus = fifo-irqstatus;
- mbox_write_reg(bit, p-irqstatus);
+ mbox_write_reg(bit, irqstatus);
/* Flush posted write for irq status to avoid spurious interrupts */
- mbox_read_reg(p-irqstatus);
+ mbox_read_reg(irqstatus);
}
static int is_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
- struct omap_mbox_priv *p = mbox-priv;
- u32 bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
- u32 enable = mbox_read_reg(p-irqenable);
- u32 status = mbox_read_reg(p-irqstatus);
+ struct omap_mbox_fifo *fifo = (irq == IRQ_TX) ?
+ mbox-tx_fifo : mbox-rx_fifo;
+ u32 bit = fifo-intr_bit;
+ u32 irqenable = fifo-irqenable;
+ u32 irqstatus = fifo-irqstatus;
+
+ u32 enable = mbox_read_reg(irqenable);
+ u32 status = mbox_read_reg(irqstatus);
return (int)(enable status bit);
}
@@ -206,18 +203,17 @@ EXPORT_SYMBOL(omap_mbox_msg_send);
void omap_mbox_save_ctx(struct omap_mbox *mbox)
{
int i;
- struct omap_mbox_priv *p = mbox-priv;
int nr_regs;
- if (p-intr_type)
+ if (mbox-intr_type)
nr_regs = OMAP4_MBOX_NR_REGS;
else
nr_regs = MBOX_NR_REGS;
for (i = 0; i nr_regs; i++) {
- p-ctx[i] = mbox_read_reg(i * sizeof(u32));
+ mbox-ctx[i] = mbox_read_reg(i * sizeof(u32));
dev_dbg(mbox-dev, %s: [%02x] %08x\n, __func__
[PATCH 7/7] mailbox/omap: add a parent structure for every IP instance
A new structure, omap_mbox_device, is added to contain
the global variables pertinent to a mailbox h/w IP block.
This enables the support for having multiple instances of
the same h/w IP block in the SoC. This is in preparation
to support the DRA7 SoC, which is the first SoC in the OMAP
family to have multiple mailbox IP instances.
The changes include enhancements to the sub-mailbox registration
logic and mbox startup sequencing, removing the usage of single
global configuration variables for all h/w instances, and storing
the registered sub-mailboxes with the parent mailbox device
structure.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/mailbox/omap-mailbox.c | 173 +++--
1 file changed, 115 insertions(+), 58 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index d9a5039..a27e00e 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -84,11 +84,22 @@ struct omap_mbox_queue {
bool full;
};
+struct omap_mbox_device {
+ struct device *dev;
+ struct mutex cfg_lock;
+ void __iomem *mbox_base;
+ u32 num_users;
+ u32 num_fifos;
+ struct omap_mbox **mboxes;
+ struct list_head elem;
+};
+
struct omap_mbox {
const char *name;
int irq;
struct omap_mbox_queue *txq, *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];
@@ -97,48 +108,49 @@ struct omap_mbox {
struct blocking_notifier_head notifier;
};
-static void __iomem *mbox_base;
-static struct omap_mbox **mboxes;
-
-static DEFINE_MUTEX(mbox_configured_lock);
+/* global variables for the mailbox devices */
+static DEFINE_MUTEX(omap_mbox_devices_lock);
+static LIST_HEAD(omap_mbox_devices);
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 inline unsigned int mbox_read_reg(size_t ofs)
+static inline
+unsigned int mbox_read_reg(struct omap_mbox_device *mdev, size_t ofs)
{
- return __raw_readl(mbox_base + ofs);
+ return __raw_readl(mdev-mbox_base + ofs);
}
-static inline void mbox_write_reg(u32 val, size_t ofs)
+static inline
+void mbox_write_reg(struct omap_mbox_device *mdev, u32 val, size_t ofs)
{
- __raw_writel(val, mbox_base + ofs);
+ __raw_writel(val, mdev-mbox_base + ofs);
}
/* Mailbox FIFO handle functions */
static mbox_msg_t mbox_fifo_read(struct omap_mbox *mbox)
{
struct omap_mbox_fifo *fifo = mbox-rx_fifo;
- return (mbox_msg_t) mbox_read_reg(fifo-msg);
+ return (mbox_msg_t) mbox_read_reg(mbox-parent, fifo-msg);
}
static void mbox_fifo_write(struct omap_mbox *mbox, mbox_msg_t msg)
{
struct omap_mbox_fifo *fifo = mbox-tx_fifo;
- mbox_write_reg(msg, fifo-msg);
+ mbox_write_reg(mbox-parent, msg, fifo-msg);
}
static int mbox_fifo_empty(struct omap_mbox *mbox)
{
struct omap_mbox_fifo *fifo = mbox-rx_fifo;
- return (mbox_read_reg(fifo-msg_stat) == 0);
+ return (mbox_read_reg(mbox-parent, fifo-msg_stat) == 0);
}
static int mbox_fifo_full(struct omap_mbox *mbox)
{
struct omap_mbox_fifo *fifo = mbox-tx_fifo;
- return mbox_read_reg(fifo-fifo_stat);
+ return mbox_read_reg(mbox-parent, fifo-fifo_stat);
}
/* Mailbox IRQ handle functions */
@@ -149,10 +161,10 @@ static void ack_mbox_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
u32 bit = fifo-intr_bit;
u32 irqstatus = fifo-irqstatus;
- mbox_write_reg(bit, irqstatus);
+ mbox_write_reg(mbox-parent, bit, irqstatus);
/* Flush posted write for irq status to avoid spurious interrupts */
- mbox_read_reg(irqstatus);
+ mbox_read_reg(mbox-parent, irqstatus);
}
static int is_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
@@ -163,8 +175,8 @@ static int is_mbox_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
u32 irqenable = fifo-irqenable;
u32 irqstatus = fifo-irqstatus;
- u32 enable = mbox_read_reg(irqenable);
- u32 status = mbox_read_reg(irqstatus);
+ u32 enable = mbox_read_reg(mbox-parent, irqenable);
+ u32 status = mbox_read_reg(mbox-parent, irqstatus);
return (int)(enable status bit);
}
@@ -210,7 +222,7 @@ void omap_mbox_save_ctx(struct omap_mbox *mbox)
else
nr_regs = MBOX_NR_REGS;
for (i = 0; i nr_regs; i++) {
- mbox-ctx[i] = mbox_read_reg(i * sizeof(u32));
+ mbox-ctx[i] = mbox_read_reg(mbox-parent, i * sizeof(u32));
dev_dbg(mbox-dev, %s: [%02x] %08x\n, __func__,
i, mbox-ctx[i]);
@@ -228,7 +240,7 @@ void
[PATCH 0/9]
Hi Tony, Paul, This patch series adds the minimal mailbox DT nodes for the SoCs that are currently missing them (OMAP4, AM335x, DRA7). It also limits the legacy mailbox platform device creation only for non-DT boot, and cleans up the legacy hwmod addresses and attributes used for creating the sub-mailbox devices. The sub-mailboxes in DT boot are not created until the OMAP mailbox DT adoption series, and is not an issue since some of the other required hwmod data for using legacy-mode devices have already been cleaned up. The patches are based on 3.16-rc2. The series do not have any order dependencies with the OMAP mailbox cleanup series [1], and can be applied in any order. The following shows the boot logs on various OMAP platforms with just these patches on top of 3.16-rc2: OMAP2 (SDP2430) : http://slexy.org/view/s21gGdJxXP OMAP3 (BeagleXM) : http://slexy.org/view/s2n8Pc83Rp OMAP4 (PandaBoard): http://slexy.org/view/s21StNWKPz OMAP5 (OMAP5 uEVM): http://slexy.org/view/s2y3t6HZtk DRA7 (DRA7 EVM) : http://slexy.org/view/s2qY23Mt97 AM33xx (BeagleBone Black) : http://slexy.org/view/s2ce8jj35O AM43xx (AM437x GP EVM): http://slexy.org/view/s2nttmOLSq [1] http://marc.info/?l=linux-omapm=140365705821115w=2 Suman Anna (9): ARM: dts: OMAP4: Add mailbox node ARM: dts: AM33xx: Add mailbox node ARM: dts: AM4372: Correct mailbox node data ARM: dts: DRA7: Add mailbox nodes ARM: DRA7: hwmod_data: Add mailbox hwmod data ARM: OMAP2+: Avoid mailbox legacy device creation for DT-boot ARM: OMAP2: hwmod_data: Remove legacy mailbox data and addrs ARM: OMAP4: hwmod_data: Remove legacy mailbox addrs ARM: AM33xx: hwmod_data: Remove legacy mailbox addrs arch/arm/boot/dts/am33xx.dtsi | 7 + arch/arm/boot/dts/am4372.dtsi | 7 +- arch/arm/boot/dts/dra7.dtsi| 91 ++ arch/arm/boot/dts/omap4.dtsi | 7 + arch/arm/mach-omap2/devices.c | 2 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 14 - arch/arm/mach-omap2/omap_hwmod_2430_data.c | 13 - .../omap_hwmod_2xxx_3xxx_interconnect_data.c | 9 - .../omap_hwmod_33xx_43xx_interconnect_data.c | 10 - arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 - arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 305 + arch/arm/mach-omap2/omap_hwmod_common_data.h | 1 - 12 files changed, 412 insertions(+), 64 deletions(-) -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] OMAP Mailbox DT node/hwmod cleanup
Hi Tony, Paul, This patch series adds the minimal mailbox DT nodes for the SoCs that are currently missing them (OMAP4, AM335x, DRA7). It also limits the legacy mailbox platform device creation only for non-DT boot, and cleans up the legacy hwmod addresses and attributes used for creating the sub-mailbox devices. The sub-mailboxes in DT boot are not created until the OMAP mailbox DT adoption series, and is not an issue since some of the other required hwmod data for using legacy-mode devices have already been cleaned up. The patches are based on 3.16-rc2. The series do not have any order dependencies with the OMAP mailbox cleanup series [1], and can be applied in any order. The following shows the boot logs on various OMAP platforms with just these patches on top of 3.16-rc2: OMAP2 (SDP2430) : http://slexy.org/view/s21gGdJxXP OMAP3 (BeagleXM) : http://slexy.org/view/s2n8Pc83Rp OMAP4 (PandaBoard): http://slexy.org/view/s21StNWKPz OMAP5 (OMAP5 uEVM): http://slexy.org/view/s2y3t6HZtk DRA7 (DRA7 EVM) : http://slexy.org/view/s2qY23Mt97 AM33xx (BeagleBone Black) : http://slexy.org/view/s2ce8jj35O AM43xx (AM437x GP EVM): http://slexy.org/view/s2nttmOLSq [1] http://marc.info/?l=linux-omapm=140365705821115w=2 Suman Anna (9): ARM: dts: OMAP4: Add mailbox node ARM: dts: AM33xx: Add mailbox node ARM: dts: AM4372: Correct mailbox node data ARM: dts: DRA7: Add mailbox nodes ARM: DRA7: hwmod_data: Add mailbox hwmod data ARM: OMAP2+: Avoid mailbox legacy device creation for DT-boot ARM: OMAP2: hwmod_data: Remove legacy mailbox data and addrs ARM: OMAP4: hwmod_data: Remove legacy mailbox addrs ARM: AM33xx: hwmod_data: Remove legacy mailbox addrs arch/arm/boot/dts/am33xx.dtsi | 7 + arch/arm/boot/dts/am4372.dtsi | 7 +- arch/arm/boot/dts/dra7.dtsi| 91 ++ arch/arm/boot/dts/omap4.dtsi | 7 + arch/arm/mach-omap2/devices.c | 2 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 14 - arch/arm/mach-omap2/omap_hwmod_2430_data.c | 13 - .../omap_hwmod_2xxx_3xxx_interconnect_data.c | 9 - .../omap_hwmod_33xx_43xx_interconnect_data.c | 10 - arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 - arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 305 + arch/arm/mach-omap2/omap_hwmod_common_data.h | 1 - 12 files changed, 412 insertions(+), 64 deletions(-) -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] ARM: dts: OMAP4: Add mailbox node
The mailbox DT node data has been added for OMAP44xx
devices.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 7e26d22..55bec30 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -649,6 +649,13 @@
};
};
+ mailbox: mailbox@4a0f4000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4a0f4000 0x200;
+ interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mailbox;
+ };
+
timer1: timer@4a318000 {
compatible = ti,omap3430-timer;
reg = 0x4a318000 0x80;
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] ARM: dts: AM33xx: Add mailbox node
The mailbox DT node data has been added for AM33xx device.
The mailbox IP in AM33xx is similar to the version found in
OMAP4+ devices.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4a4e02d..1da3bcf 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -347,6 +347,13 @@
status = disabled;
};
+ mailbox: mailbox@480C8000 {
+ compatible = ti,am3352-mailbox;
+ reg = 0x480C8000 0x200;
+ interrupts = 77;
+ ti,hwmods = mailbox;
+ };
+
timer1: timer@44e31000 {
compatible = ti,am335x-timer-1ms;
reg = 0x44e31000 0x400;
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] ARM: dts: AM4372: Correct mailbox node data
The mailbox DT node for AM4372 has been corrected to include
the correct compatible flag, and remove the other properties
that have crept in by mistake.
Fixes: 9e3269b (ARM: dts: AM4372: Add L2, EDMA, mailbox, MMC and SHAM nodes)
Cc: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 49fa596..390cbb53 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -162,15 +162,10 @@
};
mailbox: mailbox@480C8000 {
- compatible = ti,omap4-mailbox;
+ compatible = ti,am4372-mailbox;
reg = 0x480C8000 0x200;
interrupts = GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox;
- ti,mbox-num-users = 4;
- ti,mbox-num-fifos = 8;
- ti,mbox-names = wkup_m3;
- ti,mbox-data = 0 0 0 0;
- status = disabled;
};
timer1: timer@44e31000 {
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] ARM: dts: DRA7: Add mailbox nodes
DRA7xx has 13 system mailboxes, and is present on both the
DRA72x and DRA74x family of SoCs. Add the DT nodes for all
these 13 mailboxes. Except for mailbox 1, all other mailboxes
do not have interrupts mapped into the MPU GIC by default.
All the mailboxes have been disabled and the interrupts
property information is left out intentionally for now,
because of the dependencies against the crossbar driver.
These mailboxes can be enabled when a usecase arises
and the crossbar driver dependencies are met.
NOTE: The mailbox 1 is backward compatible with the mailbox
IP on OMAP4/OMAP5 with different number of mailbox fifos
and IP interrupts, and hence the omap4 compatibility string
is used.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 91 +
1 file changed, 91 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index c29945e..8d7626f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -338,6 +338,97 @@
status = disabled;
};
+ mailbox1: mailbox@4a0f4000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4a0f4000 0x200;
+ ti,hwmods = mailbox1;
+ status = disabled;
+ };
+
+ mailbox2: mailbox@4883a000 {
+ compatible = ti,dra7-mailbox;
+ reg = 0x4883a000 0x200;
+ ti,hwmods = mailbox2;
+ status = disabled;
+ };
+
+ mailbox3: mailbox@4883c000 {
+ compatible = ti,dra7-mailbox;
+ reg = 0x4883c000 0x200;
+ ti,hwmods = mailbox3;
+ status = disabled;
+ };
+
+ mailbox4: mailbox@4883e000 {
+ compatible = ti,dra7-mailbox;
+ reg = 0x4883e000 0x200;
+ ti,hwmods = mailbox4;
+ status = disabled;
+ };
+
+ mailbox5: mailbox@4884 {
+ compatible = ti,dra7-mailbox;
+ reg = 0x4884 0x200;
+ ti,hwmods = mailbox5;
+ status = disabled;
+ };
+
+ mailbox6: mailbox@48842000 {
+ compatible = ti,dra7-mailbox;
+ reg = 0x48842000 0x200;
+ ti,hwmods = mailbox6;
+ status = disabled;
+ };
+
+ mailbox7: mailbox@48844000 {
+ compatible = ti,dra7-mailbox;
+ reg = 0x48844000 0x200;
+ ti,hwmods = mailbox7;
+ status = disabled;
+ };
+
+ mailbox8: mailbox@48846000 {
+ compatible = ti,dra7-mailbox;
+ reg = 0x48846000 0x200;
+ ti,hwmods = mailbox8;
+ status = disabled;
+ };
+
+ mailbox9: mailbox@4885e000 {
+ compatible = ti,dra7-mailbox;
+ reg = 0x4885e000 0x200;
+ ti,hwmods = mailbox9;
+ status = disabled;
+ };
+
+ mailbox10: mailbox@4886 {
+ compatible = ti,dra7-mailbox;
+ reg = 0x4886 0x200;
+ ti,hwmods = mailbox10;
+ status = disabled;
+ };
+
+ mailbox11: mailbox@48862000 {
+ compatible = ti,dra7-mailbox;
+ reg = 0x48862000 0x200;
+ ti,hwmods = mailbox11;
+ status = disabled;
+ };
+
+ mailbox12: mailbox@48864000 {
+ compatible = ti,dra7-mailbox;
+ reg = 0x48864000 0x200;
+ ti,hwmods = mailbox12;
+ status = disabled;
+ };
+
+ mailbox13: mailbox@48802000 {
+ compatible = ti,dra7-mailbox;
+ reg = 0x48802000 0x200;
+ ti,hwmods = mailbox13;
+ status = disabled;
+ };
+
timer1: timer@4ae18000 {
compatible = ti,omap5430-timer;
reg = 0x4ae18000 0x80;
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/9] ARM: AM33xx: hwmod_data: Remove legacy mailbox addrs
The legacy-style definition of the hwmod addr space is no longer
required as AM33xx/AM43xx are DT-boot only, and the minimal mailbox
DT nodes have been added, so clean up this data.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
index e2db378..8f5989d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
@@ -317,21 +317,11 @@ struct omap_hwmod_ocp_if am33xx_l4_per__i2c3 = {
.user = OCP_USER_MPU,
};
-static struct omap_hwmod_addr_space am33xx_mailbox_addrs[] = {
- {
- .pa_start = 0x480C8000,
- .pa_end = 0x480C8000 + (SZ_4K - 1),
- .flags = ADDR_TYPE_RT
- },
- { }
-};
-
/* l4 ls - mailbox */
struct omap_hwmod_ocp_if am33xx_l4_per__mailbox = {
.master = am33xx_l4_ls_hwmod,
.slave = am33xx_mailbox_hwmod,
.clk= l4ls_gclk,
- .addr = am33xx_mailbox_addrs,
.user = OCP_USER_MPU,
};
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] ARM: OMAP2+: Avoid mailbox legacy device creation for DT-boot
The legacy platform device for mailbox should not be created for
a DT boot, so adjust the platform device initialization logic
appropriately.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/devices.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 592ba0a..708eb7d 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -460,9 +460,9 @@ static int __init omap2_init_devices(void)
omap_init_audio();
omap_init_camera();
omap_init_hdmi_audio();
- omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
+ omap_init_mbox();
omap_init_mcspi();
omap_init_sham();
omap_init_aes();
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] ARM: OMAP4: hwmod_data: Remove legacy mailbox addrs
The legacy-style definition of the hwmod addr space is no longer
required after the addition of the OMAP4 mailbox DT node, so
clean up this data.
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson bcous...@baylibre.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 41e54f7..5e61b8c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4142,21 +4142,11 @@ static struct omap_hwmod_ocp_if omap44xx_l4_wkup__kbd =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-static struct omap_hwmod_addr_space omap44xx_mailbox_addrs[] = {
- {
- .pa_start = 0x4a0f4000,
- .pa_end = 0x4a0f41ff,
- .flags = ADDR_TYPE_RT
- },
- { }
-};
-
/* l4_cfg - mailbox */
static struct omap_hwmod_ocp_if omap44xx_l4_cfg__mailbox = {
.master = omap44xx_l4_cfg_hwmod,
.slave = omap44xx_mailbox_hwmod,
.clk= l4_div_ck,
- .addr = omap44xx_mailbox_addrs,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] ARM: DRA7: hwmod_data: Add mailbox hwmod data
Add the hwmod data for the 13 instances of the system mailbox
IP in DRA7 SoC. The patch is needed for performing a soft-reset
while configuring the respective mailbox instance, otherwise is
a non-essential change for functionality. The modules are smart
idled on reset, and the IP module mode is hardware controlled.
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 305 ++
1 file changed, 305 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 20b4398..e35f5b1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -939,6 +939,194 @@ static struct omap_hwmod dra7xx_i2c5_hwmod = {
};
/*
+ * 'mailbox' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_mailbox_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class dra7xx_mailbox_hwmod_class = {
+ .name = mailbox,
+ .sysc = dra7xx_mailbox_sysc,
+};
+
+/* mailbox1 */
+static struct omap_hwmod dra7xx_mailbox1_hwmod = {
+ .name = mailbox1,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX1_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX1_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox2 */
+static struct omap_hwmod dra7xx_mailbox2_hwmod = {
+ .name = mailbox2,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX2_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX2_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox3 */
+static struct omap_hwmod dra7xx_mailbox3_hwmod = {
+ .name = mailbox3,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX3_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX3_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox4 */
+static struct omap_hwmod dra7xx_mailbox4_hwmod = {
+ .name = mailbox4,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX4_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX4_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox5 */
+static struct omap_hwmod dra7xx_mailbox5_hwmod = {
+ .name = mailbox5,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX5_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX5_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox6 */
+static struct omap_hwmod dra7xx_mailbox6_hwmod = {
+ .name = mailbox6,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX6_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX6_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox7 */
+static struct omap_hwmod dra7xx_mailbox7_hwmod = {
+ .name = mailbox7,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX7_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX7_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox8 */
+static struct omap_hwmod dra7xx_mailbox8_hwmod = {
+ .name = mailbox8,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX8_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX8_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox9 */
+static struct omap_hwmod dra7xx_mailbox9_hwmod = {
+ .name
[PATCH 7/9] ARM: OMAP2: hwmod_data: Remove legacy mailbox data and addrs
OMAP2 devices are devicetree boot only, and the legacy mode
of mailbox device creation should no longer be used, so remove
the mailbox attribute data and the hwmod addr space used for
creating mailboxes in legacy mode.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 14 --
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 13 -
.../mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c| 9 -
arch/arm/mach-omap2/omap_hwmod_common_data.h | 1 -
4 files changed, 37 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 2f15979..65b1647 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -16,7 +16,6 @@
#include linux/i2c-omap.h
#include linux/platform_data/spi-omap2-mcspi.h
#include linux/omap-dma.h
-#include linux/platform_data/mailbox-omap.h
#include plat/dmtimer.h
#include omap_hwmod.h
@@ -163,18 +162,6 @@ static struct omap_hwmod omap2420_dma_system_hwmod = {
};
/* mailbox */
-static struct omap_mbox_dev_info omap2420_mailbox_info[] = {
- { .name = dsp, .tx_id = 0, .rx_id = 1, .irq_id = 0, .usr_id = 0 },
- { .name = iva, .tx_id = 2, .rx_id = 3, .irq_id = 1, .usr_id = 3 },
-};
-
-static struct omap_mbox_pdata omap2420_mailbox_attrs = {
- .num_users = 4,
- .num_fifos = 6,
- .info_cnt = ARRAY_SIZE(omap2420_mailbox_info),
- .info = omap2420_mailbox_info,
-};
-
static struct omap_hwmod omap2420_mailbox_hwmod = {
.name = mailbox,
.class = omap2xxx_mailbox_hwmod_class,
@@ -188,7 +175,6 @@ static struct omap_hwmod omap2420_mailbox_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
},
},
- .dev_attr = omap2420_mailbox_attrs,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 6d1b609..c2555cb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -17,7 +17,6 @@
#include linux/platform_data/asoc-ti-mcbsp.h
#include linux/platform_data/spi-omap2-mcspi.h
#include linux/omap-dma.h
-#include linux/platform_data/mailbox-omap.h
#include plat/dmtimer.h
#include omap_hwmod.h
@@ -161,17 +160,6 @@ static struct omap_hwmod omap2430_dma_system_hwmod = {
};
/* mailbox */
-static struct omap_mbox_dev_info omap2430_mailbox_info[] = {
- { .name = dsp, .tx_id = 0, .rx_id = 1 },
-};
-
-static struct omap_mbox_pdata omap2430_mailbox_attrs = {
- .num_users = 4,
- .num_fifos = 6,
- .info_cnt = ARRAY_SIZE(omap2430_mailbox_info),
- .info = omap2430_mailbox_info,
-};
-
static struct omap_hwmod omap2430_mailbox_hwmod = {
.name = mailbox,
.class = omap2xxx_mailbox_hwmod_class,
@@ -185,7 +173,6 @@ static struct omap_hwmod omap2430_mailbox_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
},
},
- .dev_attr = omap2430_mailbox_attrs,
};
/* mcspi3 */
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
index 0413dab..c1e98d5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
@@ -152,15 +152,6 @@ struct omap_hwmod_addr_space omap2_dma_system_addrs[] = {
{ }
};
-struct omap_hwmod_addr_space omap2_mailbox_addrs[] = {
- {
- .pa_start = 0x48094000,
- .pa_end = 0x48094000 + SZ_512 - 1,
- .flags = ADDR_TYPE_RT,
- },
- { }
-};
-
struct omap_hwmod_addr_space omap2_mcbsp1_addrs[] = {
{
.name = mpu,
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_common_data.h
index 2c38c6b..11ed5a1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.h
@@ -33,7 +33,6 @@ extern struct omap_hwmod_addr_space omap2_mcspi1_addr_space[];
extern struct omap_hwmod_addr_space omap2_mcspi2_addr_space[];
extern struct omap_hwmod_addr_space omap2430_mcspi3_addr_space[];
extern struct omap_hwmod_addr_space omap2_dma_system_addrs[];
-extern struct omap_hwmod_addr_space omap2_mailbox_addrs[];
extern struct omap_hwmod_addr_space omap2_mcbsp1_addrs[];
extern struct omap_hwmod_addr_space omap2_hdq1w_addr_space[];
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9]
On 06/24/2014 08:00 PM, Suman Anna wrote: Hi Tony, Paul, Please ignore this, resent the same message and the series with the proper subject. regards Suman This patch series adds the minimal mailbox DT nodes for the SoCs that are currently missing them (OMAP4, AM335x, DRA7). It also limits the legacy mailbox platform device creation only for non-DT boot, and cleans up the legacy hwmod addresses and attributes used for creating the sub-mailbox devices. The sub-mailboxes in DT boot are not created until the OMAP mailbox DT adoption series, and is not an issue since some of the other required hwmod data for using legacy-mode devices have already been cleaned up. The patches are based on 3.16-rc2. The series do not have any order dependencies with the OMAP mailbox cleanup series [1], and can be applied in any order. The following shows the boot logs on various OMAP platforms with just these patches on top of 3.16-rc2: OMAP2 (SDP2430) : http://slexy.org/view/s21gGdJxXP OMAP3 (BeagleXM) : http://slexy.org/view/s2n8Pc83Rp OMAP4 (PandaBoard): http://slexy.org/view/s21StNWKPz OMAP5 (OMAP5 uEVM): http://slexy.org/view/s2y3t6HZtk DRA7 (DRA7 EVM) : http://slexy.org/view/s2qY23Mt97 AM33xx (BeagleBone Black) : http://slexy.org/view/s2ce8jj35O AM43xx (AM437x GP EVM): http://slexy.org/view/s2nttmOLSq [1] http://marc.info/?l=linux-omapm=140365705821115w=2 Suman Anna (9): ARM: dts: OMAP4: Add mailbox node ARM: dts: AM33xx: Add mailbox node ARM: dts: AM4372: Correct mailbox node data ARM: dts: DRA7: Add mailbox nodes ARM: DRA7: hwmod_data: Add mailbox hwmod data ARM: OMAP2+: Avoid mailbox legacy device creation for DT-boot ARM: OMAP2: hwmod_data: Remove legacy mailbox data and addrs ARM: OMAP4: hwmod_data: Remove legacy mailbox addrs ARM: AM33xx: hwmod_data: Remove legacy mailbox addrs arch/arm/boot/dts/am33xx.dtsi | 7 + arch/arm/boot/dts/am4372.dtsi | 7 +- arch/arm/boot/dts/dra7.dtsi| 91 ++ arch/arm/boot/dts/omap4.dtsi | 7 + arch/arm/mach-omap2/devices.c | 2 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 14 - arch/arm/mach-omap2/omap_hwmod_2430_data.c | 13 - .../omap_hwmod_2xxx_3xxx_interconnect_data.c | 9 - .../omap_hwmod_33xx_43xx_interconnect_data.c | 10 - arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 - arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 305 + arch/arm/mach-omap2/omap_hwmod_common_data.h | 1 - 12 files changed, 412 insertions(+), 64 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] OMAP Mailbox framework adoption DT support
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-omapm=137582560717973w=2 [3] http://marc.info/?l=linux-omapm=140365705821115w=2 [4] http://marc.info/?l=linux-omapm=140365833121612w=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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] Documentation: dt: add omap mailbox bindings
Add the device tree bindings document for OMAP2+ mailbox.
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Suman Anna s-a...@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 000..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
[PATCH 2/6] mailbox/omap: add support for parsing dt devices
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 jassisinghb...@gmail.com
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Suman Anna s-a...@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
[PATCH 5/6] ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes
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 bcous...@baylibre.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Suman Anna s-a...@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 = 0x4884 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 = 0x4886 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
[PATCH 4/6] mailbox/omap: adapt to the new mailbox framework
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 jassisinghb...@gmail.com
Cc: Ohad Ben-Cohen o...@wizery.com
Cc: Omar Ramirez Luna omar.rami...@copitl.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Suman Anna s-a...@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 kfifofifo;
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
[PATCH 3/6] ARM: dts: OMAP2+: Add sub mailboxes device node information
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 bcous...@baylibre.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Suman Anna s-a...@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
[PATCH 6/6] mailbox/omap: add a custom of_xlate function
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 jassisinghb...@gmail.com
Signed-off-by: Suman Anna s-a...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: OMAP3: PRM/CM: Add back macros used by TI DSP/Bridge driver
The commit 7be914f {ARM: OMAP3: PRM/CM: Cleanup unused header} removed
some of the macros used by the TI DSP/Bridge driver. This fixes the
following build errors when trying to build DSP/Bridge driver (disabled
at present), otherwise results in the following build errors:
drivers/staging/tidspbridge/core/tiomap3430.c:531:31: error:
'OMAP3430_AUTO_IVA2_DPLL_SHIFT' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap3430.c:531:31: note: each undeclared
identifier is reported only once for each function it appears in
make[3]: *** [drivers/staging/tidspbridge/core/tiomap3430.o] Error 1
make[3]: *** Waiting for unfinished jobs
drivers/staging/tidspbridge/core/tiomap_io.c: In function 'sm_interrupt_dsp':
drivers/staging/tidspbridge/core/tiomap_io.c:404:31: error:
'OMAP3430_AUTO_IVA2_DPLL_SHIFT' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap_io.c:404:31: note: each undeclared
identifier is reported only once for each function it appears in
drivers/staging/tidspbridge/core/tiomap_io.c:414:12: error:
'OMAP3430_IVA2_DPLL_FREQSEL_SHIFT' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap_io.c:415:12: error:
'OMAP3430_EN_IVA2_DPLL_SHIFT' undeclared (first use in this function)
make[3]: *** [drivers/staging/tidspbridge/core/tiomap_io.o] Error 1
drivers/staging/tidspbridge/core/tiomap3430_pwr.c: In function
'dsp_clk_wakeup_event_ctrl':
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:442:19: error:
'OMAP3430_GRPSEL_GPT5_MASK' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:442:19: note: each undeclared
identifier is reported only once for each function it appears in
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:455:19: error:
'OMAP3430_GRPSEL_GPT6_MASK' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:468:19: error:
'OMAP3430_GRPSEL_GPT7_MASK' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:481:19: error:
'OMAP3430_GRPSEL_GPT8_MASK' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:494:19: error:
'OMAP3430_GRPSEL_MCBSP1_MASK' undeclared (first use in this function)
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:546:19: error:
'OMAP3430_GRPSEL_MCBSP5_MASK' undeclared (first use in this function)
make[3]: *** [drivers/staging/tidspbridge/core/tiomap3430_pwr.o] Error 1
make[2]: *** [drivers/staging/tidspbridge] Error 2
Fixes: 7be914f (ARM: OMAP3: PRM/CM: Cleanup unused header)
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/cm-regbits-34xx.h | 3 +++
arch/arm/mach-omap2/prm-regbits-34xx.h | 6 ++
2 files changed, 9 insertions(+)
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 04dab2f..ee6c784 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -26,11 +26,14 @@
#define OMAP3430_EN_WDT3_SHIFT 12
#define OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK (1 0)
#define OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_SHIFT 0
+#define OMAP3430_IVA2_DPLL_FREQSEL_SHIFT 4
#define OMAP3430_IVA2_DPLL_FREQSEL_MASK(0xf 4)
#define OMAP3430_EN_IVA2_DPLL_DRIFTGUARD_SHIFT 3
+#define OMAP3430_EN_IVA2_DPLL_SHIFT0
#define OMAP3430_EN_IVA2_DPLL_MASK (0x7 0)
#define OMAP3430_ST_IVA2_SHIFT 0
#define OMAP3430_ST_IVA2_CLK_MASK (1 0)
+#define OMAP3430_AUTO_IVA2_DPLL_SHIFT 0
#define OMAP3430_AUTO_IVA2_DPLL_MASK (0x7 0)
#define OMAP3430_IVA2_CLK_SRC_SHIFT19
#define OMAP3430_IVA2_CLK_SRC_WIDTH3
diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h
b/arch/arm/mach-omap2/prm-regbits-34xx.h
index 106132d..cbefbd7 100644
--- a/arch/arm/mach-omap2/prm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-34xx.h
@@ -35,6 +35,8 @@
#define OMAP3430_LOGICSTATEST_MASK (1 2)
#define OMAP3430_LASTLOGICSTATEENTERED_MASK(1 2)
#define OMAP3430_LASTPOWERSTATEENTERED_MASK(0x3 0)
+#define OMAP3430_GRPSEL_MCBSP5_MASK(1 10)
+#define OMAP3430_GRPSEL_MCBSP1_MASK(1 9)
#define OMAP3630_GRPSEL_UART4_MASK (1 18)
#define OMAP3430_GRPSEL_GPIO6_MASK (1 17)
#define OMAP3430_GRPSEL_GPIO5_MASK (1 16)
@@ -42,6 +44,10 @@
#define OMAP3430_GRPSEL_GPIO3_MASK (1 14)
#define OMAP3430_GRPSEL_GPIO2_MASK (1 13)
#define OMAP3430_GRPSEL_UART3_MASK (1 11)
+#define OMAP3430_GRPSEL_GPT8_MASK (1 9)
+#define OMAP3430_GRPSEL_GPT7_MASK (1 8)
+#define
[PATCH 3/3] ARM: OMAP2+: create dsp device only on OMAP3 SoCs
The DSP platform device for TI DSP/Bridge is currently
created unconditionally whenever CONFIG_TIDSPBRIDGE is
enabled. This device should only be created on OMAP34xx/
OMAP36xx SoCs, and not for other OMAP3 derived SoCs or when
booting multi-arch images on other SoCs. So, add a check for
the SoC family both before creating the device and allocating
the carveout memory for the device.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/dsp.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
index b8208b4..f7492df 100644
--- a/arch/arm/mach-omap2/dsp.c
+++ b/arch/arm/mach-omap2/dsp.c
@@ -29,6 +29,7 @@
#ifdef CONFIG_TIDSPBRIDGE_DVFS
#include omap-pm.h
#endif
+#include soc.h
#include linux/platform_data/dsp-omap.h
@@ -59,6 +60,9 @@ void __init omap_dsp_reserve_sdram_memblock(void)
phys_addr_t size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
phys_addr_t paddr;
+ if (!cpu_is_omap34xx())
+ return;
+
if (!size)
return;
@@ -83,6 +87,9 @@ static int __init omap_dsp_init(void)
int err = -ENOMEM;
struct omap_dsp_platform_data *pdata = omap_dsp_pdata;
+ if (!cpu_is_omap34xx())
+ return 0;
+
pdata-phys_mempool_base = omap_dsp_get_mempool_base();
if (pdata-phys_mempool_base) {
@@ -115,6 +122,9 @@ module_init(omap_dsp_init);
static void __exit omap_dsp_exit(void)
{
+ if (!cpu_is_omap34xx())
+ return;
+
platform_device_unregister(omap_dsp_pdev);
}
module_exit(omap_dsp_exit);
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Misc. DSPBridge build/boot fixes
Hi, The following are couple of miscellaneous patches for fixing build and boot issues when I attempted to build TI DSP/Bridge while doing the adaptation and validation of OMAP mailbox driver against the mailbox framework. The DSP/Bridge driver is disabled by default, so these can be treated as non-urgent fixes. Suman Anna (3): staging: tidspbridge: fix an erroneous removal of parentheses ARM: OMAP3: PRM/CM: Add back macros used by TI DSP/Bridge driver ARM: OMAP2+: create dsp device only on OMAP3 SoCs arch/arm/mach-omap2/cm-regbits-34xx.h | 3 +++ arch/arm/mach-omap2/dsp.c | 10 ++ arch/arm/mach-omap2/prm-regbits-34xx.h| 6 ++ drivers/staging/tidspbridge/core/tiomap3430.c | 6 -- 4 files changed, 23 insertions(+), 2 deletions(-) -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] staging: tidspbridge: fix an erroneous removal of parentheses
Commit 4a9fdbb (staging: core: tiomap3430.c Fix line over 80 characters.) erroneously removed the parentheses around the function pointer leading to the following build error (when enabling the build of TI DSP/Bridge driver): drivers/staging/tidspbridge/core/tiomap3430.c: In function 'bridge_brd_monitor': drivers/staging/tidspbridge/core/tiomap3430.c:283:10: error: invalid type argument of unary '*' (have 'u32') make[3]: *** [drivers/staging/tidspbridge/core/tiomap3430.o] Error 1 Fix this build error properly. Fixes: 4a9fdbb (staging: core: tiomap3430.c Fix line over 80 characters.) Cc: Aybuke Ozdemir aybuke@gmail.com Cc: Peter P Waskiewicz Jr peter.p.waskiewicz...@intel.com Cc: Omar Ramirez Luna omar.rami...@copitl.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Signed-off-by: Suman Anna s-a...@ti.com --- drivers/staging/tidspbridge/core/tiomap3430.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c b/drivers/staging/tidspbridge/core/tiomap3430.c index 8945b4e..cb50120 100644 --- a/drivers/staging/tidspbridge/core/tiomap3430.c +++ b/drivers/staging/tidspbridge/core/tiomap3430.c @@ -280,8 +280,10 @@ static int bridge_brd_monitor(struct bridge_dev_context *dev_ctxt) OMAP3430_IVA2_MOD, OMAP2_CM_CLKSTCTRL); /* Wait until the state has moved to ON */ - while (*pdata-dsp_prm_read(OMAP3430_IVA2_MOD, OMAP2_PM_PWSTST) - OMAP_INTRANSITION_MASK); + while ((*pdata-dsp_prm_read)(OMAP3430_IVA2_MOD, + OMAP2_PM_PWSTST) + OMAP_INTRANSITION_MASK) + ; /* Disable Automatic transition */ (*pdata-dsp_cm_write)(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, OMAP3430_IVA2_MOD, OMAP2_CM_CLKSTCTRL); -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [v2 Patch 2/6] ARM: TI: Describe the ti reset DT entries
Dan,
On 05/06/2014 08:18 AM, Murphy, Dan wrote:
Tony
Thanks for the comments
On 05/05/2014 05:01 PM, Tony Lindgren wrote:
* Dan Murphy dmur...@ti.com [140505 13:10]:
+
+Required parent properties:
+- compatible : Should be one of,
+ ti,omap4-prm for OMAP4 PRM instances
+ ti,omap5-prm for OMAP5 PRM instances
+ ti,dra7-prm for DRA7xx PRM instances
+ ti,am4-prcm for AM43xx PRCM instances
+ ti,am3-prcm for AM33xx PRCM instances
+
+Required child reset property:
+- compatible : Should be
+ resets for All TI SoCs
+
+example:
+ prm: prm@4ae06000 {
+ compatible = ti,omap5-prm;
+ reg = 0x4ae06000 0x3000;
+
+ prm_resets: resets {
+ #address-cells = 1;
+ #size-cells = 1;
+ #reset-cells = 1;
+ };
+ };
The reg entries you have in the example below has different format
compared to this?
Right, the #size-cells should have been 0, or each reg field updated
with an additional field value of 4 as the registers are all of constant
width - 4 bytes.
This is the parent to the resets. The reg entries below are for
the child reset signals.
+Reset node declaration
+==
+The reset node is declared in a parent child relationship. The main parent
+is the PRCM module which contains the base address. The first child within
+the reset parent declares the target modules reset name. This is followed
by
+the control and status offsets.
+
+Within the first reset child node is a secondary child node which declares
the
+reset signal of interest. Under this node the control and status bits
+are declared. These bits declare the bit mask for the target reset.
+
+
+Required properties:
+reg - This is the register offset from the PRCM parent.
+ This must be declared as:
+
+ reg = control register offset,
+ status register offset;
+
+control-bit - This is the bit within the register which controls the reset
+ of the target module. This is declared as a bit mask for the register.
+status-bit - This is the bit within the register which contains the status
of
+ the reset of the target module.
+ This is declared as a bit mask for the register.
+
+example:
+prm_resets {
+ dsp_rstctrl {
+ reg = 0x1c00,
+ 0x1c04;
Shouldn't this be start and size instead of start and end here?
These are two registers - one for control and one for status.
I could do start and size. But the size will be the same for each register.
AM33xx really hurts the consistency model here as the other patches in the
series
it appears that the control and status are consistent but AM33xx the
registers are all over
the place.
I have not looked at OMAP2-4 yet for control and status register offsets.
+ dsp_reset: dsp_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+};
Are the control-bit and status-bit always the same? If so, you can
keep that knowlede private to the the driver.
No there is a case in the am33xx resets file where the status and control
bits are not the same.
Do we really need two separate properties to represent this, as these
are essentially the relevant bits in the corresponding reg elements.
I guess this is somewhat same as Tony's suggestion about using the reg
field for these sub-nodes, in which case, you would have to add another
#address-cells as 1 for each of the child reset nodes.
regards
Suman
And maybe you can have the bit offset in a reg property here to
avoid adding any custom properties? Something like:
dsp_reset: reset@1 {
reg = 1;
};
If reg is not suitable for that, it seems that some generic property
to describe the bit offset is needed by quite a few drivers
anyways, for things like clocks and regulators.
I will have to look into this. Maybe a generic entry called bit-offset
that defines the bit or a mask for the registers. It can mimic the reg
entry.
+Client Node Declaration
+==
+This is the consumer of the parent node to declare what resets this
+particular module is interested in.
+
+example:
+ src: src@55082000 {
+ resets = reset_src phandle;
+ reset-names = reset_name;
+ };
+
+Required Properties:
+reset_src - This is the parent DT entry for the reset controller
+phandle - This is the phandle of the specific reset to be used by the clien
+ driver.
+reset-names - This is the reset name of module that the device driver
+ needs to be able to reset. This value must correspond to a value within
+ the reset controller array.
+
+example:
+resets = prm_resets dsp_mmu_reset;
+reset-names =
Re: [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
Hi Josh,
On 05/05/2014 04:54 PM, Josh Cartwright wrote:
On Mon, May 05, 2014 at 04:44:25PM -0500, Suman Anna wrote:
Hi Rob,
On 04/30/2014 07:34 PM, Suman Anna wrote:
The property 'hwlock-reserved-locks' will be used to represent
the number of locks to be reserved for clients that would need
to request/operate on specific locks. A new OF helper function,
of_hwspin_lock_get_num_reserved_locks(), is added to minimize
duplication in different platform implementations.
The function will return a value of 0 if the property is not
defined, so as to support a default behavior of marking all
locks as unused and open for anonymous allocations.
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/hwlock.txt | 3 +++
drivers/hwspinlock/hwspinlock_core.c | 25
++
include/linux/hwspinlock.h | 1 +
3 files changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
index d538a9b..88d16d2 100644
--- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -18,6 +18,9 @@ Common properties:
property is needed on hwlock devices, where the number
of supported locks within a hwlock device cannot be
read from a register.
+- hwlock-reserved-locks: Number of locks to reserve for clients requiring
+ specific locks. This value cannot exceed the value of
+ hwlock-num-locks.
Any suggestions here on the approach? This property falls into a gray
area as well, as the current approach is somewhat limiting (it doesn't
support sparse reserved locks, and expects them at the beginning of the
lock range).
Is it possible to implement a pinctrl-like hogging approach, whereby the
specific locks that need to be reserved are consumed by the controller
itself?
Thanks for the suggestion. I did take a look at pinctrl and while it is
possible to implement something similar, I feel it is a bit heavy for
hwspinlock framework with no added advantages. It requires that the
controller and clients always need to be updated together. Ohad had
already brought this up [1]. Here's an alternate approach that does not
require any additional property to the controller itself, while the
client node usage is as before. The logic is based on parsing through
the DT blob and marking only those that are used by any clients. The RFC
patch below is a replacement for Patches 11 to 15, and do not require
any changes to platform implementations or additional DT properties.
It currently marks locks as reserved even for disabled client nodes
(very easy to change that behavior). It will also impose a standard
property name hwlocks on the client nodes. What do you think of this
approach?
regards
Suman
[1] http://marc.info/?l=linux-omapm=139514977622964w=2
From 4f4cbe91e56c1be8faa6a3ee863add4df6e6714b Mon Sep 17 00:00:00 2001
From: Suman Anna s-a...@ti.com
Date: Fri, 9 May 2014 14:26:54 -0500
Subject: [RFC PATCH] hwspinlock/core: add support for reserved locks
The HwSpinlock core allows requesting either a specific lock or an
available normal lock. The specific locks are usually reserved during
board init time, while the normal available locks are intended to be
assigned at runtime.
The HwSpinlock core has been enhanced to mark certain locks as 'reserved'
by parsing through the DT blob. Thes
The HwSpinlock core has been enhanced to:
1. mark certain locks as 'reserved' by parsing the DT blob for any
locks used by client nodes.
2. restrict the anonymous hwspin_lock_request() API to allocate only
from non-reserved locks for DT boots.
3. limit these reserved locks to be allocated only using the
_request_specific() API variants for DT boots.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/hwspinlock_core.c | 50
++--
1 file changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index c2063bc..0c924c9 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -425,6 +425,42 @@ static int hwspinlock_device_add(struct
hwspinlock_device *bank)
return ret;
}
+static void hwspin_mark_reserved_locks(struct hwspinlock_device *bank)
+{
+ struct device_node *np = bank-dev-of_node;
+ const char *prop_name = hwlocks;
+ const char *cells_name = #hwlock-cells;
+ struct device_node *node = NULL;
+ struct of_phandle_args args;
+ struct hwspinlock *hwlock;
+ int i, id, count, ret;
+
+ for_each_node_with_property(node, prop_name) {
+ count = of_count_phandle_with_args(node, prop_name,
cells_name);
+ if (count = 0)
+ continue
Re: [PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT
Hi Rob, On 05/05/2014 03:37 PM, Rob Herring wrote: On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna s-a...@ti.com wrote: The HwSpinlock core requires a base id for registering a bank of hwspinlocks. This base id needs to be unique across multiple IP instances of a hwspinlock device, so that each hwlock can be represented uniquely in a system. Support has been added to represent this in DT through a common property 'hwlock-base-id', and retrieve the value through a core OF helper function, of_hwspin_lock_get_base_id(). The representation in DT provides a uniform way of assigning a fixed base value for a hwspinlock device across different SoCs. Signed-off-by: Suman Anna s-a...@ti.com --- Documentation/devicetree/bindings/hwlock/hwlock.txt | 6 ++ drivers/hwspinlock/hwspinlock_core.c| 21 + include/linux/hwspinlock.h | 1 + 3 files changed, 28 insertions(+) diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt index 32381cc..d538a9b 100644 --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt @@ -18,6 +18,12 @@ Common properties: property is needed on hwlock devices, where the number of supported locks within a hwlock device cannot be read from a register. +- hwlock-base-id: An unique base Id for the locks for a particular hwlock + device. This property is mandatory ONLY if a SoC has + several hwlock devices. + + See documentation on struct hwspinlock_pdata in + include/linux/hwspinlock.h for more details. The documentation cannot refer to kernel files. OK, good to know. There are couple of such existing references, so didn't think it was an issue. I will fold this patch and remove the kernel reference if this property is ok to add. Generally, creating a global number space like this would not be accepted, but I don't really have any better idea here. Please put all binding docs in 1 patch and copy all the DT binding maintainers. I have deliberately put these in separate patches (as RFC) as there doesn't seem to be a consensus on this. I had added this originally, dropped it and brought it back again based on discussion on the previous version. Intention was either to fold into the original patch if accepted or drop them and revisit later. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
Hi Rob,
On 04/30/2014 07:34 PM, Suman Anna wrote:
The property 'hwlock-reserved-locks' will be used to represent
the number of locks to be reserved for clients that would need
to request/operate on specific locks. A new OF helper function,
of_hwspin_lock_get_num_reserved_locks(), is added to minimize
duplication in different platform implementations.
The function will return a value of 0 if the property is not
defined, so as to support a default behavior of marking all
locks as unused and open for anonymous allocations.
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/hwlock.txt | 3 +++
drivers/hwspinlock/hwspinlock_core.c | 25
++
include/linux/hwspinlock.h | 1 +
3 files changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
index d538a9b..88d16d2 100644
--- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -18,6 +18,9 @@ Common properties:
property is needed on hwlock devices, where the number
of supported locks within a hwlock device cannot be
read from a register.
+- hwlock-reserved-locks: Number of locks to reserve for clients requiring
+ specific locks. This value cannot exceed the value of
+ hwlock-num-locks.
Any suggestions here on the approach? This property falls into a gray
area as well, as the current approach is somewhat limiting (it doesn't
support sparse reserved locks, and expects them at the beginning of the
lock range).
regards
Suman
- hwlock-base-id:An unique base Id for the locks for a particular hwlock
device. This property is mandatory ONLY if a SoC has
several hwlock devices.
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index e05cea8..e74b55b 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -286,6 +286,31 @@ int of_hwspin_lock_get_base_id(struct device_node *dn)
EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
/**
+ * of_hwspin_lock_get_num_reserved_locks() - retrieve number of reserved
locks
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying
platform
+ * specific implementations, to retrieve the number of locks to reserve from
+ * the hwspinlock device instance's base id. The hwlock-reserved-locks DT
+ * property needs to be defined for requesting any DT-based locks.
+ *
+ * Returns a positive number of locks on success, a default value of 0 if the
+ * property is missing or an appropriate error code as returned by the OF
layer
+ */
+int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn)
+{
+ unsigned int val = 0;
+ int ret;
+
+ ret = of_property_read_u32(dn, hwlock-reserved-locks, val);
+ if (!ret || ret == -EINVAL)
+ ret = val;
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_num_reserved_locks);
+
+/**
* of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
* @dn: device node pointer
*
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index d120035..d18431f 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -69,6 +69,7 @@ int of_hwspin_lock_simple_xlate(struct hwspinlock_device
*bank,
const struct of_phandle_args *hwlock_spec);
int of_hwspin_lock_get_base_id(struct device_node *dn);
int of_hwspin_lock_get_num_locks(struct device_node *dn);
+int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn);
int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
const struct hwspinlock_ops *ops, int base_id, int num_locks,
int num_reserved_locks);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock
Hi Rob,
On 05/02/2014 09:58 AM, Rob Herring wrote:
On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna s-a...@ti.com wrote:
This patch adds the generic common bindings used to represent
a hwlock device and use/request locks in a device-tree build.
All the platform-specific hwlock driver implementations need the
number of locks and associated base id for registering the locks
present within the device with the driver core. The number of locks
is represented by 'hwlock-num-locks' property in DT bindings. A
property for base id is not needed in DT binding, as it can be
satisfied using a phandle + args specifier. The args specifier
length is dependent on each vendor-specific implementation and
is represented through the '#hwlock-cells' property.
Note that the document is named hwlock.txt deliberately to keep it
a bit more generic.
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/hwlock.txt | 52
++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
new file mode 100644
index 000..32381cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,52 @@
+Generic hwlock bindings
+===
+
+Generic bindings that are common to all the hwlock platform specific driver
+implementations, the retrieved values are used for registering the device
+specific parameters with the hwspinlock core.
+
+The validity and need of these common properties may vary from one platform
+implementation to another. The platform specific bindings should explicitly
+state if a property is mandatory or optional. Please look through the
+individual platform specific hwlock binding documentations for identifying
+the applicable properties.
+
+Common properties:
+- #hwlock-cells: Specifies the number of cells needed to represent a
+ specific lock.
This should never be optional.
Thanks for reviewing this. I can add a statement here to make this clear.
+- hwlock-num-locks:Number of locks present in a hwlock device. This
+ property is needed on hwlock devices, where the
number
+ of supported locks within a hwlock device cannot be
+ read from a register.
Do you have any users of this? The omap binding doesn't use it.
Wouldn't you typically know this based on the IP block? Similarly you
typically don't have to list how many irqs an interrupt controller
has.
The MSM Spinlock driver [1] would be using this, it is waiting on this
series to get finalized. It currently defines a custom property, and the
number of locks is a generic property that the hwspinlock core uses and
is common to different platform implementations, so created the generic
property. OMAP doesn't use this because the number is read directly off
a IP register.
can you also take a look at patches 8 and 12 as they add additional
properties based on discussion in [2]. The hwspinlocks are used for
arbitration between different initiators on an SoC, and typically would
need a SoC-level identifier for each lock. All these properties allow a
hwlock to be statically identified and be assigned to a user and its
peer user on a different initiator, and not allowing them to be run-time
assigned.
regards
Suman
[1] https://lkml.org/lkml/2013/8/14/528
[2] http://marc.info/?l=linux-omapm=139510004009415w=2
+
+Hwlock Users:
+=
+
+Nodes that require specific hwlock(s) should specify them using one or more
+properties, each containing a phandle to the hwlock node and an args
specifier
+value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
+an array of the phandle and hwlock number specifier tuple.
+
+1. Example of a node using a single specific hwlock:
+
+The following example has a node requesting a hwlock in the bank defined by
+the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
+of length 1.
+
+ node {
+ ...
+ hwlocks = hwlock1 2;
+ ...
+ };
+
+2. Example of a node using multiple specific hwlocks:
+
+The following example has a node requesting two hwlocks, a hwlock within
+the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
+hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of
2.
+
+ node {
+ ...
+ hwlocks = hwlock1 2, hwlock2 0 3;
+ ...
+ };
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 RFC 10/15] hwspinlock/core: prepare core to support reserved locks
The HwSpinlock core allows requesting either a specific lock or
an available normal lock. The specific locks are usually reserved
during board init time, while the normal available locks are
intended to be assigned at runtime.
This patch prepares the hwspinlock core to support this concept
of reserved locks. A new element is added to struct hwlock to
identify whether it is reserved to be allocated using the
hwspin_lock_request_specific() variants or available for dynamic
allocation. A new tag name, HWSPINLOCK_RESERVED, is introduced
to mark the reserved locks as such.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/hwspinlock_core.c | 14 --
drivers/hwspinlock/hwspinlock_internal.h | 2 ++
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index ed47e77..c2063bc 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -33,6 +33,7 @@
/* radix tree tags */
#define HWSPINLOCK_UNUSED (0) /* tags an hwspinlock as unused */
+#define HWSPINLOCK_RESERVED(1) /* tags an hwspinlock as reserved */
/*
* A radix tree is used to maintain the available hwspinlock instances.
@@ -326,7 +327,7 @@ static int hwspin_lock_register_single(struct hwspinlock
*hwlock, int id)
}
/* mark this hwspinlock as available */
- tmp = radix_tree_tag_set(hwspinlock_tree, id, HWSPINLOCK_UNUSED);
+ tmp = radix_tree_tag_set(hwspinlock_tree, id, hwlock-type);
/* self-sanity check which should never fail */
WARN_ON(tmp != hwlock);
@@ -344,7 +345,7 @@ static int hwspin_lock_unregister_single(struct hwspinlock
*hwlock, int id)
mutex_lock(hwspinlock_tree_lock);
/* make sure the hwspinlock is not in use (tag is set) */
- if (!radix_tree_tag_get(hwspinlock_tree, id, HWSPINLOCK_UNUSED)) {
+ if (!radix_tree_tag_get(hwspinlock_tree, id, hwlock-type)) {
pr_err(hwspinlock %d still in use (or not present)\n, id);
ret = -EBUSY;
goto out;
@@ -467,6 +468,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
spin_lock_init(hwlock-lock);
hwlock-bank = bank;
+ hwlock-type = HWSPINLOCK_UNUSED;
ret = hwspin_lock_register_single(hwlock, base_id + i);
if (ret)
@@ -551,7 +553,7 @@ static int __hwspin_lock_request(struct hwspinlock *hwlock)
/* mark hwspinlock as used, should not fail */
tmp = radix_tree_tag_clear(hwspinlock_tree, hwlock_to_id(hwlock),
- HWSPINLOCK_UNUSED);
+ hwlock-type);
/* self-sanity check that should never fail */
WARN_ON(tmp != hwlock);
@@ -650,7 +652,7 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned
int id)
WARN_ON(hwlock_to_id(hwlock) != id);
/* make sure this hwspinlock is unused */
- ret = radix_tree_tag_get(hwspinlock_tree, id, HWSPINLOCK_UNUSED);
+ ret = radix_tree_tag_get(hwspinlock_tree, id, hwlock-type);
if (ret == 0) {
pr_warn(hwspinlock %u is already in use\n, id);
hwlock = NULL;
@@ -741,7 +743,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
/* make sure the hwspinlock is used */
ret = radix_tree_tag_get(hwspinlock_tree, hwlock_to_id(hwlock),
- HWSPINLOCK_UNUSED);
+ hwlock-type);
if (ret == 1) {
dev_err(dev, %s: hwlock is already free\n, __func__);
dump_stack();
@@ -756,7 +758,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
/* mark this hwspinlock as available */
tmp = radix_tree_tag_set(hwspinlock_tree, hwlock_to_id(hwlock),
- HWSPINLOCK_UNUSED);
+ hwlock-type);
/* sanity check (this shouldn't happen) */
WARN_ON(tmp != hwlock);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h
b/drivers/hwspinlock/hwspinlock_internal.h
index 5e42613..1be32ca 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -47,11 +47,13 @@ struct hwspinlock_ops {
* struct hwspinlock - this struct represents a single hwspinlock instance
* @bank: the hwspinlock_device structure which owns this lock
* @lock: initialized and used by hwspinlock core
+ * @type: type of lock, used to distinguish regular locks from reserved locks
* @priv: private data, owned by the underlying platform-specific hwspinlock
drv
*/
struct hwspinlock {
struct hwspinlock_device *bank;
spinlock_t lock;
+ unsigned int type;
void *priv;
};
--
1.9.2
[PATCHv5 RFC 14/15] hwspinlock/core: return ERR_PTRs on failure in _request_ api
The various hwspin_lock_request* interfaces return a NULL pointer
on error, or a valid hwlock pointer on success. It is standard
practice to pass the error value back to the consumers on failure
cases, so change the functions to return an equivalent ERR_PTR()
value instead of NULL. The regular client api functions are
also modified to check for an invalid hwlock handle.
The consumers MUST check using IS_ERR() when requesting hwlocks
going forward to determine a valid hwlock.
Signed-off-by: Suman Anna s-a...@ti.com
---
TODO: Move this patch before the Patch4,
hwspinlock/core: add common OF helpers
if accepted to go with the current series
---
Documentation/hwspinlock.txt | 12 ++--
drivers/hwspinlock/hwspinlock_core.c | 25 ++---
2 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 903d477..bf1c7e46 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -35,15 +35,15 @@ independent, drivers.
2. User API
struct hwspinlock *hwspin_lock_request(void);
- - dynamically assign an hwspinlock and return its address, or NULL
- in case an unused hwspinlock isn't available. Users of this
+ - dynamically assign a hwspinlock and return its address, or an equivalent
+ ERR_PTR() in case an unused hwspinlock isn't available. Users of this
API will usually want to communicate the lock's id to the remote core
before it can be used to achieve synchronization.
Should be called from a process context (might sleep).
struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
- - assign a specific hwspinlock id and return its address, or NULL
- if that hwspinlock is already in use. Usually board code will
+ - assign a specific hwspinlock id and return its address, or an equivalent
+ ERR_PTR() if that hwspinlock is already in use. Usually board code will
be calling this function in order to reserve specific hwspinlock
ids for predefined purposes.
Should be called from a process context (might sleep).
@@ -172,7 +172,7 @@ int hwspinlock_example1(void)
/* dynamically assign a hwspinlock */
hwlock = hwspin_lock_request();
- if (!hwlock)
+ if (IS_ERR(hwlock))
...
id = hwspin_lock_get_id(hwlock);
@@ -208,7 +208,7 @@ int hwspinlock_example2(void)
* by board init code.
*/
hwlock = hwspin_lock_request_specific(PREDEFINED_LOCK_ID);
- if (!hwlock)
+ if (IS_ERR(hwlock))
...
/* try to take it, but don't spin on it */
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index e74b55b..56c4303 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -96,7 +96,7 @@ int __hwspin_trylock(struct hwspinlock *hwlock, int mode,
unsigned long *flags)
{
int ret;
- BUG_ON(!hwlock);
+ BUG_ON(IS_ERR_OR_NULL(hwlock));
BUG_ON(!flags mode == HWLOCK_IRQSTATE);
/*
@@ -235,7 +235,7 @@ EXPORT_SYMBOL_GPL(__hwspin_lock_timeout);
*/
void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
{
- BUG_ON(!hwlock);
+ BUG_ON(IS_ERR_OR_NULL(hwlock));
BUG_ON(!flags mode == HWLOCK_IRQSTATE);
/*
@@ -600,7 +600,7 @@ static int __hwspin_lock_request(struct hwspinlock *hwlock)
*/
int hwspin_lock_get_id(struct hwspinlock *hwlock)
{
- if (!hwlock) {
+ if (IS_ERR_OR_NULL(hwlock)) {
pr_err(invalid hwlock\n);
return -EINVAL;
}
@@ -620,7 +620,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_get_id);
*
* Should be called from a process context (might sleep)
*
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent ERR_PTR()
+ * on error
*/
struct hwspinlock *hwspin_lock_request(void)
{
@@ -634,7 +635,7 @@ struct hwspinlock *hwspin_lock_request(void)
0, 1, HWSPINLOCK_UNUSED);
if (ret == 0) {
pr_warn(a free hwspinlock is not available\n);
- hwlock = NULL;
+ hwlock = ERR_PTR(-ENXIO);
goto out;
}
@@ -644,7 +645,7 @@ struct hwspinlock *hwspin_lock_request(void)
/* mark as used and power up */
ret = __hwspin_lock_request(hwlock);
if (ret 0)
- hwlock = NULL;
+ hwlock = ERR_PTR(ret);
out:
mutex_unlock(hwspinlock_tree_lock);
@@ -663,7 +664,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_request);
*
* Should be called from a process context (might sleep)
*
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent
+ * ERR_PTR() on error
*/
struct hwspinlock
[PATCHv5 RFC 13/15] hwspinlock/omap: use OF helper to get reserved locks
Retrieve the number of reserved locks for OMAP by using the
of_hwspin_lock_get_num_reserved_locks() OF helper function
provided by the hwspinlock core. The range sanity check will
be performed by the hwspinlock core during the registration.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/omap_hwspinlock.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 1d0c78e..0dad783 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -143,6 +143,12 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
for (i = 0, hwlock = bank-lock[0]; i num_locks; i++, hwlock++)
hwlock-priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
+ reserved_locks = of_hwspin_lock_get_num_reserved_locks(node);
+ if (reserved_locks 0) {
+ ret = -EINVAL;
+ goto iounmap_base;
+ }
+
ret = hwspin_lock_register(bank, pdev-dev, omap_hwspinlock_ops,
base_id, num_locks, reserved_locks);
if (ret)
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 RFC 15/15] hwspinlock/core: change return codes of_hwspin_lock_request_specific
Changed the return statements to return an ERR_PTR instead of NULL in case of an error. This patch helps with deferred probing of any client users if the corresponding hwspinlock bank is not yet registered with the hwspinlock core. Signed-off-by: Suman Anna s-a...@ti.com --- TODO: Collapse into Patch4, hwspinlock/core: add common OF helpers if accepted to go with the current series --- Documentation/hwspinlock.txt | 4 ++-- drivers/hwspinlock/hwspinlock_core.c | 9 + 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt index bf1c7e46..10d7ecc 100644 --- a/Documentation/hwspinlock.txt +++ b/Documentation/hwspinlock.txt @@ -50,8 +50,8 @@ independent, drivers. struct hwspinlock *of_hwspin_lock_request_specific( struct device_node *np, const char *propname, int index); - - assign a specific hwspinlock id and return its address, or NULL - if that hwspinlock is already in use. This function is the OF + - assign a specific hwspinlock id and return its address, or an equivalent + ERR_PTR() if that hwspinlock is already in use. This function is the OF equivalent of hwspin_lock_request_specific() function, and provides a means for users of the hwspinlock module to request a specific hwspinlock using the phandle of the hwspinlock device. diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c index 56c4303..a838dbd 100644 --- a/drivers/hwspinlock/hwspinlock_core.c +++ b/drivers/hwspinlock/hwspinlock_core.c @@ -722,7 +722,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_request_specific); * lock number is indexed relative to the hwspinlock device, unlike the * hwspin_lock_request_specific() which is an absolute lock number. * - * Returns the address of the assigned hwspinlock, or NULL on error + * Returns the address of the assigned hwspinlock, or an equivalent + * ERR_PTR() on error */ struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np, const char *propname, @@ -736,7 +737,7 @@ struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np, ret = of_parse_phandle_with_args(np, propname, #hwlock-cells, index, args); if (ret) - return NULL; + return ERR_PTR(ret); mutex_lock(hwspinlock_tree_lock); list_for_each_entry(bank, hwspinlock_devices, list) @@ -744,11 +745,11 @@ struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np, break; mutex_unlock(hwspinlock_tree_lock); if (bank-list == hwspinlock_devices) - return NULL; + return ERR_PTR(-EPROBE_DEFER); id = bank-ops-of_xlate(bank, args); if (id 0 || id = bank-num_locks) - return NULL; + return ERR_PTR(-EINVAL); id += bank-base_id; return hwspin_lock_request_specific(id); -- 1.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 07/15] hwspinlock/omap: enable build for AM33xx, AM43xx DRA7xx
HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC device families as well. The IPs are identical to that of OMAP4/OMAP5, except for the number of locks. Add a depends on to the above family of SoCs to enable the build support for OMAP hwspinlock driver for any of the above SoC configs. Signed-off-by: Suman Anna s-a...@ti.com --- drivers/hwspinlock/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig index 70637d2..3612cb5 100644 --- a/drivers/hwspinlock/Kconfig +++ b/drivers/hwspinlock/Kconfig @@ -10,7 +10,7 @@ menu Hardware Spinlock drivers config HWSPINLOCK_OMAP tristate OMAP Hardware Spinlock device - depends on ARCH_OMAP4 || SOC_OMAP5 + depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || SOC_AM43XX select HWSPINLOCK help Say y here to support the OMAP Hardware Spinlock device (firstly -- 1.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 RFC 09/15] hwspinlock/core: prepare unregister code to support reserved locks
Rearrange the code between hwspin_lock_unregister() and the underlying
hwspin_lock_unregister_single() functions so that the semantics are
similar to the _register_ functions. This change prepares the hwspinlock
driver core to support unregistration of reserved locks better.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/hwspinlock_core.c | 37 +++-
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 4be1664..ed47e77 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -336,29 +336,33 @@ out:
return 0;
}
-static struct hwspinlock *hwspin_lock_unregister_single(unsigned int id)
+static int hwspin_lock_unregister_single(struct hwspinlock *hwlock, int id)
{
- struct hwspinlock *hwlock = NULL;
- int ret;
+ struct hwspinlock *tmp = NULL;
+ int ret = 0;
mutex_lock(hwspinlock_tree_lock);
/* make sure the hwspinlock is not in use (tag is set) */
- ret = radix_tree_tag_get(hwspinlock_tree, id, HWSPINLOCK_UNUSED);
- if (ret == 0) {
+ if (!radix_tree_tag_get(hwspinlock_tree, id, HWSPINLOCK_UNUSED)) {
pr_err(hwspinlock %d still in use (or not present)\n, id);
+ ret = -EBUSY;
goto out;
}
- hwlock = radix_tree_delete(hwspinlock_tree, id);
- if (!hwlock) {
+ tmp = radix_tree_delete(hwspinlock_tree, id);
+ if (!tmp) {
pr_err(failed to delete hwspinlock %d\n, id);
+ ret = -EIO;
goto out;
}
+ /* self-sanity check that should never fail */
+ WARN_ON(tmp != hwlock);
+
out:
mutex_unlock(hwspinlock_tree_lock);
- return hwlock;
+ return ret;
}
/**
@@ -472,8 +476,10 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
return 0;
reg_failed:
- while (--i = 0)
- hwspin_lock_unregister_single(base_id + i);
+ while (--i = 0) {
+ hwlock = bank-lock[i];
+ hwspin_lock_unregister_single(hwlock, base_id + i);
+ }
mutex_lock(hwspinlock_tree_lock);
list_del(bank-list);
mutex_unlock(hwspinlock_tree_lock);
@@ -494,18 +500,15 @@ EXPORT_SYMBOL_GPL(hwspin_lock_register);
*/
int hwspin_lock_unregister(struct hwspinlock_device *bank)
{
- struct hwspinlock *hwlock, *tmp;
- int i;
+ struct hwspinlock *hwlock;
+ int i, ret;
for (i = 0; i bank-num_locks; i++) {
hwlock = bank-lock[i];
- tmp = hwspin_lock_unregister_single(bank-base_id + i);
- if (!tmp)
+ ret = hwspin_lock_unregister_single(hwlock, bank-base_id + i);
+ if (ret)
return -EBUSY;
-
- /* self-sanity check that should never fail */
- WARN_ON(tmp != hwlock);
}
mutex_lock(hwspinlock_tree_lock);
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 RFC 11/15] hwspinlock/core: add support for reserved locks
The HwSpinlock core allows requesting either a specific lock or an
available normal lock. The specific locks are usually reserved during
board init time, while the normal available locks are intended to be
assigned at runtime.
The HwSpinlock core has been enhanced to:
1. allow the platform implementations to register a set of 'reserved'
locks
2. restrict the anonymous hwspin_lock_request() API to allocate only
from non-reserved locks
3. limit these reserved locks to be allocated only using the
_request_specific() API variants.
The existing platform implementations have also been updated to adjust
for the change of the registration API.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/hwspinlock_core.c | 20
drivers/hwspinlock/hwspinlock_internal.h | 3 +++
drivers/hwspinlock/omap_hwspinlock.c | 4 ++--
drivers/hwspinlock/u8500_hsem.c | 3 ++-
include/linux/hwspinlock.h | 10 +++---
5 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index c2063bc..e05cea8 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -432,6 +432,8 @@ static int hwspinlock_device_add(struct hwspinlock_device
*bank)
* @ops: hwspinlock handlers for this device
* @base_id: id of the first hardware spinlock in this bank
* @num_locks: number of hwspinlocks provided by this device
+ * @num_reserved_locks: number of reserved hwspinlocks starting from @base_id
+ * on this device
*
* This function should be called from the underlying platform-specific
* implementation, to register a new hwspinlock device instance.
@@ -441,13 +443,15 @@ static int hwspinlock_device_add(struct hwspinlock_device
*bank)
* Returns 0 on success, or an appropriate error code on failure
*/
int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
- const struct hwspinlock_ops *ops, int base_id, int num_locks)
+ const struct hwspinlock_ops *ops, int base_id, int num_locks,
+ int num_reserved_locks)
{
struct hwspinlock *hwlock;
int ret = 0, i;
if (!bank || !ops || !dev || !num_locks || !ops-trylock ||
- !ops-unlock || (dev-of_node !ops-of_xlate)) {
+ !ops-unlock || (dev-of_node !ops-of_xlate) ||
+ (num_locks num_reserved_locks)) {
pr_err(invalid parameters\n);
return -EINVAL;
}
@@ -456,6 +460,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
bank-ops = ops;
bank-base_id = base_id;
bank-num_locks = num_locks;
+ bank-num_reserved_locks = num_reserved_locks;
mutex_lock(hwspinlock_tree_lock);
ret = hwspinlock_device_add(bank);
@@ -468,7 +473,8 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
spin_lock_init(hwlock-lock);
hwlock-bank = bank;
- hwlock-type = HWSPINLOCK_UNUSED;
+ hwlock-type = (i num_reserved_locks ?
+ HWSPINLOCK_RESERVED : HWSPINLOCK_UNUSED);
ret = hwspin_lock_register_single(hwlock, base_id + i);
if (ret)
@@ -651,7 +657,13 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned
int id)
/* sanity check (this shouldn't happen) */
WARN_ON(hwlock_to_id(hwlock) != id);
- /* make sure this hwspinlock is unused */
+ if (hwlock-type != HWSPINLOCK_RESERVED) {
+ pr_warn(hwspinlock %u is not a reserved lock\n, id);
+ hwlock = NULL;
+ goto out;
+ }
+
+ /* make sure this hwspinlock is an unused reserved lock */
ret = radix_tree_tag_get(hwspinlock_tree, id, hwlock-type);
if (ret == 0) {
pr_warn(hwspinlock %u is already in use\n, id);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h
b/drivers/hwspinlock/hwspinlock_internal.h
index 1be32ca..570e876 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -64,6 +64,8 @@ struct hwspinlock {
* @ops: platform-specific hwspinlock handlers
* @base_id: id index of the first lock in this device
* @num_locks: number of locks in this device
+ * @num_reserved_locks: number of reserved locks in this device starting
+ * from @base_id
* @lock: dynamically allocated array of 'struct hwspinlock'
*/
struct hwspinlock_device {
@@ -72,6 +74,7 @@ struct hwspinlock_device {
const struct hwspinlock_ops *ops;
int base_id;
int num_locks;
+ int num_reserved_locks;
struct hwspinlock lock[0];
};
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 7764291..1d0c78e 100644
--- a/drivers/hwspinlock
[PATCHv5 06/15] hwspinlock/omap: enable module before reading SYSSTATUS register
The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.
This particular issue is seen rather easily on AM33XX, since the
module wakeup is software controlled, and it is disabled out of
reset. Make sure the module is enabled and clocked before reading
the SYSSTATUS register.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/omap_hwspinlock.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 9f56fb2..7764291 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -101,10 +101,29 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
if (!io_base)
return -ENOMEM;
+ /*
+* make sure the module is enabled and clocked before reading
+* the module SYSSTATUS register
+*/
+ pm_runtime_enable(pdev-dev);
+ ret = pm_runtime_get_sync(pdev-dev);
+ if (ret 0) {
+ pm_runtime_put_noidle(pdev-dev);
+ goto iounmap_base;
+ }
+
/* Determine number of locks */
i = readl(io_base + SYSSTATUS_OFFSET);
i = SPINLOCK_NUMLOCKS_BIT_OFFSET;
+ /*
+* runtime PM will make sure the clock of this module is
+* enabled again iff at least one lock is requested
+*/
+ ret = pm_runtime_put_sync(pdev-dev);
+ if (ret 0)
+ goto iounmap_base;
+
/* one of the four lsb's must be set, and nothing else */
if (hweight_long(i 0xf) != 1 || i 8) {
ret = -EINVAL;
@@ -124,12 +143,6 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
for (i = 0, hwlock = bank-lock[0]; i num_locks; i++, hwlock++)
hwlock-priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
- /*
-* runtime PM will make sure the clock of this module is
-* enabled iff at least one lock is requested
-*/
- pm_runtime_enable(pdev-dev);
-
ret = hwspin_lock_register(bank, pdev-dev, omap_hwspinlock_ops,
base_id, num_locks);
if (ret)
@@ -138,9 +151,9 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
return 0;
reg_fail:
- pm_runtime_disable(pdev-dev);
kfree(bank);
iounmap_base:
+ pm_runtime_disable(pdev-dev);
iounmap(io_base);
return ret;
}
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT
The HwSpinlock core requires a base id for registering a bank
of hwspinlocks. This base id needs to be unique across multiple
IP instances of a hwspinlock device, so that each hwlock can be
represented uniquely in a system.
Support has been added to represent this in DT through a common
property 'hwlock-base-id', and retrieve the value through a core
OF helper function, of_hwspin_lock_get_base_id(). The representation
in DT provides a uniform way of assigning a fixed base value for a
hwspinlock device across different SoCs.
Signed-off-by: Suman Anna s-a...@ti.com
---
Documentation/devicetree/bindings/hwlock/hwlock.txt | 6 ++
drivers/hwspinlock/hwspinlock_core.c| 21 +
include/linux/hwspinlock.h | 1 +
3 files changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
index 32381cc..d538a9b 100644
--- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -18,6 +18,12 @@ Common properties:
property is needed on hwlock devices, where the number
of supported locks within a hwlock device cannot be
read from a register.
+- hwlock-base-id: An unique base Id for the locks for a particular hwlock
+ device. This property is mandatory ONLY if a SoC has
+ several hwlock devices.
+
+ See documentation on struct hwspinlock_pdata in
+ include/linux/hwspinlock.h for more details.
Hwlock Users:
=
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 3966c0c..4be1664 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -264,6 +264,27 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode,
unsigned long *flags)
EXPORT_SYMBOL_GPL(__hwspin_unlock);
/**
+ * of_hwspin_lock_get_base_id() - OF helper to retrieve base id
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying
+ * platform-specific implementations, to retrieve the base id for the
+ * set of locks present within a hwspinlock device instance.
+ *
+ * Returns the base id value on success, or an appropriate error code
+ * as returned by the OF layer
+ */
+int of_hwspin_lock_get_base_id(struct device_node *dn)
+{
+ unsigned int val;
+ int ret;
+
+ ret = of_property_read_u32(dn, hwlock-base-id, val);
+ return ret ? ret : val;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
+
+/**
* of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
* @dn: device node pointer
*
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 068e628..4857728 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -64,6 +64,7 @@ struct hwspinlock_pdata {
int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
const struct of_phandle_args *hwlock_spec);
+int of_hwspin_lock_get_base_id(struct device_node *dn);
int of_hwspin_lock_get_num_locks(struct device_node *dn);
int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
const struct hwspinlock_ops *ops, int base_id, int num_locks);
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock
This patch adds the generic common bindings used to represent
a hwlock device and use/request locks in a device-tree build.
All the platform-specific hwlock driver implementations need the
number of locks and associated base id for registering the locks
present within the device with the driver core. The number of locks
is represented by 'hwlock-num-locks' property in DT bindings. A
property for base id is not needed in DT binding, as it can be
satisfied using a phandle + args specifier. The args specifier
length is dependent on each vendor-specific implementation and
is represented through the '#hwlock-cells' property.
Note that the document is named hwlock.txt deliberately to keep it
a bit more generic.
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/hwlock.txt | 52 ++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
new file mode 100644
index 000..32381cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,52 @@
+Generic hwlock bindings
+===
+
+Generic bindings that are common to all the hwlock platform specific driver
+implementations, the retrieved values are used for registering the device
+specific parameters with the hwspinlock core.
+
+The validity and need of these common properties may vary from one platform
+implementation to another. The platform specific bindings should explicitly
+state if a property is mandatory or optional. Please look through the
+individual platform specific hwlock binding documentations for identifying
+the applicable properties.
+
+Common properties:
+- #hwlock-cells: Specifies the number of cells needed to represent a
+ specific lock.
+- hwlock-num-locks:Number of locks present in a hwlock device. This
+ property is needed on hwlock devices, where the number
+ of supported locks within a hwlock device cannot be
+ read from a register.
+
+Hwlock Users:
+=
+
+Nodes that require specific hwlock(s) should specify them using one or more
+properties, each containing a phandle to the hwlock node and an args specifier
+value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
+an array of the phandle and hwlock number specifier tuple.
+
+1. Example of a node using a single specific hwlock:
+
+The following example has a node requesting a hwlock in the bank defined by
+the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
+of length 1.
+
+ node {
+ ...
+ hwlocks = hwlock1 2;
+ ...
+ };
+
+2. Example of a node using multiple specific hwlocks:
+
+The following example has a node requesting two hwlocks, a hwlock within
+the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
+hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
+
+ node {
+ ...
+ hwlocks = hwlock1 2, hwlock2 0 3;
+ ...
+ };
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 04/15] hwspinlock/core: add common OF helpers
This patch adds three new OF helper functions to use/request
locks from a hwspinlock device instantiated through a
device-tree blob.
1. The of_hwspin_lock_get_num_locks() is a common helper
function to read the common 'hwlock-num-locks' property.
2. The of_hwspin_lock_simple_xlate() is a simple default
translator function for hwspinlock provider implementations
that use a single cell number for requesting a specific lock
(relatively indexed) within a hwlock bank.
3. The of_hwspin_lock_request_specific() API can be used by
hwspinlock clients to request a specific lock using the
phandle + args specifier. This function relies on the
implementation providing back a relative hwlock id within
the bank from the args specifier.
Signed-off-by: Suman Anna s-a...@ti.com
---
Documentation/hwspinlock.txt | 34 ++-
drivers/hwspinlock/hwspinlock_core.c | 100 ++-
drivers/hwspinlock/hwspinlock_internal.h | 4 ++
include/linux/hwspinlock.h | 22 ++-
4 files changed, 155 insertions(+), 5 deletions(-)
diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 640ae47..903d477 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -48,6 +48,15 @@ independent, drivers.
ids for predefined purposes.
Should be called from a process context (might sleep).
+ struct hwspinlock *of_hwspin_lock_request_specific(
+ struct device_node *np, const char *propname, int index);
+ - assign a specific hwspinlock id and return its address, or NULL
+ if that hwspinlock is already in use. This function is the OF
+ equivalent of hwspin_lock_request_specific() function, and provides
+ a means for users of the hwspinlock module to request a specific
+ hwspinlock using the phandle of the hwspinlock device.
+ Should be called from a process context (might sleep).
+
int hwspin_lock_free(struct hwspinlock *hwlock);
- free a previously-assigned hwspinlock; returns 0 on success, or an
appropriate error code on failure (e.g. -EINVAL if the hwspinlock
@@ -243,6 +252,23 @@ int hwspinlock_example2(void)
Returns the address of hwspinlock on success, or NULL on error (e.g.
if the hwspinlock is still in use).
+ int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
+ const struct of_phandle_args *hwlock_spec);
+ - is a simple default OF translate helper function that can be plugged in
+ as the underlying vendor-specific implementation's of_xlate ops function.
+ This can be used by implementations that use a single integer argument in
+ the DT node argument specifier, that indicates the hwlock index number.
+ Returns a hwlock index within a bank, or appropriate error code on
+ failure.
+
+ int of_hwspin_lock_get_num_locks(struct device_node *dn);
+ - is a common OF helper function that can be used by some underlying
+ vendor-specific implementations. This can be used by implementations
+ that require and define the number of locks supported within a hwspinlock
+ bank as a device tree node property. This function should be called by
+ needed implementations before registering a hwspinlock device with the
+ core.
+
5. Important structs
struct hwspinlock_device is a device which usually contains a bank
@@ -288,12 +314,14 @@ initialized by the hwspinlock core itself.
6. Implementation callbacks
-There are three possible callbacks defined in 'struct hwspinlock_ops':
+There are four possible callbacks defined in 'struct hwspinlock_ops':
struct hwspinlock_ops {
int (*trylock)(struct hwspinlock *lock);
void (*unlock)(struct hwspinlock *lock);
void (*relax)(struct hwspinlock *lock);
+ int (*of_xlate)(struct hwspinlock_device *bank,
+ const struct of_phandle_args *hwlock_spec);
};
The first two callbacks are mandatory:
@@ -307,3 +335,7 @@ may _not_ sleep.
The -relax() callback is optional. It is called by hwspinlock core while
spinning on a lock, and can be used by the underlying implementation to force
a delay between two successive invocations of -trylock(). It may _not_ sleep.
+
+The -of_xlate() callback is mandatory to support requesting hwlocks through
+device-tree nodes. It is called by hwspinlock core to retrieve the relative
+lock index within a bank from the underlying implementation.
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 48f7866..3966c0c 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -27,6 +27,7 @@
#include linux/hwspinlock.h
#include linux/pm_runtime.h
#include linux/mutex.h
+#include linux/of.h
#include hwspinlock_internal.h
@@ -262,6 +263,33 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode,
unsigned long *flags)
}
EXPORT_SYMBOL_GPL(__hwspin_unlock
[PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
The hwspinlock_device structure is used for registering a bank of
locks with the driver core. The structure already contains the
necessary members to identify the bank of locks. The core does not
maintain the hwspinlock_devices itself, but maintains only a radix
tree for all the registered locks. A specific lock can be requested
by users using a global lock id, and any device-specific fields
can be retrieved through a reference to the hwspinlock_device in
each lock.
The global lock id, however, is not friendly to be requested for
users using the device-tree model. The device-tree representation
will typically have each of the hwspinlock devices represented as
a DT node, and a specific lock can be requested using the device's
phandle and a lock specifier. Add support to the core therefore to
maintain all the registered hwspinlock_devices, so that a device
can be looked up and a specific lock belonging to the device
requested through a phandle + args approach.
Signed-off-by: Suman Anna s-a...@ti.com
---
Documentation/hwspinlock.txt | 2 ++
drivers/hwspinlock/hwspinlock_core.c | 51
drivers/hwspinlock/hwspinlock_internal.h | 2 ++
3 files changed, 55 insertions(+)
diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 62f7d4e..640ae47 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -251,6 +251,7 @@ implementation using the hwspin_lock_register() API.
/**
* struct hwspinlock_device - a device which usually spans numerous hwspinlocks
+ * @list: list element to link hwspinlock devices together
* @dev: underlying device, will be used to invoke runtime PM api
* @ops: platform-specific hwspinlock handlers
* @base_id: id index of the first lock in this device
@@ -258,6 +259,7 @@ implementation using the hwspin_lock_register() API.
* @lock: dynamically allocated array of 'struct hwspinlock'
*/
struct hwspinlock_device {
+ struct list_head list;
struct device *dev;
const struct hwspinlock_ops *ops;
int base_id;
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d7..48f7866 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -59,6 +59,11 @@ static RADIX_TREE(hwspinlock_tree, GFP_KERNEL);
*/
static DEFINE_MUTEX(hwspinlock_tree_lock);
+/*
+ * A linked list for maintaining all the registered hwspinlock devices.
+ * The list is maintained in an ordered-list of the supported locks group.
+ */
+static LIST_HEAD(hwspinlock_devices);
/**
* __hwspin_trylock() - attempt to lock a specific hwspinlock
@@ -307,6 +312,40 @@ out:
return hwlock;
}
+/*
+ * Add a new hwspinlock device to the global list, keeping the list of
+ * devices sorted by base order.
+ *
+ * Returns 0 on success, or -EBUSY if the new device overlaps with some
+ * other device's lock space.
+ */
+static int hwspinlock_device_add(struct hwspinlock_device *bank)
+{
+ struct list_head *entry = hwspinlock_devices;
+ struct hwspinlock_device *_bank;
+ int ret = 0;
+
+ list_for_each(entry, hwspinlock_devices) {
+ _bank = list_entry(entry, struct hwspinlock_device, list);
+ if (_bank-base_id = bank-base_id + bank-num_locks)
+ break;
+ }
+
+ if (entry != hwspinlock_devices
+ entry-prev != hwspinlock_devices) {
+ _bank = list_entry(entry-prev, struct hwspinlock_device, list);
+ if (_bank-base_id + _bank-num_locks bank-base_id) {
+ dev_err(bank-dev, hwlock space overlap, cannot add
device\n);
+ ret = -EBUSY;
+ }
+ }
+
+ if (!ret)
+ list_add_tail(bank-list, entry);
+
+ return ret;
+}
+
/**
* hwspin_lock_register() - register a new hw spinlock device
* @bank: the hwspinlock device, which usually provides numerous hw locks
@@ -339,6 +378,12 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
bank-base_id = base_id;
bank-num_locks = num_locks;
+ mutex_lock(hwspinlock_tree_lock);
+ ret = hwspinlock_device_add(bank);
+ mutex_unlock(hwspinlock_tree_lock);
+ if (ret)
+ return ret;
+
for (i = 0; i num_locks; i++) {
hwlock = bank-lock[i];
@@ -355,6 +400,9 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
reg_failed:
while (--i = 0)
hwspin_lock_unregister_single(base_id + i);
+ mutex_lock(hwspinlock_tree_lock);
+ list_del(bank-list);
+ mutex_unlock(hwspinlock_tree_lock);
return ret;
}
EXPORT_SYMBOL_GPL(hwspin_lock_register);
@@ -386,6 +434,9 @@ int hwspin_lock_unregister(struct hwspinlock_device *bank)
WARN_ON(tmp != hwlock);
}
+ mutex_lock(hwspinlock_tree_lock
[PATCHv5 05/15] hwspinlock/omap: add support for dt nodes
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.
Signed-off-by: Suman Anna s-a...@ti.com
[t...@atomide.com: ack for legacy file removal]
Acked-by: Tony Lindgren t...@atomide.com
---
MAINTAINERS | 1 -
arch/arm/mach-omap2/Makefile | 3 --
arch/arm/mach-omap2/hwspinlock.c | 60
drivers/hwspinlock/omap_hwspinlock.c | 18 ---
4 files changed, 14 insertions(+), 68 deletions(-)
delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e67ea24..5147902 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6355,7 +6355,6 @@ M:Ohad Ben-Cohen o...@wizery.com
L: linux-omap@vger.kernel.org
S: Maintained
F: drivers/hwspinlock/omap_hwspinlock.c
-F: arch/arm/mach-omap2/hwspinlock.c
OMAP MMC SUPPORT
M: Jarkko Lavinen jarkko.lavi...@nokia.com
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8421f38..9f4b6dd 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -289,9 +289,6 @@ obj-y += $(smc91x-m)
$(smc91x-y)
smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
-ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
-obj-y += hwspinlock.o
-endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
deleted file mode 100644
index ef175ac..000
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * OMAP hardware spinlock device initialization
- *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
- *
- * Contact: Simon Que s...@ti.com
- * Hari Kanigeri h-kanige...@ti.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/err.h
-#include linux/hwspinlock.h
-
-#include soc.h
-#include omap_hwmod.h
-#include omap_device.h
-
-static struct hwspinlock_pdata omap_hwspinlock_pdata __initdata = {
- .base_id = 0,
-};
-
-static int __init hwspinlocks_init(void)
-{
- int retval = 0;
- struct omap_hwmod *oh;
- struct platform_device *pdev;
- const char *oh_name = spinlock;
- const char *dev_name = omap_hwspinlock;
-
- /*
-* Hwmod lookup will fail in case our platform doesn't support the
-* hardware spinlock module, so it is safe to run this initcall
-* on all omaps
-*/
- oh = omap_hwmod_lookup(oh_name);
- if (oh == NULL)
- return -EINVAL;
-
- pdev = omap_device_build(dev_name, 0, oh, omap_hwspinlock_pdata,
- sizeof(struct hwspinlock_pdata));
- if (IS_ERR(pdev)) {
- pr_err(Can't build omap_device for %s:%s\n, dev_name,
- oh_name);
- retval = PTR_ERR(pdev);
- }
-
- return retval;
-}
-/* early board code might need to reserve specific hwspinlock instances */
-omap_postcore_initcall(hwspinlocks_init);
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 292869c..9f56fb2 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -1,7 +1,7 @@
/*
* OMAP hardware spinlock driver
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2014 Texas Instruments Incorporated - http://www.ti.com
*
* Contact: Simon Que s...@ti.com
* Hari Kanigeri h-kanige...@ti.com
@@ -27,6 +27,7 @@
#include linux/slab.h
#include linux/spinlock.h
#include linux/hwspinlock.h
+#include linux/of_device.h
#include linux/platform_device.h
#include hwspinlock_internal.h
@@ -76,18 +77,20 @@ static const struct hwspinlock_ops omap_hwspinlock_ops = {
.trylock = omap_hwspinlock_trylock,
.unlock = omap_hwspinlock_unlock,
.relax = omap_hwspinlock_relax,
+ .of_xlate = of_hwspin_lock_simple_xlate,
};
static int omap_hwspinlock_probe(struct platform_device *pdev)
{
- struct hwspinlock_pdata *pdata = pdev-dev.platform_data;
+ struct device_node *node = pdev-dev.of_node
[PATCHv5 02/15] Documentation: dt: add the omap hwspinlock bindings document
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
DT bindings information for OMAP hwspinlock module.
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/omap-hwspinlock.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
new file mode 100644
index 000..568eae2
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
@@ -0,0 +1,24 @@
+OMAP4+ HwSpinlock Driver
+
+
+Required properties:
+- compatible: Should be ti,omap4-hwspinlock for
+ OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg: Contains the hwspinlock module register address space
+ (base address and length)
+- ti,hwmods: Name of the hwmod associated with the hwspinlock device
+- #hwlock-cells: Should be 1. The OMAP hwspinlock users will use a
+ 0-indexed relative hwlock number as the argument
+ specifier value for requesting a specific hwspinlock
+ within a hwspinlock bank.
+
+
+Example:
+
+/* OMAP4 */
+hwspinlock: spinlock@4a0f6000 {
+ compatible = ti,omap4-hwspinlock;
+ reg = 0x4a0f6000 0x1000;
+ ti,hwmods = spinlock;
+ #hwlock-cells = 1;
+};
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 00/15] hwspinlock/omap dt support
Hi Ohad, This is a refresh/update of the hwspinlock dt support series. The series is rebased onto v3.15-rc3, and adds 8 new patches (RFC) to handle various discussion points arised on v4. Following are the main changes in v5: - Base DT patches (Patches 1 to 7, except for 4) are identical to v4. Patch4 is updated to remove some traces and fix --strict checkpatch warnings. - Patch 8 brings back the DT-based hwlock-base-id property, for registration purposes. Based on v4 discussion [1]. - Patches 9 through 13 introduce the concept of reserved locks, again based on the discussion in v4 [1]. The approach taken here is simplistic, each hwlock is assigned a type attribute during registration, with the _request_ apis honoring the lock type attribute. - Staged patches 14 15 for converting return convention to better support deferred probing of client drivers. I do think that it is still a good idea to return ERR_PTRs (unconcluded discussion in v4 [2]). The main advantage is to support deferred probing for DT boots. The original argument/change for returning NULL pointers pre-dates both the deferred driver probe mechanism and DT-based boot, so it may be moot on the current kernel. I have marked the new patches as RFC, and should ideally be dealt with as a separate series. I have added these to this series as they also add couple of DT-based properties, as well as maintain the discussion context from the previous series. I am ok for the reserved lock patches to be left out for 3.16 merge window if these patches still need some work. I am hoping to have the first 7 or 8 patches (and finalized return code changes) to make it to 3.16. The validation logs on all the applicable OMAP SoCs are at: OMAP4 - http://slexy.org/view/s2MMyLZTiH OMAP5 - http://slexy.org/view/s20U2ElygK DRA74x - http://slexy.org/view/s20fAoWJ84 AM33xx - http://slexy.org/view/s2HLj2b406 AM43xx - http://slexy.org/view/s2JNrJSWLm The above logs are generated with some additional test patches staged here for reference (not for merging) https://github.com/sumananna/omap-kernel/commits/hwspinlock/3.15-rc3-v5 https://github.com/sumananna/omap-kernel/commits/hwspinlock/3.15-rc3-v5-test regards Suman [1] http://marc.info/?l=linux-omapm=139510004009415w=2 [2] http://marc.info/?l=linux-omapm=139490475424338w=2 --- v4: - The DT bindings are split into separate patches, and updated to add comments about #hwlock-cells - Fixed a registration issue with repeated module installation and removal. - Added a new OF helper to support #hwlock-cells in addition to the previous OF functions. The OMAP adaptation patch is updated to use the default translate function - Updated hwspinlock documentation to adjust for the structure changes and the new api additions. - Added build support for AM335x, AM43xx and DRA7xx http://marc.info/?l=linux-omapm=138965904015225w=2 v3: - Removed the DT property hwlock-base-id and associated OF helper - Added changes in core to support requesting a specific hwlock using phandle + args approach - Revised both the common and OMAP DT bindings document http://marc.info/?l=linux-omapm=138143992932197w=2 v2: - Added a new common DT binding documentation and OF helpers. - Revised OMAP DT parse support to use the new OF helper (Patch2) - OMAP5 hwspinlock support including the hwmod entry and DT node - Add AM335x support to OMAP hwspinlock driver, including a fix needed in driver given that AM335 spinlock module requires s/w wakeup - AM335 DT node for spinlock, and a hwmod change to enable smart-idle for AM335. - OMAP4 DT node patch is unchanged http://marc.info/?l=linux-omapm=137944644112727w=2 v1: - Add DT parse support to OMAP hwspinlock driver - Add OMAP4 DT node and bindings information http://marc.info/?l=linux-omapm=137823082308009w=2 --- Suman Anna (15): Documentation: dt: add common bindings for hwspinlock Documentation: dt: add the omap hwspinlock bindings document hwspinlock/core: maintain a list of registered hwspinlock banks hwspinlock/core: add common OF helpers hwspinlock/omap: add support for dt nodes hwspinlock/omap: enable module before reading SYSSTATUS register hwspinlock/omap: enable build for AM33xx, AM43xx DRA7xx hwspinlock/core: add support for base id in DT hwspinlock/core: prepare unregister code to support reserved locks hwspinlock/core: prepare core to support reserved locks hwspinlock/core: add support for reserved locks hwspinlock/core: add OF helper to parse reserved locks hwspinlock/omap: use OF helper to get reserved locks hwspinlock/core: return ERR_PTRs on failure in _request_ api hwspinlock/core: change return codes of_hwspin_lock_request_specific .../devicetree/bindings/hwlock/hwlock.txt | 61 + .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 24 ++ Documentation/hwspinlock.txt | 48 +++- MAINTAINERS| 1 - arch/arm/mach-omap2
Re: [PATCH 0/3] Minor OMAP DTS fixes
Tony, On 04/25/2014 11:57 AM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [140422 15:24]: Hi Tony, Benoit, This series includes couple of minor fixes in the OMAP DTS files. The patches are based on 3.15-rc2. The first patch fixes the only WARN_ON trace present during kernel boot on OMAP5 uEVM, and this has been present since some time now. [0.045578] [ cut here ] [0.045598] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3dc() [0.045605] omap_hwmod: mailbox: doesn't have mpu register target base [0.045611] Modules linked in: [0.045625] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-1-gb5e85a0 #45 [0.045653] [c0015724] (unwind_backtrace) from [c00120f4] (show_stack+0x10/0x14) [0.045672] [c00120f4] (show_stack) from [c05a1ccc] (dump_stack+0x78/0x94) [0.045686] [c05a1ccc] (dump_stack) from [c0042a74] (warn_slowpath_common+0x6c/0x8c) [0.045698] [c0042a74] (warn_slowpath_common) from [c0042b28] (warn_slowpath_fmt+0x30/0x40) [0.045710] [c0042b28] (warn_slowpath_fmt) from [c0803b40] (_init+0x1c0/0x3dc) [0.045724] [c0803b40] (_init) from [c0029c8c] (omap_hwmod_for_each+0x34/0x5c) [0.045736] [c0029c8c] (omap_hwmod_for_each) from [c08042b0] (__omap_hwmod_setup_all+0x24/0x40) [0.045748] [c08042b0] (__omap_hwmod_setup_all) from [c00088b8] (do_one_initcall+0x34/0x160) [0.045761] [c00088b8] (do_one_initcall) from [c07f7bf4] (kernel_init_freeable+0xfc/0x1c8) [0.045772] [c07f7bf4] (kernel_init_freeable) from [c059c4f4] (kernel_init+0x8/0xe4) [0.045784] [c059c4f4] (kernel_init) from [c000eaa8] (ret_from_fork+0x14/0x2c) [0.045826] ---[ end trace c25fc521f2569d3c ]--- The last patch eliminates the following traces on AM3517 based boards. [0.418496] platform iva.2: Cannot lookup hwmod 'iva' [0.454352] platform 48094000.mailbox: Cannot lookup hwmod 'mailbox' [0.460610] platform 480bd400.mmu: Cannot lookup hwmod 'mmu_isp' [0.464065] platform 480c9000.smartreflex: Cannot lookup hwmod 'smartreflex_mpu_iva' There are a few other such traces remaining, but these are all on valid nodes. [0.420275] platform 480c5000.aes: Cannot lookup hwmod 'aes' [0.462403] platform 480c3000.sham: Cannot lookup hwmod 'sham' [0.463246] platform 480cb000.smartreflex: Cannot lookup hwmod 'smartreflex_core' [0.477243] platform 480ab000.usb_otg_hs: Cannot lookup hwmod 'usb_otg_hs' Thanks applying all three into omap-for-v3.15/fixes-v2 with patch updated with the above warnings. Next time, please include the warnings into the patch description, just leave out the time stamps. Thanks. I have mentioned the warning for the OMAP5 one very briefly, and wasn't sure if I needed to copy the entire backtrace, but will remember to include them in the future. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/4] ARM: OMAP2+: Add machine entry for dra72x devices
Hi Rajendra,
On 04/24/2014 05:06 AM, Nayak, Rajendra wrote:
The only difference from the dra74x devices is the missing .smp entry.
While at it, also fix the use of __initdata (across the file) and replace them
with __initconst as reported by checkpatch
ERROR: Use of const init definition must use __initconst
+static const char *dra72x_boards_compat[] __initdata = {
Since it looks like you are gonna do another respin, care to separate
out the __initdata to __initconst change for existing ones into a
different patch, and limit this patch to just what the patch subject says.
regards
Suman
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 45
---
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index b8920b6..dabb9f6 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -43,7 +43,7 @@ static void __init omap_generic_init(void)
}
#ifdef CONFIG_SOC_OMAP2420
-static const char *omap242x_boards_compat[] __initdata = {
+static const char *omap242x_boards_compat[] __initconst = {
ti,omap2420,
NULL,
};
@@ -62,7 +62,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_OMAP2430
-static const char *omap243x_boards_compat[] __initdata = {
+static const char *omap243x_boards_compat[] __initconst = {
ti,omap2430,
NULL,
};
@@ -81,7 +81,7 @@ MACHINE_END
#endif
#ifdef CONFIG_ARCH_OMAP3
-static const char *omap3_boards_compat[] __initdata = {
+static const char *omap3_boards_compat[] __initconst = {
ti,omap3430,
ti,omap3,
NULL,
@@ -100,7 +100,7 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened
Device Tree))
.restart= omap3xxx_restart,
MACHINE_END
-static const char *omap36xx_boards_compat[] __initdata = {
+static const char *omap36xx_boards_compat[] __initconst = {
ti,omap36xx,
NULL,
};
@@ -118,7 +118,7 @@ DT_MACHINE_START(OMAP36XX_DT, Generic OMAP36xx
(Flattened Device Tree))
.restart= omap3xxx_restart,
MACHINE_END
-static const char *omap3_gp_boards_compat[] __initdata = {
+static const char *omap3_gp_boards_compat[] __initconst = {
ti,omap3-beagle,
timll,omap3-devkit8000,
NULL,
@@ -137,7 +137,7 @@ DT_MACHINE_START(OMAP3_GP_DT, Generic OMAP3-GP
(Flattened Device Tree))
.restart= omap3xxx_restart,
MACHINE_END
-static const char *am3517_boards_compat[] __initdata = {
+static const char *am3517_boards_compat[] __initconst = {
ti,am3517,
NULL,
};
@@ -157,7 +157,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_AM33XX
-static const char *am33xx_boards_compat[] __initdata = {
+static const char *am33xx_boards_compat[] __initconst = {
ti,am33xx,
NULL,
};
@@ -177,7 +177,7 @@ MACHINE_END
#endif
#ifdef CONFIG_ARCH_OMAP4
-static const char *omap4_boards_compat[] __initdata = {
+static const char *omap4_boards_compat[] __initconst = {
ti,omap4460,
ti,omap4430,
ti,omap4,
@@ -199,7 +199,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_OMAP5
-static const char *omap5_boards_compat[] __initdata = {
+static const char *omap5_boards_compat[] __initconst = {
ti,omap5432,
ti,omap5430,
ti,omap5,
@@ -221,7 +221,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_AM43XX
-static const char *am43_boards_compat[] __initdata = {
+static const char *am43_boards_compat[] __initconst = {
ti,am4372,
ti,am43,
NULL,
@@ -240,13 +240,13 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_DRA7XX
-static const char *dra7xx_boards_compat[] __initdata = {
- ti,dra7xx,
+static const char *dra74x_boards_compat[] __initconst = {
+ ti,dra74,
ti,dra7,
NULL,
};
-DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened Device Tree))
+DT_MACHINE_START(DRA74X_DT, Generic DRA74X (Flattened Device Tree))
.reserve= omap_reserve,
.smp= smp_ops(omap4_smp_ops),
.map_io = omap5_map_io,
@@ -255,7 +255,24 @@ DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened
Device Tree))
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_time = omap5_realtime_timer_init,
- .dt_compat = dra7xx_boards_compat,
+ .dt_compat = dra74x_boards_compat,
+ .restart= omap44xx_restart,
+MACHINE_END
+
+static const char *dra72x_boards_compat[] __initconst = {
+ ti,dra72,
+ NULL,
+};
+
+DT_MACHINE_START(DRA72_DT, Generic DRA72X (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap5_map_io,
+ .init_early = dra7xx_init_early,
+ .init_late = dra7xx_init_late,
+ .init_irq = omap_gic_of_init,
+ .init_machine = omap_generic_init,
+
[PATCH 3/3] ARM: dts: AM3517: Disable absent IPs inherited from OMAP3
AM3517 inherits OMAP3 dts file, but does not have all the IPs
that are present on OMAP3. This patch disables the following
absent IPs for AM3517: Mailbox, IVA, MMU_ISP, MPU_IVA SmartReflex.
A label had to be added for IVA node in omap3.dtsi to be able to
get a reference to the node for disabling.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/am3517.dtsi | 16
arch/arm/boot/dts/omap3.dtsi | 2 +-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
index 788391f..5a452fd 100644
--- a/arch/arm/boot/dts/am3517.dtsi
+++ b/arch/arm/boot/dts/am3517.dtsi
@@ -62,5 +62,21 @@
};
};
+iva {
+ status = disabled;
+};
+
+mailbox {
+ status = disabled;
+};
+
+mmu_isp {
+ status = disabled;
+};
+
+smartreflex_mpu_iva {
+ status = disabled;
+};
+
/include/ am35xx-clocks.dtsi
/include/ omap36xx-am35xx-omap3430es2plus-clocks.dtsi
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 5e5790f..f45f77f 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -61,7 +61,7 @@
ti,hwmods = mpu;
};
- iva {
+ iva: iva {
compatible = ti,iva2.2;
ti,hwmods = iva;
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: dts: OMAP5: Add mailbox dt node to fix boot warning
Add the mailbox device DT node for OMAP5 SoC. The OMAP5 mailbox
IP is identical to that used in OMAP4.
The OMAP5 hwmod data no longer publishes the module address space,
so this patch fixes the WARN_ON backtrace associated with the
following trace during the kernel boot:
omap_hwmod: mailbox: doesn't have mpu register target base.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 6f3de22..e8988bb 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -630,6 +630,13 @@
status = disabled;
};
+ mailbox: mailbox@4a0f4000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4a0f4000 0x200;
+ interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mailbox;
+ };
+
timer1: timer@4ae18000 {
compatible = ti,omap5430-timer;
reg = 0x4ae18000 0x80;
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Minor OMAP DTS fixes
Hi Tony, Benoit, This series includes couple of minor fixes in the OMAP DTS files. The patches are based on 3.15-rc2. The first patch fixes the only WARN_ON trace present during kernel boot on OMAP5 uEVM, and this has been present since some time now. [0.045578] [ cut here ] [0.045598] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3dc() [0.045605] omap_hwmod: mailbox: doesn't have mpu register target base [0.045611] Modules linked in: [0.045625] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-1-gb5e85a0 #45 [0.045653] [c0015724] (unwind_backtrace) from [c00120f4] (show_stack+0x10/0x14) [0.045672] [c00120f4] (show_stack) from [c05a1ccc] (dump_stack+0x78/0x94) [0.045686] [c05a1ccc] (dump_stack) from [c0042a74] (warn_slowpath_common+0x6c/0x8c) [0.045698] [c0042a74] (warn_slowpath_common) from [c0042b28] (warn_slowpath_fmt+0x30/0x40) [0.045710] [c0042b28] (warn_slowpath_fmt) from [c0803b40] (_init+0x1c0/0x3dc) [0.045724] [c0803b40] (_init) from [c0029c8c] (omap_hwmod_for_each+0x34/0x5c) [0.045736] [c0029c8c] (omap_hwmod_for_each) from [c08042b0] (__omap_hwmod_setup_all+0x24/0x40) [0.045748] [c08042b0] (__omap_hwmod_setup_all) from [c00088b8] (do_one_initcall+0x34/0x160) [0.045761] [c00088b8] (do_one_initcall) from [c07f7bf4] (kernel_init_freeable+0xfc/0x1c8) [0.045772] [c07f7bf4] (kernel_init_freeable) from [c059c4f4] (kernel_init+0x8/0xe4) [0.045784] [c059c4f4] (kernel_init) from [c000eaa8] (ret_from_fork+0x14/0x2c) [0.045826] ---[ end trace c25fc521f2569d3c ]--- The last patch eliminates the following traces on AM3517 based boards. [0.418496] platform iva.2: Cannot lookup hwmod 'iva' [0.454352] platform 48094000.mailbox: Cannot lookup hwmod 'mailbox' [0.460610] platform 480bd400.mmu: Cannot lookup hwmod 'mmu_isp' [0.464065] platform 480c9000.smartreflex: Cannot lookup hwmod 'smartreflex_mpu_iva' There are a few other such traces remaining, but these are all on valid nodes. [0.420275] platform 480c5000.aes: Cannot lookup hwmod 'aes' [0.462403] platform 480c3000.sham: Cannot lookup hwmod 'sham' [0.463246] platform 480cb000.smartreflex: Cannot lookup hwmod 'smartreflex_core' [0.477243] platform 480ab000.usb_otg_hs: Cannot lookup hwmod 'usb_otg_hs' regards Suman Suman Anna (3): ARM: dts: OMAP5: Add mailbox dt node to fix boot warning ARM: dts: OMAP2: Fix interrupts for OMAP2420 mailbox ARM: dts: AM3517: Disable absent IPs inherited from OMAP3 arch/arm/boot/dts/am3517.dtsi | 16 arch/arm/boot/dts/omap2.dtsi| 7 --- arch/arm/boot/dts/omap2420.dtsi | 8 arch/arm/boot/dts/omap2430.dtsi | 7 +++ arch/arm/boot/dts/omap3.dtsi| 2 +- arch/arm/boot/dts/omap5.dtsi| 7 +++ 6 files changed, 39 insertions(+), 8 deletions(-) -- 1.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: dts: OMAP2: Fix interrupts for OMAP2420 mailbox
The mailbox module is capable of generating two interrupts
to MPU in OMAP2420, compared to one in OMAP2430. The second
interrupt is to handle interrupts from the additional IVA
processor present only on OMAP2420.
Move the current common mailbox DT node into the SoC
specific files to allow the above differentiation. Also,
added back the interrupt-names on OMAP2420, that were
previously defined in hwmod data.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap2.dtsi| 7 ---
arch/arm/boot/dts/omap2420.dtsi | 8
arch/arm/boot/dts/omap2430.dtsi | 7 +++
3 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 22f35ea..8f8c07d 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -71,13 +71,6 @@
interrupts = 58;
};
- mailbox: mailbox@48094000 {
- compatible = ti,omap2-mailbox;
- ti,hwmods = mailbox;
- reg = 0x48094000 0x200;
- interrupts = 26;
- };
-
intc: interrupt-controller@1 {
compatible = ti,omap2-intc;
interrupt-controller;
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index 85b1fb0..2d99798 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -125,6 +125,14 @@
dma-names = tx, rx;
};
+ mailbox: mailbox@48094000 {
+ compatible = ti,omap2-mailbox;
+ reg = 0x48094000 0x200;
+ interrupts = 26, 34;
+ interrupt-names = dsp, iva;
+ ti,hwmods = mailbox;
+ };
+
timer1: timer@48028000 {
compatible = ti,omap2420-timer;
reg = 0x48028000 0x400;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index d09697d..42d2c61 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -216,6 +216,13 @@
dma-names = tx, rx;
};
+ mailbox: mailbox@48094000 {
+ compatible = ti,omap2-mailbox;
+ reg = 0x48094000 0x200;
+ interrupts = 26;
+ ti,hwmods = mailbox;
+ };
+
timer1: timer@49018000 {
compatible = ti,omap2420-timer;
reg = 0x49018000 0x400;
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/6] iommu/omap: Fix 'no page for' debug message in flush_iotlb_page()
Hi Laurent, On 04/03/2014 03:01 PM, Laurent Pinchart wrote: The flush_iotlb_page() function prints a debug message when no corresponding page was found in the TLB. That condition is incorrectly checked and always resolves to true, given that the for_each_iotlb_cr() loop is never interrupted and always reaches obj-nr_tlb_entries. Given that we can't have two TLB entries for the same VA, break from the loop when a match is found. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Thanks for the reworked and simplified patch. Acked-by: Suman Anna s-a...@ti.com --- drivers/iommu/omap-iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index fdf3dd0..428b47a 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -394,6 +394,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da) __func__, start, da, bytes); iotlb_load_cr(obj, cr); iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY); + break; } } pm_runtime_put_sync(obj-dev); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] OMAP IOMMU fixes
Hi Laurent, On 04/03/2014 03:01 PM, Laurent Pinchart wrote: Hello, This patch set fixes miscellaneous issues with the OMAP IOMMU driver, found when trying to port the OMAP3 ISP away from omap-iovmm to the ARM DMA API. The biggest issue is fixed by patch 6/6, while the other patches fix smaller problems that I've noticed when reading the code, without experiencing them at runtime. I believe I've addressed all comments received for v1. Suman, could you please have a quick look at ack the patches you haven't acked yet ? I'll then send a pull request. Thanks for the revised series. Just acked Patch 4/6. Patch 3/6 is a simple comment removal, and I am good with that change. First 3 are already are from me, so I guess you need to add your sign-off before you send out the pull request. regards Suman Changes since v1: - Dropped the iommu/omap: Use the cache cleaning API and iommu/omap: Flush the TLB only after updating translation table entries patches - Reworked iommu/omap: Fix 'no page for' debug message in flush_iotlb_page() to just break out of the loop - Added patches 1/6 to 3/6 Laurent Pinchart (3): iommu/omap: Fix 'no page for' debug message in flush_iotlb_page() iommu/omap: Remove comment about supporting single page mappings only iommu/omap: Fix map protection value handling Suman Anna (3): iommu/omap: Correct init value of iotlb_entry valid field iommu/omap: Remove omap_iommu_domain_has_cap() function iommu/omap: Move to_iommu definition from omap-iopgtable.h drivers/iommu/omap-iommu.c | 31 --- drivers/iommu/omap-iopgtable.h | 3 --- 2 files changed, 12 insertions(+), 22 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] OMAP IOMMU fixes
On 04/03/2014 04:02 PM, Anna, Suman wrote: Hi Laurent, On 04/03/2014 03:01 PM, Laurent Pinchart wrote: Hello, This patch set fixes miscellaneous issues with the OMAP IOMMU driver, found when trying to port the OMAP3 ISP away from omap-iovmm to the ARM DMA API. The biggest issue is fixed by patch 6/6, while the other patches fix smaller problems that I've noticed when reading the code, without experiencing them at runtime. I believe I've addressed all comments received for v1. Suman, could you please have a quick look at ack the patches you haven't acked yet ? I'll then send a pull request. Thanks for the revised series. Just acked Patch 4/6. Patch 3/6 is a simple comment removal, and I am Sorry, had a minor typo, I meant 5/6 w.r.t comment removal. good with that change. First 3 are already are from me, so I guess you need to add your sign-off before you send out the pull request. regards Suman Changes since v1: - Dropped the iommu/omap: Use the cache cleaning API and iommu/omap: Flush the TLB only after updating translation table entries patches - Reworked iommu/omap: Fix 'no page for' debug message in flush_iotlb_page() to just break out of the loop - Added patches 1/6 to 3/6 Laurent Pinchart (3): iommu/omap: Fix 'no page for' debug message in flush_iotlb_page() iommu/omap: Remove comment about supporting single page mappings only iommu/omap: Fix map protection value handling Suman Anna (3): iommu/omap: Correct init value of iotlb_entry valid field iommu/omap: Remove omap_iommu_domain_has_cap() function iommu/omap: Move to_iommu definition from omap-iopgtable.h drivers/iommu/omap-iommu.c | 31 --- drivers/iommu/omap-iopgtable.h | 3 --- 2 files changed, 12 insertions(+), 22 deletions(-) ___ iommu mailing list io...@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/7] omap hwspinlock dt support
On 03/18/2014 08:35 AM, Ohad Ben-Cohen wrote: Hi Suman, On Tue, Mar 18, 2014 at 1:46 AM, Suman Anna s-a...@ti.com wrote: So far, we have not come across multiple controllers. I see your point, and I think this also depends on the semantics of how you exchange the lock id number. The agreement at the moment is on base_ids across multiple SoC components. If the semantics involve exchanging the controller instance, for example, then we might get away with it. But that probably involves adding additional helpers to retrieve controller instance in addition to lock number, or some other similar functions. Yes, this could be done too, but I agree it is less simple with no real win. Sorry, I should have rephrased it better - by order, I meant the inherent order between board early code and other drivers. With DT, we cannot guarantee that right, as specific locks are requested from drivers. Yeah. Understood. And we may have to assign the client association with a lock as well. These are core changes that were actually not needed in the non-DT case due to the inherent order as stated above. So, are you suggesting that we add one more property to the controller node to mark which are reserved, or rely on constructing this through DT tree parsing? I guess this is a question to the DT folks; both approaches work from hwspinlock perspective. In the past Arnd Benoit and myself were happy with adding one more property to the controller node, but this might be somewhat error prone as it leaves room for mistakes - developers can add hwlock phandles and forget to update the reserved property in the controller node. Ohad, I agree that this is the most simplest form (either a reserved number starting from base, or a reserved range - I prefer the first). The developer errors can be restricted by having the of_hwspin_lock_request_specific() return an error if anything outside this reserved range is requested. Mark, Kumar, Any recommendations/objections on this problem/approach? I also have to bring back the hwlock-base-id property (dropped in v3) for registration purposes, so that the registration does not change based on the probe order of the multiple controller nodes. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/7] omap hwspinlock dt support
Hi Ohad, On 03/17/2014 09:23 AM, Ohad Ben-Cohen wrote: Hi Suman, On Sat, Mar 15, 2014 at 1:58 AM, Suman Anna s-a...@ti.com wrote: The series doesn't change the semantics of hwspinlock registration or adds a new OF controller registration function. Implementations would still need to register a controller using a base_id and number of locks. The series rather adds a DT-friendly function _ONLY_ for requesting a specific hwlock, and there are no restrictions on the args specifier being relative id numbers. Though this is what the simple default xlate helper does (most common usage), the added xlate ops and #hwlock-cells should allow individual implementation drivers to adjust any variations, and return a relative lock w.r.t its registered base_id, as this is how a lock gets registered in the first place. I might be missing something, but why can't we have the specifier+base_id be the hwlock id and then we can entirely drop most of the core changes in this patch-set? base_id would be a property (if added) of the hwspinlock controller node, and from DT perspective, we will be using the phandle for the controller anyway. So, using a base_id+specifier seems redundant, as the specifier is already w.r.t a hwspinlock controller node. It is best to leave the base_id out, just use the specifier. This is pretty much the standard practice (GPIOs, DMAs, etc all follow this). Please see the comments from Mark regarding the same on an earlier version. http://marc.info/?l=linux-omapm=138135487703774w=2 I realize we couldn't easily support sparse id numbers, but not sure this is relevant to hwspinlocks? do we have a use case that couldn't be supported in this case? I agree on the sparse id numbers on hwspinlock, I don't see a need for it. I actually started out this series with the base_id property, and dropped it in v3 based on comments looking at it from the request-specific-lock semantics with DT. That said, the drivers still need to manage a 'base_id' needed for registration when they get probed for multiple controllers. Getting the base_id from DT _may_ be useful just for registration purposes, but for requesting a hwlock, a controller phandle and an implementation defined args-specifier should suffice IMHO. How could drivers know what the base_id is if DT doesn't provide it? please note that we can't depend on order of controller probing; the hwlock id numbers cannot depend on implementation details. Yes, I agree this is an issue if we have to have the base_ids fixed per controller. But I don't think it makes any difference from requesting a lock from a client DTS node. I can bring it back if Mark agrees. The exact notion of informing the hwspinlock core about a list of reserved locks is missing at the moment (even in the non-DT case). I am not sure if this got lost during the conversion of the registration from per lock to registering a bank of locks together, or if it is implied by the base_id + num_locks combination. The core today supports requesting only those locks that were actually registered, whether allocating a free one dynamically or giving a specific one. Before DT came along, early board code could have reserved specific hwspinlocks if needed. Now with DT, we should add the list of reserved locks to the controller node, in order to prevent them from being dynamically allocated by others. But that strictly relied on the order of requests without any core changes in the hwspinlock core, right. Also mandates that unique locks were requested for different clients (left to board integration). The early board code also has to pass on the reserved hwspinlock information to the actual client driver somehow (platform data). With DT, the early board code is much simplified. Looking at the same scenario from DT case, it seems kinda redundant to specify a set of reserved locks both in the controller node, as well as the respective client drivers, as there is almost no platform data with DT. The only use case for DT client nodes would be for requesting specific locks. I agree with the problem you described, and I think it will require a different set of changes to the core. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] iommu/omap: Use the cache cleaning API
Hi Santosh,
On 03/15/2014 12:54 PM, Santosh Shilimkar wrote:
On Friday 14 March 2014 09:49 PM, Suman Anna wrote:
Hi Santosh, Laurent, Russell, Arnd,
On 03/14/2014 12:51 PM, Santosh Shilimkar wrote:
On Friday 14 March 2014 12:38 PM, Laurent Pinchart wrote:
Hi Santosh,
On Friday 14 March 2014 12:15:11 Santosh Shilimkar wrote:
+ Russell, Arnd
On Thursday 13 March 2014 10:47 PM, Anna, Suman wrote:
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
The page table entries must be cleaned from the cache before being
accessed by the IOMMU. Instead of implementing cache management manually
(and ignoring L2 cache), use clean_dcache_area() to make sure the
entries are visible to the device.
Thanks for fixing this, this has been long pending. There have been some
previous attempts at this as well by Ramesh Gupta, with the last thread
(a long time now) being
http://marc.info/?t=13475203541r=1w=2
Santosh,
Can you please take a look at this patch and provide your comments?
regards
Suman
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 41 ++-
1 file changed, 10 insertions(+), 31 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index a893eca..bb605c9 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -500,24 +500,9 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
/*
*H/W pagetable operations
*/
-static void flush_iopgd_range(u32 *first, u32 *last)
+static void flush_pgtable(void *addr, size_t size)
{
-/* FIXME: L2 cache should be taken care of if it exists */
-do {
-asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pgd
-: : r (first));
-first += L1_CACHE_BYTES / sizeof(*first);
-} while (first = last);
-}
-
-static void flush_iopte_range(u32 *first, u32 *last)
-{
-/* FIXME: L2 cache should be taken care of if it exists */
-do {
-asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pte
-: : r (first));
-first += L1_CACHE_BYTES / sizeof(*first);
-} while (first = last);
+clean_dcache_area(addr, size);
I remember NAKing this approach in past and my stand remains same.
The cache APIs which you are trying to use here are not suppose
to be used outside.
So this particular change has a long history (have to dig through to educate
myself). I have not seen clean_dcache_area attempted before, and I wasn't sure
myself it it can be used here. Ramesh and Fernando definitely did start out
with dmac_flush_range and outer_flush_range which was definitely nacked [1].
OK. Please wrap the lines appropriately while replying.
Hmm, weird. I don't see this with my other responses. But sorry for
the trouble.
Please note that the omap-iommu driver already uses clean_dcache_area().
That's where I got the idea :-)
So that fall through the cracks then ;-)
I think the right way to fix this is to make use of streaming APIs.
If needed, IOMMU can have its own dma_ops for special case
handling if any.
I can replace clean_dcache_area() with dma_map_page() as done by the arm-smmu
driver. If that's fine I'll modify this patch accordingly in v2.
Ramesh had also attempted to use dma_page_single() previously [2], and Russell
has instead suggested to extend the cpu cache operations [3].
Ramesh had worked based on this suggestion and the series reached v6 [4] (same
as link I mentioned above) and this is the last attempt on this, but the thread
went silent.
I am wondering if that is still valid and is the right way to go, as this seems
to be a common problem. I do see dmac_flush_range being used for similar
purposes in msm_iommu.c and exynos-iommu.c, so looks like they also fell
through the cracks.
Thanks for the links. I think you should revive the v6 series unless and until
RMK has some other suggestion. This can also help to remove the wrong usages
from other IOMMU drivers as you pointed out.
OK, will do.
regards
Suman
Laurent,
Can you drop this patch out from v2 so that it is not clubbed with the small
cleanup patches, and we can track this separately?
Agree
Regards,
Santosh
[1] http://marc.info/?l=linux-omapm=129907009019355w=2
[2] http://marc.info/?t=13028180495r=1w=2
[3] http://marc.info/?l=linux-omapm=131310179423214w=2
[4] http://marc.info/?t=13475203541r=1w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions
Hi Laurent, Sakari, On 03/16/2014 04:54 PM, Sakari Ailus wrote: Hi Laurent and Suman, On Fri, Mar 14, 2014 at 12:00:16PM +0100, Laurent Pinchart wrote: Hi Suman, (CC'ing Joerg Roedel and Marek Szyprowski for the core IOMMU discussion) On Thursday 13 March 2014 21:33:37 Suman Anna wrote: On 03/07/2014 06:46 PM, Laurent Pinchart wrote: Hello, This patch set fixes miscellaneous issues with the OMAP IOMMU driver, found when trying to port the OMAP3 ISP away from omap-iovmm to the ARM DMA API. The biggest issue is fixed by patch 5/5, while the other patches fix smaller problems that I've noticed when reading the code, without experiencing them at runtime. I'd like to take this as an opportunity to discuss OMAP IOMMU integration with the ARM DMA mapping implementation. The idea is to hide the IOMMU completely behind the DMA mapping API, making it completely transparent to drivers. Thanks for starting the discussion. A drivers will only need to allocate memory with dma_alloc_*, and behind the scene the ARM DMA mapping implementation will find out that the device is behind an IOMMU and will map the buffers through the IOMMU, returning an I/O VA address to the driver. No direct call to the OMAP IOMMU driver or to the IOMMU core should be necessary anymore. To use the IOMMU the ARM DMA implementation requires a VA mapping to be created with a call to arm_iommu_create_mapping() and to then be attached to the device with arm_iommu_attach_device(). This is currently not performed by the OMAP IOMMU driver, I have thus added that code to the OMAP3 ISP driver for now. I believe this to still be an improvement compared to the current situation, as it allows getting rid of custom memory allocation code in the OMAP3 ISP driver and custom I/O VA space management in omap-iovmm. However, that code should ideally be removed from the driver. The question is, where should it be moved to ? One possible solution would be to add the code to the OMAP IOMMU driver. However, this would require all OMAP IOMMU users to be converted to the ARM DMA API. I assume there would be issues that I don't foresee though. Yeah, I think this will pose some problems for the other main user of IOMMUs - the remoteproc devices (DSP, Dual-Cortex M3/M4 processors in OMAP4 and beyond). A remoteproc device also needs to map memory at specific addresses for its code and data sections, and not rely on a I/O VA address being given to it. The firmware sections are already linked at specific addresses, and so remoteproc needs to allocate memory, load the firmware and map into appropriate device addresses. We are doing this currently usage a combination of CMA memory to get contiguous memory (there are some restrictions for certain sections) and iommu_map/unmap API to program the MMU with these pages. This usage is different from what is expected from exchanging buffers, which can be allocated from a predefined mapping range. Even that one is tricky if we need to support different cache properties/attributes as the cache configuration is in general local to these processors. Right, we indeed need two levels of API, one for drivers such as remoteproc that need direct control of the IOMMU, and one for drivers that only need to map buffers without any additional requirement. In the second case the drivers should ideally use the DMA mapping API not even be aware that an IOMMU is present. This would require moving the ARM mapping allocation out of the client driver. Actually, I think there is one another use case, even with remoteprocs which is to runtime map buffers. This is different from the firmware management. The memory for buffers could have been allocated from other subsystems, but remoteproc would need just to manage the VA space and map. The IOMMU core or the IOMMU driver will need to know whether the driver expects to control the IOMMU directly or to have it managed transparently. As this is a software configuration I don't think the information belongs to DT. The question is, how should this information be conveyed? Can this be done through iommu_domain_set_attr? But that means the client driver has to dictate this. The iommu driver can be configured appropriately based on this. The driver would need to know that, I think. Currently the DMA mapping API doesn't allow explicit addressing to IOVA address space AFAIK. The IOMMU API does. It's a good question how to do this as I don't think there's even a way for the driver to explicitly obtain access to the IOMMU. The virtual address space allocation would need to take into account that some of the address space is actually mapped outside it. The iova library can do this already. I'm not even sure whether the OMAP IOMMU driver would be the best place to put that code. Ideally VA spaces should be created by the platform somehow, and mapping of devices to IOMMUs should be handled by the IOMMU core instead of the IOMMU drivers. We're not there yet, and the path might
Re: [GIT PULL 1/2] omap device tree changes for v3.15, part 3
Hi Arnd, Tony,
On 03/17/2014 11:45 AM, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [140317 07:18]:
On Thursday 13 March 2014, Tony Lindgren wrote:
Hi,
Resending these two, looks like my updated scripts have some issues hitting
the mailing lists..
The following changes since commit 18c49af3ee9e32a535413a949672bea726699f04:
ARM: dts: am335x-evmsk: enable dual_emac mode (2014-03-05 11:53:36 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.15/dt-part3
for you to fetch changes up to e1902bbe44844597a38c8cbae30ca895f6e126ee:
ARM: dts: Add MMC2/SDIO/WLAN support for cm-t3530 (2014-03-12 10:40:37 -0700)
Device tree related changes to the omap iommu driver as that
is finally getting updated. Also few trivial board related
.dts updates to add more devices.
Pulled into next/dt, thanks!
Thanks, looks like the merge ddf071148934047b1e87bf89e823e74f267f0b84
introduces a build failure though:
@@@ -22,8 -23,7 +23,7 @@@
#include common-board-devices.h
#include dss-common.h
#include control.h
- #include omap-secure.h
-#include omap_device.h
+#include soc.h
struct pdata_init {
const char *compatible;
Those need to be added back to keep things building.
I haven't really been following the iommu discussions, so I have to trust
you are doing the right thing here. What is the status on iommu
support through DT? Do we have or require a generic binding for iommus?
There are certainly various things that could be improved in the
drivers/iommu, just doing grep EXPORT_SYMBOL drivers/iommu shows quite
a few things that should probably be implemented in a generic way.
Yes, Laurent is working towards removing omap-iovmm.c completely and
started a discussion/cleanup series towards thats[1]. I expect some of
the other export symbols for OMAP to also vanish slowly once iovmm is
removed.
Currently the bindings don't do much, but could probably be simplified
further. Things like ti,#tlb-entries and ti,iommu-bus-err-back may not
even be needed and could be set by the driver match .data based on the
compatible flag alone.
Yeah, I was in fact looking for feedback on exactly these properties
[2]. I haven't removed this as the only feedback I got was positive for
the changes [3].
This set contains the independent SoC related changes related to get
things moving for the drivers/iommu changes as discussed here:
http://www.spinics.net/lists/arm-kernel/msg312144.html
Some things like reset are still being done using platform_data with
a promise of future patches:
http://www.spinics.net/lists/linux-omap/msg104328.html
Are you following that, or will you have to do incompatible changes to
do that?
I'm not following too closely on the drivers/iommu parts, mostly
following just the moving away from platform data part at this point.
Suman can probably describe what needs to be done more accurately.
I am not expecting any changes to bindings as this series is mainly
adding the OMAP iommu DT nodes and having the OMAP IOMMU driver
functional with the DT-based IOMMU devices. We are yet to add any DTS
client devices use IOMMU.
regards
Suman
[1] http://marc.info/?l=linux-omapm=139423949120188w=2
[2] http://marc.info/?l=linux-omapm=139231544416973w=2
[3] http://marc.info/?l=linux-omapm=139338074931831w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/7] omap hwspinlock dt support
Hi Ohad, On 03/17/2014 02:47 PM, Ohad Ben-Cohen wrote: Hi Suman, On Mon, Mar 17, 2014 at 9:10 PM, Suman Anna s-a...@ti.com wrote: base_id would be a property (if added) of the hwspinlock controller node, and from DT perspective, we will be using the phandle for the controller anyway. So, using a base_id+specifier seems redundant, as the specifier is already w.r.t a hwspinlock controller node. It is best to leave the base_id out, just use the specifier. This is pretty much the standard practice (GPIOs, DMAs, etc all follow this). Do you mean hwspin_lock_get_id() will return just the specifier instead of base_id+specifier? This is problematic, because Linux will not be able to communicate this lock id outside to a different core running a different OS: that OS will have no idea what hwlock controller this is relative to. The behavior of hwspin_lock_get_id() is unchanged, so you will still get the global lock id back. The hwspin_lock_request_specific() (note: not the OF one) will also still be operating on the global lock id. Please see the comments from Mark regarding the same on an earlier version. I think I understand and agree with Mark generally, but in this case, the hwlock id is not an implementation detail. Unlike GPIOs/DMAs, this id number is global and system-wide (Linux is just one component in the system, and must use the same predefined id numbers all other cores use, otherwise it will be impossible to use those hwlocks for multi-core synchronization). Yes, I agree this is an issue if we have to have the base_ids fixed per controller. Do you see any other way this could work if the base_ids were not predefined? Linux and some other core running a different OS must agree on the id numbers of the hardware locks we have in the system. So far, we have not come across multiple controllers. I see your point, and I think this also depends on the semantics of how you exchange the lock id number. The agreement at the moment is on base_ids across multiple SoC components. If the semantics involve exchanging the controller instance, for example, then we might get away with it. But that probably involves adding additional helpers to retrieve controller instance in addition to lock number, or some other similar functions. I can add back the hwlock-base-id binding to the controller node. Mark, Kumar, Do you have any issues adding back this element for registration purposes? Before DT came along, early board code could have reserved specific hwspinlocks if needed. Now with DT, we should add the list of reserved locks to the controller node, in order to prevent them from being dynamically allocated by others. But that strictly relied on the order of requests without any core changes in the hwspinlock core, right. I don't think so, you could request a specific lock by id number. Sorry, I should have rephrased it better - by order, I meant the inherent order between board early code and other drivers. With DT, we cannot guarantee that right, as specific locks are requested from drivers. With DT, the early board code is much simplified. Looking at the same scenario from DT case, it seems kinda redundant to specify a set of reserved locks both in the controller node, as well as the respective client drivers, as there is almost no platform data with DT. The only use case for DT client nodes would be for requesting specific locks. I agree with the problem you described, and I think it will require a different set of changes to the core. Exactly. The platform-specific hwspinlock driver will have to inform the core, upon registration, which of the locks are already reserved. In turn, the core will never provide them to clients that dynamically allocate an hwlock: they will be provided only to clients that ask for them specifically (using phandle+specifier). Understood. And we may have to assign the client association with a lock as well. These are core changes that were actually not needed in the non-DT case due to the inherent order as stated above. So, are you suggesting that we add one more property to the controller node to mark which are reserved, or rely on constructing this through DT tree parsing? regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] iommu/omap: Use the cache cleaning API
On 03/17/2014 06:12 PM, Laurent Pinchart wrote: Hi Arnd, On Friday 14 March 2014 17:57:48 Arnd Bergmann wrote: On Friday 14 March 2014, Santosh Shilimkar wrote: I remember NAKing this approach in past and my stand remains same. The cache APIs which you are trying to use here are not suppose to be used outside. I think the right way to fix this is to make use of streaming APIs. If needed, IOMMU can have its own dma_ops for special case handling if any. Russell, Arnd might have more ideas. I have a bad feeling about using the dma-mapping API within the IOMMU code, because that driver is also used to implement the dma-mapping API for devices attached to the IOMMU. It's possible that it just works. Right, but I hope the memory port used by the IOMMU to fetch page table entries will not go through itself the same IOMMU :-) Is the IOMMU actually designed to have page tables in noncoherent memory? I would have expected that the iopt accesses must all be done on dma_alloc_coherent() provided memory to guarantee proper accesses. I'm not knowledgeable enough about the OMAP IOMMU, but at least the Renesas IOMMU doesn't need coherent memory as long as the driver makes sure that changes to the page tables are made visible to the device. That is the case with OMAP IOMMU as well, we have all along been using non-coherent memory. Switching to coherent memory will probably simplify things in the IOMMU driver (and eliminate this discussion on OMAP :)) regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/7] omap hwspinlock dt support
Hi Ohad, On 03/14/2014 03:10 PM, Ohad Ben-Cohen wrote: Hi Suman, Mark, On Mon, Feb 24, 2014 at 8:14 PM, Suman Anna s-a...@ti.com wrote: Mark, Ohad, ... Gentle reminder, can you provide your acks/comments? Sorry for the late jump in. I have a few comments: Thanks for the comments. It probably covers few topics that are slightly beyond the scope of the series, but nevertheless are good discussion points for finalizing the series. - Hardware spinlocks must have global and system-wide id numbers; these numbers cannot be maintained internally by the Linux Kernel. Think of an SoC with several asynchronous heterogeneous processors, each of which is running a different OS, and they all need to use a specific hardware spinlock in order to share some resource. For that to happen, every hwlock must have a predefined and deterministic id number which is global in the system. We can't have those id numbers be relative to an hwlock controller, and we can't have two hwlock controllers share the same id numbers. The series doesn't change the semantics of hwspinlock registration or adds a new OF controller registration function. Implementations would still need to register a controller using a base_id and number of locks. The series rather adds a DT-friendly function _ONLY_ for requesting a specific hwlock, and there are no restrictions on the args specifier being relative id numbers. Though this is what the simple default xlate helper does (most common usage), the added xlate ops and #hwlock-cells should allow individual implementation drivers to adjust any variations, and return a relative lock w.r.t its registered base_id, as this is how a lock gets registered in the first place. - I suspect the simplest and most straight forward way to achieve this is by (a) bringing back the concept of the base_id property, and I actually started out this series with the base_id property, and dropped it in v3 based on comments looking at it from the request-specific-lock semantics with DT. That said, the drivers still need to manage a 'base_id' needed for registration when they get probed for multiple controllers. Getting the base_id from DT _may_ be useful just for registration purposes, but for requesting a hwlock, a controller phandle and an implementation defined args-specifier should suffice IMHO. (b) letting the global hwlock id be the DT identifier (plus the base_id) and then providing it directly to the drivers when needed.The latter is required in order to support dynamically allocation of hwlocks, in which case Linux must know the global system-wide id number, and then share it with the other asynchronous OSes via some IPC. Each lock still retains a global lock id value, and you can retrieve it using the existing hwspin_lock_get_id(). Why is the latter required for dynamic allocation, isn't it the other way around, allocate a lock, and you will be able to get the lock id. If wanting to request a specific lock received across, the regular hwspin_lock_request_specific should be used. - If we feel there's no way any system is going to have more than a single hwlock controller, then we can live without a base_id property, but then this needs to be clearly documented and prohibited. Today both the hwlock DT representation, and the coupled kernel code, implicitly allow this anomaly to exist. I haven't removed the concept of base_id, it is just not defined in the DT-bindings, and am currently expecting the drivers to manage it and use it for registration. - Hwlock controller nodes should have a list of reserved locks (those locks for which other nodes have a phandle+identifier pointing at) to prevent those locks from being dynamically allocated by eager drivers. The exact notion of informing the hwspinlock core about a list of reserved locks is missing at the moment (even in the non-DT case). I am not sure if this got lost during the conversion of the registration from per lock to registering a bank of locks together, or if it is implied by the base_id + num_locks combination. The core today supports requesting only those locks that were actually registered, whether allocating a free one dynamically or giving a specific one. There were some slightly similar comments from Kumar earlier on the v2 series, please see the thread in [1]. Most of these issues were discussed Arnd, Benoit and myself back then, please see below: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064265.html Thanks for the pointer to the previous discussion, I wasn't aware of an earlier attempt. The primary approach on requesting locks is actually no different from what Arnd suggested originally. regards Suman [1] http://marc.info/?l=linux-omapm=138031002012191w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 4/5] clocksource: omap-timer: Introduce clocksource driver for OMAP SoCs
Hi Joel,
On 03/13/2014 03:35 PM, Joel Fernandes wrote:
We introduce functions to initialize clocksource and clockevent, use
CLOCKSOURCE_OF_DECLARE to declare the clocksource, and handle the clocksource
selection on a per-SoC basis (Currently only AM335x is supported). Powering up
of the timer will be done with the help of the mach-omap layer function that's
introduced earlier in the series.
We make a local copy of dmtimer API for use by clocksource, the original
dmtimer API in plat-omap is kept as-is till the migration of all SoCs is
completed after which it can't be deleted.
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/clocksource/Makefile |1 +
drivers/clocksource/omap-timer.c | 1157 ++
drivers/clocksource/omap-timer.h | 422 ++
3 files changed, 1580 insertions(+)
create mode 100644 drivers/clocksource/omap-timer.c
create mode 100644 drivers/clocksource/omap-timer.h
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index c7ca50a..2ffe698 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
obj-$(CONFIG_ARM_GLOBAL_TIMER)+= arm_global_timer.o
obj-$(CONFIG_CLKSRC_METAG_GENERIC)+= metag_generic.o
obj-$(CONFIG_ARCH_HAS_TICK_BROADCAST) += dummy_timer.o
+obj-y += omap-timer.o
diff --git a/drivers/clocksource/omap-timer.c b/drivers/clocksource/omap-timer.c
new file mode 100644
index 000..91593d8
--- /dev/null
+++ b/drivers/clocksource/omap-timer.c
@@ -0,0 +1,1157 @@
+/*
+ * drivers/clocksource/omap-timer.c
+ *
+ * OMAP Dual-Mode Timers
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Joel Fernandes jo...@ti.com
+ * Tarun Kanti DebBarma tarun.ka...@ti.com
+ * Thara Gopinath th...@ti.com
+ *
+ * dmtimer adaptation to platform_driver.
+ *
+ * Copyright (C) 2005 Nokia Corporation
+ * OMAP2 support by Juha Yrjola
+ * API improvements and OMAP2 clock framework support by Timo Teras
+ *
+ * Copyright (C) 2014 Texas Instruments
+ * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include linux/init.h
+#include linux/time.h
+#include linux/interrupt.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/irq.h
+#include linux/clocksource.h
+#include linux/clockchips.h
+#include linux/slab.h
+#include linux/sched_clock.h
+
+#include linux/clk.h
+#include linux/module.h
+#include linux/io.h
+#include linux/device.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_irq.h
+#include linux/of_address.h
+
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/platform_data/dmtimer-omap.h
+#include omap-timer.h
+/*
+ * TODO: OMAP1 support removed due to need for header mach/hardware.h
+ *OMAP2 support may be broken due to lack of cpu_is stuff, see
omap_dm_timer_get_errata
+ */
+
+/**
+ * omap_dm_timer_get_errata - get errata flags for a timer
+ *
+ * Get the timer errata flags that are specific to the OMAP device being used.
+ */
+static u32 __init omap_dm_timer_get_errata(void)
+{
+ /* ifdef'd out due to lack of availaibility of soc.h */
+#if 0
+ if (cpu_is_omap24xx())
+ return 0;
You should be able to fix this using some compatible checks.
regards
Suman
+#endif
+ return OMAP_TIMER_ERRATA_I103_I767;
+}
+
+
-snip-
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] iommu/omap: Fix map protection value handling
Hi Laurent,
On 03/14/2014 04:46 AM, Laurent Pinchart wrote:
Hi Suman,
Thank you for the review.
On Thursday 13 March 2014 19:07:33 Suman Anna wrote:
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
The prot flags passed to the IOMMU map handler are defined in
include/linux/iommu.h as IOMMU_(READ|WRITE|CACHE|EXEC). However, the
driver expects to receive MMU_RAM_* OMAP-specific flags. This causes
IOMMU flags being interpreted as page sizes, leading to failures.
Hardcode the OMAP mapping parameters to little-endian, 8-bits and
non-mixed page attributes. Furthermore, as the OMAP IOMMU doesn't
support read-only or write-only mappings, ignore the prot value.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 59de3fc..9f7f1d4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1016,8 +1016,7 @@ static void iopte_cachep_ctor(void *iopte)
clean_dcache_area(iopte, IOPTE_TABLE_SIZE);
}
-static u32 iotlb_init_entry(struct iotlb_entry *e, u32 da, u32 pa,
- u32 flags)
+static u32 iotlb_init_entry(struct iotlb_entry *e, u32 da, u32 pa, int
pgsz)
{
memset(e, 0, sizeof(*e));
@@ -1025,10 +1024,10 @@ static u32 iotlb_init_entry(struct iotlb_entry *e,
u32 da, u32 pa,
e-pa= pa;
e-valid = 1;
As I was looking through this, I found a small bug here. This is unrelated
to this patch, but you can fix it in the same patch. The e-valid value is
directly used in omap2_alloc_cr, so it should be initialized to MMU_CAM_V.
It is not a problem currently as PREFETCH_IOTLB is not used, if used, this
is overriding the size bit-fields when it prefetches the entry, which may
lead to an MMU fault.
Good catch. As it's a separate issue, do you mind if I fix that in a separate
patch in v2 ?
I actually have couple of minor cleanup patches as well. I will send
them out and you can include them with your series when you post v2.
/* FIXME: add OMAP1 support */
- e-pgsz = flags MMU_CAM_PGSZ_MASK;
- e-endian= flags MMU_RAM_ENDIAN_MASK;
- e-elsz = flags MMU_RAM_ELSZ_MASK;
- e-mixed = flags MMU_RAM_MIXED_MASK;
+ e-pgsz = pgsz;
+ e-endian= MMU_RAM_ENDIAN_LITTLE;
+ e-elsz = MMU_RAM_ELSZ_8;
+ e-mixed = 0;
Thanks, the change of these settings looks good overall. The only ones for
which it may apply anyway is just the Camera in OMAP2/OMAP3 (as per TRM,
endianness conversion supported only on writes anyway, so I am assuming that
we never use the combination), and OMAP2420 DSP, for which there is no
driver currently nor is the MMU being instantiated. All other processors are
pure little endian, and they even ignore the values written in these fields.
Please recheck the Camera subsystem once, and see if the e-elsz should be
set as MMU_RAM_ELSZ_NONE (I am not too familiar with the Camera usage, so
you are probably in a better place than me).
I've tested MMU_RAM_ELSZ_NONE and it works fine. I'll update the patch in v2.
Thanks for checking and confirming this.
regards
Suman
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] iommu/omap: Flush the TLB only after updating translation table entries
Hi Laurent,
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
Flushing the TLB before updating translation entries creates a race
condition and can lead to stale TLB entries if a translation request
arrives between flushing the TLB and updating the translation entries.
As there's no requirement to flush the TLB before updating the entries,
flush it after only.
I do not expect a device to be actively using a region if we are about
to change its mapping, we expect the access from the device to be only
between a map and an unmap. The race condition (if any in such
scenarios) would exist even after this patch, like after you programmed
the entry, and the translation request comes before you flush the page.
Then it is still operating on an older address, while you have already
programmed a new one. An unmap currently clears the entry and flushes
any TLB as well, so I don't think this patch makes a big difference.
I agree that the patch won't make a difference in practice. Should I drop it
from v2 ?
Yes, that should be safe.
regards
Suman
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index cb1e1de..fedd303 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -662,10 +662,11 @@ int omap_iopgtable_store_entry(struct omap_iommu
*obj, struct iotlb_entry *e)
{
int err;
- flush_iotlb_page(obj, e-da);
err = iopgtable_store_entry_core(obj, e);
- if (!err)
+ if (!err) {
+ flush_iotlb_page(obj, e-da);
prefetch_iotlb_entry(obj, e);
+ }
return err;
}
EXPORT_SYMBOL_GPL(omap_iopgtable_store_entry);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] iommu/omap: Use the cache cleaning API
Hi Santosh, Laurent, Russell, Arnd,
On 03/14/2014 12:51 PM, Santosh Shilimkar wrote:
On Friday 14 March 2014 12:38 PM, Laurent Pinchart wrote:
Hi Santosh,
On Friday 14 March 2014 12:15:11 Santosh Shilimkar wrote:
+ Russell, Arnd
On Thursday 13 March 2014 10:47 PM, Anna, Suman wrote:
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
The page table entries must be cleaned from the cache before being
accessed by the IOMMU. Instead of implementing cache management manually
(and ignoring L2 cache), use clean_dcache_area() to make sure the
entries are visible to the device.
Thanks for fixing this, this has been long pending. There have been some
previous attempts at this as well by Ramesh Gupta, with the last thread
(a long time now) being
http://marc.info/?t=13475203541r=1w=2
Santosh,
Can you please take a look at this patch and provide your comments?
regards
Suman
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 41 ++-
1 file changed, 10 insertions(+), 31 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index a893eca..bb605c9 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -500,24 +500,9 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
/*
* H/W pagetable operations
*/
-static void flush_iopgd_range(u32 *first, u32 *last)
+static void flush_pgtable(void *addr, size_t size)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcr p15, 0, %0, c7, c10, 1 @ flush_pgd
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
-}
-
-static void flush_iopte_range(u32 *first, u32 *last)
-{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcr p15, 0, %0, c7, c10, 1 @ flush_pte
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
+ clean_dcache_area(addr, size);
I remember NAKing this approach in past and my stand remains same.
The cache APIs which you are trying to use here are not suppose
to be used outside.
So this particular change has a long history (have to dig through to
educate myself). I have not seen clean_dcache_area attempted before, and
I wasn't sure myself it it can be used here. Ramesh and Fernando
definitely did start out with dmac_flush_range and outer_flush_range
which was definitely nacked [1].
Please note that the omap-iommu driver already uses clean_dcache_area().
That's where I got the idea :-)
So that fall through the cracks then ;-)
I think the right way to fix this is to make use of streaming APIs.
If needed, IOMMU can have its own dma_ops for special case
handling if any.
I can replace clean_dcache_area() with dma_map_page() as done by the arm-smmu
driver. If that's fine I'll modify this patch accordingly in v2.
Ramesh had also attempted to use dma_page_single() previously [2], and
Russell has instead suggested to extend the cpu cache operations [3].
Ramesh had worked based on this suggestion and the series reached v6 [4]
(same as link I mentioned above) and this is the last attempt on this,
but the thread went silent.
I am wondering if that is still valid and is the right way to go, as
this seems to be a common problem. I do see dmac_flush_range being used
for similar purposes in msm_iommu.c and exynos-iommu.c, so looks like
they also fell through the cracks.
Laurent,
Can you drop this patch out from v2 so that it is not clubbed with the
small cleanup patches, and we can track this separately?
regards
Suman
[1] http://marc.info/?l=linux-omapm=129907009019355w=2
[2] http://marc.info/?t=13028180495r=1w=2
[3] http://marc.info/?l=linux-omapm=131310179423214w=2
[4] http://marc.info/?t=13475203541r=1w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP2+: Add machine entry for dra72x devices
Hi Rajendra,
On 03/14/2014 04:20 AM, Nayak, Rajendra wrote:
The only difference from the dra75x devices is the missing .smp entry.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 8e3daa1..d803d99 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -253,4 +253,22 @@ DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened Device
Tree))
.dt_compat = dra7xx_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
+
+static const char *dra72_boards_compat[] __initdata = {
How about using dra72x_ instead of dra72_ and keeping it consistent
at the other places as well?
regards
Suman
+ ti,dra72x,
+ ti,dra7,
+ NULL,
+};
+
+DT_MACHINE_START(DRA72_DT, Generic DRA72 (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap5_map_io,
+ .init_early = dra7xx_init_early,
+ .init_late = dra7xx_init_late,
+ .init_irq = omap_gic_of_init,
+ .init_machine = omap_generic_init,
+ .init_time = omap5_realtime_timer_init,
+ .dt_compat = dra72_boards_compat,
+ .restart= omap44xx_restart,
+MACHINE_END
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] iommu/omap: Fix 'no page for' debug message in flush_iotlb_page()
Hi Laurent,
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
The flush_iotlb_page() function prints a debug message when no
corresponding page was found in the TLB. That condition is incorrectly
checked and always resolves to true, given that the for_each_iotlb_cr()
loop is never interrupted and always reaches obj-nr_tlb_entries.
Nice catch.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index bb605c9..cb1e1de 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -376,6 +376,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
{
int i;
struct cr_regs cr;
+ bool found = false;
pm_runtime_get_sync(obj-dev);
@@ -394,11 +395,12 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32
da)
__func__, start, da, bytes);
iotlb_load_cr(obj, cr);
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
+ found = true;
The patch is fine as it is, but I think the loop can be breaked when an
entry is found for simplification. I do not expect that we will have
multiple entries with the same da in the TLBs (it is a multi-hit fault
scenario) to continue looping through all entries. The only means for
the multi-hit scenario to happen is user error with programming TLBs
directly. This function call seems to be added in general to take care
of any prefetching. I don't have the complete history on the
PREFETCH_IOTLB on why it was added, it doesn't seem to be enabled but
this should ideally be left to the h/w unless you are locking a TLB
entry. DSP/Bridge is the only one that uses locked TLB entries at the
moment, but it is not using the OMAP IOMMU driver yet.
regards
Suman
}
}
pm_runtime_put_sync(obj-dev);
- if (i == obj-nr_tlb_entries)
+ if (!found)
dev_dbg(obj-dev, %s: no page for %08x\n, __func__, da);
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] iommu/omap: Flush the TLB only after updating translation table entries
Hi Laurent,
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
Flushing the TLB before updating translation entries creates a race
condition and can lead to stale TLB entries if a translation request
arrives between flushing the TLB and updating the translation entries.
As there's no requirement to flush the TLB before updating the entries,
flush it after only.
I do not expect a device to be actively using a region if we are about
to change its mapping, we expect the access from the device to be only
between a map and an unmap. The race condition (if any in such
scenarios) would exist even after this patch, like after you programmed
the entry, and the translation request comes before you flush the page.
Then it is still operating on an older address, while you have already
programmed a new one. An unmap currently clears the entry and flushes
any TLB as well, so I don't think this patch makes a big difference.
regards
Suman
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index cb1e1de..fedd303 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -662,10 +662,11 @@ int omap_iopgtable_store_entry(struct omap_iommu *obj,
struct iotlb_entry *e)
{
int err;
- flush_iotlb_page(obj, e-da);
err = iopgtable_store_entry_core(obj, e);
- if (!err)
+ if (!err) {
+ flush_iotlb_page(obj, e-da);
prefetch_iotlb_entry(obj, e);
+ }
return err;
}
EXPORT_SYMBOL_GPL(omap_iopgtable_store_entry);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
