| Message ID | 1444926461-16092-1-git-send-email-fcooper@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 15/10/15 19:27, Franklin S Cooper Jr wrote: > ELM address information is provided by device tree. No longer need > to include this information within hwmod. > > Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> Acked-by: Roger Quadros <rogerq@ti.com> -- cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 16 Oct 2015, Roger Quadros wrote: > On 15/10/15 19:27, Franklin S Cooper Jr wrote: > > ELM address information is provided by device tree. No longer need > > to include this information within hwmod. > > > > Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> > > Acked-by: Roger Quadros <rogerq@ti.com> Thanks, queued. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 15 Oct 2015, Franklin S Cooper Jr wrote: > ELM address information is provided by device tree. No longer need > to include this information within hwmod. > > Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> The OMAP4 DTS files don't have the ELM address space declared. I'm going to drop that portion of your patch. Could you please send a two-patch series that first adds the ELM address space to the OMAP4 DTS file and then subsequently drops it from the OMAP4 hwmod data file? - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/23/2015 02:00 PM, Paul Walmsley wrote: > On Thu, 15 Oct 2015, Franklin S Cooper Jr wrote: > >> ELM address information is provided by device tree. No longer need >> to include this information within hwmod. >> >> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> > The OMAP4 DTS files don't have the ELM address space declared. I'm going > to drop that portion of your patch. Could you please send a two-patch > series that first adds the ELM address space to the OMAP4 DTS file and > then subsequently drops it from the OMAP4 hwmod data file? Hi Paul, Sorry about that. I can create the patches but I don't see any board omap4 board that has nand support. So I'm not going to be able to test to insure if omap_elm.c will work as is. Should I just drop omap4 from this patchset or should I just add the elm node to omap4.dtsi and if people report an issue with omap_elm then we can fix it? > > > - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Franklin, On Mon, 26 Oct 2015, Franklin S Cooper Jr. wrote: > On 10/23/2015 02:00 PM, Paul Walmsley wrote: > > On Thu, 15 Oct 2015, Franklin S Cooper Jr wrote: > > > >> ELM address information is provided by device tree. No longer need > >> to include this information within hwmod. > >> > >> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> > > The OMAP4 DTS files don't have the ELM address space declared. I'm going > > to drop that portion of your patch. Could you please send a two-patch > > series that first adds the ELM address space to the OMAP4 DTS file and > > then subsequently drops it from the OMAP4 hwmod data file? > Hi Paul, > > Sorry about that. I can create the patches but I don't see any board omap4 > board that has nand support. So I'm not going to be able to test to insure if > omap_elm.c will work as is. > > Should I just drop omap4 from this patchset or should I just add the elm node > to omap4.dtsi and if people report an issue with omap_elm then we can fix it? Please write the OMAP4 patches since we're trying to get the data cleaned up. You don't need to worry about the DRA7/335x/437x platforms; those patches have already been merged. The ELM hwmod should be initialized even on boards without NAND, so that should be a reasonable test of the register address space, at least. Please note in the patch description whether your patches are untested, tested just to initialize/boot, or whether they've been tested on an active NAND flash workload. thanks - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c index 8f5989d..9ba431c 100644 --- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c @@ -152,20 +152,10 @@ struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = { .user = OCP_USER_MPU, }; -static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = { - { - .pa_start = 0x48080000, - .pa_end = 0x48080000 + SZ_8K - 1, - .flags = ADDR_TYPE_RT - }, - { } -}; - struct omap_hwmod_ocp_if am33xx_l4_ls__elm = { .master = &am33xx_l4_ls_hwmod, .slave = &am33xx_elm_hwmod, .clk = "l4ls_gclk", - .addr = am33xx_elm_addr_space, .user = OCP_USER_MPU, }; diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 43eebf2..8f13f4a 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -3915,21 +3915,11 @@ static struct omap_hwmod_ocp_if omap44xx_l4_per__dss_venc = { .user = OCP_USER_MPU, }; -static struct omap_hwmod_addr_space omap44xx_elm_addrs[] = { - { - .pa_start = 0x48078000, - .pa_end = 0x48078fff, - .flags = ADDR_TYPE_RT - }, - { } -}; - /* l4_per -> elm */ static struct omap_hwmod_ocp_if omap44xx_l4_per__elm = { .master = &omap44xx_l4_per_hwmod, .slave = &omap44xx_elm_hwmod, .clk = "l4_div_ck", - .addr = omap44xx_elm_addrs, .user = OCP_USER_MPU | OCP_USER_SDMA, }; diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c index 562247b..ad2cc7a 100644 --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c @@ -2566,21 +2566,11 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; -static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = { - { - .pa_start = 0x48078000, - .pa_end = 0x48078fff, - .flags = ADDR_TYPE_RT - }, - { } -}; - /* l4_per1 -> elm */ static struct omap_hwmod_ocp_if dra7xx_l4_per1__elm = { .master = &dra7xx_l4_per1_hwmod, .slave = &dra7xx_elm_hwmod, .clk = "l3_iclk_div", - .addr = dra7xx_elm_addrs, .user = OCP_USER_MPU | OCP_USER_SDMA, };
ELM address information is provided by device tree. No longer need to include this information within hwmod. Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> --- Version 2 changes: Removing elm addr entries also for 335x,437x and omap4 hwmod arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c | 10 ---------- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 ---------- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 ---------- 3 files changed, 30 deletions(-)