Re: [PATCH 0/3] ARM: OMAP2/3: DSS HWMOD fixes
Paul, Ping. These could be queued for the next merge window. Tomi On Thu, 2012-05-10 at 13:21 +0300, Tomi Valkeinen wrote: > Hi, > > These patches fix DSS hwmod data related to sysc flags. I haven't seen any > problem produced by these missing bits, but by looking at the TRM it's clear > that they should be defined. > > However, applying these will cause additional warnings to show during boot: > > omap_hwmod: dss_dispc: softreset failed (waited 1 usec) > omap_hwmod: dss_rfbi: softreset failed (waited 1 usec) > > Most likely the softreset fails even now, but as there's no check to verify > it, > no warnings are visible. > > I think the reason for the failing softreset is the same problem as we have on > OMAP4: dss_core hwmod should be enabled before other dss hwmods can be enabled > (and reset). > > Tomi > > Tomi Valkeinen (3): > ARM: OMAP2/3: HWMOD: Add missing flags for dispc class > ARM: OMAP2/3: HWMOD: Add missing flag for rfbi class > ARM: OMAP3: HWMOD: Add omap_hwmod_class_sysconfig for dsi > > .../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c |2 +- > arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |3 ++- > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 15 ++- > 3 files changed, 17 insertions(+), 3 deletions(-) > signature.asc Description: This is a digitally signed message part
Re: [PATCH] ARM: OMAP2+: cpu: Add am33xx device under cpu_class_is_omap2
* Vaibhav Hiremath [120610 23:49]: > On 6/11/2012 12:08 PM, Tony Lindgren wrote: > >* Vaibhav Hiremath [120609 08:00]: > >>Newly added AM33XX device falls under omap2 class, so > >>make cpu_class_is_omap2() true for AM33XX > >>(Add soc_is_am33xx() check). > >> > >>Signed-off-by: Vaibhav Hiremath > >>--- > >> arch/arm/plat-omap/include/plat/cpu.h |2 +- > >> 1 files changed, 1 insertions(+), 1 deletions(-) > >> > >>diff --git a/arch/arm/plat-omap/include/plat/cpu.h > >>b/arch/arm/plat-omap/include/plat/cpu.h > >>index 14f050f..5e36564 100644 > >>--- a/arch/arm/plat-omap/include/plat/cpu.h > >>+++ b/arch/arm/plat-omap/include/plat/cpu.h > >>@@ -375,7 +375,7 @@ IS_OMAP_TYPE(3430, 0x3430) > >> #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() > >> || \ > >>cpu_is_omap16xx()) > >> #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() > >> || \ > >>- cpu_is_omap44xx()) > >>+ cpu_is_omap44xx() || soc_is_am33xx()) > >> /* Various silicon revisions for omap2 */ > >> #define OMAP242X_CLASS0x24200024 > >I think this can be now simply !cpu_class_is_omap1() as there is > >a very slim chance that we'll ever be compiling omap1 and omap2+ together > >because of the different compiler flags needed. > > > >Regards, > > > >Tony > > Ok... > > Shall I submit patch with this change? Yes thanks. 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] ARM: OMAP2+: cpu: Add am33xx device under cpu_class_is_omap2
On 6/11/2012 12:08 PM, Tony Lindgren wrote: * Vaibhav Hiremath [120609 08:00]: Newly added AM33XX device falls under omap2 class, so make cpu_class_is_omap2() true for AM33XX (Add soc_is_am33xx() check). Signed-off-by: Vaibhav Hiremath --- arch/arm/plat-omap/include/plat/cpu.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 14f050f..5e36564 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -375,7 +375,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() || \ cpu_is_omap16xx()) #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \ - cpu_is_omap44xx()) + cpu_is_omap44xx() || soc_is_am33xx()) /* Various silicon revisions for omap2 */ #define OMAP242X_CLASS0x24200024 I think this can be now simply !cpu_class_is_omap1() as there is a very slim chance that we'll ever be compiling omap1 and omap2+ together because of the different compiler flags needed. Regards, Tony Ok... Shall I submit patch with this change? Thanks, Vaibhav -- 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: omap: drop unused IRQ defines
* Felipe Balbi [120608 07:16]: > twl[46]030 have been converted to sparse IRQ > already, so we can remove the unused defines > and drop some code from board-files. Nice :) > drivers/mtd/chips/cfi_cmdset_0001.c: In function 'cfi_intelext_write_words': > include/linux/mtd/map.h:331:11: warning: 'r$x$0' may be used uninitialized in > this function This one I don't know if it's been fixed. > WARNING: drivers/mmc/host/built-in.o(.devinit.text+0x2fc): Section mismatch > in reference from the function mmc_omap_probe() to the function > .init.text:mmc_omap_new_slot() > The function __devinit mmc_omap_probe() references > a function __init mmc_omap_new_slot(). > If mmc_omap_new_slot is only used by mmc_omap_probe then > annotate mmc_omap_new_slot with a matching annotation. The MMC related should be fixed and queued up. > fs/ubifs/dir.c: In function 'ubifs_rename': > fs/ubifs/dir.c:972:15: warning: 'saved_nlink' may be used uninitialized in > this function > net/mac80211/mlme.c: In function 'ieee80211_prep_connection': > net/mac80211/mlme.c:3017:19: warning: 'sta' may be used uninitialized in this > function No idea about these. 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] ARM: OMAP2+: cpu: Add am33xx device under cpu_class_is_omap2
* Vaibhav Hiremath [120609 08:00]: > Newly added AM33XX device falls under omap2 class, so > make cpu_class_is_omap2() true for AM33XX > (Add soc_is_am33xx() check). > > Signed-off-by: Vaibhav Hiremath > --- > arch/arm/plat-omap/include/plat/cpu.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/plat-omap/include/plat/cpu.h > b/arch/arm/plat-omap/include/plat/cpu.h > index 14f050f..5e36564 100644 > --- a/arch/arm/plat-omap/include/plat/cpu.h > +++ b/arch/arm/plat-omap/include/plat/cpu.h > @@ -375,7 +375,7 @@ IS_OMAP_TYPE(3430, 0x3430) > #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() || \ > cpu_is_omap16xx()) > #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \ > - cpu_is_omap44xx()) > + cpu_is_omap44xx() || soc_is_am33xx()) > > /* Various silicon revisions for omap2 */ > #define OMAP242X_CLASS 0x24200024 I think this can be now simply !cpu_class_is_omap1() as there is a very slim chance that we'll ever be compiling omap1 and omap2+ together because of the different compiler flags needed. 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: [PATCHv2 09/12] ARM: OMAP2+: usb_host_fs: add custom setup_preprogram for usb_host_fs (fsusb)
Hi,
Similar comments to the asess patch on this one below.
* Paul Walmsley [120610 17:57]:
> --- /dev/null
> +++ b/include/linux/platform_data/fsusb.h
This would be better as include/linux/platform_data/omap-usb.h.
> +#include
This include should not be needed here if the hwmod function is
a static function in the some hwmod*.c file.
> +/* HCCOMMANDSTATUS: the register offset of the HCCOMMANDSTATUS register */
> +#define HCCOMMANDSTATUS 0x0008
> +
> +/* HCCOMMANDSTATUS_HCR: the bitmask of the host controller reset flag */
> +#define HCCOMMANDSTATUS_HCR_MASK (1 << 0)
I think these already have standard defines in some OHCI header?
Felipe may be able to comment more on this?
> +static int fsusb_reset_host_controller(const char *name, void __iomem *base)
> +{
> + int i;
> +
> + writel(HCCOMMANDSTATUS_HCR_MASK, base + HCCOMMANDSTATUS);
> +
> + for (i = 0; i < MAX_FSUSB_HCR_TIME; i++) {
> + if (!(readl(base + HCCOMMANDSTATUS) & HCCOMMANDSTATUS_HCR_MASK))
> + break;
> + udelay(1);
> + }
> +
> + if (i == MAX_FSUSB_HCR_TIME) {
> + pr_warn("%s: %s: host controller reset failed (waited %d
> usec)\n",
> + __func__, name, MAX_FSUSB_HCR_TIME);
> + return -EBUSY;
> + }
> +
> + return 0;
> +}
This should be "static inline int fsusb_reset_host_controller" as it's
in a header.
> +static int __maybe_unused hwmod_fsusb_preprogram(struct omap_hwmod *oh)
> +{
> + void __iomem *va;
> +
> + va = omap_hwmod_get_mpu_rt_va(oh);
> + if (!va)
> + return -EINVAL;
> +
> + fsusb_reset_host_controller(oh->name, va);
> +
> + return 0;
> +}
And this too should be a static function in some hwmod*.c file.
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: [PATCHv2 07/12] ARM: OMAP4+: AESS: enable internal auto-gating during initial setup
Hi,
Few comments below on making the platform_data work better along
with other archs.
* Paul Walmsley [120610 17:56]:
> Enable the AESS auto-gating control bit during AESS hwmod setup. This
> fixes the following boot warning on OMAP4:
...
> --- /dev/null
> +++ b/include/linux/platform_data/aess.h
This should be include/linux/platform_data/omap-aess.h or similar as
there are other aess controllers too.
> +/*
> + * AESS_AUTO_GATING_ENABLE_OFFSET: offset in bytes of the AESS IP
> + * block's AESS_AUTO_GATING_ENABLE__1 register from the IP block's
> + * base address
> + */
> +#define AESS_AUTO_GATING_ENABLE_OFFSET 0x07c
> +
> +/* Register bitfields in the AESS_AUTO_GATING_ENABLE__1 register */
> +#define AESS_AUTO_GATING_ENABLE_SHIFT0
Also these should be OMAP_AESS_AUTOGATING etc, or even better,
XYZ_AESS_AUTOGATING where XYZ is the type of the AESS controller.
> +/**
> + * aess_enable_autogating - enable AESS internal autogating
> + * @oh: struct omap_hwmod *
> + *
> + * Enable internal autogating on the AESS. This allows the AESS to
> + * indicate that it is idle to the OMAP PRCM. Returns 0.
> + */
> +static void aess_enable_autogating(void __iomem *base)
> +{
> + u32 v;
> +
> + /* Set AESS_AUTO_GATING_ENABLE__1.ENABLE to allow idle entry */
> + v = 1 << AESS_AUTO_GATING_ENABLE_SHIFT;
> + writel(v, base + AESS_AUTO_GATING_ENABLE_OFFSET);
> +}
This should be static inline function as it's in the header, and again
something like omap_aess_enable_autogating.
> +/**
> + * hwmod_aess_preprogram - enable AESS internal autogating (called by hwmod)
> + * @oh: struct omap_hwmod *
> + *
> + * The AESS will not IdleAck to the PRCM until its internal autogating
> + * is enabled. Since internal autogating is disabled by default after
> + * AESS reset, we must enable autogating after the hwmod code resets
> + * the AESS. Returns 0.
> + */
> +static int __maybe_unused hwmod_aess_preprogram(struct omap_hwmod *oh)
> +{
> + void __iomem *va;
> +
> + va = omap_hwmod_get_mpu_rt_va(oh);
> + if (!va)
> + return -EINVAL;
> +
> + aess_enable_autogating(va);
> +
> + return 0;
> +}
Then this function should not be in this header, instead it should be a
static function somewhere in the omap hwmod code in some .c file. That's
because this header should only have omap aess specific driver code, no
hwmod code should be needed here.
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 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)
* Paul Walmsley [120608 18:35]: > On Thu, 7 Jun 2012, Tony Lindgren wrote: > > > Oh OK yeah makes sense as that's hwmod internal function. Then the driver > > specific part should use just void __iomem *base and use readl/writel and > > live under include/linux/platform_data/omap-usb.h. > > This sounds like something that might be flame-bait, since these functions > aren't platform_data. They at least should be as both platform init code and the driver will potentially use these functions. > How about putting these functions in arch/arm/plat-omap/include/plat? > Drivers are able to include those files easily. We need to pretty much get rid of all those headers and make them driver specific for the multi-zimage support. Drivers should be arch independent, and whatever parts need to be shared between platform init code and drivers should follow the standard platform driver stuff. The other place would be just the standard driver include at somewhere like include/linux/usb/omap-usb.h etc. 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 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)
* Paul Walmsley [120608 06:33]: > On Fri, 8 Jun 2012, Cousson, Benoit wrote: > > > On 6/8/2012 3:11 AM, Paul Walmsley wrote: > > > On Thu, 7 Jun 2012, Cousson, Benoit wrote: > > > > > > > Indeed, what I did not mention is that potentially the whole device > > > > init should be done ondemand as well. Meaning the whole hwmod setup > > > > phase should be done only when the driver will probe the device. > > > > > > That means if no driver exists for an IP block, or if the driver isn't > > > using PM runtime, the IP block won't be reset. And somehow we still are > > > missing drivers in mainline. We also still have drivers that aren't yet > > > PM runtime converted. > > > > No the point is still the same as before. You let the drivers do the job if > > they are there, and then do a pass at very late time during the boot process > > to handle the ones that were not probed by any driver. > > Ah, I see what you mean. Above you wrote that the the hwmod setup phase > would be done only when the driver will probe the device. But you also > mean that it should also be done for the remaining devices before starting > userspace. > > > At least you will avoid the enable -> reset -> idle -> enable sequence > > we are doing right now for most of the active drivers when it is not > > necessary. > > It must not be widely known, but early reset was implemented > intentionally. The goal was to keep any configuration damage from > out-of-date or broken bootloaders or previous OSes to a minimum length of > time during the boot process. These devices should get reset as the device drivers initialize. Some parts of course need to be initialized properly early like caches and DMA controller. > I don't really have a huge problem with switching to a late reset, > but there are disadvantages to it. I think the early reset actually has more disadvantages to it compared to driver reset. We don't see any errors when things go wrong, and we may even kill the only debug console in the reset process. We are already doing what Benoit describes with clocks where we only reset the unclaimed ones at late_initcall level, and that has proven to work well. 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: RFC: changing DMA slave configuration API
On Sun, 2012-06-10 at 12:22 +0100, Russell King - ARM Linux wrote:
> On Sun, Jun 10, 2012 at 07:19:47PM +0800, Barry Song wrote:
> > 2012/6/10 Russell King - ARM Linux :
> > > Dan, Vinod,
> > >
> > > There's a change I would like to do to the DMA slave configuration.
> > > It's currently a pain to have the source and destination parameters in
> > > the dma_slave_config structure as separate elements; it means when you
> > > want to extract them, you end up with code in DMA engine drivers like:
> > >
> > > + if (dir == DMA_DEV_TO_MEM) {
> > > + dev_addr = c->src_addr;
> > > + dev_width = c->src_addr_width;
> > > + burst = c->src_maxburst;
> > > + } else if (dir == DMA_MEM_TO_DEV) {
> > > + dev_addr = c->dst_addr;
> > > + dev_width = c->dst_addr_width;
> > > + burst = c->dst_maxburst;
> > > + }
> > >
> > > If we redefine the structure as below, this all becomes more simple:
> > >
> > > + if (dir == DMA_DEV_TO_MEM)
> > > + cfg = &c->dev_src;
> > > + else if (dir == DMA_MEM_TO_DEV)
> > > + cfg = &c->dev_dst;
> >
> > it seems that might mean an union in your dma_slave_cfg, but not
> > co-exitense of both?
>
> No, I want both so it's possible to select between the two when preparing
> a DMA slave transfer.
>
> > struct dma_slave_cfg {
> > + union {
> > struct dma_dev_cfg dev_src;
> > struct dma_dev_cfg dev_dst;
> >}
> >bool device_fc;
> > };
>
> If you do that, the union becomes pointless, and you might as well have:
>
> struct dma_slave_cfg {
> struct dma_dev_cfg dev;
> bool device_fc;
> };
>
> instead.
Hi Russell,
I think it is a good idea. And I would like to extend it even a little
bit. Do we have any users of peripheral to peripheral slave dma?
IIRC that is not the case, or does anyone know of existence or plans
for such a h/w?
If not, lets junk the src/dst fields and keep burst, length, addr fields
which point to the peripheral values.
Alternatively if we need both, then we can't have union and Russell's
idea seems good one :)
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] ARM: OMAP AM33xx: voltagedomain: Add voltage domain data
Hi Vaibhav, Afzal, Tony,
On Mon, 21 May 2012, Paul Walmsley wrote:
> From: Vaibhav Hiremath
>
> Currently dummy voltage domain data is being created
> in order to succeed boot process, nothing has been done
> w.r.t actual hardware (voltage control).
>
> Also, hook up the AM33XX voltage domain to OMAP framework.
I had to update this patch again for v3.5 to account for the lack of
am33xx_init_early(). So now this patch has to add it (updated patch
below).
But it seems to me that I must be missing something. Are we missing a
prerequisite patch for this series from mainline? Or is this some
casualty of kicking out the board file?
If the latter, how do we make sure that am33xx_init_early() is called at
the right time?
Once we get this sorted out, I'll send the pull request.
Branch on git://git.pwsan.com/linux-2.6 in 'am33xx_prcm_devel_3.6'
- Paul
>From 127240db05c0d381a50712a320439c5679fb22da Mon Sep 17 00:00:00 2001
From: Vaibhav Hiremath
Date: Sun, 10 Jun 2012 18:56:14 -0600
Subject: [PATCH] ARM: OMAP AM33xx: voltagedomain: Add voltage domain data
Currently dummy voltage domain data is being created
in order to succeed boot process, nothing has been done
w.r.t actual hardware (voltage control).
Also, hook up the AM33XX voltage domain to OMAP framework.
Signed-off-by: Vaibhav Hiremath
Signed-off-by: Afzal Mohammed
Cc: Benoit Cousson
Cc: Tony Lindgren
Cc: Kevin Hilman
Cc: Paul Walmsley
Cc: Rajendra Nayak
Acked-by: Kevin Hilman
[p...@pwsan.com: updated for 3.5]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/io.c | 13 +++-
arch/arm/mach-omap2/voltage.h |1 +
arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 +
5 files changed, 58 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fa742f3..6a3aef6 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -99,6 +99,7 @@ obj-$(CONFIG_ARCH_OMAP3) +=
$(voltagedomain-common)
obj-$(CONFIG_ARCH_OMAP3) += voltagedomains3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common)
obj-$(CONFIG_ARCH_OMAP4) += voltagedomains44xx_data.o
+obj-$(CONFIG_SOC_AM33XX)+= voltagedomains33xx_data.o
# OMAP powerdomain framework
powerdomain-common += powerdomain.o powerdomain-common.o
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index be9dfd1..dad91e2 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -128,6 +128,7 @@ void omap3430_init_early(void);
void omap35xx_init_early(void);
void omap3630_init_early(void);
void omap3_init_early(void); /* Do not use this one */
+void am33xx_init_early(void);
void am35xx_init_early(void);
void ti81xx_init_early(void);
void omap4430_init_early(void);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 8d014ba..37ecc71 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -381,11 +381,22 @@ void __init omap2430_init_late(void)
}
#endif
+#ifdef CONFIG_SOC_AM33XX
+void __init am33xx_init_early(void)
+{
+ omap2_set_globals_am33xx();
+ omap3xxx_check_revision();
+ ti81xx_check_features();
+ omap_common_init_early();
+ am33xx_voltagedomains_init();
+}
+#endif
+
/*
* Currently only board-omap3beagle.c should call this because of the
* same machine_id for 34xx and 36xx beagle.. Will get fixed with DT.
*/
-#ifdef CONFIG_ARCH_OMAP3
+#ifdef CONFIG_SOC_OMAP3430
void __init omap3_init_early(void)
{
omap2_set_globals_3xxx();
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 16a1b09..a7c43c1 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -156,6 +156,7 @@ int omap_voltage_late_init(void);
extern void omap2xxx_voltagedomains_init(void);
extern void omap3xxx_voltagedomains_init(void);
+extern void am33xx_voltagedomains_init(void);
extern void omap44xx_voltagedomains_init(void);
struct voltagedomain *voltdm_lookup(const char *name);
diff --git a/arch/arm/mach-omap2/voltagedomains33xx_data.c
b/arch/arm/mach-omap2/voltagedomains33xx_data.c
new file mode 100644
index 000..965458d
--- /dev/null
+++ b/arch/arm/mach-omap2/voltagedomains33xx_data.c
@@ -0,0 +1,43 @@
+/*
+ * AM33XX voltage domain data
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; withou
[PATCHv2 07/12] ARM: OMAP4+: AESS: enable internal auto-gating during initial setup
Enable the AESS auto-gating control bit during AESS hwmod setup. This
fixes the following boot warning on OMAP4:
omap_hwmod: aess: _wait_target_disable failed
Without this patch, the AESS IP block does not indicate to the PRCM
that it is idle after it is reset. This prevents some types of SoC
power management until something sets the auto-gating control bit.
This second version of this patch moves the control functions to
include/linux/platform_data/aess.h at Tony's request:
http://www.spinics.net/lists/arm-kernel/msg178329.html
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
Cc: Péter Ujfalusi
Cc: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +
include/linux/platform_data/aess.h | 76
2 files changed, 79 insertions(+)
create mode 100644 include/linux/platform_data/aess.h
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6b0aedc..7700d6d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -20,6 +20,8 @@
#include
+#include
+
#include
#include
#include
@@ -313,6 +315,7 @@ static struct omap_hwmod_class_sysconfig omap44xx_aess_sysc
= {
static struct omap_hwmod_class omap44xx_aess_hwmod_class = {
.name = "aess",
.sysc = &omap44xx_aess_sysc,
+ .setup_preprogram = hwmod_aess_preprogram,
};
/* aess */
diff --git a/include/linux/platform_data/aess.h
b/include/linux/platform_data/aess.h
new file mode 100644
index 000..1e0d71b
--- /dev/null
+++ b/include/linux/platform_data/aess.h
@@ -0,0 +1,76 @@
+/*
+ * AESS IP block integration
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+#ifndef __LINUX_PLATFORM_DATA_AESS_H__
+#define __LINUX_PLATFORM_DATA_AESS_H__
+
+#include
+
+#include
+
+/*
+ * AESS_AUTO_GATING_ENABLE_OFFSET: offset in bytes of the AESS IP
+ * block's AESS_AUTO_GATING_ENABLE__1 register from the IP block's
+ * base address
+ */
+#define AESS_AUTO_GATING_ENABLE_OFFSET 0x07c
+
+/* Register bitfields in the AESS_AUTO_GATING_ENABLE__1 register */
+#define AESS_AUTO_GATING_ENABLE_SHIFT 0
+
+/**
+ * aess_enable_autogating - enable AESS internal autogating
+ * @oh: struct omap_hwmod *
+ *
+ * Enable internal autogating on the AESS. This allows the AESS to
+ * indicate that it is idle to the OMAP PRCM. Returns 0.
+ */
+static void aess_enable_autogating(void __iomem *base)
+{
+ u32 v;
+
+ /* Set AESS_AUTO_GATING_ENABLE__1.ENABLE to allow idle entry */
+ v = 1 << AESS_AUTO_GATING_ENABLE_SHIFT;
+ writel(v, base + AESS_AUTO_GATING_ENABLE_OFFSET);
+}
+
+/**
+ * hwmod_aess_preprogram - enable AESS internal autogating (called by hwmod)
+ * @oh: struct omap_hwmod *
+ *
+ * The AESS will not IdleAck to the PRCM until its internal autogating
+ * is enabled. Since internal autogating is disabled by default after
+ * AESS reset, we must enable autogating after the hwmod code resets
+ * the AESS. Returns 0.
+ */
+static int __maybe_unused hwmod_aess_preprogram(struct omap_hwmod *oh)
+{
+ void __iomem *va;
+
+ va = omap_hwmod_get_mpu_rt_va(oh);
+ if (!va)
+ return -EINVAL;
+
+ aess_enable_autogating(va);
+
+ return 0;
+}
+
+#endif /* __LINUX_PLATFORM_DATA_AESS_H__ */
--
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
[PATCHv2 08/12] ARM: OMAP4: hwmod data: add SL2IF hardreset line
On boot, the sl2if module can't be enabled. The following message is
logged:
omap_hwmod: sl2if: cannot be enabled for reset (3)
This is probably because the SL2IF is still being held in hardreset.
The SL2IF's hardreset line is shared with one of the IVAHD's hardreset
lines; see for example Table 3-536 "RM_IVAHD_RSTCTRL" in the OMAP4430
TRM Rev. AA (SWPU231AA). To work around this, add the SL2IF's
hardreset line to the hwmod data. This is correct from a hardware
perspective and also will prevent the hwmod from attempting to enable
the SL2IF during reset. The driver for this IP block will need to
handle its integration until the appropriate way to handle the IVAHD
integration can be elucidated.
Signed-off-by: Paul Walmsley
Cc: Tero Kristo
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7700d6d..037424f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2597,15 +2597,22 @@ static struct omap_hwmod_class
omap44xx_sl2if_hwmod_class = {
.name = "sl2if",
};
+static struct omap_hwmod_rst_info omap44xx_sl2if_resets[] = {
+ { .name = "logic", .rst_shift = 2 },
+};
+
/* sl2if */
static struct omap_hwmod omap44xx_sl2if_hwmod = {
.name = "sl2if",
.class = &omap44xx_sl2if_hwmod_class,
.clkdm_name = "ivahd_clkdm",
+ .rst_lines = omap44xx_sl2if_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_sl2if_resets),
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_IVAHD_SL2_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_IVAHD_SL2_CONTEXT_OFFSET,
+ .rstctrl_offs = OMAP4_RM_IVAHD_RSTCTRL_OFFSET,
.modulemode = MODULEMODE_HWCTRL,
},
},
--
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
[PATCHv2 11/12] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks
Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated with it. This
patch populates some clock structure clockdomain names to resolve the
following warnings during kernel init:
omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.
Signed-off-by: Paul Walmsley
Cc: Rajendra Nayak
Cc: Benoît Cousson
---
arch/arm/mach-omap2/clock44xx_data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2172f66..e2b701e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -84,6 +84,7 @@ static struct clk slimbus_clk = {
static struct clk sys_32k_ck = {
.name = "sys_32k_ck",
+ .clkdm_name = "prm_clkdm",
.rate = 32768,
.ops= &clkops_null,
};
@@ -512,6 +513,7 @@ static struct clk ddrphy_ck = {
.name = "ddrphy_ck",
.parent = &dpll_core_m2_ck,
.ops= &clkops_null,
+ .clkdm_name = "l3_emif_clkdm",
.fixed_div = 2,
.recalc = &omap_fixed_divisor_recalc,
};
@@ -769,6 +771,7 @@ static const struct clksel dpll_mpu_m2_div[] = {
static struct clk dpll_mpu_m2_ck = {
.name = "dpll_mpu_m2_ck",
.parent = &dpll_mpu_ck,
+ .clkdm_name = "cm_clkdm",
.clksel = dpll_mpu_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_MPU,
.clksel_mask= OMAP4430_DPLL_CLKOUT_DIV_MASK,
@@ -1149,6 +1152,7 @@ static const struct clksel l3_div_div[] = {
static struct clk l3_div_ck = {
.name = "l3_div_ck",
.parent = &div_core_ck,
+ .clkdm_name = "cm_clkdm",
.clksel = l3_div_div,
.clksel_reg = OMAP4430_CM_CLKSEL_CORE,
.clksel_mask= OMAP4430_CLKSEL_L3_MASK,
@@ -2824,6 +2828,7 @@ static const struct clksel trace_clk_div_div[] = {
static struct clk trace_clk_div_ck = {
.name = "trace_clk_div_ck",
.parent = &pmd_trace_clk_mux_ck,
+ .clkdm_name = "emu_sys_clkdm",
.clksel = trace_clk_div_div,
.clksel_reg = OMAP4430_CM_EMU_DEBUGSS_CLKCTRL,
.clksel_mask= OMAP4430_CLKSEL_PMD_TRACE_CLK_MASK,
--
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
[PATCHv2 04/12] ARM: OMAP4: hwmod data: fix 32k sync timer idle modes
The 32k sync timer IP block target idle modes are incorrect in the
hwmod data are incorrect. The IP block does not support any
smart-idle modes. Update the data to reflect the correct modes.
This problem was initially identified and a diff fragment posted to
the lists by Benoît Cousson .
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
Cc: Tero Kristo
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 484..6b0aedc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -393,8 +393,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_counter_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0004,
.sysc_flags = SYSC_HAS_SIDLEMODE,
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
- SIDLE_SMART_WKUP),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO),
.sysc_fields= &omap_hwmod_sysc_type1,
};
--
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
[PATCHv2 06/12] ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block during init
Add HWMOD_EXT_OPT_MAIN_CLK flag to indicate that this IP block is
dependent on an off-chip functional clock that is not guaranteed to be
present during initialization. IP blocks marked with this flag are
left in the INITIALIZED state during kernel init.
This is a workaround for a hardware problem. It should be possible to
guarantee that at least one clock source will be present and active
for any IP block's main functional clock. This ensures that the hwmod
code can enable and reset the IP block. Resetting the IP block during
kernel init prevents any bogus bootloader, ROM code, or previous OS
configuration from affecting the kernel. Hopefully a clock
multiplexer can be added on future SoCs.
N.B., at some point in the future, it should be possible to query the
clock framework for this type of information. Then this flag should
no longer be needed.
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
---
arch/arm/mach-omap2/omap_hwmod.c |3 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h |6 ++
2 files changed, 9 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index d27bf48..e0b8131 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2140,6 +2140,9 @@ static int __init _setup_reset(struct omap_hwmod *oh)
if (oh->_state != _HWMOD_STATE_INITIALIZED)
return -EINVAL;
+ if (oh->flags & HWMOD_EXT_OPT_MAIN_CLK)
+ return -EPERM;
+
if (oh->rst_lines_cnt == 0) {
r = _enable(oh);
if (r) {
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 2c53648..b5f3efc 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -417,6 +417,11 @@ struct omap_hwmod_omap4_prcm {
* running on the chip (e.g., the MPU is in idle). For such modules,
* fine-grained PM runtime-based idle control is simply a waste of
* CPU cycles.
+ * HWMOD_EXT_OPT_MAIN_CLK: The only main functional clock source for
+ * this IP block comes from an off-chip source and is not always
+ * enabled. This prevents the hwmod code from being able to
+ * enable and reset the IP block early. XXX Eventually it should
+ * be possible to query the clock framework for this information.
*/
#define HWMOD_SWSUP_SIDLE (1 << 0)
#define HWMOD_SWSUP_MSTANDBY (1 << 1)
@@ -428,6 +433,7 @@ struct omap_hwmod_omap4_prcm {
#define HWMOD_CONTROL_OPT_CLKS_IN_RESET(1 << 7)
#define HWMOD_16BIT_REG(1 << 8)
#define HWMOD_ALWAYS_FORCE_SIDLE (1 << 9)
+#define HWMOD_EXT_OPT_MAIN_CLK (1 << 10)
/*
* omap_hwmod._int_flags definitions
--
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
[PATCHv2 12/12] ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init
Resolve this kernel boot message:
omap_hwmod: mcpdm: cannot be enabled for reset (3)
It appears that the McPDM on OMAP4 can only receive its functional
clock from an off-chip source. This source is not guaranteed to be
present on the board, and when present, it is controlled by I2C. This
would introduce a board dependency to the early hwmod code which it
was not designed to handle. Also, neither the driver for this
off-chip clock provider nor the I2C code is available early in boot
when the hwmod code is attempting to enable and reset IP blocks. This
effectively makes it impossible to enable and reset this device during
hwmod init.
At its core, this patch is a workaround for an OMAP hardware problem.
It should be possible to configure the OMAP to provide any IP block's
functional clock from an on-chip source. (This is true for almost
every IP block on the chip. As far as I know, McPDM is the only
exception.) If the kernel cannot reset and configure IP blocks, it
cannot guarantee a sane SoC state. Relying on an optional off-chip
clock also creates a board dependency which is beyond the scope of the
early hwmod code.
This patch works around the issue by marking the McPDM hwmod record
with the HWMOD_EXT_OPT_MAIN_CLK flag. This prevents the hwmod
code from touching the device early during boot.
Signed-off-by: Paul Walmsley
Cc: Péter Ujfalusi
Cc: Benoît Cousson
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 3613054..86fc513 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2091,6 +2091,18 @@ static struct omap_hwmod omap44xx_mcpdm_hwmod = {
.name = "mcpdm",
.class = &omap44xx_mcpdm_hwmod_class,
.clkdm_name = "abe_clkdm",
+ /*
+* It's suspected that the McPDM requires an off-chip main
+* functional clock, controlled via I2C. This IP block is
+* currently reset very early during boot, before I2C is
+* available, so it doesn't seem that we have any choice in
+* the kernel other than to avoid resetting it. XXX This is
+* really a hardware issue workaround: every IP block should
+* be able to source its main functional clock from either
+* on-chip or off-chip sources. McPDM seems to be the only
+* current exception.
+*/
+ .flags = HWMOD_EXT_OPT_MAIN_CLK,
.mpu_irqs = omap44xx_mcpdm_irqs,
.sdma_reqs = omap44xx_mcpdm_sdma_reqs,
.main_clk = "mcpdm_fck",
--
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
[PATCHv2 05/12] ARM: OMAP2+: hwmod: add setup_preprogram hook
After reset, some IP blocks cannot indicate to the PRCM that they are
inactive until they are configured. Some examples on OMAP4 include
the AESS and FSUSB IP blocks.
To fix this cleanly, this patch adds another optional function
pointer, setup_preprogram, to the IP block's hwmod data. The function
that is pointed to is called by the hwmod code immediately after the
IP block is reset.
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
Cc: Péter Ujfalusi
Cc: Felipe Balbi
---
arch/arm/mach-omap2/omap_hwmod.c | 21 -
arch/arm/plat-omap/include/plat/omap_hwmod.h |9 +
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 2dd..d27bf48 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2108,6 +2108,23 @@ static void __init _setup_iclk_autoidle(struct
omap_hwmod *oh)
}
/**
+ * _setup_preprogram - Pre-program an IP block during the _setup() process
+ * @oh: struct omap_hwmod *
+ *
+ * Some IP blocks (such as AESS) require some additional programming
+ * after reset before they can enter idle. If a function pointer to
+ * do so is present in the hwmod data, then call it and pass along the
+ * return value; otherwise, return 0.
+ */
+static int __init _setup_preprogram(struct omap_hwmod *oh)
+{
+ if (!oh->class->setup_preprogram)
+ return 0;
+
+ return oh->class->setup_preprogram(oh);
+}
+
+/**
* _setup_reset - reset an IP block during the setup process
* @oh: struct omap_hwmod *
*
@@ -2229,8 +2246,10 @@ static int __init _setup(struct omap_hwmod *oh, void
*data)
_setup_iclk_autoidle(oh);
- if (!_setup_reset(oh))
+ if (!_setup_reset(oh)) {
+ _setup_preprogram(oh);
_setup_postsetup(oh);
+ }
return 0;
}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 038c0d7..2c53648 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -467,6 +467,7 @@ struct omap_hwmod_omap4_prcm {
* @rev: revision of the IP class
* @pre_shutdown: ptr to fn to be executed immediately prior to device shutdown
* @reset: ptr to fn to be executed in place of the standard hwmod reset fn
+ * @setup_preprogram: ptr to fn to be executed after the reset in _setup()
*
* Represent the class of a OMAP hardware "modules" (e.g. timer,
* smartreflex, gpio, uart...)
@@ -483,6 +484,13 @@ struct omap_hwmod_omap4_prcm {
* executed in place of the standard hwmod _reset() code in
* mach-omap2/omap_hwmod.c. This is needed for IP blocks which have
* unusual reset sequences - usually processor IP blocks like the IVA.
+ *
+ * @setup_preprogram is called between the calls to _setup_reset() and
+ * _setup_postsetup(). It is intended to be used for IP blocks that
+ * require some initial configuration during their first
+ * initialization. (For example, the AESS IP block on OMAP4+ cannot
+ * enter idle until its internal autogating bit is set.) Most IP blocks
+ * will not need this.
*/
struct omap_hwmod_class {
const char *name;
@@ -490,6 +498,7 @@ struct omap_hwmod_class {
u32 rev;
int (*pre_shutdown)(struct
omap_hwmod *oh);
int (*reset)(struct omap_hwmod *oh);
+ int (*setup_preprogram)(struct
omap_hwmod *oh);
};
/**
--
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
[PATCHv2 03/12] ARM: OMAP4+: hwmod: fix issue causing IPs not going back to Smart-Standby
From: Djamil Elaidi If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature the IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup. Signed-off-by: Djamil Elaidi Signed-off-by: Paul Walmsley --- arch/arm/mach-omap2/omap_hwmod.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 096474c..2dd 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -530,7 +530,7 @@ static int _disable_wakeup(struct omap_hwmod *oh, u32 *v) if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP) _set_slave_idlemode(oh, HWMOD_IDLEMODE_SMART, v); if (oh->class->sysc->idlemodes & MSTANDBY_SMART_WKUP) - _set_master_standbymode(oh, HWMOD_IDLEMODE_SMART_WKUP, v); + _set_master_standbymode(oh, HWMOD_IDLEMODE_SMART, v); /* XXX test pwrdm_get_wken for this hwmod's subsystem */ -- 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
[PATCHv2 09/12] ARM: OMAP2+: usb_host_fs: add custom setup_preprogram for usb_host_fs (fsusb)
Add a custom setup_preprogram function for the usb_host_fs/fsusb IP
block, and connect it to the OMAP4 FSUSB block.
This is the first of two fixes required to get rid of the boot
warning:
omap_hwmod: usb_host_fs: _wait_target_disable failed
and to allow the module to idle.
It may be necessary to use this reset method for OMAP2xxx SoCs as
well; this is left for a future patch.
Based on a patch originally written by Tero Kristo .
This second version of this patch moves the control functions to
include/linux/platform_data/aess.h at Tony's request:
http://www.spinics.net/lists/arm-kernel/msg178329.html
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
Cc: Felipe Balbi
Cc: Tero Kristo
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +
include/linux/platform_data/fsusb.h| 105
2 files changed, 107 insertions(+)
create mode 100644 include/linux/platform_data/fsusb.h
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 037424f..b8b28be 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include
#include
@@ -3314,6 +3315,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_usb_host_fs_sysc = {
static struct omap_hwmod_class omap44xx_usb_host_fs_hwmod_class = {
.name = "usb_host_fs",
.sysc = &omap44xx_usb_host_fs_sysc,
+ .setup_preprogram = hwmod_fsusb_preprogram,
};
/* usb_host_fs */
diff --git a/include/linux/platform_data/fsusb.h
b/include/linux/platform_data/fsusb.h
new file mode 100644
index 000..d1e08e0
--- /dev/null
+++ b/include/linux/platform_data/fsusb.h
@@ -0,0 +1,105 @@
+/*
+ * FSUSB IP block integration
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+#ifndef __LINUX_PLATFORM_DATA_FSUSB_H__
+#define __LINUX_PLATFORM_DATA_FSUSB_H__
+
+#include
+#include
+
+#include
+
+ /*
+ * MAX_MODULE_SOFTRESET_TIME: maximum time in microseconds to wait for
+ * an IP block to finish an OCP SOFTRESET.
+ */
+#define MAX_MODULE_SOFTRESET_TIME 1
+
+ /*
+ * MAX_FSUSB_HCR_TIME: maximum time in microseconds to wait for the
+ * FSUSB block to complete its Host Controller Reset. This 30 µs
+ * timeout comes from ohci-hcd.c:ohci_run().
+ */
+#define MAX_FSUSB_HCR_TIME 30
+
+/* HCCOMMANDSTATUS: the register offset of the HCCOMMANDSTATUS register */
+#define HCCOMMANDSTATUS0x0008
+
+/* HCCOMMANDSTATUS_HCR: the bitmask of the host controller reset flag */
+#define HCCOMMANDSTATUS_HCR_MASK (1 << 0)
+
+/**
+ * fsusb_reset_host_controller - execute an OHCI host controller reset
+ * @name: string that uniquely identifies this on-chip instance of the IP block
+ * @base: base virtual address of the FSUSB IP block
+ *
+ * Run a Host Controller reset on the FSUSB IP block. At the
+ * conclusion of this reset, the controller will be in UsbSuspend
+ * mode. This differs from the OCP softreset, which leaves the
+ * controller in the UsbReset mode. (The FSUSB must be in UsbSuspend
+ * mode to indicate idle to the OMAP PRCM.) Returns 0 upon success
+ * or -EBUSY if the reset timed out.
+ */
+static int fsusb_reset_host_controller(const char *name, void __iomem *base)
+{
+ int i;
+
+ writel(HCCOMMANDSTATUS_HCR_MASK, base + HCCOMMANDSTATUS);
+
+ for (i = 0; i < MAX_FSUSB_HCR_TIME; i++) {
+ if (!(readl(base + HCCOMMANDSTATUS) & HCCOMMANDSTATUS_HCR_MASK))
+ break;
+ udelay(1);
+ }
+
+ if (i == MAX_FSUSB_HCR_TIME) {
+ pr_warn("%s: %s: host controller reset failed (waited %d
usec)\n",
+ __func__, name, MAX_FSUSB_HCR_TIME);
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
+/**
+ * hwmod_fsusb_preprogram - place the FSUSB into UsbSuspend state
+ * @oh: struct omap_hwmod *
+ *
+ * Run a Host Controller Reset on the FSUSB. This will place the host
+ * controller into UsbSuspend state, which will cause the FSUSB
+ * indicate that it is idle to the OMAP PRCM. This is intended to run
+ * _after_ the OCP softreset, which can be handled via the standard
+ * function. Passes along the return value of
+ *
[PATCHv2 10/12] ARM: OMAP2+: CM: increase the module disable timeout
Increase the timeout for disabling an IP block to five milliseconds. This is to handle the usb_host_fs idle latency, which takes almost four milliseconds after a host controller reset. This is the second of two patches needed to resolve the following boot warning: omap_hwmod: usb_host_fs: _wait_target_disable failed Signed-off-by: Paul Walmsley Cc: Tero Kristo --- arch/arm/mach-omap2/cm.h | 11 +++ arch/arm/mach-omap2/cminst44xx.c |4 ++-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 + 3 files changed, 14 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h index a7bc096..f24e3f7 100644 --- a/arch/arm/mach-omap2/cm.h +++ b/arch/arm/mach-omap2/cm.h @@ -22,4 +22,15 @@ */ #define MAX_MODULE_READY_TIME 2000 +/* + * MAX_MODULE_DISABLE_TIME: max duration in microseconds to wait for + * the PRCM to request that a module enter the inactive state in the + * case of OMAP2 & 3. In the case of OMAP4 this is the max duration + * in microseconds for the module to reach the inactive state from + * a functional state. + * XXX FSUSB on OMAP4430 takes ~4ms to idle after reset during + * kernel init. + */ +#define MAX_MODULE_DISABLE_TIME5000 + #endif diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c index 8c86d29..1a39945 100644 --- a/arch/arm/mach-omap2/cminst44xx.c +++ b/arch/arm/mach-omap2/cminst44xx.c @@ -313,9 +313,9 @@ int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs, u16 clkctrl_off omap_test_timeout((_clkctrl_idlest(part, inst, cdoffs, clkctrl_offs) == CLKCTRL_IDLEST_DISABLED), - MAX_MODULE_READY_TIME, i); + MAX_MODULE_DISABLE_TIME, i); - return (i < MAX_MODULE_READY_TIME) ? 0 : -EBUSY; + return (i < MAX_MODULE_DISABLE_TIME) ? 0 : -EBUSY; } /** diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index b8b28be..3613054 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -33,6 +33,7 @@ #include #include #include +#include #include "omap_hwmod_common_data.h" -- 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
[PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database") broke CORE idle on OMAP3. This prevents device low power
states.
The root cause is that the 32K sync timer IP block does not support
smart-idle mode[1], and so the hwmod code keeps the IP block in
no-idle mode while it is active. This in turn prevents the WKUP
clockdomain from transitioning to idle. There is a hardcoded sleep
dependency that prevents the CORE_L3 and CORE_CM clockdomains from
transitioning to idle when the WKUP clockdomain is active[2], so the
chip cannot enter any device low power states.
It turns out that there is no need to take the 32k sync timer out of
idle. The IP block itself probably does not have any native idle
handling at all, due to its simplicity. Furthermore, the PRCM will
never request target idle for this IP block while the kernel is
running, due to the sleep dependency that prevents the WKUP
clockdomain from idling while the CORE_L3 clockdomain is active. So
we can safely leave the 32k sync timer in target-no-idle mode, even
while we continue to access it.
This workaround is implemented by defining a new hwmod flag,
HWMOD_ALWAYS_FORCE_SIDLE, that places the IP block into target
force-idle mode even when enabled. The 32k sync timer hwmods are
marked with this flag for OMAP3 and OMAP4 SoCs. (On OMAP2xxx, no OCP
header existed on the 32k sync timer.)
Another theoretically clean fix for this problem would be to implement
PM runtime-based control for 32k sync timer accesses. These PM
runtime calls would need to located in a custom clocksource, since the
32k sync timer is currently used as an MMIO clocksource. But in
practice, there would be little benefit to doing so; and there would
be some cost, due to the addition of unnecessary lines of code and the
additional CPU overhead of the PM runtime and hwmod code - unnecessary
in this case.
Another possible fix would have been to modify the pm34xx.c code to
force the IP block idle before entering WFI. But this would not have
been an acceptable approach: we are trying to remove this type of
centralized IP block idle control from the PM code.
This patch is effectively a workaround for a hardware problem. A
better hardware approach would have been to implement a smart-idle
target idle mode for this IP block. The smart-idle mode in this case
would behave identically to the force-idle mode. We consider the
force-idle and no-idle target idle mode settings to be intended for
debugging and automatic idle management bug workarounds only[4].
This patch is a collaboration between Kevin Hilman
and Paul Walmsley .
Thanks to Vaibhav Hiremath for providing comments on
an earlier version of this patch. Thanks to Tero Kristo
for identifying a bug in an earlier version of this
patch. Thanks to Benoît Cousson for identifying a
bug in an earlier version of this patch and for implementation comments.
References:
1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
(SWPU223U), available from:
http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip
2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
(SWPU223U)
3. ibid.
4. Section 3.1.1.1.2 "Module-Level Clock Management" of the OMAP4430
TRM Rev. vAA (SWPU231AA).
Cc: Tony Lindgren
Cc: Vaibhav Hiremath
Cc: Benoît Cousson
Cc: Tero Kristo
Tested-by: Kevin Hilman
Signed-off-by: Kevin Hilman
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod.c | 17 +++--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |9 +
4 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index bf86f7e..096474c 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1124,10 +1124,12 @@ static struct omap_hwmod_addr_space * __init
_find_mpu_rt_addr_space(struct omap
* _enable_sysc - try to bring a module out of idle via OCP_SYSCONFIG
* @oh: struct omap_hwmod *
*
- * If module is marked as SWSUP_SIDLE, force the module out of slave
- * idle; otherwise, configure it for smart-idle. If module is marked
- * as SWSUP_MSUSPEND, force the module out of master standby;
- * otherwise, configure it for smart-standby. No return value.
+ * Ensure that the OCP_SYSCONFIG register for the IP block represented
+ * by @oh is set to indicate to the PRCM that the IP block is active.
+ * Usually this means placing the module into smart-idle mode and
+ * smart-standby, but if there is a bug in the automatic idle handling
+ * for the IP block, it may need to be placed into the force-idle or
+ * no-idle variants of these modes. No return value.
*/
static void _enable_sysc(struct omap_hwmod *oh)
{
@@ -1141,8 +1143,11 @@ static void _enable_sysc(struct omap_h
[PATCHv2 01/12] ARM: OMAP: PM: Lock clocks list while generating summary
From: Todd Poynor Commit a53025724052b2b1edbc982a4a248784638f563d (OMAP: Add debugfs node to show the summary of all clocks) introduced clock summary, however, we are interested in seeing snapshot of the clock state, not in dynamically changing clock configurations as the data provided by clock summary will then be useless for debugging configuration issues. So, hold the common lock when dumping the clock summary. Cc: Paul Walmsley Cc: Tony Lindgren Signed-off-by: Todd Poynor [n...@ti.com: added commit message] Signed-off-by: Nishanth Menon [p...@pwsan.com: minor edits to commit message] Signed-off-by: Paul Walmsley --- arch/arm/plat-omap/clock.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c index 62ec5c4..706b7e2 100644 --- a/arch/arm/plat-omap/clock.c +++ b/arch/arm/plat-omap/clock.c @@ -461,6 +461,7 @@ static int clk_dbg_show_summary(struct seq_file *s, void *unused) struct clk *c; struct clk *pa; + mutex_lock(&clocks_mutex); seq_printf(s, "%-30s %-30s %-10s %s\n", "clock-name", "parent-name", "rate", "use-count"); @@ -469,6 +470,7 @@ static int clk_dbg_show_summary(struct seq_file *s, void *unused) seq_printf(s, "%-30s %-30s %-10lu %d\n", c->name, pa ? pa->name : "none", c->rate, c->usecount); } + mutex_unlock(&clocks_mutex); return 0; } -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 00/12] ARM: OMAP: core/hwmod: first set of fixes for 3.5-rc
Hi,
Here is an initial set of fixes for power management and OMAP core
infrastructure for 3.5-rc. Most of these patches address boot
warnings and power management problems on OMAP4, although a few of
them address more general issues.
Thanks to (in alphabetical order) Benoît Cousson, Tero Kristo, Kevin
Hilman, Vaibhav Hiremath, and Tony Lindgren for help with this series.
Compile-test information is below. The patches been boot-tested on
OMAP3530 ES3.0 BeagleBoard and OMAP4430 ES2.0 PandaBoard. Suspend and
idle are broken on both of these platforms right now. Unfortunately
my board farm is down at the moment, so I'm unable to do further
testing on other boards. Boot logs, such as they are, are available
from:
http://www.pwsan.com/omap/bootlogs/20120610/omap_fixes_a_3.5rc__1869336b045e205b874e178443213815a8561cd1/
These patches are available via git from git://git.pwsan.com/linux-2.6
in the branch 'omap_fixes_a_3.5rc'.
This second version contains several changes:
- Rebased on v3.5-rc2.
- A new patch has been added to change the 32k sync timer
SIDLEMODE flags ("ARM: OMAP4: hwmod data: fix 32k sync timer
idle modes").
- A bug has been fixed ("ARM: OMAP2+: hwmod code/data: fix 32K
sync timer").
- setup_preprogram code for the AESS and FSUSB IP blocks has been
moved to include/linux/platform_data at Tony's request
("ARM: OMAP4+: AESS: enable internal auto-gating during initial
setup" and "ARM: OMAP2+: usb_host_fs: add custom
setup_preprogram for usb_host_fs (fsusb)")
- Paul
---
object size (delta in bytes from v3.5-rc2
(cfaf025112d3856637ff34a767ef785ef5cf2ca9)):
textdata bss total kernel
0 0 0 0 5912osk_testconfig/vmlinux
+64 +96 0+160 n800_multi_omap2xxx/vmlinux
+96 +96 0+192 n800_testconfig/vmlinux
0 0 0 0 omap1510_defconfig/vmlinux
0 0 0 0 omap1_defconfig/vmlinux
+304+320 0+624 omap2_4_testconfig/vmlinux
+304+448 0+752 omap2plus_defconfig/vmlinux
+240+384 0+624 omap2plus_no_pm/vmlinux
+4404+312 0 +4716 omap3_4_testconfig/vmlinux
+100 +56 0+156 omap3_testconfig/vmlinux
+308+280 0+588 omap4_testconfig/vmlinux
Djamil Elaidi (1):
ARM: OMAP4+: hwmod: fix issue causing IPs not going back to Smart-Standby
Paul Walmsley (10):
ARM: OMAP2+: hwmod code/data: fix 32K sync timer
ARM: OMAP4: hwmod data: fix 32k sync timer idle modes
ARM: OMAP2+: hwmod: add setup_preprogram hook
ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block
during init
ARM: OMAP4+: AESS: enable internal auto-gating during initial setup
ARM: OMAP4: hwmod data: add SL2IF hardreset line
ARM: OMAP2+: usb_host_fs: add custom setup_preprogram for usb_host_fs
(fsusb)
ARM: OMAP2+: CM: increase the module disable timeout
ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks
ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel
init
Todd Poynor (1):
ARM: OMAP: PM: Lock clocks list while generating summary
arch/arm/mach-omap2/clock44xx_data.c |5 +
arch/arm/mach-omap2/cm.h | 11 +++
arch/arm/mach-omap2/cminst44xx.c |4 -
arch/arm/mach-omap2/omap_hwmod.c | 43 +--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 30 +++
arch/arm/plat-omap/clock.c |2
arch/arm/plat-omap/include/plat/omap_hwmod.h | 24 ++
include/linux/platform_data/aess.h | 76 +++
include/linux/platform_data/fsusb.h | 105 ++
10 files changed, 288 insertions(+), 14 deletions(-)
create mode 100644 include/linux/platform_data/aess.h
create mode 100644 include/linux/platform_data/fsusb.h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: changing DMA slave configuration API
On Sun, Jun 10, 2012 at 07:19:47PM +0800, Barry Song wrote:
> 2012/6/10 Russell King - ARM Linux :
> > Dan, Vinod,
> >
> > There's a change I would like to do to the DMA slave configuration.
> > It's currently a pain to have the source and destination parameters in
> > the dma_slave_config structure as separate elements; it means when you
> > want to extract them, you end up with code in DMA engine drivers like:
> >
> > + if (dir == DMA_DEV_TO_MEM) {
> > + dev_addr = c->src_addr;
> > + dev_width = c->src_addr_width;
> > + burst = c->src_maxburst;
> > + } else if (dir == DMA_MEM_TO_DEV) {
> > + dev_addr = c->dst_addr;
> > + dev_width = c->dst_addr_width;
> > + burst = c->dst_maxburst;
> > + }
> >
> > If we redefine the structure as below, this all becomes more simple:
> >
> > + if (dir == DMA_DEV_TO_MEM)
> > + cfg = &c->dev_src;
> > + else if (dir == DMA_MEM_TO_DEV)
> > + cfg = &c->dev_dst;
>
> it seems that might mean an union in your dma_slave_cfg, but not
> co-exitense of both?
No, I want both so it's possible to select between the two when preparing
a DMA slave transfer.
> struct dma_slave_cfg {
> + union {
> struct dma_dev_cfg dev_src;
> struct dma_dev_cfg dev_dst;
>}
>bool device_fc;
> };
If you do that, the union becomes pointless, and you might as well have:
struct dma_slave_cfg {
struct dma_dev_cfg dev;
bool device_fc;
};
instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: changing DMA slave configuration API
2012/6/10 Russell King - ARM Linux :
> Dan, Vinod,
>
> There's a change I would like to do to the DMA slave configuration.
> It's currently a pain to have the source and destination parameters in
> the dma_slave_config structure as separate elements; it means when you
> want to extract them, you end up with code in DMA engine drivers like:
>
> + if (dir == DMA_DEV_TO_MEM) {
> + dev_addr = c->src_addr;
> + dev_width = c->src_addr_width;
> + burst = c->src_maxburst;
> + } else if (dir == DMA_MEM_TO_DEV) {
> + dev_addr = c->dst_addr;
> + dev_width = c->dst_addr_width;
> + burst = c->dst_maxburst;
> + }
>
> If we redefine the structure as below, this all becomes more simple:
>
> + if (dir == DMA_DEV_TO_MEM)
> + cfg = &c->dev_src;
> + else if (dir == DMA_MEM_TO_DEV)
> + cfg = &c->dev_dst;
it seems that might mean an union in your dma_slave_cfg, but not
co-exitense of both?
struct dma_slave_cfg {
+ union {
struct dma_dev_cfg dev_src;
struct dma_dev_cfg dev_dst;
}
bool device_fc;
};
>
> and then we can access the data through cfg->{element} rather than having
> to cache each individual elements value in a local variable.
>
> Thoughts?
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 56377df..e6519f7 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -367,6 +367,18 @@ struct dma_slave_config {
> bool device_fc;
> };
>
> +struct dma_dev_cfg {
> + dma_addr_t addr;
> + enum dma_slave_buswidth width;
> + u32 maxburst;
> +};
> +
> +struct dma_slave_cfg {
> + struct dma_dev_cfg dev_src;
> + struct dma_dev_cfg dev_dst;
> + bool device_fc;
> +};
> +
> static inline const char *dma_chan_name(struct dma_chan *chan)
> {
> return dev_name(&chan->dev->device);
>
Thanks
barry
--
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
RFC: changing DMA slave configuration API
Dan, Vinod,
There's a change I would like to do to the DMA slave configuration.
It's currently a pain to have the source and destination parameters in
the dma_slave_config structure as separate elements; it means when you
want to extract them, you end up with code in DMA engine drivers like:
+ if (dir == DMA_DEV_TO_MEM) {
+ dev_addr = c->src_addr;
+ dev_width = c->src_addr_width;
+ burst = c->src_maxburst;
+ } else if (dir == DMA_MEM_TO_DEV) {
+ dev_addr = c->dst_addr;
+ dev_width = c->dst_addr_width;
+ burst = c->dst_maxburst;
+ }
If we redefine the structure as below, this all becomes more simple:
+ if (dir == DMA_DEV_TO_MEM)
+ cfg = &c->dev_src;
+ else if (dir == DMA_MEM_TO_DEV)
+ cfg = &c->dev_dst;
and then we can access the data through cfg->{element} rather than having
to cache each individual elements value in a local variable.
Thoughts?
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 56377df..e6519f7 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -367,6 +367,18 @@ struct dma_slave_config {
bool device_fc;
};
+struct dma_dev_cfg {
+ dma_addr_t addr;
+ enum dma_slave_buswidth width;
+ u32 maxburst;
+};
+
+struct dma_slave_cfg {
+ struct dma_dev_cfg dev_src;
+ struct dma_dev_cfg dev_dst;
+ bool device_fc;
+};
+
static inline const char *dma_chan_name(struct dma_chan *chan)
{
return dev_name(&chan->dev->device);
--
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: [CFT 05/31] dmaengine: PL08x: clean up get_signal/put_signal
On Thu, Jun 07, 2012 at 11:47:23AM +0100, Russell King wrote:
> Try to avoid dereferencing the DMA engine's channel struct in these
> platform helpers; instead, pass a pointer to the channel data into
> get_signal(), and the returned signal number to put_signal().
>
> Signed-off-by: Russell King
The Spear stuff breaks as a result of this patch, so it needs the patch
below combined with this one to prevent that breakage occuring.
diff --git a/arch/arm/plat-spear/include/plat/pl080.h
b/arch/arm/plat-spear/include/plat/pl080.h
index e14a3e4..1786eeb 100644
--- a/arch/arm/plat-spear/include/plat/pl080.h
+++ b/arch/arm/plat-spear/include/plat/pl080.h
@@ -14,8 +14,8 @@
#ifndef __PLAT_PL080_H
#define __PLAT_PL080_H
-struct pl08x_dma_chan;
-int pl080_get_signal(struct pl08x_dma_chan *ch);
-void pl080_put_signal(struct pl08x_dma_chan *ch);
+struct pl08x_channel_data;
+int pl080_get_signal(const struct pl08x_channel_data *cd);
+void pl080_put_signal(const struct pl08x_channel_data *cd, int signal);
#endif /* __PLAT_PL080_H */
diff --git a/arch/arm/plat-spear/pl080.c b/arch/arm/plat-spear/pl080.c
index a56a067..08bec1a 100644
--- a/arch/arm/plat-spear/pl080.c
+++ b/arch/arm/plat-spear/pl080.c
@@ -27,9 +27,8 @@ struct {
unsigned char val;
} signals[16] = {{0, 0}, };
-int pl080_get_signal(struct pl08x_dma_chan *ch)
+int pl080_get_signal(const struct pl08x_channel_data *cd)
{
- const struct pl08x_channel_data *cd = ch->cd;
unsigned int signal = cd->min_signal, val;
unsigned long flags;
@@ -63,18 +62,17 @@ int pl080_get_signal(struct pl08x_dma_chan *ch)
return signal;
}
-void pl080_put_signal(struct pl08x_dma_chan *ch)
+void pl080_put_signal(const struct pl08x_channel_data *cd, int signal)
{
- const struct pl08x_channel_data *cd = ch->cd;
unsigned long flags;
spin_lock_irqsave(&lock, flags);
/* if signal is not used */
- if (!signals[cd->min_signal].busy)
+ if (!signals[signal].busy)
BUG();
- signals[cd->min_signal].busy--;
+ signals[signal].busy--;
spin_unlock_irqrestore(&lock, flags);
}
--
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
