Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
* Tomi Valkeinen tomi.valkei...@iki.fi [130611 00:49]: On 10/06/13 17:14, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@iki.fi [130610 03:44]: DSS does not have DT bindings, and removing DSS from hwmod data will break DSS for omap4. Ah that's right. Care to post a patch reverting the minimal parts that you need for omap4 against omap-for-v3.11/cleanup? This one adds back the DSS data. OK thanks, applying into omap-for-v3.11/cleanup. Regards, Tony -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On 10/06/13 17:14, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@iki.fi [130610 03:44]:
DSS does not have DT bindings, and removing DSS from hwmod data will
break DSS for omap4.
Ah that's right. Care to post a patch reverting the minimal parts that
you need for omap4 against omap-for-v3.11/cleanup?
This one adds back the DSS data.
Tomi
From e23a18fe14cbfebf9b08e3004aec92e05a86a117 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Tue, 11 Jun 2013 10:37:19 +0300
Subject: [PATCH] ARM: OMAP4: hwmod data: add DSS data back
Commit 3b9b10151c6838af52244cec4af41a938bb5b7ec (ARM: OMAP4: hwmod data:
Clean up the data file) removes hwmod data for omap4, including DSS
data. DSS has not yet been converted to DT, so the hwmod data is still
needed.
This patch adds back the DSS parts of the hwmod data.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 54 ++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 5f5d631..c8d4957 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -619,6 +619,16 @@ static struct omap_hwmod_class omap44xx_dispc_hwmod_class
= {
};
/* dss_dispc */
+static struct omap_hwmod_irq_info omap44xx_dss_dispc_irqs[] = {
+ { .irq = 25 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_dss_dispc_sdma_reqs[] = {
+ { .dma_req = 5 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
static struct omap_dss_dispc_dev_attr omap44xx_dss_dispc_dev_attr = {
.manager_count = 3,
.has_framedonetv_irq= 1
@@ -628,6 +638,8 @@ static struct omap_hwmod omap44xx_dss_dispc_hwmod = {
.name = dss_dispc,
.class = omap44xx_dispc_hwmod_class,
.clkdm_name = l3_dss_clkdm,
+ .mpu_irqs = omap44xx_dss_dispc_irqs,
+ .sdma_reqs = omap44xx_dss_dispc_sdma_reqs,
.main_clk = dss_dss_clk,
.prcm = {
.omap4 = {
@@ -660,6 +672,16 @@ static struct omap_hwmod_class omap44xx_dsi_hwmod_class = {
};
/* dss_dsi1 */
+static struct omap_hwmod_irq_info omap44xx_dss_dsi1_irqs[] = {
+ { .irq = 53 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_dss_dsi1_sdma_reqs[] = {
+ { .dma_req = 74 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
static struct omap_hwmod_opt_clk dss_dsi1_opt_clks[] = {
{ .role = sys_clk, .clk = dss_sys_clk },
};
@@ -668,6 +690,8 @@ static struct omap_hwmod omap44xx_dss_dsi1_hwmod = {
.name = dss_dsi1,
.class = omap44xx_dsi_hwmod_class,
.clkdm_name = l3_dss_clkdm,
+ .mpu_irqs = omap44xx_dss_dsi1_irqs,
+ .sdma_reqs = omap44xx_dss_dsi1_sdma_reqs,
.main_clk = dss_dss_clk,
.prcm = {
.omap4 = {
@@ -680,6 +704,16 @@ static struct omap_hwmod omap44xx_dss_dsi1_hwmod = {
};
/* dss_dsi2 */
+static struct omap_hwmod_irq_info omap44xx_dss_dsi2_irqs[] = {
+ { .irq = 84 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_dss_dsi2_sdma_reqs[] = {
+ { .dma_req = 83 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
static struct omap_hwmod_opt_clk dss_dsi2_opt_clks[] = {
{ .role = sys_clk, .clk = dss_sys_clk },
};
@@ -688,6 +722,8 @@ static struct omap_hwmod omap44xx_dss_dsi2_hwmod = {
.name = dss_dsi2,
.class = omap44xx_dsi_hwmod_class,
.clkdm_name = l3_dss_clkdm,
+ .mpu_irqs = omap44xx_dss_dsi2_irqs,
+ .sdma_reqs = omap44xx_dss_dsi2_sdma_reqs,
.main_clk = dss_dss_clk,
.prcm = {
.omap4 = {
@@ -720,6 +756,16 @@ static struct omap_hwmod_class omap44xx_hdmi_hwmod_class =
{
};
/* dss_hdmi */
+static struct omap_hwmod_irq_info omap44xx_dss_hdmi_irqs[] = {
+ { .irq = 101 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_dss_hdmi_sdma_reqs[] = {
+ { .dma_req = 75 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
static struct omap_hwmod_opt_clk dss_hdmi_opt_clks[] = {
{ .role = sys_clk, .clk = dss_sys_clk },
};
@@ -733,6 +779,8 @@ static struct omap_hwmod omap44xx_dss_hdmi_hwmod = {
* set idle mode by software.
*/
.flags = HWMOD_SWSUP_SIDLE,
+ .mpu_irqs = omap44xx_dss_hdmi_irqs,
+ .sdma_reqs = omap44xx_dss_hdmi_sdma_reqs,
.main_clk = dss_48mhz_clk,
.prcm = {
.omap4 = {
@@ -765,6 +813,11 @@ static struct omap_hwmod_class omap44xx_rfbi_hwmod_class =
{
};
/* dss_rfbi */
+static struct omap_hwmod_dma_info
Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On 07/06/13 20:50, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130607 09:35]: * Paul Walmsley p...@pwsan.com [130607 05:38]: On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. OK thanks, applying into omap-for-v3.11/cleanup. I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Seems to work now the same way as earlier for both omap4sdp and blaze es, except for DSS, which seems to be a separate issue as posted by Tomi. Pushed out now to omap-for-v3.11/cleanup. What issue do you refer to? DSS does not have DT bindings, and removing DSS from hwmod data will break DSS for omap4. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
* Tomi Valkeinen tomi.valkei...@iki.fi [130610 03:44]: On 07/06/13 20:50, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130607 09:35]: * Paul Walmsley p...@pwsan.com [130607 05:38]: On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. OK thanks, applying into omap-for-v3.11/cleanup. I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Seems to work now the same way as earlier for both omap4sdp and blaze es, except for DSS, which seems to be a separate issue as posted by Tomi. Pushed out now to omap-for-v3.11/cleanup. What issue do you refer to? DSS does not have DT bindings, and removing DSS from hwmod data will break DSS for omap4. Ah that's right. Care to post a patch reverting the minimal parts that you need for omap4 against omap-for-v3.11/cleanup? Regards, Tony -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
Hi, On Saturday 08 June 2013 12:14 AM, Santosh Shilimkar wrote: On Friday 07 June 2013 02:37 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130607 11:20]: On Friday 07 June 2013 01:50 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130607 09:35]: * Paul Walmsley p...@pwsan.com [130607 05:38]: On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. OK thanks, applying into omap-for-v3.11/cleanup. I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Seems to work now the same way as earlier for both omap4sdp and blaze es, except for DSS, which seems to be a separate issue as posted by Tomi. Pushed out now to omap-for-v3.11/cleanup. Thats strange. You shouldn't need those fixes since that data is expected to be coming from DT. Sricharan, Can you please try out the patch against Tony's V3.11/clean-up branch and see whats missing there. Looking at the diff output with and without, it seems to be that the DMA channels won't get configured. That should work since DMA engine changes are in mainline and the DMA channel information is already in DT. regards, Santosh The issue is that mmc, spi drivers try to get the 'dma' request number from get_platform_resource, which fails if hwmod has not populated the data. There are patches already from Balaji [1] for hsmmc, Matt Porter [2] mcspi for adapting the drivers for Dma engine. Dma engine gets the data from DT. [1] http://comments.gmane.org/gmane.linux.kernel.mmc/20378 [2] http://www.spinics.net/lists/linux-omap/msg87634.html [1] is already in mmc-next for 3.10 branch. Then one more patch for spi [3] is required for completing this. This is similar to the patch done for mmc to skip the get_platform_resource call in case of DT. [3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90112.html Regards, Sricharan -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
* Sricharan R r.sricha...@ti.com [130608 09:52]: On Saturday 08 June 2013 12:14 AM, Santosh Shilimkar wrote: On Friday 07 June 2013 02:37 PM, Tony Lindgren wrote: Looking at the diff output with and without, it seems to be that the DMA channels won't get configured. That should work since DMA engine changes are in mainline and the DMA channel information is already in DT. The issue is that mmc, spi drivers try to get the 'dma' request number from get_platform_resource, which fails if hwmod has not populated the data. There are patches already from Balaji [1] for hsmmc, Matt Porter [2] mcspi for adapting the drivers for Dma engine. Dma engine gets the data from DT. [1] http://comments.gmane.org/gmane.linux.kernel.mmc/20378 [2] http://www.spinics.net/lists/linux-omap/msg87634.html [1] is already in mmc-next for 3.10 branch. Then one more patch for spi [3] is required for completing this. This is similar to the patch done for mmc to skip the get_platform_resource call in case of DT. [3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90112.html OK thanks for looking into that. Once those driver changes hit mainline, please send a follow-up patch to remove the spi and mmc entries. Regards, Tony -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
Sorry for top posting. We should still drop the IRQ data for those devices and only retain DMA data in that case. Tony, can you please refresh your commit so that IRQ data is dropped from those devices ? Regards, Santosh From: Tony Lindgren [t...@atomide.com] Sent: Saturday, June 08, 2013 12:57 PM To: R, Sricharan Cc: Shilimkar, Santosh; Paul Walmsley; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Nayak, Rajendra; Cousson, Benoit; Kristo, Tero; K, Ambresh Subject: Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file * Sricharan R r.sricha...@ti.com [130608 09:52]: On Saturday 08 June 2013 12:14 AM, Santosh Shilimkar wrote: On Friday 07 June 2013 02:37 PM, Tony Lindgren wrote: Looking at the diff output with and without, it seems to be that the DMA channels won't get configured. That should work since DMA engine changes are in mainline and the DMA channel information is already in DT. The issue is that mmc, spi drivers try to get the 'dma' request number from get_platform_resource, which fails if hwmod has not populated the data. There are patches already from Balaji [1] for hsmmc, Matt Porter [2] mcspi for adapting the drivers for Dma engine. Dma engine gets the data from DT. [1] http://comments.gmane.org/gmane.linux.kernel.mmc/20378 [2] http://www.spinics.net/lists/linux-omap/msg87634.html [1] is already in mmc-next for 3.10 branch. Then one more patch for spi [3] is required for completing this. This is similar to the patch done for mmc to skip the get_platform_resource call in case of DT. [3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90112.html OK thanks for looking into that. Once those driver changes hit mainline, please send a follow-up patch to remove the spi and mmc entries. Regards, Tony -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
* Shilimkar, Santosh santosh.shilim...@ti.com [130608 10:27]: Sorry for top posting. We should still drop the IRQ data for those devices and only retain DMA data in that case. OK Tony, can you please refresh your commit so that IRQ data is dropped from those devices ? Additional patch please, I've already pushed it out. Regards, Tony -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. - Paul -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
* Paul Walmsley p...@pwsan.com [130607 05:38]: On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. OK thanks, applying into omap-for-v3.11/cleanup. Regards, Tony -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
* Tony Lindgren t...@atomide.com [130607 09:35]:
* Paul Walmsley p...@pwsan.com [130607 05:38]:
On Fri, 7 Jun 2013, Sricharan R wrote:
- The IO resource information like dma request lines, irq number and
ocp address space can be populated via dt blob. So such data is stripped
from OMAP4 SOC hwmod data file.
- The devices which are still missing the device tree bindings,
address space entries are not removed yet. When such devices add
the dt bindings, respective address space data can be deleted.
- Also other unnecessary hwmods like firewalls are removed as a part of
this.
Since emif was getting registered only because of this firewalls links,
the mpu-emif direct link is added now.
The above update, results in reduction of about ~1650 lines of code.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
Can't test this one since I don't have an OMAP4 DT config set up in the
testbed
yet. Maybe will add that to the testbed after the v3.10 release.
OK thanks, applying into omap-for-v3.11/cleanup.
I had to undo the following parts to avoid regressions on omap4sdp.
Can you please follow up on fixing the related issues so the fixup
won't be needed?
Seems to work now the same way as earlier for both omap4sdp and blaze
es, except for DSS, which seems to be a separate issue as posted by
Tomi. Pushed out now to omap-for-v3.11/cleanup.
Regards,
Tony
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -465,6 +465,7 @@ static struct omap_dma_dev_attr dma_dev_attr = {
.lch_count = 32,
};
+/* dma_system */
static struct omap_hwmod_irq_info omap44xx_dma_system_irqs[] = {
{ .name = 0, .irq = 12 + OMAP44XX_IRQ_GIC_START },
{ .name = 1, .irq = 13 + OMAP44XX_IRQ_GIC_START },
@@ -473,7 +474,6 @@ static struct omap_hwmod_irq_info
omap44xx_dma_system_irqs[] = {
{ .irq = -1 }
};
-/* dma_system */
static struct omap_hwmod omap44xx_dma_system_hwmod = {
.name = dma_system,
.class = omap44xx_dma_hwmod_class,
@@ -1747,6 +1747,23 @@ static struct omap_hwmod_class
omap44xx_mcspi_hwmod_class = {
};
/* mcspi1 */
+static struct omap_hwmod_irq_info omap44xx_mcspi1_irqs[] = {
+ { .irq = 65 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcspi1_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 34 + OMAP44XX_DMA_REQ_START },
+ { .name = rx0, .dma_req = 35 + OMAP44XX_DMA_REQ_START },
+ { .name = tx1, .dma_req = 36 + OMAP44XX_DMA_REQ_START },
+ { .name = rx1, .dma_req = 37 + OMAP44XX_DMA_REQ_START },
+ { .name = tx2, .dma_req = 38 + OMAP44XX_DMA_REQ_START },
+ { .name = rx2, .dma_req = 39 + OMAP44XX_DMA_REQ_START },
+ { .name = tx3, .dma_req = 40 + OMAP44XX_DMA_REQ_START },
+ { .name = rx3, .dma_req = 41 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
/* mcspi1 dev_attr */
static struct omap2_mcspi_dev_attr mcspi1_dev_attr = {
.num_chipselect = 4,
@@ -1756,6 +1773,8 @@ static struct omap_hwmod omap44xx_mcspi1_hwmod = {
.name = mcspi1,
.class = omap44xx_mcspi_hwmod_class,
.clkdm_name = l4_per_clkdm,
+ .mpu_irqs = omap44xx_mcspi1_irqs,
+ .sdma_reqs = omap44xx_mcspi1_sdma_reqs,
.main_clk = func_48m_fclk,
.prcm = {
.omap4 = {
@@ -1768,6 +1787,19 @@ static struct omap_hwmod omap44xx_mcspi1_hwmod = {
};
/* mcspi2 */
+static struct omap_hwmod_irq_info omap44xx_mcspi2_irqs[] = {
+ { .irq = 66 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcspi2_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 42 + OMAP44XX_DMA_REQ_START },
+ { .name = rx0, .dma_req = 43 + OMAP44XX_DMA_REQ_START },
+ { .name = tx1, .dma_req = 44 + OMAP44XX_DMA_REQ_START },
+ { .name = rx1, .dma_req = 45 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
/* mcspi2 dev_attr */
static struct omap2_mcspi_dev_attr mcspi2_dev_attr = {
.num_chipselect = 2,
@@ -1777,6 +1809,8 @@ static struct omap_hwmod omap44xx_mcspi2_hwmod = {
.name = mcspi2,
.class = omap44xx_mcspi_hwmod_class,
.clkdm_name = l4_per_clkdm,
+ .mpu_irqs = omap44xx_mcspi2_irqs,
+ .sdma_reqs = omap44xx_mcspi2_sdma_reqs,
.main_clk = func_48m_fclk,
.prcm = {
.omap4 = {
@@ -1789,6 +1823,19 @@ static struct omap_hwmod omap44xx_mcspi2_hwmod = {
};
/* mcspi3 */
+static struct omap_hwmod_irq_info omap44xx_mcspi3_irqs[] = {
+ { .irq = 91 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcspi3_sdma_reqs[] = {
+ { .name = tx0,
Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Friday 07 June 2013 01:50 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130607 09:35]: * Paul Walmsley p...@pwsan.com [130607 05:38]: On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. OK thanks, applying into omap-for-v3.11/cleanup. I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Seems to work now the same way as earlier for both omap4sdp and blaze es, except for DSS, which seems to be a separate issue as posted by Tomi. Pushed out now to omap-for-v3.11/cleanup. Thats strange. You shouldn't need those fixes since that data is expected to be coming from DT. Sricharan, Can you please try out the patch against Tony's V3.11/clean-up branch and see whats missing there. Regards, Santosh -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Friday 07 June 2013 02:10 PM, Paul Walmsley wrote: On Fri, 7 Jun 2013, Tony Lindgren wrote: I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Well, I can't even test it at the moment. So it's probably best for Santosh and Sricharan to fix those issues - they're the ones who are responsible for testing the patch before it's sent. Unless there's some specific reason why I'd be the best person to do it? Will take care of that Paul. Regards, Santosh -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Fri, 7 Jun 2013, Tony Lindgren wrote: I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Well, I can't even test it at the moment. So it's probably best for Santosh and Sricharan to fix those issues - they're the ones who are responsible for testing the patch before it's sent. Unless there's some specific reason why I'd be the best person to do it? - Paul -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
* Santosh Shilimkar santosh.shilim...@ti.com [130607 11:20]: On Friday 07 June 2013 02:10 PM, Paul Walmsley wrote: On Fri, 7 Jun 2013, Tony Lindgren wrote: I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Well, I can't even test it at the moment. So it's probably best for Santosh and Sricharan to fix those issues - they're the ones who are responsible for testing the patch before it's sent. Unless there's some specific reason why I'd be the best person to do it? Will take care of that Paul. Thanks, sorry I did not mean Paul, I meant the authors of the patches :) Regards, Tony -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
* Santosh Shilimkar santosh.shilim...@ti.com [130607 11:20]: On Friday 07 June 2013 01:50 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130607 09:35]: * Paul Walmsley p...@pwsan.com [130607 05:38]: On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. OK thanks, applying into omap-for-v3.11/cleanup. I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Seems to work now the same way as earlier for both omap4sdp and blaze es, except for DSS, which seems to be a separate issue as posted by Tomi. Pushed out now to omap-for-v3.11/cleanup. Thats strange. You shouldn't need those fixes since that data is expected to be coming from DT. Sricharan, Can you please try out the patch against Tony's V3.11/clean-up branch and see whats missing there. Looking at the diff output with and without, it seems to be that the DMA channels won't get configured. Regards, Tony -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Friday 07 June 2013 02:37 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130607 11:20]: On Friday 07 June 2013 01:50 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130607 09:35]: * Paul Walmsley p...@pwsan.com [130607 05:38]: On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. OK thanks, applying into omap-for-v3.11/cleanup. I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Seems to work now the same way as earlier for both omap4sdp and blaze es, except for DSS, which seems to be a separate issue as posted by Tomi. Pushed out now to omap-for-v3.11/cleanup. Thats strange. You shouldn't need those fixes since that data is expected to be coming from DT. Sricharan, Can you please try out the patch against Tony's V3.11/clean-up branch and see whats missing there. Looking at the diff output with and without, it seems to be that the DMA channels won't get configured. That should work since DMA engine changes are in mainline and the DMA channel information is already in DT. regards, Santosh -- 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
