Re: [PATCHv4 6/7] hwspinlock/omap: enable module before reading SYSSTATUS register
Felipe, On 01/14/2014 08:04 AM, Felipe Balbi wrote: Hi again, On Tue, Jan 14, 2014 at 07:10:52AM -0600, Felipe Balbi wrote: diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c index 9f56fb2..194886e 100644 --- a/drivers/hwspinlock/omap_hwspinlock.c +++ b/drivers/hwspinlock/omap_hwspinlock.c @@ -101,10 +101,23 @@ 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); +pm_runtime_get_sync(pdev-dev); another thing, you need to check return of pm_runtime_get_sync() OK, let me check this and your other comment, and the fix is probably a separate patch. I realized the changes relevant to your comments were introduced in this patch, so just refreshed the patch with fixes instead of doing a separate patch. I didn't do a v5 just for these change, and will do so if there are more comments on the DT adaptation. 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 7/7] hwspinlock/omap: enable build for AM33xx, AM43xx DRA7xx
Felipe, On 01/14/2014 07:12 AM, Felipe Balbi wrote: On Mon, Jan 13, 2014 at 06:19:24PM -0600, Suman Anna wrote: 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 how about just using ARCH_OMAP2PLUS ? We do not want the driver to build in OMAP2-only and/or OMAP3-only configurations, on which the hwspinlock IP is not even present. 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 6/7] hwspinlock/omap: enable module before reading SYSSTATUS register
Felipe, On 01/14/2014 08:04 AM, Felipe Balbi wrote: Hi again, On Tue, Jan 14, 2014 at 07:10:52AM -0600, Felipe Balbi wrote: diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c index 9f56fb2..194886e 100644 --- a/drivers/hwspinlock/omap_hwspinlock.c +++ b/drivers/hwspinlock/omap_hwspinlock.c @@ -101,10 +101,23 @@ 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); + pm_runtime_get_sync(pdev-dev); another thing, you need to check return of pm_runtime_get_sync() OK, let me check this and your other comment, and the fix is probably a separate patch. 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 7/7] hwspinlock/omap: enable build for AM33xx, AM43xx DRA7xx
On 01/14/2014 11:29 AM, Felipe Balbi wrote: On Tue, Jan 14, 2014 at 10:51:31AM -0600, Anna, Suman wrote: Felipe, On 01/14/2014 07:12 AM, Felipe Balbi wrote: On Mon, Jan 13, 2014 at 06:19:24PM -0600, Suman Anna wrote: 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 how about just using ARCH_OMAP2PLUS ? We do not want the driver to build in OMAP2-only and/or OMAP3-only configurations, on which the hwspinlock IP is not even present. It won't be enabled by default, will it ? You're just saying that it _can_ be enabled. Yes, that's correct. The menuconfig will not even show this driver at present on OMAP2-only and/or OMAP3-only configs. I would prefer to keep it that way. 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] ARM: dts: OMAP2: fix interrupt number for rng
Tony, On 01/07/2014 06:28 PM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [131223 15:01]: The irq data for rng module defined in hwmod data previously missed the OMAP_INTC_START relative offset, so the interrupt number is probably misconfigured during the DT node addition adjusting for this OMAP_INTC_START. Interrupt #36 is associated with a watchdog timer, so fix the rng module's interrupt to the appropriate interrupt #52. Hmm indeed as the .dtsi files were generated from the hwmod data. Are the other interrupts fixed earlier OK? GPMC DT nodes are already configured properly, the ISP MMU one needs fixing. I left it out to be fixed as part of Florian's patch that corrects the ISP MMU DT node. There is no IVA MMU DT node yet, and will add the correct number when we add the DT node. 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 2/7] iommu/omap: omap_iommu_attach() should return ENODEV, not NULL
On 12/17/2013 06:53 AM, Florian Vaussard wrote:
omap_iommu_attach() returns NULL or ERR_PTR in case of error, but
omap_iommu_attach_dev() only checks for IS_ERR. Thus a NULL return value (in
case driver_find_device fails) will cause the kernel to panic when
omap_iommu_attach_dev() dereferences the pointer.
In such case, omap_iommu_attach() should return ENODEV, not NULL.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Acked-by: Suman Anna s-a...@ti.com
---
drivers/iommu/omap-iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index ee83bcc..385bf5e 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -863,7 +863,7 @@ static int device_match_by_alias(struct device *dev, void
*data)
**/
static struct omap_iommu *omap_iommu_attach(const char *name, u32 *iopgd)
{
- int err = -ENOMEM;
+ int err = -ENODEV;
struct device *dev;
struct omap_iommu *obj;
@@ -871,7 +871,7 @@ static struct omap_iommu *omap_iommu_attach(const char
*name, u32 *iopgd)
(void *)name,
device_match_by_alias);
if (!dev)
- return NULL;
+ return ERR_PTR(err);
obj = to_iommu(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 0/7] Fix omap-iommu probe and convert to DT for 3.14
Hi Florian, On 12/17/2013 06:53 AM, Florian Vaussard wrote: OMAP2+ is heading towards a full device tree boot for 3.14. Currently, the iommu used by the OMAP3 camera subsystem is not yet converted. It cannot be probed as necessary data are only passed through device tree. Patches 1 and 2 are small fixes for problems encountered while developing this series. Patches 3 to 5 add the device tree logic to omap-iommu, and complete iommu data in omap3.dtsi. Patches 6 and 7 remove unused iommu hwmod data and platform code from OMAP2+. This is a good starting patch series for the OMAP iommu DT conversion, but it only handles OMAP3 ISP MMU. The OMAP3 ISP MMU is not the only MMU handled by the OMAP iommu driver. There is also an OMAP3 IVA MMU and MMUs associated with DSP and IPU in OMAP4/OMAP5. The conversion is simpler just with the OMAP3 ISP MMU, as it doesn't have any reset lines associated with it. But all the other MMUs would require asserting/deasserting the resets (performed currently through the pdata function pointers). Your patch series removes that functionality completely, and if this were to go into 3.14, this has to be handled through some pdata quirks until all the resets in hwmod data are converted to a reset driver. I have provided some more comments directly in the respective patches. regards Suman This was tested on Overo (OMAP36xx) with an MT9V032 sensor connected to the isp interface. The full testing tree can be found here [2] (not safe for merging). Patches are based on 3.13-rc3. OMAP-related patches are based on Tony's omap-for-v3.14/omap3-board-removal branch [1]. Regards, Florian [1] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git omap-for-v3.14/omap3-board-removal [2] g...@github.com:vaussard/linux.git overo-for-3.14/iommu/dt Florian Vaussard (7): iommu/omap: Do bus_set_iommu() only if probe() succeeds iommu/omap: omap_iommu_attach() should return ENODEV, not NULL iommu/omap: Convert to devicetree iommu/omap: Allow enable/disable even without pdata ARM: dts: Complete data for isp iommu ARM: OMAP2+: Remove legacy data from hwmod for omap3 isp iommu ARM: OMAP2+: Remove platform-specific omap-iommu .../devicetree/bindings/iommu/ti,omap-iommu.txt| 19 ++ arch/arm/boot/dts/omap3.dtsi | 4 +- arch/arm/mach-omap2/Makefile | 3 - arch/arm/mach-omap2/omap-iommu.c | 74 -- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8 - drivers/iommu/omap-iommu.c | 247 +++-- 6 files changed, 156 insertions(+), 199 deletions(-) create mode 100644 Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt delete mode 100644 arch/arm/mach-omap2/omap-iommu.c -- 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/7] iommu/omap: Do bus_set_iommu() only if probe() succeeds
Hi Florian,
On 12/17/2013 06:53 AM, Florian Vaussard wrote:
Currently, bus_set_iommu() is done in omap_iommu_init(). However,
omap_iommu_probe() can fail in a number of ways, leaving the platform
bus with a dangling reference to a non-initialized iommu. Perform
bus_set_iommu() only if omap_iommu_probe() succeed.
Can you clarify a bit more on what kind of issues you were seeing
specifically? In general, there can be multiple instances of the iommu,
so setting it in probe may not be fixing whatever issue you were seeing.
The current OMAP3 code has only the ISP MMU enabled, but there is also
another one for the IVA MMU (currently not configured by default).
Moving the bus_set_iommu to probe makes sense if only one iommu is
present, so this patch may not be needed at all.
Also, the main change in this patch is moving the bus_set_iommu from
omap_iommu_init to omap_iommu_probe, so you should probably leave out
moving the function. The omap_iommu_probe function would anyway need
conversion to using devm_ functions.
regards
Suman
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
drivers/iommu/omap-iommu.c | 207 +++--
1 file changed, 104 insertions(+), 103 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index bcd78a7..ee83bcc 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -930,107 +930,6 @@ static void omap_iommu_detach(struct omap_iommu *obj)
dev_dbg(obj-dev, %s: %s\n, __func__, obj-name);
}
-/*
- * OMAP Device MMU(IOMMU) detection
- */
-static int omap_iommu_probe(struct platform_device *pdev)
-{
- int err = -ENODEV;
- int irq;
- struct omap_iommu *obj;
- struct resource *res;
- struct iommu_platform_data *pdata = pdev-dev.platform_data;
-
- obj = kzalloc(sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
- if (!obj)
- return -ENOMEM;
-
- obj-nr_tlb_entries = pdata-nr_tlb_entries;
- obj-name = pdata-name;
- obj-dev = pdev-dev;
- obj-ctx = (void *)obj + sizeof(*obj);
- obj-da_start = pdata-da_start;
- obj-da_end = pdata-da_end;
-
- spin_lock_init(obj-iommu_lock);
- mutex_init(obj-mmap_lock);
- spin_lock_init(obj-page_table_lock);
- INIT_LIST_HEAD(obj-mmap);
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- err = -ENODEV;
- goto err_mem;
- }
-
- res = request_mem_region(res-start, resource_size(res),
-dev_name(pdev-dev));
- if (!res) {
- err = -EIO;
- goto err_mem;
- }
-
- obj-regbase = ioremap(res-start, resource_size(res));
- if (!obj-regbase) {
- err = -ENOMEM;
- goto err_ioremap;
- }
-
- irq = platform_get_irq(pdev, 0);
- if (irq 0) {
- err = -ENODEV;
- goto err_irq;
- }
- err = request_irq(irq, iommu_fault_handler, IRQF_SHARED,
- dev_name(pdev-dev), obj);
- if (err 0)
- goto err_irq;
- platform_set_drvdata(pdev, obj);
-
- pm_runtime_irq_safe(obj-dev);
- pm_runtime_enable(obj-dev);
-
- dev_info(pdev-dev, %s registered\n, obj-name);
- return 0;
-
-err_irq:
- iounmap(obj-regbase);
-err_ioremap:
- release_mem_region(res-start, resource_size(res));
-err_mem:
- kfree(obj);
- return err;
-}
-
-static int omap_iommu_remove(struct platform_device *pdev)
-{
- int irq;
- struct resource *res;
- struct omap_iommu *obj = platform_get_drvdata(pdev);
-
- iopgtable_clear_entry_all(obj);
-
- irq = platform_get_irq(pdev, 0);
- free_irq(irq, obj);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(res-start, resource_size(res));
- iounmap(obj-regbase);
-
- pm_runtime_disable(obj-dev);
-
- dev_info(pdev-dev, %s removed\n, obj-name);
- kfree(obj);
- return 0;
-}
-
-static struct platform_driver omap_iommu_driver = {
- .probe = omap_iommu_probe,
- .remove = omap_iommu_remove,
- .driver = {
- .name = omap-iommu,
- },
-};
-
static void iopte_cachep_ctor(void *iopte)
{
clean_dcache_area(iopte, IOPTE_TABLE_SIZE);
@@ -1265,6 +1164,110 @@ static struct iommu_ops omap_iommu_ops = {
.pgsize_bitmap = OMAP_IOMMU_PGSIZES,
};
+/*
+ * OMAP Device MMU(IOMMU) detection
+ */
+static int omap_iommu_probe(struct platform_device *pdev)
+{
+ int err = -ENODEV;
+ int irq;
+ struct omap_iommu *obj;
+ struct resource *res;
+ struct iommu_platform_data *pdata = pdev-dev.platform_data;
+
+ obj = kzalloc(sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
+ if (!obj)
+ return -ENOMEM;
+
+ obj-nr_tlb_entries = pdata-nr_tlb_entries;
+
Re: [PATCH 6/7] ARM: OMAP2+: Remove legacy data from hwmod for omap3 isp iommu
Hi Florian,
On 12/17/2013 06:53 AM, Florian Vaussard wrote:
The data are now passed using the devicetree.
Patch is good by itself. A similar change is needed for the IVA
MMU as well.
regards
Suman
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0477131..6dccd46 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -2469,15 +2469,8 @@ static struct omap_hwmod_class omap3xxx_mmu_hwmod_class
= {
/* mmu isp */
-static struct omap_mmu_dev_attr mmu_isp_dev_attr = {
- .da_start = 0x0,
- .da_end = 0xf000,
- .nr_tlb_entries = 8,
-};
-
static struct omap_hwmod omap3xxx_mmu_isp_hwmod;
-
/* l4_core - mmu isp */
static struct omap_hwmod_ocp_if omap3xxx_l4_core__mmu_isp = {
.master = omap3xxx_l4_core_hwmod,
@@ -2489,7 +2482,6 @@ static struct omap_hwmod omap3xxx_mmu_isp_hwmod = {
.name = mmu_isp,
.class = omap3xxx_mmu_hwmod_class,
.main_clk = cam_ick,
- .dev_attr = mmu_isp_dev_attr,
.flags = HWMOD_NO_IDLEST,
};
--
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 4/7] iommu/omap: Allow enable/disable even without pdata
Hi Florian,
On 12/17/2013 06:53 AM, Florian Vaussard wrote:
When booting with a devietree, no platform data is provided. Do not prematurely
exit iommu_enable() and iommu_disable() in such a case.
Platform data may still be needed if we were to go with the pdata quirks
approach for handling resets. You may need to revise the patch
description then, but the change itself may be ok if supporting only DT
devices.
regards
Suman
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
drivers/iommu/omap-iommu.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 51efcc4..0a9854d 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -149,13 +149,10 @@ static int iommu_enable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj-dev);
struct iommu_platform_data *pdata = pdev-dev.platform_data;
- if (!pdata)
- return -EINVAL;
-
if (!arch_iommu)
return -ENODEV;
- if (pdata-deassert_reset) {
+ if (pdata pdata-deassert_reset) {
err = pdata-deassert_reset(pdev, pdata-reset_name);
if (err) {
dev_err(obj-dev, deassert_reset failed: %d\n, err);
@@ -175,14 +172,11 @@ static void iommu_disable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj-dev);
struct iommu_platform_data *pdata = pdev-dev.platform_data;
- if (!pdata)
- return;
-
arch_iommu-disable(obj);
pm_runtime_put_sync(obj-dev);
- if (pdata-assert_reset)
+ if (pdata pdata-assert_reset)
pdata-assert_reset(pdev, pdata-reset_name);
}
--
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/7] ARM: dts: Complete data for isp iommu
Hi Florian,
On 12/17/2013 06:53 AM, Florian Vaussard wrote:
Add missing information required to probe the iommu for the camera
subsystem.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index daabf99..610d084 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -371,11 +371,13 @@
dma-names = tx, rx;
};
- mmu_isp: mmu@480bd400 {
+ mmu_isp: mmu_isp@480bd400 {
Any reason for switching the name to mmu_isp?
compatible = ti,omap3-mmu-isp;
ti,hwmods = mmu_isp;
reg = 0x480bd400 0x80;
interrupts = 8;
As I was testing the series, I found that this interrupt number is
wrong. The interrupt number should be 24, you can fix it in this patch.
I will post couple of patches to correct the interrupt numbers for
couple of other occurrences.
regards
Suman
+ ti,#tlb-entries = 8;
+ dma-window = 0 0xf000; /* IOVA start
length */
};
wdt2: wdt@48314000 {
--
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/7] iommu/omap: Convert to devicetree
Hi Florian,
On 12/17/2013 06:53 AM, Florian Vaussard wrote:
As OMAP2+ is moving to a full DT boot for 3.14, commit 7ce93f3
ARM: OMAP2+: Fix more missing data for omap3.dtsi file adds
basic DT bits. But the driver is not yet converted, so this will
not work and driver will not be probed. Convert it!
Apart from standard bindings, this patch uses 'dma-window' (already
used by Tegra SMMU) and adds a custom 'ti,#tlb-entries' binding.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
.../devicetree/bindings/iommu/ti,omap-iommu.txt| 19
arch/arm/mach-omap2/omap-iommu.c | 5 +++
drivers/iommu/omap-iommu.c | 36 +++---
3 files changed, 55 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
new file mode 100644
index 000..4e5027c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -0,0 +1,19 @@
+OMAP3 IOMMU used by camera subsystem
As I mentioned in comments on your cover-letter, the current binding is
only limited to OMAP3 ISP, but the driver is common for all OMAP2+ SoCs.
This binding an update to handle all SoCs.
To summarize the differences, OMAP2/3 has the same MMU register set for
all remote processor MMUs (IVA/DSP/ISP) with the only difference being
the number of TLBs supported (8 for ISP on OMAP2/3 and 32 for all other
instances on all OMAP2+ SoCs). Depending on whether the compatibility
property is defined for an SoC or for the processor, ti,#tlb-entries
can be retrieved directly from the match data or made as an optional
property, with the default value being 32.
OMAP4 and OMAP5 have some additional registers (MMU_FAULT_PC,
MMU_FAULT_STATUS, MMU_GP_REG/DSPSS_MMU_GPR) on top of the OMAP2/OMAP3
ones, and DRA7 a further superset of OMAP4/OMAP5. The only difference is
the definition of the MMU_GPR register, which is different between the
IPU and DSP processors, but present at the same offset, and dictates the
validity of the MMU_FAULT_PC and MMU_FAULT_STATUS registers. The MMU_GPR
register is also not defined on OMAP4430 ES1.0, but is present on all
other newer SoCs.
+
+Required properties:
+- compatible : ti,omap3-mmu-isp
My suggestion would be to use
ti,omap2-iommu for OMAP2/OMAP3 MMUs with the optional
ti,#tlb-entries to distinguish ISP MMU.
ti,omap4-iommu for OMAP4/OMAP5 MMUs with an additional boolean
property to distinguish the presence/functionality of the MMU_GPR register
ti,dra7-iommu for DRA7 MMUs
Mark, Tony,
Do you have any other recommendations given the above summary?
+- ti,hwmods : mmu_isp
Replace with general description
+- reg : address space for the configuration registers
+- interrupts : interrupt line
+- dma-window : IOVA start address and length.
+- ti,#tlb-entries : number of entries in the translation look-aside buffer
+
+Example:
+ mmu_isp: mmu_isp@480bd400 {
+ compatible = ti,omap3-mmu-isp;
+ ti,hwmods = mmu_isp;
+ reg = 0x480bd400 0x80;
+ interrupts = 8;
+ dma-window = 0 0xf000;
+ ti,#tlb-entries = 8;
+ };
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f6daae8..f1fab56 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -10,6 +10,7 @@
* published by the Free Software Foundation.
*/
+#include linux/of.h
#include linux/module.h
#include linux/platform_device.h
#include linux/err.h
@@ -58,6 +59,10 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
static int __init omap_iommu_init(void)
{
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
return omap_hwmod_for_each_by_class(mmu, omap_iommu_dev_init, NULL);
}
/* must be ready before omap3isp is probed */
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 385bf5e..51efcc4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -23,6 +23,9 @@
#include linux/spinlock.h
#include linux/io.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_iommu.h
+#include linux/of_irq.h
#include asm/cacheflush.h
@@ -1171,20 +1174,30 @@ static int omap_iommu_probe(struct platform_device
*pdev)
{
int err = -ENODEV;
int irq;
+ size_t len;
struct omap_iommu *obj;
struct resource *res;
struct iommu_platform_data *pdata = pdev-dev.platform_data;
+ struct device_node *of = pdev-dev.of_node;
obj = kzalloc(sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
if (!obj)
return -ENOMEM;
- obj-nr_tlb_entries = pdata-nr_tlb_entries;
-
Re: [PATCH 6/7] ARM: OMAP2+: Remove legacy data from hwmod for omap3 isp iommu
Hi Florian, On 12/17/2013 06:53 AM, Florian Vaussard wrote: The data are now passed using the devicetree. Patch is good by itself. A similar change is needed for the IVA MMU as well. As I understood, the IVA MMU is still not integrated into the iommu core, as its implementation lives under staging/tidspbridge/. But correct me if I am wrong. Yes, that is correct. That shouldn't stop us though from adding the IVA MMU node to the DT file and the associated cleanup. To begin with, we can have the DT node added with status=disabled. 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/7] iommu/omap: Do bus_set_iommu() only if probe() succeeds
Hi Florian, On 12/17/2013 06:53 AM, Florian Vaussard wrote: Currently, bus_set_iommu() is done in omap_iommu_init(). However, omap_iommu_probe() can fail in a number of ways, leaving the platform bus with a dangling reference to a non-initialized iommu. Perform bus_set_iommu() only if omap_iommu_probe() succeed. Can you clarify a bit more on what kind of issues you were seeing specifically? In general, there can be multiple instances of the iommu, so setting it in probe may not be fixing whatever issue you were seeing. The current OMAP3 code has only the ISP MMU enabled, but there is also another one for the IVA MMU (currently not configured by default). Moving the bus_set_iommu to probe makes sense if only one iommu is present, so this patch may not be needed at all. If omap_iommu_probe() fails, the init will have called bus_set_iommu() anyways. Thus, when a driver request the iommu by calling iommu_domain_alloc(), it will succeed (but iommu_attach_device() will fail if I remember). Yeah, thats the behavior I expected anyway. Leaving a driver with a dangling reference to a phantom iommu is not good IMHO. It will lead to strange behaviours one day or another. As for the multiple iommu case, as I do not think it is currently possible, as bus_type (in this case platform_bus_type) has only one struct iommu_ops. bus_set_iommu() will return EBUSY on the second call. Am I missing something? What I meant was the problem you cited will still exist, say if ISP MMU probe failed, but the IVA MMU probe succeeded. The bus_set_iommu() can only be called once anyway, so moving it from init to probe would not help much. regards Suman Also, the main change in this patch is moving the bus_set_iommu from omap_iommu_init to omap_iommu_probe, so you should probably leave out moving the function. The omap_iommu_probe function would anyway need conversion to using devm_ functions. This was my first try also, but as bus_set_iommu() needs omap_iommu_ops (itself depending on several functions), its call must come after the declaration of omap_iommu_ops. Thus I moved omap_iommu_probe() after the declaration of omap_iommu_ops. But I can probably use a forward declaration for omap_iommu_ops, this would be better. Indeed, we can also convert to devm_. Regards, Florian -- 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/7] iommu/omap: Convert to devicetree
Hi Florian, On 12/17/2013 06:53 AM, Florian Vaussard wrote: As OMAP2+ is moving to a full DT boot for 3.14, commit 7ce93f3 ARM: OMAP2+: Fix more missing data for omap3.dtsi file adds basic DT bits. But the driver is not yet converted, so this will not work and driver will not be probed. Convert it! Apart from standard bindings, this patch uses 'dma-window' (already used by Tegra SMMU) and adds a custom 'ti,#tlb-entries' binding. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch --- .../devicetree/bindings/iommu/ti,omap-iommu.txt| 19 arch/arm/mach-omap2/omap-iommu.c | 5 +++ drivers/iommu/omap-iommu.c | 36 +++--- 3 files changed, 55 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file mode 100644 index 000..4e5027c --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt @@ -0,0 +1,19 @@ +OMAP3 IOMMU used by camera subsystem As I mentioned in comments on your cover-letter, the current binding is only limited to OMAP3 ISP, but the driver is common for all OMAP2+ SoCs. This binding an update to handle all SoCs. To summarize the differences, OMAP2/3 has the same MMU register set for all remote processor MMUs (IVA/DSP/ISP) with the only difference being the number of TLBs supported (8 for ISP on OMAP2/3 and 32 for all other instances on all OMAP2+ SoCs). Depending on whether the compatibility property is defined for an SoC or for the processor, ti,#tlb-entries can be retrieved directly from the match data or made as an optional property, with the default value being 32. It makes sense. OMAP4 and OMAP5 have some additional registers (MMU_FAULT_PC, MMU_FAULT_STATUS, MMU_GP_REG/DSPSS_MMU_GPR) on top of the OMAP2/OMAP3 ones, and DRA7 a further superset of OMAP4/OMAP5. The only difference is the definition of the MMU_GPR register, which is different between the IPU and DSP processors, but present at the same offset, and dictates the validity of the MMU_FAULT_PC and MMU_FAULT_STATUS registers. The MMU_GPR register is also not defined on OMAP4430 ES1.0, but is present on all other newer SoCs. Thank you for this detailed comparison ! I do not know much about OMAP4 and OMAP5. In the current implementation, I was unable to find references to these specificities. Is this currently supported? OMAP4 iommu devices are instantiated today in legacy form, using the hwmod data. These are used by the remoteproc driver. OMAP5 data has not yet been added, as there is no point in adding it in legacy form at the moment. + +Required properties: +- compatible : ti,omap3-mmu-isp My suggestion would be to use ti,omap2-iommu for OMAP2/OMAP3 MMUs with the optional ti,#tlb-entries to distinguish ISP MMU. ti,omap4-iommu for OMAP4/OMAP5 MMUs with an additional boolean property to distinguish the presence/functionality of the MMU_GPR register ti,dra7-iommu for DRA7 MMUs Mark, Tony, Do you have any other recommendations given the above summary? +- ti,hwmods : mmu_isp Replace with general description You mean something like Name of the hwmod associated to the IOMMU? Yes. regards Suman [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 0/7] Fix omap-iommu probe and convert to DT for 3.14
Hi Florian, On 12/17/2013 06:53 AM, Florian Vaussard wrote: OMAP2+ is heading towards a full device tree boot for 3.14. Currently, the iommu used by the OMAP3 camera subsystem is not yet converted. It cannot be probed as necessary data are only passed through device tree. Patches 1 and 2 are small fixes for problems encountered while developing this series. Patches 3 to 5 add the device tree logic to omap-iommu, and complete iommu data in omap3.dtsi. Patches 6 and 7 remove unused iommu hwmod data and platform code from OMAP2+. This is a good starting patch series for the OMAP iommu DT conversion, but it only handles OMAP3 ISP MMU. The OMAP3 ISP MMU is not the only MMU handled by the OMAP iommu driver. There is also an OMAP3 IVA MMU and MMUs associated with DSP and IPU in OMAP4/OMAP5. The conversion is simpler just with the OMAP3 ISP MMU, as it doesn't have any reset lines associated with it. But all the other MMUs would require asserting/deasserting the resets (performed currently through the pdata function pointers). Your patch series removes that functionality completely, and if this were to go into 3.14, this has to be handled through some pdata quirks until all the resets in hwmod data are converted to a reset driver. Indeed, this patchset currently addresses only the OMAP ISP IOMMU. For the OMAP3 IVA, the current implementation looks completely different (inside drivers/staging/tidspbridge/). And to the best of my knowledge, the current omap-iommu driver can handle only one instance. By calling bus_set_iommu(platform_bus_type, omap_iommu_ops); Not really, the omap_iommu_ops are identical for all instances. The usage would be by different drivers, with each of them doing a attach for the respective device. the driver register the iommu on the platform bus (which is maybe not the best choice). This call will fill the struct iommu_ops of the bus_type, but if an iommu is already present, it will fail and return EBUSY. Thus only one iommu can be set on the same bus. But for the OMAP4 and OMAP5, I understand your concern. If a reset is needed for these IPs, then a solution must be found. pdata-quirks can be a temporary solution for 3.14. Otherwise a proper reset controller should be devised from the current PRM module. Even if I already looked at the reset core, I do not know the amount of work necessary for this solution. And I do not have the hardware to test the solution. But I can have a look after the XMAS break. Yeah, the DT conversion has been on my list, and wanted to do this after the TI reset framework changes. That would probably take some time as it also involves the hwmod framework, so the only short term solution to enable this would be to use the pdata-quirks. Tony, do you have any objections to this approach? 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 5/7] ARM: dts: Complete data for isp iommu
Hi Florian,
On 12/23/2013 03:34 PM, Florian Vaussard wrote:
Hi Suman,
On 12/23/2013 08:12 PM, Anna, Suman wrote:
Hi Florian,
On 12/17/2013 06:53 AM, Florian Vaussard wrote:
Add missing information required to probe the iommu for the camera
subsystem.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index daabf99..610d084 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -371,11 +371,13 @@
dma-names = tx, rx;
};
-mmu_isp: mmu@480bd400 {
+mmu_isp: mmu_isp@480bd400 {
Any reason for switching the name to mmu_isp?
The name of the hwmod is mmu_isp. This was not working otherwise,
but I cannot tell you for sure why without getting back at my office.
Ok, did a bit of digging, this is due to the name tie-in for iommu arch
data (look at the omap3_camera_init in mach-omap2/devices.c), and the
obj-name assignment of of-name. This is another thing that needs to be
looked into since it would be preferable to move away from the name
based lookup towards using a phandle approach by the iommu consumer drivers.
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: [PATCHv3 0/8] omap hwspinlock dt support
Hi, This is an updated series addressing the review comments from the v2 series. The hwmod patches have been dropped from the repost as per Paul's request, they have already been queued. Mark, Any comments on this series? Tony has picked up the OMAP DTS patches for 3.13, and so the ti,omap4-hwspinlock compatible string is showing up as undocumented in linux-next. How do you want me to proceed here? I will be separating out the bindings into separate patches in the future. regards Suman The series is tested on top of v3.12-rc4 + Benoit's 3.13 DTS branch and Tero's clock series, along with the queued hwmod patches. Changes in 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 - OMAP AM335 support patches are unchanged from v2. - OMAP DTS patches are unchanged from v2. v2 - Added a new common DT binding documentation and OF helpers (Patch1), addressing the review comments from v1 [2]. The MSM support [1] needs to be reworked on top of this common patch. - Revised OMAP DT parse support to use the new OF helper (Patch2) - OMAP5 hwspinlock support including the hwmod entry and DT node (Patches 4, 5) - Add AM335x support to OMAP hwspinlock driver, including a fix needed in driver given that AM335 spinlock module requires s/w wakeup (Patches 6, 7) - AM335 DT node for spinlock, and a hwmod change to enable smart-idle for AM335 (Patches 8, 9). The sysc patch is not essential for AM335 spinlock functionality, but is needed for smart-idling the IP when the module is enabled. - OMAP4 DT node patch is unchanged (Patch 3) 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 [1] https://lkml.org/lkml/2013/8/14/528 [2] http://marc.info/?t=13782309035r=1w=2 Suman Anna (8): hwspinlock/core: maintain a list of registered hwspinlock banks hwspinlock/core: add common dt bindings and OF helpers hwspinlock/omap: add support for dt nodes hwspinlock/omap: enable module before reading SYSSTATUS register hwspinlock/omap: support AM33xx ARM: dts: OMAP4: Add hwspinlock node ARM: dts: OMAP5: Add hwspinlock node ARM: dts: AM33XX: Add hwspinlock node .../devicetree/bindings/hwlock/hwlock.txt | 49 .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 19 +++ arch/arm/boot/dts/am33xx.dtsi | 6 + arch/arm/boot/dts/omap4.dtsi | 6 + arch/arm/boot/dts/omap5.dtsi | 6 + arch/arm/mach-omap2/Makefile | 3 - arch/arm/mach-omap2/hwspinlock.c | 60 -- drivers/hwspinlock/Kconfig | 2 +- drivers/hwspinlock/hwspinlock_core.c | 133 - drivers/hwspinlock/hwspinlock_internal.h | 2 + drivers/hwspinlock/omap_hwspinlock.c | 38 -- include/linux/hwspinlock.h | 19 ++- 12 files changed, 263 insertions(+), 80 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt delete mode 100644 arch/arm/mach-omap2/hwspinlock.c -- 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: find real users and drivers of rpmsg
Barry,
On Mon, Jul 8, 2013 at 10:31 AM, Barry Song 21cn...@gmail.com wrote:
hi Ohad/all,
i am trying to find some real users of rpmsg, here i only get
samples/rpmsg/rpmsg_client_sample.c, does it mean other real drivers
are out of mainline?
Yes
where could i get them?
TI maintains them in internal trees, some of which might be public.
I'm looping in Suman from TI who might be able to refer you to some
You will find couple of rpmsg client drivers in our product kernels.
Following is a kernel used towards our Android product, you can look
in the drivers/rpmsg folder.
http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-
linux-omap-3.4
yes. i have repmsg-resmgr and repmsg-omx now. and i also have
sysbios-rpmsg and domx. thanks!
i am also trying to find source codes running in Cortex-M3 which use
rpmsg and hope to find some Linux userspace codes which use rpmsg too.
Thanks
barry
Some information from the following wiki might also be handy (kinda old,
but still useful) for you to find the equivalent code running on the
Cortex-M3
http://omappedia.org/wiki/Category:RPMsg
DOMX(Distributed OpenMAX for OMAP4 processors) on the page seems to be
based on syslink and lose maintaince for 3 years, where can i get a
new version based on rpmsg?
Look through the following project,
http://git.omapzoom.org/?p=platform/hardware/ti/domx.git;a=shortlog;h=refs/heads/p-jb-mr1-release
regards
Suman
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [GIT PULL 7/7] omap mailbox move to drivers for v3.11 merge window
Arnd, On Tuesday 18 June 2013, Tony Lindgren wrote: The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10: Linux 3.10-rc5 (2013-06-08 17:41:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap- for-v3.11/mailbox-signed for you to fetch changes up to d2e993289cc5f1780ce74188e3a8d2b404748397: Merge tag 'omap-mailbox-for-v3.11' of git://github.com/sumananna/mailbox into omap-for-v3.11/mailbox (2013-06-17 03:51:54 -0700) Move OMAP Mailbox framework to drivers via Suman Anna s-a...@ti.com The OMAP Mailbox driver framework is moved out of arch/arm folder into drivers/mailbox folder, to re-enable building it and also serve as a baseline for adapting to the new mailbox driver framework. The changes mainly contain: - a minor bug fix and cleanup of mach-specific mailbox code - remove any header dependencies from plat-omap for multi-platform support - represent mailbox device data through platform data/hwmod attrs - move the omap mailbox code out of plat-omap/mach-omapX to drivers/mailbox folder I've pulled this into next/drivers as well, rather than a separate branch that we had for 3.10 (and dropped). I am a bit puzzled about this series though. Is it right that for 3.10 we had plans for a generic subsystem, and now it's just the omap drivers? Yes, we still have a plan for a generic subsystem, and these would form the the base patches of OMAP adaptation towards that. OMAP mailbox was disabled since couple of releases now because of the multi-platform enablement. There were couple of different work-items needed on OMAP mailbox like fixing the multi-platform, converting to DT and adapting to the new framework. The previous subsystem was derived of the OMAP mailbox, so the first and last items were kinda automatic. The newest one based on Jassi's work is not gonna reuse any OMAP stuff, so this series handles the first one to avoid a huge pending patchset for OMAP on the generic framework finalization. Regards Suman
RE: [PATCH 1/2] ARM: dts: OMAP5: add PWM capability to timer nodes missing it
Benoit, Tony,
On 04/17/2013 06:23 PM, Suman Anna wrote:
OMAP5 has 6 timers (GPTimers 5, 6, 8 to 11) that are capable of PWM.
The PWM capability property is missing from the node definitions of
couple of timers, and this has been fixed.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..0d155f5 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -422,6 +422,7 @@
interrupts = 0 41 0x4;
ti,hwmods = timer5;
ti,timer-dsp;
+ ti,timer-pwm;
};
timer6: timer@4013a000 {
@@ -458,6 +459,7 @@
reg = 0x4803e000 0x80;
interrupts = 0 45 0x4;
ti,hwmods = timer9;
+ ti,timer-pwm;
};
timer10: timer@48086000 {
@@ -465,6 +467,7 @@
reg = 0x48086000 0x80;
interrupts = 0 46 0x4;
ti,hwmods = timer10;
+ ti,timer-pwm;
};
timer11: timer@48088000 {
Make sure you copy the linux-arm and device-tree mailing lists.
Acked-by: Jon Hunter jon-hun...@ti.com
Can you include this patch in your next fixes pull request (if you haven't
already done so)? The other patch in the series is a feature change, but
this is a fix, and can go into 3.10 itself.
Regards
Suman
RE: [PATCH 2/2] ARM: OMAP4+: Add a timer attribute for timers that can interrupt IPU
Jon,
On 04/17/2013 07:04 PM, Jon Hunter wrote:
On 04/17/2013 06:23 PM, Suman Anna wrote:
Some instances of the DMTIMER peripheral on OMAP4+ devices have the
ability to interrupt the on-chip image processor unit (IPU) subsystem
(a common name for the dual Cortex-M3 subsystem on OMAP4 or the dual
Cortex-M4 subsystem on OMAP5) in addition to the ARM CPU. Add a
DMTIMER attribute to indicate which timers can interrupt the IPU.
This patch is similar to the patch, 5c3e4ec (ARM: OMAP: Add a timer
attribute for timers that can interrupt the DSP) that adds a similar
capability for DSP.
DMTIMERs that have the ability to interrupt the IPU on OMAP devices
are as follows:
OMAP1/2/3 devices : not applicable
OMAP4/5 devices : DMTIMERs 3,4,9 11
Signed-off-by: Suman Anna s-a...@ti.com
---
Documentation/devicetree/bindings/arm/omap/timer.txt | 3 +++
arch/arm/boot/dts/omap4.dtsi | 4
arch/arm/boot/dts/omap5.dtsi | 4
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16
++--
arch/arm/plat-omap/dmtimer.c | 2 ++
arch/arm/plat-omap/include/plat/dmtimer.h| 1 +
6 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
b/Documentation/devicetree/bindings/arm/omap/timer.txt
index 8732d4d..edaf664 100644
--- a/Documentation/devicetree/bindings/arm/omap/timer.txt
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -15,6 +15,9 @@ Optional properties:
- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
- ti,timer-dsp: Indicates the timer can interrupt the on-chip
DSP
in
addition to the ARM CPU.
+- ti,timer-ipu: Indicates the timer can interrupt the on-chip
IPU
(the
+ dual Cortex-M3/Cortex-M4 subsystem on
OMAP4/OMAP5) in
+ addition to the ARM CPU.
I am ok with adding a new property. However, reading the omap5
reference manual I see that the timers can interrupt the dsp, c2c and ipu.
Therefore, I am not sure if we should consider making this a property
with a value that is a mask of all other devices that can be
interrupted. For example, ti,timer-irqs.
Do you intend for this to be only a DT entry simplification, but re-use the
capability element in struct omap_dm_timer when parsing it and storing it? That
might be ok since the capability property is already a bit-mask. If the
intention is to add another element/property, then I feel it may not add that
much value.
- ti,timer-pwm: Indicates the timer can generate a PWM output.
- ti,timer-secure:Indicates the timer is reserved on a secure
OMAP device
and therefore cannot be used by the kernel.
diff --git a/arch/arm/boot/dts/omap4.dtsi
b/arch/arm/boot/dts/omap4.dtsi index 739bb79..55c633a 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -460,6 +460,7 @@
reg = 0x48034000 0x80;
interrupts = 0 39 0x4;
ti,hwmods = timer3;
+ ti,timer-ipu;
};
timer4: timer@48036000 {
@@ -467,6 +468,7 @@
reg = 0x48036000 0x80;
interrupts = 0 40 0x4;
ti,hwmods = timer4;
+ ti,timer-ipu;
};
timer5: timer@40138000 {
@@ -511,6 +513,7 @@
reg = 0x4803e000 0x80;
interrupts = 0 45 0x4;
ti,hwmods = timer9;
+ ti,timer-ipu;
ti,timer-pwm;
};
@@ -527,6 +530,7 @@
reg = 0x48088000 0x80;
interrupts = 0 47 0x4;
ti,hwmods = timer11;
+ ti,timer-ipu;
ti,timer-pwm;
};
};
diff --git a/arch/arm/boot/dts/omap5.dtsi
b/arch/arm/boot/dts/omap5.dtsi index 0d155f5..c9ecdbe 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -406,6 +406,7 @@
reg = 0x48034000 0x80;
interrupts = 0 39 0x4;
ti,hwmods = timer3;
+ ti,timer-ipu;
};
timer4: timer@48036000 {
@@ -413,6 +414,7 @@
reg = 0x48036000 0x80;
interrupts = 0 40 0x4;
ti,hwmods = timer4;
+ ti,timer-ipu;
};
timer5: timer@40138000 {
@@ -459,6 +461,7 @@
reg = 0x4803e000 0x80;
interrupts = 0 45 0x4;
ti,hwmods = timer9;
+ ti,timer-ipu;
ti,timer-pwm;
};
@@ -475,6 +478,7 @@
RE: [GIT PULL] mailbox driver framework for v3.10 merge window
On Thursday 04 April 2013, Anna, Suman wrote: OMAP and ST-Ericsson platforms are both using mailbox to communicate with some coprocessors. This series creates a consolidated framework, living under drivers/mailbox. The changes mainly contain: - create a mailbox framework independent from OMAP h/w - creates dbx500 mailbox driver for ST-Ericsson platforms - move the omap mailbox out of plat-omap/mach-omapX adapting to the new framework. - minor bug fixes in mailbox code Pulled into a new next/mailbox branch, to keep it separate from the existing subsystems. As a note for you: when you send a pull request, please make sure that you use a tag that includes the changeset text (your description above), so I don't have to copy it from the email. I noticed that you do have a tag mailbox-for-v3.10 in your tree, but the pull request was for the branch with the same contents. Thanks Arnd. Yes, the tag is for the same SHA, and has the same comments as above. I understood the process only a bit 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
[GIT PULL] mailbox driver framework for v3.10 merge window
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://github.com/sumananna/mailbox.git dbx500-prcmu-mailbox for you to fetch changes up to c497eba5247728c67ba0e0de0907723dd114134a: mailbox: fix invalid use of sizeof in mailbox_msg_send() (2013-03-23 15:04:14 +0800) -- OMAP and ST-Ericsson platforms are both using mailbox to communicate with some coprocessors. This series creates a consolidated framework, living under drivers/mailbox. The changes mainly contain: - create a mailbox framework independent from OMAP h/w - creates dbx500 mailbox driver for ST-Ericsson platforms - move the omap mailbox out of plat-omap/mach-omapX adapting to the new framework. - minor bug fixes in mailbox code This series is needed for the work currently being done on the PRCMU driver. -- Loic Pallardy (7): mailbox: rename omap_mbox in mailbox mailbox: create opened message type mailbox: change protection mechanisms mailbox: add shared memory mailbox type mailbox: add IRQF_NO_SUSPEND flag mailbox: add no_irq send message mailbox: create dbx500 mailbox driver Omar Ramirez Luna (2): mailbox: OMAP: introduce mailbox framework mailbox: split internal header from API header Suman Anna (5): mailbox: rename pl320-ipc specific mailbox.h ARM: OMAP2+: mbox: remove dependencies with soc.h mailbox/omap: check iomem resource before dereferencing it mailbox: check for NULL nb in mailbox_put mailbox: call request_irq after mbox queues are allocated Wei Yongjun (1): mailbox: fix invalid use of sizeof in mailbox_msg_send() .../devicetree/bindings/mailbox/dbx500-mailbox.txt | 27 + arch/arm/configs/omap1_defconfig | 3 +- arch/arm/mach-omap1/Makefile | 4 - arch/arm/mach-omap1/mailbox.c | 199 --- arch/arm/mach-omap2/Makefile | 3 - arch/arm/mach-omap2/devices.c | 13 +- arch/arm/mach-omap2/mailbox.c | 430 -- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 12 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 11 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 11 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 + arch/arm/plat-omap/Kconfig | 16 - arch/arm/plat-omap/Makefile| 3 - arch/arm/plat-omap/include/plat/mailbox.h | 105 arch/arm/plat-omap/mailbox.c | 435 -- drivers/cpufreq/highbank-cpufreq.c | 2 +- drivers/mailbox/Kconfig| 41 ++ drivers/mailbox/Makefile | 5 + drivers/mailbox/mailbox-dbx500.c | 648 + drivers/mailbox/mailbox-omap1.c| 229 drivers/mailbox/mailbox-omap2.c| 370 drivers/mailbox/mailbox.c | 552 ++ drivers/mailbox/mailbox_internal.h | 70 +++ drivers/mailbox/pl320-ipc.c| 2 +- drivers/remoteproc/Kconfig | 3 +- drivers/remoteproc/omap_remoteproc.c | 36 +- drivers/staging/tidspbridge/Kconfig| 3 +- drivers/staging/tidspbridge/core/_tiomap.h | 2 +- drivers/staging/tidspbridge/core/chnl_sm.c | 8 +- drivers/staging/tidspbridge/core/io_sm.c | 5 +- drivers/staging/tidspbridge/core/tiomap3430.c | 6 +- drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 6 +- drivers/staging/tidspbridge/core/tiomap_io.c | 9 +- .../tidspbridge/include/dspbridge/host_os.h| 2 +- include/linux/mailbox.h| 52 +- include/linux/pl320-ipc.h | 17 + include/linux/platform_data/mailbox-dbx500.h | 12 + include/linux/platform_data/mailbox-omap.h | 53 ++ 38 files changed, 2170 insertions(+), 1248 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt delete mode 100644 arch/arm/mach-omap1/mailbox.c delete mode 100644 arch/arm/mach-omap2/mailbox.c delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h delete mode 100644 arch/arm/plat-omap/mailbox.c create mode 100644 drivers/mailbox/mailbox-dbx500.c create mode 100644 drivers/mailbox/mailbox-omap1.c create mode 100644 drivers/mailbox/mailbox-omap2.c create mode 100644 drivers/mailbox/mailbox.c create mode 100644 drivers/mailbox/mailbox_internal.h create mode 100644 include/linux/pl320-ipc.h create mode 100644 include/linux/platform_data/mailbox-dbx500.h create mode 100644
RE: [PATCHv3 02/14] ARM: OMAP2+: mbox: remove dependencies with soc.h
Paul, The OMAP mailbox platform driver code has been cleaned up to remove the dependencies with soc.h in preparation for moving the mailbox code to drivers folder. The code relied on cpu_is_xxx/soc_is_xxx macros previously to pick the the right set of mailbox devices and register with the mailbox driver. This data is now represented in a concise format and moved to the respective omap_hwmod data files and published to the driver through the platform data. Signed-off-by: Suman Anna s-a...@ti.com The hwmod/dev_attr parts look fine to me, but please start thinking about how to convert the driver to get this data from DT instead. Yes, that is the plan. I will have the DT conversion when I add the support for OMAP5. 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: [PATCHv3 00/14] drivers: mailbox: framework creation
Stephen, I have hosted the series at [3]. Can you pull this into linux-next sometime next week? [3] https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox Please quote git URLs ... I guessed you meant git://github.com/sumananna/mailbox.git, branch dbx500-prcmu-mailbox ? Added from today. Yes, that's correct. Thanks Stephen. 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: [PATCHv3 03/14] mailbox: OMAP: introduce mailbox framework
On Wed, Mar 13, 2013 at 4:24 AM, Suman Anna s-a...@ti.com wrote: From: Omar Ramirez Luna omar.l...@linaro.org (...) Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org [s-a...@ti.com: Kconfig fixes for build errors] Signed-off-by: Suman Anna s-a...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Linus Walleij linus.wall...@linaro.org It's not like I care super-much, but I think your SoB should be at the bottom. It's a simple git rebase -i anyway... Sure, will do. Only this patch, right? I have my SoB only on one another original patch, will adjust on that as well, but all the remaining ones will have yours at the bottom. 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: [PATCHv3 01/14] mailbox: rename pl320-ipc specific mailbox.h
On Tue, Mar 12, 2013 at 10:23:50PM -0500, Suman Anna wrote: The patch 30058677 ARM / highbank: add support for pl320 IPC added a pl320 IPC specific header file as a generic mailbox.h. This file has been renamed appropriately to allow the introduction of the generic mailbox API framework. Signed-off-by: Suman Anna s-a...@ti.com Cc: Mark Langsdorf mark.langsd...@calxeda.com Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com --- drivers/cpufreq/highbank-cpufreq.c | 2 +- drivers/mailbox/pl320-ipc.c| 2 +- include/linux/mailbox.h| 17 - include/linux/pl320-ipc.h | 17 + 4 files changed, 19 insertions(+), 19 deletions(-) delete mode 100644 include/linux/mailbox.h create mode 100644 include/linux/pl320-ipc.h Why are you sending these To: me? I'm not the mailbox maintainer, and have never handled them before that I can remember. Who is the maintainer? Er.. sorry Greg, I have taken the recipient list from the original series posting, but this series should have been directed to the ARM-SoC maintainer. The patches are generalizing the OMAP mailbox driver to add support for ST's mailbox as well, and moving it to under /drivers/mailbox. The folder is new in 3.9, and the code under this, so far, has all been for ARM based chips. I guess the maintainer for this folder needs to be sorted out for the long-term. 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 v2 00/13] drivers: mailbox: framework creation
On Wed, Feb 13, 2013 at 02:36:32PM +0100, Linus Walleij wrote: On Tue, Feb 12, 2013 at 5:56 AM, Suman Anna s-a...@ti.com wrote: I have hosted the series at [3]. [3] https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox Suman, I suggest you ask Stepgen Rothwell to include this branch into the linux-next tree, so we can get some rotation of this stuff in preparation for the v3.10 merge window. (It's not going in now anyway.) Best wait until after v3.9-rc1 - remember that linux-next is supposed to be a staging tree for the _next_ merge window only. Yes, will do. Anyway, we need a new revision of one patch (so far) to address Mark Rutland's comments. Thanks 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] omap: iommu: fix pte attributes for super section
On Mon, May 16, 2011 at 2:11 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext Anna, Suman s-a...@ti.com Subject: [PATCH] omap: iommu: fix pte attributes for super section Date: Tue, 10 May 2011 10:25:17 -0700 From 5796d8d8a0ea5aee342b78ca6ead229971cff6c5 Mon Sep 17 00:00:00 2001 From: Suman Anna s-a...@ti.com Date: Wed, 4 May 2011 17:45:37 -0500 Subject: [PATCH] omap: iommu: fix pte attributes for super section The PTE programming causes a 16MB entry to be interpreted as a 4K entry because of the bitwise check, and therefore does not set the attributes properly in the first-level descriptor table. The bitwise check has been replaced appropriately. Signed-off-by: Suman Anna s-a...@ti.com Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com Tony, Can this patch be queued up for the next rc, or is there any reason for this to remain archived? https://patchwork.kernel.org/patch/774932/ 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] omap: iommu: fix pte attributes for super section
From 5796d8d8a0ea5aee342b78ca6ead229971cff6c5 Mon Sep 17 00:00:00 2001 From: Suman Anna s-a...@ti.com Date: Wed, 4 May 2011 17:45:37 -0500 Subject: [PATCH] omap: iommu: fix pte attributes for super section The PTE programming causes a 16MB entry to be interpreted as a 4K entry because of the bitwise check, and therefore does not set the attributes properly in the first-level descriptor table. The bitwise check has been replaced appropriately. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/mach-omap2/iommu2.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c index adb083e..c21fbe6 100644 --- a/arch/arm/mach-omap2/iommu2.c +++ b/arch/arm/mach-omap2/iommu2.c @@ -225,7 +225,8 @@ static u32 omap2_get_pte_attr(struct iotlb_entry *e) attr = e-mixed 5; attr |= e-endian; attr |= e-elsz 3; - attr = ((e-pgsz MMU_CAM_PGSZ_4K) ? 0 : 6); + attr = (((e-pgsz == MMU_CAM_PGSZ_4K) || + (e-pgsz == MMU_CAM_PGSZ_64K)) ? 0 : 6); return attr; } -- 1.7.0.4 -- 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/5 v2] omap2/3/4: mailbox: remove compiler warning
From 02c45559105c62343e31226fe67117231ea10c35 Mon Sep 17 00:00:00 2001
From: Suman Anna s-a...@ti.com
Date: Mon, 25 Jan 2010 18:27:21 -0600
Subject: [PATCH] omap2/3/4: mailbox: remove compiler warning
Remove a compiler warning in device-specific
mailbox module.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/mailbox.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 2c9fd1c..a732664 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -409,19 +409,19 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
if (unlikely(!res)) {
dev_err(pdev-dev, invalid irq resource\n);
ret = -ENODEV;
- goto err_iva1;
+ omap_mbox_unregister(mbox_dsp_info);
+ goto err_dsp;
}
mbox_iva_info.irq = res-start;
ret = omap_mbox_register(pdev-dev, mbox_iva_info);
- if (ret)
- goto err_iva1;
+ if (ret) {
+ omap_mbox_unregister(mbox_dsp_info);
+ goto err_dsp;
+ }
}
#endif
return 0;
-err_iva1:
- omap_mbox_unregister(mbox_dsp_info);
-
err_dsp:
iounmap(mbox_base);
return ret;
--
1.6.6.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: [RESEND] [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
Omar, +#if defined(CONFIG_ARCH_OMAP2420) /* IVA */ err_iva1: - omap_mbox_unregister(mbox_dsp_info); + if (cpu_is_omap2420()) + omap_mbox_unregister(mbox_dsp_info); +#endif why not moving omap_mbox_unregister to the block containing the ifdefs? at least you won't be adding an ifdef and if(cpu_xx) Thanks Omar for the comment. I have received multiple comments on this new #ifdef. So, have sent out a new cleaner patch removing 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 1/5] omap2/3/4: mailbox: remove compiler warning
Hi Santosh, -Original Message- From: Shilimkar, Santosh Sent: Saturday, February 20, 2010 12:47 PM To: Anna, Suman; linux-omap@vger.kernel.org Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam Subject: RE: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Anna, Suman Sent: Friday, February 19, 2010 2:37 AM To: linux-omap@vger.kernel.org Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning From 78d00b562548e1d95ad12a4d8121be67950daf68 Mon Sep 17 00:00:00 2001 From: Suman Anna s-a...@ti.com Date: Mon, 25 Jan 2010 18:27:21 -0600 Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning Remove a compiler warning in device-specific mailbox module. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/mach-omap2/mailbox.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach- omap2/mailbox.c index 2c9fd1c..c970cf6 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -419,8 +419,10 @@ static int __devinit omap2_mbox_probe(struct platform_device *pdev) #endif return 0; +#if defined(CONFIG_ARCH_OMAP2420) /* IVA */ err_iva1: omap_mbox_unregister(mbox_dsp_info); +#endif Can't we avoid the #ifdef here? Is this omap_mbox_unregister omap2 specific? Yes, this #ifdef is specific to 2420. There are other places in the mailbox code which also utilize a similar #ifdef. I have merely added it to remove the compile warning. I think it needs a separate patch to remove all the 2420 specific #ifdefs. Regards, Santosh 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 2/5] omap: mailbox: correct OMAP4 reset logic
Hi Santosh,
-Original Message-
From: Shilimkar, Santosh
Sent: Saturday, February 20, 2010 12:53 PM
To: Anna, Suman; linux-omap@vger.kernel.org
Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam
Subject: RE: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Anna,
Suman
Sent: Friday, February 19, 2010 2:37 AM
To: linux-omap@vger.kernel.org
Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam
Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
From 2488815a9facca29e2da3ddd279de441a5de6a58 Mon Sep 17 00:00:00 2001
From: Suman Anna s-a...@ti.com
Date: Tue, 26 Jan 2010 16:55:29 -0600
Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
OMAP4 mailbox has a different register set. There is
no MAILBOX_SYSSTATUS register. The reset is indicated
with the SOFTRESET bit of the MAILBOX_SYSCONFIG register
itself. This bit should read 0 for a successful Reset.
Also, the SOFTRESET bit occupies bit0 and not bit1 as with
previous generations.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/mailbox.c | 38 +++---
1 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-
omap2/mailbox.c
index c970cf6..88e9043 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -40,6 +40,7 @@
#define AUTOIDLE (1 0)
#define SOFTRESET (1 1)
#define SMARTIDLE (2 3)
+#define OMAP4_SOFTRESET(1 0)
/* SYSSTATUS: register bit definition */
#define RESETDONE (1 0)
@@ -99,17 +100,32 @@ static int omap2_mbox_startup(struct omap_mbox
*mbox)
}
clk_enable(mbox_ick_handle);
- mbox_write_reg(SOFTRESET, MAILBOX_SYSCONFIG);
- timeout = jiffies + msecs_to_jiffies(20);
- do {
- l = mbox_read_reg(MAILBOX_SYSSTATUS);
- if (l RESETDONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (!(l RESETDONE)) {
- pr_err(Can't take mmu out of reset\n);
- return -ENODEV;
+ if (cpu_is_omap44xx()) {
Not so strong opinion but can we make use of mailbox ip revision instead
of cpu_is_() check.
This may be a better option in the longer-run, but the current mailbox
registers are assigned based on the cpu_is_() macro, and I have used this
readily available macro rather doing a new one. Also, note that the IP revision
value is not published in the TRM.
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 2/5] omap: mailbox: correct OMAP4 reset logic
Hi Benoit, -Original Message- From: Cousson, Benoit Sent: Sunday, February 21, 2010 7:36 AM To: Shilimkar, Santosh; Anna, Suman; linux-omap@vger.kernel.org Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam Subject: RE: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic Hi Suman, Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Saturday, February 20, 2010 7:53 PM To: Anna, Suman; linux-omap@vger.kernel.org Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam Subject: RE: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Anna, Suman Sent: Friday, February 19, 2010 2:37 AM To: linux-omap@vger.kernel.org Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic From 2488815a9facca29e2da3ddd279de441a5de6a58 Mon Sep 17 00:00:00 2001 From: Suman Anna s-a...@ti.com Date: Tue, 26 Jan 2010 16:55:29 -0600 Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic OMAP4 mailbox has a different register set. There is no MAILBOX_SYSSTATUS register. The reset is indicated with the SOFTRESET bit of the MAILBOX_SYSCONFIG register itself. This bit should read 0 for a successful Reset. Also, the SOFTRESET bit occupies bit0 and not bit1 as with previous generations. This is due to the new standard defined for OMAP4 IPs and well explain by Thara in a recently posted patch to handle that smoothly using hwmod. [PATCH V4] OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg23509.html Is there a reason to not convert the mailbox driver to use hwmod? It will avoid you to handle that in the mailbox driver code, whereas the hwmod framework is already taking care of that. Regards, Benoit Thanks for the reference. Mailbox driver is yet to migrate to use the new hwmod. It is still based on the old framework. 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] omap2/3/4: mailbox: remove compiler warning
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, February 22, 2010 3:37 PM
To: Anna, Suman
Cc: Shilimkar, Santosh; linux-omap@vger.kernel.org;
hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam
Subject: Re: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
* Anna, Suman s-a...@ti.com [100222 11:53]:
Hi Santosh,
-Original Message-
From: Shilimkar, Santosh
Sent: Saturday, February 20, 2010 12:47 PM
To: Anna, Suman; linux-omap@vger.kernel.org
Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A,
Subramaniam
Subject: RE: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Anna,
Suman
Sent: Friday, February 19, 2010 2:37 AM
To: linux-omap@vger.kernel.org
Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A,
Subramaniam
Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
From 78d00b562548e1d95ad12a4d8121be67950daf68 Mon Sep 17 00:00:00
2001
From: Suman Anna s-a...@ti.com
Date: Mon, 25 Jan 2010 18:27:21 -0600
Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
Remove a compiler warning in device-specific
mailbox module.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/mailbox.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-
omap2/mailbox.c
index 2c9fd1c..c970cf6 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -419,8 +419,10 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
#endif
return 0;
+#if defined(CONFIG_ARCH_OMAP2420) /* IVA */
err_iva1:
omap_mbox_unregister(mbox_dsp_info);
+#endif
Can't we avoid the #ifdef here? Is this omap_mbox_unregister omap2
specific?
Yes, this #ifdef is specific to 2420. There are other places in the
mailbox code which also utilize a similar #ifdef. I have merely added it
to remove the compile warning. I think it needs a separate patch to remove
all the 2420 specific #ifdefs.
Let's drop this patch for now. We should fix this with something like
this in mailbox.h:
#ifdef CONFIG_ARCH_OMAP2420
int omap_mbox_unregister(struct omap_mbox *);
#else
static inline int omap_mbox_unregister(struct omap_mbox *mbox)
{
return 0;
}
#endif
That way we can get rid of the ifdefs in other places too.
Tony
Sorry, my statement is a little bit misleading. The omap_mbox_unregister
function itself is not specific to 2420, but rather the call is. It should be
called only for 2420, and hence the #ifdef.
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
[RESEND] [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
From 657358cd06a3f20bef2472945991749bacef12e6 Mon Sep 17 00:00:00 2001 From: Suman Anna s-a...@ti.com Date: Mon, 25 Jan 2010 18:27:21 -0600 Subject: [PATCH] omap2/3/4: mailbox: remove compiler warning Remove a compiler warning in device-specific mailbox module. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/mach-omap2/mailbox.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 2c9fd1c..8b5fc2a 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -419,8 +419,11 @@ static int __devinit omap2_mbox_probe(struct platform_device *pdev) #endif return 0; +#if defined(CONFIG_ARCH_OMAP2420) /* IVA */ err_iva1: - omap_mbox_unregister(mbox_dsp_info); + if (cpu_is_omap2420()) + omap_mbox_unregister(mbox_dsp_info); +#endif err_dsp: iounmap(mbox_base); -- 1.6.6.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] omap: mailbox: unregister correct mbox device for omap2420
Hi Aguilar, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Aguilar Pena, Leed Sent: Monday, February 22, 2010 5:55 PM To: linux-omap@vger.kernel.org Cc: t...@atomide.com; Hiroshi DOYU Subject: [PATCH] omap: mailbox: unregister correct mbox device for omap2420 label err_iva1 is defined to unregister the mbox device for omap2420 which is contained in mbox_iva_info struct mbox_dsp_info is not being used by the omap2420 Signed-off-by: Leed Aguilar leed.agui...@ti.com --- arch/arm/mach-omap2/mailbox.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Index: omap/arch/arm/mach-omap2/mailbox.c === --- omap.orig/arch/arm/mach-omap2/mailbox.c 2010-02-22 17:41:24.0 -0600 +++ omap/arch/arm/mach-omap2/mailbox.c2010-02-22 17:51:31.0 - 0600 @@ -420,7 +420,7 @@ return 0; err_iva1: - omap_mbox_unregister(mbox_dsp_info); + omap_mbox_unregister(mbox_iva_info); The err_iva1 label is indicating that the iva1 registration has failed, and you need to free the previously registered dsp. So, this patch is not valid. err_dsp: iounmap(mbox_base); -- 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 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/5] Mailbox: Fix issues for OMAP4
From f2e895f74544876572adbe3328aa27d20aa1aec4 Mon Sep 17 00:00:00 2001 From: Suman Anna s-a...@ti.com Date: Thu, 18 Feb 2010 14:34:39 -0600 Subject: [PATCH 0/5] Mailbox: Fix issues for OMAP4 This patchset has fixes for OMAP4 mailbox SYSCONFIG register. Also included are patches for improving mailbox performance, and other minor fixes. Hari Kanigeri (1): omap2/3/4: mailbox: retries in case of FIFO full Rob Clark (1): omap2/3/4: mailbox: use dedicated work queue for handling mailbox rx interrupt Suman Anna (3): omap2/3/4: mailbox: remove compiler warning omap: mailbox: correct OMAP4 reset logic omap: mailbox: correct OMAP4 SIDLEMODE logic arch/arm/mach-omap2/mailbox.c | 47 ++-- arch/arm/plat-omap/mailbox.c | 14 --- 2 files changed, 45 insertions(+), 16 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 1/5] omap2/3/4: mailbox: remove compiler warning
From 78d00b562548e1d95ad12a4d8121be67950daf68 Mon Sep 17 00:00:00 2001 From: Suman Anna s-a...@ti.com Date: Mon, 25 Jan 2010 18:27:21 -0600 Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning Remove a compiler warning in device-specific mailbox module. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/mach-omap2/mailbox.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 2c9fd1c..c970cf6 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -419,8 +419,10 @@ static int __devinit omap2_mbox_probe(struct platform_device *pdev) #endif return 0; +#if defined(CONFIG_ARCH_OMAP2420) /* IVA */ err_iva1: omap_mbox_unregister(mbox_dsp_info); +#endif err_dsp: iounmap(mbox_base); -- 1.6.6.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 3/5] omap: mailbox: correct OMAP4 SIDLEMODE logic
From 18beb1784db07e4eb2b9d10783a309b5caccb979 Mon Sep 17 00:00:00 2001 From: Suman Anna s-a...@ti.com Date: Fri, 5 Feb 2010 17:20:26 -0600 Subject: [PATCH 3/5] omap: mailbox: correct OMAP4 SIDLEMODE logic OMAP4 mailbox has a different MAILBOX_SYSCONFIG register. There is now no AutoIdle. The SIDLEMODE bits have been right-shifted by 1 bit and now occupy bits 2 3. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/mach-omap2/mailbox.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 88e9043..e0c1f1b 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -41,6 +41,8 @@ #define SOFTRESET (1 1) #define SMARTIDLE (2 3) #define OMAP4_SOFTRESET(1 0) +#define OMAP4_NOIDLE (1 2) +#define OMAP4_SMARTIDLE(2 2) /* SYSSTATUS: register bit definition */ #define RESETDONE (1 0) @@ -131,7 +133,10 @@ static int omap2_mbox_startup(struct omap_mbox *mbox) l = mbox_read_reg(MAILBOX_REVISION); pr_info(omap mailbox rev %d.%d\n, (l 0xf0) 4, (l 0x0f)); - l = SMARTIDLE | AUTOIDLE; + if (cpu_is_omap44xx()) + l = OMAP4_SMARTIDLE; + else + l = SMARTIDLE | AUTOIDLE; mbox_write_reg(l, MAILBOX_SYSCONFIG); omap2_mbox_enable_irq(mbox, IRQ_RX); -- 1.6.6.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/5] omap: mailbox: correct OMAP4 reset logic
From 2488815a9facca29e2da3ddd279de441a5de6a58 Mon Sep 17 00:00:00 2001
From: Suman Anna s-a...@ti.com
Date: Tue, 26 Jan 2010 16:55:29 -0600
Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
OMAP4 mailbox has a different register set. There is
no MAILBOX_SYSSTATUS register. The reset is indicated
with the SOFTRESET bit of the MAILBOX_SYSCONFIG register
itself. This bit should read 0 for a successful Reset.
Also, the SOFTRESET bit occupies bit0 and not bit1 as with
previous generations.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/mailbox.c | 38 +++---
1 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index c970cf6..88e9043 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -40,6 +40,7 @@
#define AUTOIDLE (1 0)
#define SOFTRESET (1 1)
#define SMARTIDLE (2 3)
+#define OMAP4_SOFTRESET(1 0)
/* SYSSTATUS: register bit definition */
#define RESETDONE (1 0)
@@ -99,17 +100,32 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
}
clk_enable(mbox_ick_handle);
- mbox_write_reg(SOFTRESET, MAILBOX_SYSCONFIG);
- timeout = jiffies + msecs_to_jiffies(20);
- do {
- l = mbox_read_reg(MAILBOX_SYSSTATUS);
- if (l RESETDONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (!(l RESETDONE)) {
- pr_err(Can't take mmu out of reset\n);
- return -ENODEV;
+ if (cpu_is_omap44xx()) {
+ mbox_write_reg(OMAP4_SOFTRESET, MAILBOX_SYSCONFIG);
+ timeout = jiffies + msecs_to_jiffies(20);
+ do {
+ l = mbox_read_reg(MAILBOX_SYSCONFIG);
+ if (!(l OMAP4_SOFTRESET))
+ break;
+ } while (!time_after(jiffies, timeout));
+
+ if (l OMAP4_SOFTRESET) {
+ pr_err(Can't take mailbox out of reset\n);
+ return -ENODEV;
+ }
+ } else {
+ mbox_write_reg(SOFTRESET, MAILBOX_SYSCONFIG);
+ timeout = jiffies + msecs_to_jiffies(20);
+ do {
+ l = mbox_read_reg(MAILBOX_SYSSTATUS);
+ if (l RESETDONE)
+ break;
+ } while (!time_after(jiffies, timeout));
+
+ if (!(l RESETDONE)) {
+ pr_err(Can't take mailbox out of reset\n);
+ return -ENODEV;
+ }
}
l = mbox_read_reg(MAILBOX_REVISION);
--
1.6.6.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 4/5] omap2/3/4: mailbox: use dedicated work queue for handling mailbox rx interrupt
From 7410bf2d5c569c83a594b99a62d03b939e4f10b8 Mon Sep 17 00:00:00 2001
From: Rob Clark r...@ti.com
Date: Mon, 4 Jan 2010 19:22:03 +0530
Subject: [PATCH 4/5] omap2/3/4: mailbox: use dedicated work queue for handling
mailbox rx interrupt
keventd_wq is a shared work-queue, and should not be used when we
need fast deterministic response. Instead mailbox driver should
use it's own private work-queue, with it's own thread, to ensure
that handling of RX interrupts are not delayed by other drivers.
The tasklet is still used for transmission of mbox messages.
Signed-off-by: Rob Clark r...@ti.com
Signed-off-by: C A Subramaniam subramaniam...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/plat-omap/mailbox.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 8e90633..4229cec 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -28,6 +28,7 @@
#include plat/mailbox.h
+static struct workqueue_struct *mboxd;
static struct omap_mbox *mboxes;
static DEFINE_RWLOCK(mboxes_lock);
@@ -188,7 +189,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
/* no more messages in the fifo. clear IRQ source. */
ack_mbox_irq(mbox, IRQ_RX);
nomem:
- schedule_work(mbox-rxq-work);
+ queue_work(mboxd, mbox-rxq-work);
}
static irqreturn_t mbox_interrupt(int irq, void *p)
@@ -401,12 +402,17 @@ EXPORT_SYMBOL(omap_mbox_unregister);
static int __init omap_mbox_init(void)
{
+ mboxd = create_workqueue(mboxd);
+ if (!mboxd)
+ return -ENOMEM;
+
return 0;
}
module_init(omap_mbox_init);
static void __exit omap_mbox_exit(void)
{
+ destroy_workqueue(mboxd);
}
module_exit(omap_mbox_exit);
--
1.6.6.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 5/5] omap2/3/4: mailbox: retries in case of FIFO full
From f2e895f74544876572adbe3328aa27d20aa1aec4 Mon Sep 17 00:00:00 2001
From: Hari Kanigeri h-kanige...@ti.com
Date: Fri, 4 Dec 2009 15:52:42 -0600
Subject: [PATCH 5/5] omap2/3/4: mailbox: retries in case of FIFO full
This patch enables check for the mailbox fifo full
Without this check in some extreme stress test cases
the FIFO seems to be still full when trying to send
the message
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/mailbox.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 4229cec..8795f18 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -71,10 +71,10 @@ static int __mbox_msg_send(struct omap_mbox *mbox,
mbox_msg_t msg)
int ret = 0, i = 1000;
while (mbox_fifo_full(mbox)) {
- if (mbox-ops-type == OMAP_MBOX_TYPE2)
- return -1;
- if (--i == 0)
+ if (--i == 0) {
+ printk(KERN_ERR Mailbox send failure\n);
return -1;
+ }
udelay(1);
}
mbox_fifo_write(mbox, msg);
--
1.6.6.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
