Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
* Jamie Lokier [100622 19:54]: > Tony Lindgren wrote: > > __kuser_get_tls: @ 0x0fe0 > > - > > -#if !defined(CONFIG_HAS_TLS_REG) && !defined(CONFIG_TLS_REG_EMUL) > > - ldr r0, [pc, #(16 - 8)] @ TLS stored at 0x0ff0 > > -#else > > - mrc p15, 0, r0, c13, c0, 3 @ read TLS register > > -#endif > > + ldr r0, [pc, #(20 - 8)] @ software TLS set in > > 0x0ff4? > > + cmp r0, #0 @ hardware TLS if flag not set > > + mrceq p15, 0, r0, c13, c0, 3 @ read hardware TLS register > > + ldrne r0, [pc, #(12 - 8)] @ software TLS val at 0x0ff8 > > usr_ret lr > > - > > - .rep5 > > - .word 0 @ pad up to __kuser_helper_version > > - .endr > > + .word 0 @ non-zero for software TLS > > + .word 0 @ software TLS value > > It'd be nice not to waste instructions checking for HWCAP_TLS on archs > which definitely don't have it. I guess it doesn't matter elsewhere; > I'd expect this to be a warm path for some programs making extensive > use of TLS (I haven't measured though). OK, but let's try to figure out a way that does not add more ifdef else code as that makes it harder to build support for multiple ARM cores. > As it's only a single instruction, and the code is in a writable page > already (copied at init), how about just patching the instruction > when ELF_HWCAP is set? Yeah that can be done for __kuser_get_tls if it's always writable. But __switch_to is trickier because of the CONFIG_MMU ifdefs there. What if we have optional __switch_to and __kuser_get_tls implementations in the mm/proc-*.S files that get copied over the current locations if implemented? 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] OMAP: DSS2: DMA optimization using scaler line buffers
Op 23 jun 2010, om 07:18 heeft Nagarajan, Rajkumar het volgende geschreven: > > --- a/drivers/video/omap2/omapfb/omapfb-main.c > +++ b/drivers/video/omap2/omapfb/omapfb-main.c > @@ -552,7 +552,7 @@ static int setup_vrfb_rotation(struct fb_info *fbi) > omap_vrfb_setup(&rg->vrfb, rg->paddr, > var->xres_virtual, > var->yres_virtual, > - bytespp, yuv_mode); > + bytespp, mode, 0); Shouldn't that be 'color_mode' instead of 'mode'? regards, Koen -- 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/2] arm: Make VFPv3 usable on ARMv6
* Tony Lindgren [100622 16:15]:
> * Catalin Marinas [100622 15:53]:
> > On Mon, 2010-06-21 at 14:51 +0100, Tony Lindgren wrote:
> > > diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
> > > index 315a540..19ba626 100644
> > > --- a/arch/arm/vfp/vfpmodule.c
> > > +++ b/arch/arm/vfp/vfpmodule.c
> > > @@ -549,10 +549,14 @@ static int __init vfp_init(void)
> > > /*
> > > * Check for the presence of the Advanced SIMD
> > > * load/store instructions, integer and single
> > > -* precision floating point operations.
> > > +* precision floating point operations. Only check
> > > +* for NEON if the hardware has TLS register as the
> > > +* MVFR registers got added in ARM1136 r1p0 with TLS.
> > > */
> > > - if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
> > > - elf_hwcap |= HWCAP_NEON;
> > > + if (elf_hwcap & HWCAP_TLS) {
> > > + if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
> > > + elf_hwcap |= HWCAP_NEON;
> > > + }
> >
> > MVFR should be available with the new CPU id format:
> >
> > ((read_cpuid_id() & 0x000f) == 0x000f)
> >
> > I think that would be a cleaner test than relying on the TLS presence.
>
> OK, thanks that's better. Will update accordingly and repost.
Here's this one updated. Using your better MVFR check also removes the
dependency to the previous patch.
Regards,
Tony
From: Tony Lindgren
Date: Mon, 21 Jun 2010 16:33:28 +0300
Subject: [PATCH] arm: Make VFPv3 usable on ARMv6
MVFR0 and MVFR1 are only available starting with ARM1136 r1p0 release
according to "B.5 VFP changes" in DDI0211F_arm1136_r1p0_trm.pdf. This is
also when TLS register got added, so we can use HAS_TLS also to test for
MVFR0 and MVFR1.
Otherwise VFPFMRX and VFPFMXR access fails and we get:
Internal error: Oops - undefined instruction: 0 [#1]
PC is at no_old_VFP_process+0x8/0x3c
LR is at __und_svc+0x48/0x80
...
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/include/asm/vfpmacros.h b/arch/arm/include/asm/vfpmacros.h
index 422f3cc..3d5fc41 100644
--- a/arch/arm/include/asm/vfpmacros.h
+++ b/arch/arm/include/asm/vfpmacros.h
@@ -3,6 +3,8 @@
*
* Assembler-only file containing VFP macros and register definitions.
*/
+#include
+
#include "vfp.h"
@ Macros to allow building with old toolkits (with no VFP support)
@@ -22,12 +24,20 @@
LDC p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d0-d15}
#endif
#ifdef CONFIG_VFPv3
+#if __LINUX_ARM_ARCH__ <= 6
+ ldr \tmp, =elf_hwcap @ may not have MVFR regs
+ ldr \tmp, [\tmp, #0]
+ tst \tmp, #HWCAP_VFPv3D16
+ ldceq p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
+ addne \base, \base, #32*4 @ step over unused register space
+#else
VFPFMRX \tmp, MVFR0 @ Media and VFP Feature Register 0
and \tmp, \tmp, #MVFR0_A_SIMD_MASK @ A_SIMD field
cmp \tmp, #2 @ 32 x 64bit registers?
ldceql p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
addne \base, \base, #32*4 @ step over unused register space
#endif
+#endif
.endm
@ write all the working registers out of the VFP
@@ -38,10 +48,18 @@
STC p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d0-d15}
#endif
#ifdef CONFIG_VFPv3
+#if __LINUX_ARM_ARCH__ <= 6
+ ldr \tmp, =elf_hwcap @ may not have MVFR regs
+ ldr \tmp, [\tmp, #0]
+ tst \tmp, #HWCAP_VFPv3D16
+ stceq p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
+ addne \base, \base, #32*4 @ step over unused register space
+#else
VFPFMRX \tmp, MVFR0 @ Media and VFP Feature Register 0
and \tmp, \tmp, #MVFR0_A_SIMD_MASK @ A_SIMD field
cmp \tmp, #2 @ 32 x 64bit registers?
stceql p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
addne \base, \base, #32*4 @ step over unused register space
#endif
+#endif
.endm
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 315a540..8063a32 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -15,6 +15,7 @@
#include
#include
+#include
#include
#include
@@ -549,10 +550,13 @@ static int __init vfp_init(void)
/*
* Check for the presence of the Advanced SIMD
* load/store instructions, integer and single
- * precision floating point operations.
+ * precision floating point operations. Only check
+ * for NEON if the hardware has the MVFR registers.
*/
- if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
- elf_hwcap |= HWCAP_NEON;
+ if ((read_cpuid_id() & 0x000f) == 0x000f) {
+ if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
+elf_hwcap |= HWCAP_NEON;
+ }
#endif
}
return 0;
Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
On Wed, Jun 23, 2010 at 10:39:13AM +0300, Tony Lindgren wrote: > Yeah that can be done for __kuser_get_tls if it's always writable. > But __switch_to is trickier because of the CONFIG_MMU ifdefs there. And impossible with XIP kernels. > What if we have optional __switch_to and __kuser_get_tls implementations > in the mm/proc-*.S files that get copied over the current locations > if implemented? Also problematical with XIP - if we go down the route of implementing these by copying code fragments into the kernel, we need to strip out XIP support or implement a second way. Obviously having a second way adds maintainence burden, and the second way will probably lose out on updates. -- 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] omap: rx51: Set regulator V28 always on
It seems that the battery cover sensor in Nokia N900 is powered from the
V28 domain. Now if this regulator is disabled it causes that the gpio 160
reads only zero which effectively causes uSD removal detection.
Currently the bootloader enabled V28 is kept on but this may change in the
future according to comment in
drivers/regulator/core.c: regulator_has_full_constraints.
Also if there are any consumers on the V28 domain doing regulator_enable
regulator_disable cycle the V28 will be disabled after that.
Prepare for these by defining the V28 as always_on regulator.
Signed-off-by: Jarkko Nikula
Cc: Adrian Hunter
---
This can be tested easily by setting full regulator constraints. Then the
regulator framework will disable in a late_initcall all the regulators with
zero use count and that don't have always_on flag set.
void __init rx51_peripherals_init(void)
{
+ regulator_has_full_constraints();
rx51_i2c_init();
board_onenand_init();
board_smc91x_init();
---
arch/arm/mach-omap2/board-rx51-peripherals.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index abdf321..aeeb91d 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -362,6 +362,7 @@ static struct regulator_init_data rx51_vaux1 = {
.name = "V28",
.min_uV = 280,
.max_uV = 280,
+ .always_on = true, /* due battery cover sensor */
.valid_modes_mask = REGULATOR_MODE_NORMAL
| REGULATOR_MODE_STANDBY,
.valid_ops_mask = REGULATOR_CHANGE_MODE
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: DSS2: DMA optimization using scaler line buffers
On Wed, Jun 23, 2010 at 07:18:00AM +0200, ext Nagarajan, Rajkumar wrote:
>
> DISPC DMA optimization has been enabled and vrfb calls changed as required.
> Optimization reduces the memory traffic (DDR memory) when rotation is set
> to 90- and 270- degree and SMS-VRFB rotation engine is used.
>
> With this change,
> L3 interconnect traffic is reduced by a factor 2x for YUV422 & UYVY
> DDR memory traffic is reduced by a factor 2x for YUV422 & UYVY.
>
> Signed-off-by: Mukund Mittal
> Signed-off-by: Kishore Y
> Signed-off-by: Rajkumar N
> ---
> arch/arm/plat-omap/include/plat/vrfb.h |6 +++-
> drivers/media/video/omap/omap_vout.c |2 +-
> drivers/video/omap2/dss/dispc.c | 39
> +++---
> drivers/video/omap2/omapfb/omapfb-main.c |2 +-
> drivers/video/omap2/vrfb.c | 18 ++---
> 5 files changed, 50 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/vrfb.h
> b/arch/arm/plat-omap/include/plat/vrfb.h
> index d8a03ce..fba9ecd 100644
> --- a/arch/arm/plat-omap/include/plat/vrfb.h
> +++ b/arch/arm/plat-omap/include/plat/vrfb.h
> @@ -23,6 +23,8 @@
>
> #define OMAP_VRFB_LINE_LEN 2048
>
> +#include
> +
> struct vrfb {
> u8 context;
> void __iomem *vaddr[4];
> @@ -42,8 +44,8 @@ extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
> extern u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp);
> extern u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp);
> extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
> - u16 width, u16 height,
> - unsigned bytespp, bool yuv_mode);
> + u16 width, u16 height, unsigned bytespp,
> + enum omap_color_mode color_mode, int rotation);
> extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
> extern void omap_vrfb_restore_context(void);
>
> diff --git a/drivers/media/video/omap/omap_vout.c
> b/drivers/media/video/omap/omap_vout.c
> index b74884b..b3f94ca 100644
> --- a/drivers/media/video/omap/omap_vout.c
> +++ b/drivers/media/video/omap/omap_vout.c
> @@ -465,7 +465,7 @@ static int omap_vout_vrfb_buffer_setup(struct
> omap_vout_device *vout,
> for (i = 0; i < *count; i++)
> omap_vrfb_setup(&vout->vrfb_context[i],
> vout->smsshado_phy_addr[i], vout->pix.width,
> - vout->pix.height, vout->bpp, yuv_mode);
> + vout->pix.height, vout->bpp, vout->dss_mode,
> vout->rotation);
>
> return 0;
> }
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index e777e35..cb8eba4 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -1059,12 +1059,16 @@ static void _dispc_set_vid_accu1(enum omap_plane
> plane, int haccu, int vaccu)
> dispc_write_reg(ac1_reg[plane-1], val);
> }
>
> +static void _dispc_set_vdma_attrs(enum omap_plane plane, bool enable)
> +{
> + REG_FLD_MOD(dispc_reg_att[plane], enable ? 1 : 0, 20, 20);
> +}
>
> static void _dispc_set_scaling(enum omap_plane plane,
> u16 orig_width, u16 orig_height,
> u16 out_width, u16 out_height,
> bool ilace, bool five_taps,
> - bool fieldmode)
> + bool fieldmode, bool vdma)
> {
> int fir_hinc;
> int fir_vinc;
> @@ -1080,12 +1084,12 @@ static void _dispc_set_scaling(enum omap_plane plane,
>
> _dispc_set_scale_coef(plane, hscaleup, vscaleup, five_taps);
>
> - if (!orig_width || orig_width == out_width)
> + if (!orig_width || (!vdma && (orig_width == out_width)))
> fir_hinc = 0;
> else
> fir_hinc = 1024 * orig_width / out_width;
>
> - if (!orig_height || orig_height == out_height)
> + if (!orig_height || (!vdma && (orig_height == out_height)))
> fir_vinc = 0;
> else
> fir_vinc = 1024 * orig_height / out_height;
> @@ -1164,10 +1168,6 @@ static void _dispc_set_rotation_attrs(enum omap_plane
> plane, u8 rotation,
>
> REG_FLD_MOD(dispc_reg_att[plane], vidrot, 13, 12);
>
> - if (rotation == OMAP_DSS_ROT_90 || rotation == OMAP_DSS_ROT_270)
> - REG_FLD_MOD(dispc_reg_att[plane], 0x1, 18, 18);
> - else
> - REG_FLD_MOD(dispc_reg_att[plane], 0x0, 18, 18);
So VIDROWREPEAT is supposed to be off when vid DMA optimization is on?
There's no mention of that in the TRM.
> } else {
> REG_FLD_MOD(dispc_reg_att[plane], 0, 13, 12);
> REG_FLD_MOD(dispc_reg_att[plane], 0, 18, 18);
> @@ -1504,6 +1504,17 @@ static unsigned long calc_fclk(u16 width, u16 height,
> return dispc_pclk_rate() * vf * hf;
> }
>
> +static int dispc_is_vdma_req(u8 rotation, enum omap_color_mode color_mode)
> +{
> +/* TODO: VDMA support for RGB16 mode */
> + if (cpu_is_om
Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
* Russell King - ARM Linux [100623 11:06]: > On Wed, Jun 23, 2010 at 10:39:13AM +0300, Tony Lindgren wrote: > > Yeah that can be done for __kuser_get_tls if it's always writable. > > But __switch_to is trickier because of the CONFIG_MMU ifdefs there. > > And impossible with XIP kernels. > > > What if we have optional __switch_to and __kuser_get_tls implementations > > in the mm/proc-*.S files that get copied over the current locations > > if implemented? > > Also problematical with XIP - if we go down the route of implementing > these by copying code fragments into the kernel, we need to strip out > XIP support or implement a second way. Obviously having a second way > adds maintainence burden, and the second way will probably lose out > on updates. How about if we implement the default XIP-safe unoptimized functions, with minimal iffdeffery and then allow optional override for non-XIP kernels from mm/proc-*.S files? 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 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
On Wed, Jun 23, 2010 at 12:28:44PM +0300, Tony Lindgren wrote: > * Russell King - ARM Linux [100623 11:06]: > > On Wed, Jun 23, 2010 at 10:39:13AM +0300, Tony Lindgren wrote: > > > Yeah that can be done for __kuser_get_tls if it's always writable. > > > But __switch_to is trickier because of the CONFIG_MMU ifdefs there. > > > > And impossible with XIP kernels. > > > > > What if we have optional __switch_to and __kuser_get_tls implementations > > > in the mm/proc-*.S files that get copied over the current locations > > > if implemented? > > > > Also problematical with XIP - if we go down the route of implementing > > these by copying code fragments into the kernel, we need to strip out > > XIP support or implement a second way. Obviously having a second way > > adds maintainence burden, and the second way will probably lose out > > on updates. > > How about if we implement the default XIP-safe unoptimized functions, > with minimal iffdeffery and then allow optional override for non-XIP > kernels from mm/proc-*.S files? That's what I was referring to by "second way". -- 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 05/12] OMAP: create omap_devices for MPU, DSP, L3
>>-Original Message-
>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>Sent: Thursday, June 17, 2010 5:47 AM
>>To: linux-omap@vger.kernel.org
>>Cc: Menon, Nishanth; Gopinath, Thara; Cousson, Benoit
>>Subject: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
>>
>>Create simple omap_devices for the main processors and busses.
>>
>>This is required to support the forth-coming device-based OPP
>>approach, where OPPs are managed and tracked at the omap_device and
>>hwmod level.
>>
>>Because these omap_devices are based on platform_devices, they cannot
>>be created until the driver core has been initialized. Therefore, move
>>the init of these into a device_initcall(). Also, OMAP PM init cannot
>>be done until after this step as it depends on the OPP layer.
>>
>>Signed-off-by: Kevin Hilman
>>---
>> arch/arm/mach-omap2/devices.c|2 +
>> arch/arm/mach-omap2/io.c | 68
>> --
>> arch/arm/plat-omap/include/plat/common.h |4 ++
>> 3 files changed, 70 insertions(+), 4 deletions(-)
>>
>>diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
>>index 03e6c9e..62920ac 100644
>>--- a/arch/arm/mach-omap2/devices.c
>>+++ b/arch/arm/mach-omap2/devices.c
>>@@ -15,6 +15,7 @@
>> #include
>> #include
>> #include
>>+#include
>>
>> #include
>> #include
>>@@ -29,6 +30,7 @@
>> #include
>> #include
>> #include
>>+#include
>>
>> #include "mux.h"
>>
>>diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
>>index 78d37c0..12a2836 100644
>>--- a/arch/arm/mach-omap2/io.c
>>+++ b/arch/arm/mach-omap2/io.c
>>@@ -44,7 +44,7 @@
>>
>> #include
>> #include "clockdomains.h"
>>-#include
>>+#include
>>
>> #include "omap3-opp.h"
>> /*
>>@@ -311,12 +311,71 @@ static int __init _omap2_init_reprogram_sdrc(void)
>> return v;
>> }
>>
>>-void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
>>- struct omap_sdrc_params *sdrc_cs1)
>>+static struct omap_device_pm_latency *pm_lats;
>>+
>>+static struct device *mpu_dev; /* FIXME: needs clean SMP support */
>>+static struct device *dsp_dev;
>>+static struct device *l3_dev;
>>+
>>+struct device *omap_get_mpu_device(void)
>>+{
>>+ WARN_ON_ONCE(!mpu_dev);
>>+ return mpu_dev;
>>+}
>>+
>>+struct device *omap_get_dsp_device(void)
>>+{
>>+ WARN_ON_ONCE(!dsp_dev);
>>+ return dsp_dev;
>>+}
>>+
>>+struct device *omap_get_l3_device(void)
>> {
>>+ WARN_ON_ONCE(!l3_dev);
>>+ return l3_dev;
>>+}
>>+
>>+static int _init_omap_device(struct omap_hwmod *oh, void *user)
>>+{
>>+ struct omap_device *od;
>>+ const char *name = oh->name;
>>+ struct device **new_dev = (struct device **)user;
>>+
>>+ od = omap_device_build(name, 0, oh, NULL, 0, pm_lats, 0, false);
>>+ if (WARN(IS_ERR(od), "Could not build omap_device for %s\n", name))
>>+ return -ENODEV;
>>+
>>+ *new_dev = &od->pdev.dev;
>>+
>>+ return 0;
>>+}
>>+
>>+/*
>>+ * Build omap_devices for processors and bus.
>>+ */
>>+static void omap_init_processor_devices(void)
>>+{
>>+ omap_hwmod_for_each_by_class("mpu", _init_omap_device, &mpu_dev);
>>+ omap_hwmod_for_each_by_class("dsp", _init_omap_device, &dsp_dev);
>>+ omap_hwmod_for_each_by_class("l3", _init_omap_device, &l3_dev);
>>+}
>>+
>>+static int __init omap2_late_common_init(void)
>>+{
>>+ omap_init_processor_devices();
>>+
>> /* initialize the opp table if board file has not done so */
>> omap3_pm_init_opp_table();
>>
>>+ omap_pm_if_init();
>>+
>>+ return 0;
>>+}
>>+device_initcall(omap2_late_common_init);
Hello Kevin,
Any particular reason for making this a late init and not keeping this a part
of init_common_hw?
The reason is the board files also have an option of calling/ overriding
omap3_pm_init_opp_table. This happens really early in init_irq. (Refer
board_3430sdp.c). So if a board file calls into
omap3_pm_init_opp_table, the opp initializations will happen before the
omap_device pointers are build for mpu, iva and l3. So the dev pointers stored
as part of dev_opp tables will be screwed up.
My personal preference would be to call the omap_init_processor_devices just
after hwmod_late_init. This will remove any race conditions as above.
Regards
Thara
>>+
>>+void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
>>+ struct omap_sdrc_params *sdrc_cs1)
>>+{
>> pwrdm_init(powerdomains_omap);
>> clkdm_init(clockdomains_omap, clkdm_autodeps);
>> if (cpu_is_omap242x())
>>@@ -325,6 +384,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
>>*sdrc_cs0,
>> omap2430_hwmod_init();
>> else if (cpu_is_omap34xx())
>> omap3xxx_hwmod_init();
>>+
>> omap2_mux_init();
>> omap_pm_if_early_init();
>>
>>@@ -342,7 +402,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
>>*sdrc_cs0,
>> omap_serial_early_init();
>> if (cpu_is_omap2
pm_debug/voltage_off_while_idle has gone?
There used to be 'voltage_off_while_idle' attribute in the PM-enabled kernels that allowed to put PMIC into OFF mode. In the current tip of the linux-omap-pm tree this attribute seem to be gone Is there possibility to make PMIC enter the OFF mode when suspending to RAM? -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/11] staging: add ti dspbridge driver
Add TI's DSP Bridge driver to the staging area. TI's DSP Bridge driver supplies a direct link between host applications and DSP tasks running on a remote processor. Please pull from: git://wizery.com/pub/tidspbridge.git for-greg The patches will be sent as a follow-on to this message to lkml and l-o for people to see. The patches are the result of a staging relocation and a linux-next rebase of 85343cd5491260881b34ab7bb7cdc8fdeef078e4 at git://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git dspbridge For more information about TI's DSP Bridge, check out the submitted documentation and also: http://omapzoom.org/gf/project/omapbridge/docman/?subdir=3 The DSP/Bridge project wish to thank all of its contributors; current bridge driver is the result of the work of all of them. The following is an alphabetical order of all contributors (that we know of. If by any chance we forgot to mention anyone, please let us know, thanks!): Suman Anna Sripal Bagadia Felipe Balbi Ohad Ben-Cohen Phil Carmody Deepak Chitriki Felipe Contreras Hiroshi Doyu Seth Forshee Ivan Gomez Castellanos Mark Grosen Ramesh Gupta G Fernando Guzman Lugo Axel Haslam Janet Head Shivananda Hebbar Hari Kanigeri Tony Lindgren Antonio Luna Hari Nagalla Nishanth Menon Ameya Palande Vijay Pasam Gilbert Pitney Omar Ramirez Luna Ernesto Ramos Chris Ring Larry Schiefer Rebecca Schultz Zavin Bhavin Shah Andy Shevchenko Jeff Taylor Roman Tereshonkov Armando Uribe de Leon Nischal Varide Wenbiao Wang Thanks, Ohad Ben-Cohen (1): staging: ti dspbridge: add TODO file Omar Ramirez Luna (10): staging: ti dspbridge: add driver documentation staging: ti dspbridge: add core driver sources staging: ti dspbridge: add platform manager code staging: ti dspbridge: add resource manager staging: ti dspbridge: add MMU support staging: ti dspbridge: add generic utilities staging: ti dspbridge: add services staging: ti dspbridge: add DOFF binaries loader staging: ti dspbridge: add header files staging: ti dspbridge: enable driver building drivers/staging/Kconfig|2 + drivers/staging/Makefile |1 + .../staging/tidspbridge/Documentation/CONTRIBUTORS | 82 + drivers/staging/tidspbridge/Documentation/README | 70 + .../staging/tidspbridge/Documentation/error-codes | 157 + drivers/staging/tidspbridge/Kconfig| 88 + drivers/staging/tidspbridge/Makefile | 34 + drivers/staging/tidspbridge/TODO | 18 + drivers/staging/tidspbridge/core/_cmm.h| 45 + drivers/staging/tidspbridge/core/_deh.h| 35 + drivers/staging/tidspbridge/core/_msg_sm.h | 142 + drivers/staging/tidspbridge/core/_tiomap.h | 377 +++ drivers/staging/tidspbridge/core/_tiomap_pwr.h | 85 + drivers/staging/tidspbridge/core/chnl_sm.c | 1015 ++ drivers/staging/tidspbridge/core/dsp-clock.c | 421 +++ drivers/staging/tidspbridge/core/io_sm.c | 2410 +++ drivers/staging/tidspbridge/core/mmu_fault.c | 139 + drivers/staging/tidspbridge/core/mmu_fault.h | 36 + drivers/staging/tidspbridge/core/msg_sm.c | 673 drivers/staging/tidspbridge/core/tiomap3430.c | 1887 drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 604 drivers/staging/tidspbridge/core/tiomap_io.c | 458 +++ drivers/staging/tidspbridge/core/tiomap_io.h | 104 + drivers/staging/tidspbridge/core/ue_deh.c | 303 ++ drivers/staging/tidspbridge/core/wdt.c | 150 + drivers/staging/tidspbridge/dynload/cload.c| 1960 .../staging/tidspbridge/dynload/dload_internal.h | 351 +++ drivers/staging/tidspbridge/dynload/doff.h | 344 +++ drivers/staging/tidspbridge/dynload/getsection.c | 416 +++ drivers/staging/tidspbridge/dynload/header.h | 55 + drivers/staging/tidspbridge/dynload/module_list.h | 159 + drivers/staging/tidspbridge/dynload/params.h | 226 ++ drivers/staging/tidspbridge/dynload/reloc.c| 484 +++ drivers/staging/tidspbridge/dynload/reloc_table.h | 102 + .../tidspbridge/dynload/reloc_table_c6000.c| 257 ++ drivers/staging/tidspbridge/dynload/tramp.c| 1143 +++ .../tidspbridge/dynload/tramp_table_c6000.c| 164 + drivers/staging/tidspbridge/gen/gb.c | 167 + drivers/staging/tidspbridge/gen/gh.c | 213 ++ drivers/staging/tidspbridge/gen/gs.c | 89 + drivers/staging/tidspbridge/gen/uuidutil.c | 223 ++ drivers/staging/tidspbridge/hw/EasiGlobal.h| 41 + drivers/staging/tidspbridg
[PATCH 01/11] staging: ti dspbridge: add driver documentation
From: Omar Ramirez Luna Add a README with a general overview of TI's DSP Bridge driver, a short explanations of how error codes are currently used, and a CONTRIBUTORS file with all past & present contributors. For additional information about TI's DSP Bridge, check out http://omapzoom.org/gf/project/omapbridge/docman/?subdir=3 Note: if by any chance we forgot to mention any contributor, please let us know and we will fix that. Signed-off-by: Omar Ramirez Luna Signed-off-by: Kanigeri, Hari Signed-off-by: Ameya Palande Signed-off-by: Guzman Lugo, Fernando Signed-off-by: Hebbar, Shivananda Signed-off-by: Ramos Falcon, Ernesto Signed-off-by: Felipe Contreras Signed-off-by: Anna, Suman Signed-off-by: Gupta, Ramesh Signed-off-by: Gomez Castellanos, Ivan Signed-off-by: Andy Shevchenko Signed-off-by: Armando Uribe De Leon Signed-off-by: Deepak Chitriki Signed-off-by: Menon, Nishanth Signed-off-by: Phil Carmody Signed-off-by: Ohad Ben-Cohen --- .../staging/tidspbridge/Documentation/CONTRIBUTORS | 82 ++ drivers/staging/tidspbridge/Documentation/README | 70 + .../staging/tidspbridge/Documentation/error-codes | 157 3 files changed, 309 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/tidspbridge/Documentation/CONTRIBUTORS create mode 100644 drivers/staging/tidspbridge/Documentation/README create mode 100644 drivers/staging/tidspbridge/Documentation/error-codes diff --git a/drivers/staging/tidspbridge/Documentation/CONTRIBUTORS b/drivers/staging/tidspbridge/Documentation/CONTRIBUTORS new file mode 100644 index 000..b40e7a6 --- /dev/null +++ b/drivers/staging/tidspbridge/Documentation/CONTRIBUTORS @@ -0,0 +1,82 @@ +TI DSP/Bridge Driver - Contributors File + +The DSP/Bridge project wish to thank all of its contributors, current bridge +driver is the result of the work of all of them. If any name is accidentally +omitted, let us know by sending a mail to omar.rami...@ti.com or +x095...@ti.com. + +Please keep the following list in alphabetical order. + + Suman Anna + Sripal Bagadia + Felipe Balbi + Ohad Ben-Cohen + Phil Carmody + Deepak Chitriki + Felipe Contreras + Hiroshi Doyu + Seth Forshee + Ivan Gomez Castellanos + Mark Grosen + Ramesh Gupta G + Fernando Guzman Lugo + Axel Haslam + Janet Head + Shivananda Hebbar + Hari Kanigeri + Tony Lindgren + Antonio Luna + Hari Nagalla + Nishanth Menon + Ameya Palande + Vijay Pasam + Gilbert Pitney + Omar Ramirez Luna + Ernesto Ramos + Chris Ring + Larry Schiefer + Rebecca Schultz Zavin + Bhavin Shah + Andy Shevchenko + Jeff Taylor + Roman Tereshonkov + Armando Uribe de Leon + Nischal Varide + Wenbiao Wang + + + +The following list was taken from file Revision History, if you recognize your +alias or did any contribution to the project please let us now, so we can +proper credit your work. + + ag + ap + cc + db + dh4 + dr + hp + jg + kc + kln + kw + ge + gv + map + mf + mk + mr + nn + rajesh + rg + rr + rt + sb + sg + sh + sp + srid + swa + vp + ww diff --git a/drivers/staging/tidspbridge/Documentation/README b/drivers/staging/tidspbridge/Documentation/README new file mode 100644 index 000..df6d371 --- /dev/null +++ b/drivers/staging/tidspbridge/Documentation/README @@ -0,0 +1,70 @@ +Linux DSP/BIOS Bridge release + +DSP/BIOS Bridge overview + + +DSP/BIOS Bridge is designed for platforms that contain a GPP and one or more +attached DSPs. The GPP is considered the master or "host" processor, and the +attached DSPs are processing resources that can be utilized by applications +and drivers running on the GPP. + +The abstraction that DSP/BIOS Bridge supplies, is a direct link between a GPP +program and a DSP task. This communication link is partitioned into two +types of sub-links: messaging (short, fixed-length packets) and data +streaming (multiple, large buffers). Each sub-link operates independently, +and features in-order delivery of data, meaning that messages are delivered +in the order they were submitted to the message link, and stream buffers are +delivered in the order they were submitted to the stream link. + +In addition, a GPP client can specify what inputs and outputs a DSP task +uses. DSP tasks typically use message objects for passing control and status +information and stream objects for efficient streaming of real-time data. + +GPP Software Architecture += + +A GPP application communicates with its associated DSP task running on the +DSP subsystem using the DSP/BIOS Bridge API. For example, a GPP audio +ap
RE: ZOOM2 doesn't boot on upstream kernel
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Neshama Parhoti > Sent: Wednesday, June 23, 2010 12:12 AM > To: linux-omap@vger.kernel.org > Subject: ZOOM2 doesn't boot on upstream kernel > > Hi all, > > I can't get to boot the latest mainline kernel on ZOOM2 (using > omap_zoom2_defconfig). [Ghorai] It's working for me. 1. console=ttyS0 2. And can you try omap3_defconfig > > It just hangs after u-boot is saying "loading kernel...". > > I know that my setup is ok, because if I use TI kernel sources from my > BSP it boots fine.. > > Any idea what is the problem ? > > Maybe I need to use also recent upstream u-boot ? > > thank you > ~pnesh > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/11] staging: ti dspbridge: add MMU support
From: Omar Ramirez Luna Add TI's DSP Bridge MMU support Signed-off-by: Omar Ramirez Luna Signed-off-by: Kanigeri, Hari Signed-off-by: Ameya Palande Signed-off-by: Guzman Lugo, Fernando Signed-off-by: Hebbar, Shivananda Signed-off-by: Ramos Falcon, Ernesto Signed-off-by: Felipe Contreras Signed-off-by: Anna, Suman Signed-off-by: Gupta, Ramesh Signed-off-by: Gomez Castellanos, Ivan Signed-off-by: Andy Shevchenko Signed-off-by: Armando Uribe De Leon Signed-off-by: Deepak Chitriki Signed-off-by: Menon, Nishanth Signed-off-by: Phil Carmody Signed-off-by: Ohad Ben-Cohen --- drivers/staging/tidspbridge/hw/EasiGlobal.h | 41 ++ drivers/staging/tidspbridge/hw/GlobalTypes.h | 308 ++ drivers/staging/tidspbridge/hw/MMUAccInt.h | 76 drivers/staging/tidspbridge/hw/MMURegAcM.h | 226 ++ drivers/staging/tidspbridge/hw/hw_defs.h | 60 +++ drivers/staging/tidspbridge/hw/hw_mmu.c | 587 ++ drivers/staging/tidspbridge/hw/hw_mmu.h | 161 +++ 7 files changed, 1459 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/tidspbridge/hw/EasiGlobal.h create mode 100644 drivers/staging/tidspbridge/hw/GlobalTypes.h create mode 100644 drivers/staging/tidspbridge/hw/MMUAccInt.h create mode 100644 drivers/staging/tidspbridge/hw/MMURegAcM.h create mode 100644 drivers/staging/tidspbridge/hw/hw_defs.h create mode 100644 drivers/staging/tidspbridge/hw/hw_mmu.c create mode 100644 drivers/staging/tidspbridge/hw/hw_mmu.h diff --git a/drivers/staging/tidspbridge/hw/EasiGlobal.h b/drivers/staging/tidspbridge/hw/EasiGlobal.h new file mode 100644 index 000..9b45aa7 --- /dev/null +++ b/drivers/staging/tidspbridge/hw/EasiGlobal.h @@ -0,0 +1,41 @@ +/* + * EasiGlobal.h + * + * DSP-BIOS Bridge driver support functions for TI OMAP processors. + * + * Copyright (C) 2007 Texas Instruments, Inc. + * + * This package is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. + */ + +#ifndef _EASIGLOBAL_H +#define _EASIGLOBAL_H +#include + +/* + * DEFINE:READ_ONLY, WRITE_ONLY & READ_WRITE + * + * DESCRIPTION: Defines used to describe register types for EASI-checker tests. + */ + +#define READ_ONLY1 +#define WRITE_ONLY 2 +#define READ_WRITE 3 + +/* + * MACRO:_DEBUG_LEVEL1_EASI + * + * DESCRIPTION: A MACRO which can be used to indicate that a particular beach + * register access function was called. + * + * NOTE: We currently dont use this functionality. + */ +#define _DEBUG_LEVEL1_EASI(easiNum) ((void)0) + +#endif /* _EASIGLOBAL_H */ diff --git a/drivers/staging/tidspbridge/hw/GlobalTypes.h b/drivers/staging/tidspbridge/hw/GlobalTypes.h new file mode 100644 index 000..9b55150 --- /dev/null +++ b/drivers/staging/tidspbridge/hw/GlobalTypes.h @@ -0,0 +1,308 @@ +/* + * GlobalTypes.h + * + * DSP-BIOS Bridge driver support functions for TI OMAP processors. + * + * Global HW definitions + * + * Copyright (C) 2007 Texas Instruments, Inc. + * + * This package is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. + */ + +#ifndef _GLOBALTYPES_H +#define _GLOBALTYPES_H + +/* + * Definition: TRUE, FALSE + * + * DESCRIPTION: Boolean Definitions + */ +#ifndef TRUE +#define FALSE 0 +#define TRUE (!(FALSE)) +#endif + +/* + * Definition: NULL + * + * DESCRIPTION: Invalid pointer + */ +#ifndef NULL +#define NULL (void *)0 +#endif + +/* + * Definition: RET_CODE_BASE + * + * DESCRIPTION: Base value for return code offsets + */ +#define RET_CODE_BASE 0 + +/* + * Definition: *BIT_OFFSET + * + * DESCRIPTION: offset in bytes from start of 32-bit word. + */ +#define LOWER16BIT_OFFSET0 +#define UPPER16BIT_OFFSET2 + +#define LOWER8BIT_OFFSET 0 +#define LOWER_MIDDLE8BIT_OFFSET1 +#define UPPER_MIDDLE8BIT_OFFSET2 +#define UPPER8BIT_OFFSET 3 + +#define LOWER8BIT_OF16_OFFSET 0 +#define UPPER8BIT_OF16_OFFSET 1 + +/* + * Definition: *BIT_SHIFT + * + * DESCRIPTION: offset in bits from start of 32-bit word. + */ +#define LOWER16BIT_SHIFT 0 +#define UPPER16BIT_SHIFT 16 + +#define LOWER8BIT_SHIFT 0 +#define LOWER_MIDDLE8BIT_SHIFT8 +#define UPPER_MIDDLE8BIT_SHIFT16 +#define UPPER8BIT_SHIFT 24 + +#define LOWER8BIT_OF16_SHIFT 0 +#define UPPER8BIT_OF16_SHIFT 8 + +/* +
[PATCH 07/11] staging: ti dspbridge: add services
From: Omar Ramirez Luna
Add TI's DSP Bridge driver services code
Signed-off-by: Omar Ramirez Luna
Signed-off-by: Kanigeri, Hari
Signed-off-by: Ameya Palande
Signed-off-by: Guzman Lugo, Fernando
Signed-off-by: Hebbar, Shivananda
Signed-off-by: Ramos Falcon, Ernesto
Signed-off-by: Felipe Contreras
Signed-off-by: Anna, Suman
Signed-off-by: Gupta, Ramesh
Signed-off-by: Gomez Castellanos, Ivan
Signed-off-by: Andy Shevchenko
Signed-off-by: Armando Uribe De Leon
Signed-off-by: Deepak Chitriki
Signed-off-by: Menon, Nishanth
Signed-off-by: Phil Carmody
Signed-off-by: Ohad Ben-Cohen
---
drivers/staging/tidspbridge/services/cfg.c | 253 +++
drivers/staging/tidspbridge/services/ntfy.c | 31 +++
drivers/staging/tidspbridge/services/services.c | 69 ++
drivers/staging/tidspbridge/services/sync.c | 104 +
4 files changed, 457 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/tidspbridge/services/cfg.c
create mode 100644 drivers/staging/tidspbridge/services/ntfy.c
create mode 100644 drivers/staging/tidspbridge/services/services.c
create mode 100644 drivers/staging/tidspbridge/services/sync.c
diff --git a/drivers/staging/tidspbridge/services/cfg.c
b/drivers/staging/tidspbridge/services/cfg.c
new file mode 100644
index 000..8ae64f4
--- /dev/null
+++ b/drivers/staging/tidspbridge/services/cfg.c
@@ -0,0 +1,253 @@
+/*
+ * cfg.c
+ *
+ * DSP-BIOS Bridge driver support functions for TI OMAP processors.
+ *
+ * Implementation of platform specific config services.
+ *
+ * Copyright (C) 2005-2006 Texas Instruments, Inc.
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+/* --- DSP/BIOS Bridge */
+#include
+#include
+
+/* --- Trace & Debug */
+#include
+
+/* --- OS Adaptation Layer */
+
+/* --- This */
+#include
+#include
+
+struct drv_ext {
+ struct list_head link;
+ char sz_string[MAXREGPATHLENGTH];
+};
+
+/*
+ * cfg_exit
+ * Purpose:
+ * Discontinue usage of the CFG module.
+ */
+void cfg_exit(void)
+{
+ /* Do nothing */
+}
+
+/*
+ * cfg_get_auto_start
+ * Purpose:
+ * Retreive the autostart mask, if any, for this board.
+ */
+int cfg_get_auto_start(struct cfg_devnode *dev_node_obj,
+ OUT u32 *pdwAutoStart)
+{
+ int status = 0;
+ u32 dw_buf_size;
+ struct drv_data *drv_datap = dev_get_drvdata(bridge);
+
+ dw_buf_size = sizeof(*pdwAutoStart);
+ if (!dev_node_obj)
+ status = -EFAULT;
+ if (!pdwAutoStart || !drv_datap)
+ status = -EFAULT;
+ if (DSP_SUCCEEDED(status))
+ *pdwAutoStart = (drv_datap->base_img) ? 1 : 0;
+
+ DBC_ENSURE((status == 0 &&
+ (*pdwAutoStart == 0 || *pdwAutoStart == 1))
+ || status != 0);
+ return status;
+}
+
+/*
+ * cfg_get_dev_object
+ * Purpose:
+ * Retrieve the Device Object handle for a given devnode.
+ */
+int cfg_get_dev_object(struct cfg_devnode *dev_node_obj,
+ OUT u32 *pdwValue)
+{
+ int status = 0;
+ u32 dw_buf_size;
+ struct drv_data *drv_datap = dev_get_drvdata(bridge);
+
+ if (!drv_datap)
+ status = -EPERM;
+
+ if (!dev_node_obj)
+ status = -EFAULT;
+
+ if (!pdwValue)
+ status = -EFAULT;
+
+ dw_buf_size = sizeof(pdwValue);
+ if (DSP_SUCCEEDED(status)) {
+
+ /* check the device string and then store dev object */
+ if (!
+ (strcmp
+((char *)((struct drv_ext *)dev_node_obj)->sz_string,
+ "TIOMAP1510")))
+ *pdwValue = (u32)drv_datap->dev_object;
+ }
+ if (DSP_FAILED(status))
+ pr_err("%s: Failed, status 0x%x\n", __func__, status);
+ return status;
+}
+
+/*
+ * cfg_get_exec_file
+ * Purpose:
+ * Retreive the default executable, if any, for this board.
+ */
+int cfg_get_exec_file(struct cfg_devnode *dev_node_obj, u32 ul_buf_size,
+OUT char *pstrExecFile)
+{
+ int status = 0;
+ struct drv_data *drv_datap = dev_get_drvdata(bridge);
+
+ if (!dev_node_obj)
+ status = -EFAULT;
+
+ else if (!pstrExecFile || !drv_datap)
+ status = -EFAULT;
+
+ if (strlen(drv_datap->base_img) > ul_buf_size)
+ status = -EINV
[PATCH 06/11] staging: ti dspbridge: add generic utilities
From: Omar Ramirez Luna
Add TI's DSP Bridge generic utilities driver sources
Signed-off-by: Omar Ramirez Luna
Signed-off-by: Kanigeri, Hari
Signed-off-by: Ameya Palande
Signed-off-by: Guzman Lugo, Fernando
Signed-off-by: Hebbar, Shivananda
Signed-off-by: Ramos Falcon, Ernesto
Signed-off-by: Felipe Contreras
Signed-off-by: Anna, Suman
Signed-off-by: Gupta, Ramesh
Signed-off-by: Gomez Castellanos, Ivan
Signed-off-by: Andy Shevchenko
Signed-off-by: Armando Uribe De Leon
Signed-off-by: Deepak Chitriki
Signed-off-by: Menon, Nishanth
Signed-off-by: Phil Carmody
Signed-off-by: Ohad Ben-Cohen
---
drivers/staging/tidspbridge/gen/gb.c | 167 +
drivers/staging/tidspbridge/gen/gh.c | 213 ++
drivers/staging/tidspbridge/gen/gs.c | 89 +++
drivers/staging/tidspbridge/gen/uuidutil.c | 223
4 files changed, 692 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/tidspbridge/gen/gb.c
create mode 100644 drivers/staging/tidspbridge/gen/gh.c
create mode 100644 drivers/staging/tidspbridge/gen/gs.c
create mode 100644 drivers/staging/tidspbridge/gen/uuidutil.c
diff --git a/drivers/staging/tidspbridge/gen/gb.c
b/drivers/staging/tidspbridge/gen/gb.c
new file mode 100644
index 000..f1a9dd3
--- /dev/null
+++ b/drivers/staging/tidspbridge/gen/gb.c
@@ -0,0 +1,167 @@
+/*
+ * gb.c
+ *
+ * DSP-BIOS Bridge driver support functions for TI OMAP processors.
+ *
+ * Generic bitmap operations.
+ *
+ * Copyright (C) 2005-2006 Texas Instruments, Inc.
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+/* --- DSP/BIOS Bridge */
+#include
+#include
+/* --- This */
+#include
+#include
+
+struct gb_t_map {
+ u32 len;
+ u32 wcnt;
+ u32 *words;
+};
+
+/*
+ * gb_clear
+ * purpose:
+ * Clears a bit in the bit map.
+ */
+
+void gb_clear(struct gb_t_map *map, u32 bitn)
+{
+ u32 mask;
+
+ mask = 1L << (bitn % BITS_PER_LONG);
+ map->words[bitn / BITS_PER_LONG] &= ~mask;
+}
+
+/*
+ * gb_create
+ * purpose:
+ * Creates a bit map.
+ */
+
+struct gb_t_map *gb_create(u32 len)
+{
+ struct gb_t_map *map;
+ u32 i;
+ map = (struct gb_t_map *)gs_alloc(sizeof(struct gb_t_map));
+ if (map != NULL) {
+ map->len = len;
+ map->wcnt = len / BITS_PER_LONG + 1;
+ map->words = (u32 *) gs_alloc(map->wcnt * sizeof(u32));
+ if (map->words != NULL) {
+ for (i = 0; i < map->wcnt; i++)
+ map->words[i] = 0L;
+
+ } else {
+ gs_frees(map, sizeof(struct gb_t_map));
+ map = NULL;
+ }
+ }
+
+ return map;
+}
+
+/*
+ * gb_delete
+ * purpose:
+ * Frees a bit map.
+ */
+
+void gb_delete(struct gb_t_map *map)
+{
+ gs_frees(map->words, map->wcnt * sizeof(u32));
+ gs_frees(map, sizeof(struct gb_t_map));
+}
+
+/*
+ * gb_findandset
+ * purpose:
+ * Finds a free bit and sets it.
+ */
+u32 gb_findandset(struct gb_t_map *map)
+{
+ u32 bitn;
+
+ bitn = gb_minclear(map);
+
+ if (bitn != GB_NOBITS)
+ gb_set(map, bitn);
+
+ return bitn;
+}
+
+/*
+ * gb_minclear
+ * purpose:
+ * returns the location of the first unset bit in the bit map.
+ */
+u32 gb_minclear(struct gb_t_map *map)
+{
+ u32 bit_location = 0;
+ u32 bit_acc = 0;
+ u32 i;
+ u32 bit;
+ u32 *word;
+
+ for (word = map->words, i = 0; i < map->wcnt; word++, i++) {
+ if (~*word) {
+ for (bit = 0; bit < BITS_PER_LONG; bit++, bit_acc++) {
+ if (bit_acc == map->len)
+ return GB_NOBITS;
+
+ if (~*word & (1L << bit)) {
+ bit_location = i * BITS_PER_LONG + bit;
+ return bit_location;
+ }
+
+ }
+ } else {
+ bit_acc += BITS_PER_LONG;
+ }
+ }
+
+ return GB_NOBITS;
+}
+
+/*
+ * gb_set
+ * purpose:
+ * Sets a bit in the bit map.
+ */
+
+void gb_set(struct gb_t_map *map, u32 bitn)
+{
+ u32 mask;
+
+ mask = 1L << (bitn % BITS_PER_LONG);
+ map->words[bitn / BITS_PER_LONG] |= mask;
+
[PATCH 10/11] staging: ti dspbridge: add TODO file
Add a general cleaning roadmap TODO file to TI's DSP Bridge staging driver. Signed-off-by: Ohad Ben-Cohen --- I can also be reached at < ohadb at ti dot com > drivers/staging/tidspbridge/TODO | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/tidspbridge/TODO diff --git a/drivers/staging/tidspbridge/TODO b/drivers/staging/tidspbridge/TODO new file mode 100644 index 000..54f4a29 --- /dev/null +++ b/drivers/staging/tidspbridge/TODO @@ -0,0 +1,18 @@ +* Migrate to (and if necessary, extend) existing upstream code such as + iommu, wdt, mcbsp, gptimers +* Decouple hardware-specific code (e.g. bridge_brd_start/stop/delete/monitor) +* DOFF binary loader: consider pushing to user space. at the very least + eliminate the direct filesystem access +* Eliminate general services and libraries - use or extend existing kernel + libraries instead (e.g. gcf/lcm in nldr.c, global helpers in gen/) +* Eliminate direct manipulation of OMAP_SYSC_BASE +* Eliminate list.h : seem like a redundant wrapper to existing kernel lists +* Eliminate DSP_SUCCEEDED macros and their imposed redundant indentations + (adopt the kernel way of checking for return values) +* Audit interfaces exposed to user space +* Audit and clean up header files folder +* Use kernel coding style +* checkpatch.pl fixes + +Please send any patches to Greg Kroah-Hartman +and Omar Ramirez Luna . -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/11] staging: ti dspbridge: enable driver building
From: Omar Ramirez Luna Add Kconfig + Makefile for TI's DSP Bridge driver and expose it to the staging menu. Signed-off-by: Omar Ramirez Luna Signed-off-by: Kanigeri, Hari Signed-off-by: Ameya Palande Signed-off-by: Guzman Lugo, Fernando Signed-off-by: Hebbar, Shivananda Signed-off-by: Ramos Falcon, Ernesto Signed-off-by: Felipe Contreras Signed-off-by: Anna, Suman Signed-off-by: Gupta, Ramesh Signed-off-by: Gomez Castellanos, Ivan Signed-off-by: Andy Shevchenko Signed-off-by: Armando Uribe De Leon Signed-off-by: Deepak Chitriki Signed-off-by: Menon, Nishanth Signed-off-by: Phil Carmody Signed-off-by: Ohad Ben-Cohen --- drivers/staging/Kconfig |2 + drivers/staging/Makefile |1 + drivers/staging/tidspbridge/Kconfig | 88 ++ drivers/staging/tidspbridge/Makefile | 34 + 4 files changed, 125 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/tidspbridge/Kconfig create mode 100644 drivers/staging/tidspbridge/Makefile diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index cdd3ea3..ce1dfa8 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -151,5 +151,7 @@ source "drivers/staging/msm/Kconfig" source "drivers/staging/easycap/Kconfig" +source "drivers/staging/tidspbridge/Kconfig" + endif # !STAGING_EXCLUDE_BUILD endif # STAGING diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index beceaff..7849818 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -56,3 +56,4 @@ obj-$(CONFIG_FB_XGI) += xgifb/ obj-$(CONFIG_TOUCHSCREEN_MRSTOUCH) += mrst-touchscreen/ obj-$(CONFIG_MSM_STAGING) += msm/ obj-$(CONFIG_EASYCAP) += easycap/ +obj-$(CONFIG_TIDSPBRIDGE) += tidspbridge/ diff --git a/drivers/staging/tidspbridge/Kconfig b/drivers/staging/tidspbridge/Kconfig new file mode 100644 index 000..37fa2b1 --- /dev/null +++ b/drivers/staging/tidspbridge/Kconfig @@ -0,0 +1,88 @@ +# +# DSP Bridge Driver Support +# + +menuconfig TIDSPBRIDGE + tristate "DSP Bridge driver" + default n + select OMAP_MBOX_FWK + help + DSP/BIOS Bridge is designed for platforms that contain a GPP and + one or more attached DSPs. The GPP is considered the master or + "host" processor, and the attached DSPs are processing resources + that can be utilized by applications and drivers running on the GPP. + + This driver depends on OMAP Mailbox (OMAP_MBOX_FWK). + +config BRIDGE_DVFS + bool "Enable Bridge Dynamic Voltage and Frequency Scaling (DVFS)" + depends on TIDSPBRIDGE && OMAP_PM_SRF && CPU_FREQ + default n + help + DVFS allows DSP Bridge to initiate the operating point change to + scale the chip voltage and frequency in order to match the + performance and power consumption to the current processing + requirements. + +config BRIDGE_MEMPOOL_SIZE + hex "Physical memory pool size (Byte)" + depends on TIDSPBRIDGE + default 0x60 + help + Allocate specified size of memory at booting time to avoid allocation + failure under heavy memory fragmentation after some use time. + +config BRIDGE_DEBUG + bool "DSP Bridge Debug Support" + depends on TIDSPBRIDGE + help + Say Y to enable Bridge debugging capabilities + +config BRIDGE_RECOVERY + bool "DSP Recovery Support" + depends on TIDSPBRIDGE + help + In case of DSP fatal error, BRIDGE driver will try to + recover itself. + +config BRIDGE_CACHE_LINE_CHECK + bool "Check buffers to be 128 byte aligned" + depends on TIDSPBRIDGE + default n + help + When the DSP processes data, the DSP cache controller loads 128-Byte + chunks (lines) from SDRAM and writes the data back in 128-Byte chunks. + If a DMM buffer does not start and end on a 128-Byte boundary, the data + preceding the start address (SA) from the 128-Byte boundary to the SA + and the data at addresses trailing the end address (EA) from the EA to + the next 128-Byte boundary will be loaded and written back as well. + This can lead to heap corruption. Say Y, to enforce the check for 128 + byte alignment, buffers failing this check will be rejected. + +config BRIDGE_WDT3 + bool "Enable WDT3 interruptions" + depends on TIDSPBRIDGE + default n + help + WTD3 is managed by DSP and once it is enabled, DSP side bridge is in + charge of refreshing the timer before overflow, if the DSP hangs MPU + will caught the interrupt and try to recover DSP. + +config WDT_TIMEOUT + int "DSP watchdog timer timeout (in secs)" + depends on BRIDGE_WDT3 + default 5 + help + Watchdog timer timeout value, after that time if the watchdog timer + counter is not reset the wdt ove
Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
Tony Lindgren wrote: > > Also problematical with XIP - if we go down the route of implementing > > these by copying code fragments into the kernel, we need to strip out > > XIP support or implement a second way. Obviously having a second way > > adds maintainence burden, and the second way will probably lose out > > on updates. > > How about if we implement the default XIP-safe unoptimized functions, > with minimal iffdeffery and then allow optional override for non-XIP > kernels from mm/proc-*.S files? That might be a plan for some things like cache maintenance - skip a function call when not needed, call direct instead of indirect, but for XIP that status quo must remain. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
Tony Lindgren wrote: > * Jamie Lokier [100622 19:54]: > > Tony Lindgren wrote: > > > __kuser_get_tls: @ 0x0fe0 > > > - > > > -#if !defined(CONFIG_HAS_TLS_REG) && !defined(CONFIG_TLS_REG_EMUL) > > > - ldr r0, [pc, #(16 - 8)] @ TLS stored at 0x0ff0 > > > -#else > > > - mrc p15, 0, r0, c13, c0, 3 @ read TLS register > > > -#endif > > > + ldr r0, [pc, #(20 - 8)] @ software TLS set in > > > 0x0ff4? > > > + cmp r0, #0 @ hardware TLS if flag not set > > > + mrceq p15, 0, r0, c13, c0, 3 @ read hardware TLS register > > > + ldrne r0, [pc, #(12 - 8)] @ software TLS val at 0x0ff8 > > > usr_ret lr > > > - > > > - .rep5 > > > - .word 0 @ pad up to __kuser_helper_version > > > - .endr > > > + .word 0 @ non-zero for software TLS > > > + .word 0 @ software TLS value > > > > It'd be nice not to waste instructions checking for HWCAP_TLS on archs > > which definitely don't have it. I guess it doesn't matter elsewhere; > > I'd expect this to be a warm path for some programs making extensive > > use of TLS (I haven't measured though). > > OK, but let's try to figure out a way that does not add more ifdef else > code as that makes it harder to build support for multiple ARM cores. > > > As it's only a single instruction, and the code is in a writable page > > already (copied at init), how about just patching the instruction > > when ELF_HWCAP is set? > > Yeah that can be done for __kuser_get_tls if it's always writable. > But __switch_to is trickier because of the CONFIG_MMU ifdefs there. __kuser_get_tls must be writable in kernels where !HAS_TLS_REG is supported, because the TLS value is written to the same page. I was thinking of changing *only* __kuser_get_tls, by the way. Out of all the different places, that's the only one I'd expect to be a hot path in some TLS-using programs. > What if we have optional __switch_to and __kuser_get_tls implementations > in the mm/proc-*.S files that get copied over the current locations > if implemented? As __kuser_get_tls varies by only ones instruction, I don't think there's any point doing anything other than a single word write, at the point where the HWCAP is set, with its initial value being the !HAS_TLS_REG instruction. For other things like __switch_to and maybe cache maintenance calls, dmb() etc, I'd suggest first doing a generic asm mechanism like x86's "alternatives", keeping in mind that one of the alternatives has to be XIP friendly. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
On Wed, 23 Jun 2010, Jamie Lokier wrote: > For other things like __switch_to and maybe cache maintenance calls, > dmb() etc, I'd suggest first doing a generic asm mechanism like x86's > "alternatives", keeping in mind that one of the alternatives has to be > XIP friendly. You cannot be XIP friendly unless you rewrite the concerned function(s) into a RAM page in order to modify it. And then of course you have to play tricks with the linker so that the rewritten functions are referenced with their final rewritten location. And that means of course that the RAM location has to be a constant unless we introduce some indirect function calls. And at that point we're not much better than the proposed runtime test. Also, if you are interested by a XIP kernel, this usually means you have a fairly highly customized kernel config. In this context it is senseless to have runtime patching of the kernel. What you want in that case is as much stuff as possible selected and optimized at compile time, and anything you don't need configured out. So it would be best if dynamic function patching could be statically generated from the same source when XIP is active. Nicolas -- 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 05/12] OMAP: create omap_devices for MPU, DSP, L3
"Gopinath, Thara" writes:
>>>-Original Message-
>>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>>Sent: Thursday, June 17, 2010 5:47 AM
>>>To: linux-omap@vger.kernel.org
>>>Cc: Menon, Nishanth; Gopinath, Thara; Cousson, Benoit
>>>Subject: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
>>>
>>>Create simple omap_devices for the main processors and busses.
>>>
>>>This is required to support the forth-coming device-based OPP
>>>approach, where OPPs are managed and tracked at the omap_device and
>>>hwmod level.
>>>
>>>Because these omap_devices are based on platform_devices, they cannot
>>>be created until the driver core has been initialized. Therefore, move
>>>the init of these into a device_initcall(). Also, OMAP PM init cannot
>>>be done until after this step as it depends on the OPP layer.
>>>
>>>Signed-off-by: Kevin Hilman
[...]
>>>+
>>>+static int __init omap2_late_common_init(void)
>>>+{
>>>+omap_init_processor_devices();
>>>+
>>> /* initialize the opp table if board file has not done so */
>>> omap3_pm_init_opp_table();
>>>
>>>+omap_pm_if_init();
>>>+
>>>+return 0;
>>>+}
>>>+device_initcall(omap2_late_common_init);
> Hello Kevin,
>
> Any particular reason for making this a late init and not keeping
> this a part of init_common_hw? The reason is the board files also
> have an option of calling/ overriding omap3_pm_init_opp_table. This
> happens really early in init_irq. (Refer board_3430sdp.c). So if a
> board file calls into omap3_pm_init_opp_table, the opp
> initializations will happen before the omap_device pointers are
> build for mpu, iva and l3. So the dev pointers stored as part of
> dev_opp tables will be screwed up. My personal preference would be
> to call the omap_init_processor_devices just after
> hwmod_late_init. This will remove any race conditions as above.
I agree, I changed this yesterday and the current pm-wip/hwmods is
doing exactly this.
The initial reason for the late initcall was because omap_device_build
creates platform_devices and devices, but the driver core was not
yet initialized at this point.
To fix, I now create these devices as early platform devices so that
the init sequence can remain the same.
I'll be posting an updated version of this series today.
Kevin
--
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 05/12] OMAP: create omap_devices for MPU, DSP, L3
>>-Original Message-
>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>Sent: Wednesday, June 23, 2010 8:19 PM
>>To: Gopinath, Thara
>>Cc: linux-omap@vger.kernel.org; Menon, Nishanth; Cousson, Benoit
>>Subject: Re: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
>>
>>"Gopinath, Thara" writes:
>>
>-Original Message-
>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: Thursday, June 17, 2010 5:47 AM
>To: linux-omap@vger.kernel.org
>Cc: Menon, Nishanth; Gopinath, Thara; Cousson, Benoit
>Subject: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
>
>Create simple omap_devices for the main processors and busses.
>
>This is required to support the forth-coming device-based OPP
>approach, where OPPs are managed and tracked at the omap_device and
>hwmod level.
>
>Because these omap_devices are based on platform_devices, they cannot
>be created until the driver core has been initialized. Therefore, move
>the init of these into a device_initcall(). Also, OMAP PM init cannot
>be done until after this step as it depends on the OPP layer.
>
>Signed-off-by: Kevin Hilman
>>[...]
>>
>+
>+static int __init omap2_late_common_init(void)
>+{
>+ omap_init_processor_devices();
>+
> /* initialize the opp table if board file has not done so */
> omap3_pm_init_opp_table();
>
>+ omap_pm_if_init();
>+
>+ return 0;
>+}
>+device_initcall(omap2_late_common_init);
>>> Hello Kevin,
>>>
>>> Any particular reason for making this a late init and not keeping
>>> this a part of init_common_hw? The reason is the board files also
>>> have an option of calling/ overriding omap3_pm_init_opp_table. This
>>> happens really early in init_irq. (Refer board_3430sdp.c). So if a
>>> board file calls into omap3_pm_init_opp_table, the opp
>>> initializations will happen before the omap_device pointers are
>>> build for mpu, iva and l3. So the dev pointers stored as part of
>>> dev_opp tables will be screwed up. My personal preference would be
>>> to call the omap_init_processor_devices just after
>>> hwmod_late_init. This will remove any race conditions as above.
>>
>>I agree, I changed this yesterday and the current pm-wip/hwmods is
>>doing exactly this.
>>
>>The initial reason for the late initcall was because omap_device_build
>>creates platform_devices and devices, but the driver core was not
>>yet initialized at this point.
>>
>>To fix, I now create these devices as early platform devices so that
>>the init sequence can remain the same.
>>
>>I'll be posting an updated version of this series today.
But then early platform devices do not create a dev pointer. So you do two
initializations, eh?
Regards
Thara
--
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 06/11] staging: ti dspbridge: add generic utilities
On Wed, Jun 23, 2010 at 4:02 PM, Ohad Ben-Cohen wrote:
> Add TI's DSP Bridge generic utilities driver sources
> Signed-off-by: Andy Shevchenko
> +++ b/drivers/staging/tidspbridge/gen/uuidutil.c
Following part could be significantly simplified
> +/*
> + * htoi
> + * Purpose:
> + * Converts a hex value to a decimal integer.
> + */
> +/*
> + * uuid_uuid_from_string
> + * Purpose:
> + * Converts a string to a struct dsp_uuid.
> + */
There is a code (because I am already in s-o-b list I just put here
the excerpts, however, I could prepare patch in standard form, if you
want to)
static s32 uuid_hex_to_bin(char *buf, s32 len)
{
s32 i;
s32 result = 0;
for (i = 0; i < len; i++) {
value = hex_to_bin(*buf++);
result *= 16;
if (value > 0)
result += value;
}
return result;
}
void uuid_uuid_from_string(IN char *pszUuid, OUT struct dsp_uuid *uuid_obj)
{
s32 j;
uuid_obj->ul_data1 = uuid_hex_to_bin(pszUuid, 8);
pszUuid += 8;
/* Step over underscore */
pszUuid++;
uuid_obj->us_data2 = (u16) uuid_hex_to_bin(pszUuid, 4);
pszUuid += 4;
/* Step over underscore */
pszUuid++;
uuid_obj->us_data3 = (u16) uuid_hex_to_bin(pszUuid, 4);
pszUuid += 4;
/* Step over underscore */
pszUuid++;
uuid_obj->uc_data4 = (u8) uuid_hex_to_bin(pszUuid, 2);
pszUuid += 2;
uuid_obj->uc_data5 = (u8) uuid_hex_to_bin(pszUuid, 2);
pszUuid += 2;
/* Step over underscore */
pszUuid++;
for (j = 0; j < 6; j++) {
uuid_obj->uc_data6[j] = (u8) uuid_hex_to_bin(pszUuid, 2);
pszUuid += 2;
}
}
--
With Best Regards,
Andy Shevchenko
--
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: pm_debug/voltage_off_while_idle has gone?
Mike Rapoport writes: > There used to be 'voltage_off_while_idle' attribute in the PM-enabled > kernels that allowed to put PMIC into OFF mode. In the current tip of > the linux-omap-pm tree this attribute seem to be gone Is there > possibility to make PMIC enter the OFF mode when suspending to RAM? Hi Mike, We are currently in the middle of a major rewrite of the SmartReflex and voltage layers of the PM branch. The previous voltage-related work (like voltage_off_while_idle) are still available in the pm-vc branch of my tree, but are not currently merged with the new voltage work due to conflicts. For this particular feature, I suspect you could just apply the first patch in my pm-vc branch to add back this feature. Let me know if that works, Kevin -- 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 05/12] OMAP: create omap_devices for MPU, DSP, L3
"Gopinath, Thara" writes:
>>>-Original Message-
>>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>>Sent: Wednesday, June 23, 2010 8:19 PM
>>>To: Gopinath, Thara
>>>Cc: linux-omap@vger.kernel.org; Menon, Nishanth; Cousson, Benoit
>>>Subject: Re: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
>>>
>>>"Gopinath, Thara" writes:
>>>
>>-Original Message-
>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>Sent: Thursday, June 17, 2010 5:47 AM
>>To: linux-omap@vger.kernel.org
>>Cc: Menon, Nishanth; Gopinath, Thara; Cousson, Benoit
>>Subject: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
>>
>>Create simple omap_devices for the main processors and busses.
>>
>>This is required to support the forth-coming device-based OPP
>>approach, where OPPs are managed and tracked at the omap_device and
>>hwmod level.
>>
>>Because these omap_devices are based on platform_devices, they cannot
>>be created until the driver core has been initialized. Therefore, move
>>the init of these into a device_initcall(). Also, OMAP PM init cannot
>>be done until after this step as it depends on the OPP layer.
>>
>>Signed-off-by: Kevin Hilman
>>>[...]
>>>
>>+
>>+static int __init omap2_late_common_init(void)
>>+{
>>+ omap_init_processor_devices();
>>+
>> /* initialize the opp table if board file has not done so */
>> omap3_pm_init_opp_table();
>>
>>+ omap_pm_if_init();
>>+
>>+ return 0;
>>+}
>>+device_initcall(omap2_late_common_init);
Hello Kevin,
Any particular reason for making this a late init and not keeping
this a part of init_common_hw? The reason is the board files also
have an option of calling/ overriding omap3_pm_init_opp_table. This
happens really early in init_irq. (Refer board_3430sdp.c). So if a
board file calls into omap3_pm_init_opp_table, the opp
initializations will happen before the omap_device pointers are
build for mpu, iva and l3. So the dev pointers stored as part of
dev_opp tables will be screwed up. My personal preference would be
to call the omap_init_processor_devices just after
hwmod_late_init. This will remove any race conditions as above.
>>>
>>>I agree, I changed this yesterday and the current pm-wip/hwmods is
>>>doing exactly this.
>>>
>>>The initial reason for the late initcall was because omap_device_build
>>>creates platform_devices and devices, but the driver core was not
>>>yet initialized at this point.
>>>
>>>To fix, I now create these devices as early platform devices so that
>>>the init sequence can remain the same.
>>>
>>>I'll be posting an updated version of this series today.
>
> But then early platform devices do not create a dev pointer. So you do
> two initializations, eh?
The early platform_device indeed has a struct device (it is a struct
inside the platfor_device.) The difference is that the struct device
has not been fully initialized (no device_add() has been called.)
For our purposes here, that is perfectly OK, as all that matters is that
there is a unique pointer to be used in the OPP layer.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] OMAP3: PM: Adding voltage driver support for OMAP3
Thara Gopinath writes:
> This patch adds voltage driver support for OMAP3. The driver
> allows configuring the voltage controller and voltage
> processors during init and exports APIs to enable/disable
> voltage processors, scale voltage and reset voltage.
> The driver also maintains the global voltage table on a per
> VDD basis which contains the various voltages supported by the
> VDD along with per voltage dependent data like smartreflex
> n-target value, errminlimit and voltage processor errorgain.
> The driver allows scaling of VDD voltages either through
> "vc bypass method" or through "vp forceupdate method" the
> choice being configurable through the board file.
>
> This patch contains code originally in linux omap pm branch
> smartreflex driver. Major contributors to this driver are
> Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
> Nishant Menon, Kevin Hilman.
>
> Signed-off-by: Thara Gopinath
First some general comments:
I thought we had agreed that all the internal functions should not
need to take a VDD ID, but instead they could be just passed a
vdd_info pointer.
I would greatly improve readability to see all usage of
vdd_info[vdd_id] go away.
In the exported functions that take vdd_id as an argument, just do
something like
struct omap_vdd_info *vdd = vdd_info[vdd_id];
at the beginning, then replace all the instances of vdd_info[vdd_id]
with 'vdd->'
In the rest of the internal functions, make them take the pointer as
the argument instead of the id.
Also, we have a bunch of stuff in the current pm-vc branch which allows
boards to override settings. Are you planning to address that in this
series? or is Lesly going to continue that work?
Some other comments below...
> ---
> arch/arm/mach-omap2/Makefile |3 +-
> arch/arm/mach-omap2/voltage.c | 1059
> +
> arch/arm/mach-omap2/voltage.h | 123 +
> 3 files changed, 1184 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-omap2/voltage.c
> create mode 100644 arch/arm/mach-omap2/voltage.h
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index e975b43..e4c660d 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -46,7 +46,8 @@ obj-$(CONFIG_ARCH_OMAP2)+= sdrc2xxx.o
> ifeq ($(CONFIG_PM),y)
> obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
> obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
> -obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
> +obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o \
> +voltage.o
> obj-$(CONFIG_PM_DEBUG) += pm-debug.o
>
> AFLAGS_sleep24xx.o :=-Wa,-march=armv6
> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
> new file mode 100644
> index 000..657e322
> --- /dev/null
> +++ b/arch/arm/mach-omap2/voltage.c
> @@ -0,0 +1,1059 @@
> +/*
> + * OMAP3/OMAP4 Voltage Management Routines
> + *
> + * Author: Thara Gopinath
> + *
> + * Copyright (C) 2007 Texas Instruments, Inc.
> + * Rajendra Nayak
> + * Lesly A M
> + *
> + * Copyright (C) 2008 Nokia Corporation
> + * Kalle Jokiniemi
> + *
> + * Copyright (C) 2010 Texas Instruments, Inc.
> + * Thara Gopinath
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "prm-regbits-34xx.h"
> +#include "voltage.h"
> +
> +#define VP_IDLE_TIMEOUT 200
> +#define VP_TRANXDONE_TIMEOUT 300
> +
> +/* PRM voltage module */
> +u32 volt_mod;
should be static
> +/* Voltage processor register offsets */
> +struct vp_reg_offs {
> + u8 vpconfig_reg;
> + u8 vstepmin_reg;
> + u8 vstepmax_reg;
> + u8 vlimitto_reg;
> + u8 status_reg;
> + u8 voltage_reg;
> +};
Minor issue, but the _reg suffix is not really needed on all these
names.
[...]
> +
> +/* Generic voltage init functions */
> +static void __init init_voltageprocesor(int vp_id)
was mystified why I wasn't finding this function when grepping and
discovered there should be two 's's in processor in this function name.
[...]
> diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
[...]
For the naming, rather than the long names voltagecontroller,
voltageprocessor, I'd suggest just using vc and vp. For the external
functions, they can have the omap_ prefix.
> +unsigned long omap_voltageprocessor_get_curr_volt(int vp_id);
> +void omap_voltageprocessor_enable(int vp_id);
> +void omap_voltageprocessor_disable(int vp_id);
these should be omap_vp_*
> +int omap_voltage_scale(int vdd, unsigned long target_volt);
> +void omap_reset_vol
[PATCH] select NOP_USB_XCEIV for OMAP4
Add select statement to force selection of NOP_USB_XCEIV for OMAP4. Signed-off-by: David Anders --- drivers/usb/musb/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index cfd38ed..e4624bc 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,6 +11,7 @@ config USB_MUSB_HDRC depends on (USB || USB_GADGET) depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if ARCH_OMAP4 select TWL4030_USB if MACH_OMAP_3430SDP select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' -- 1.6.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] OMAP3: PM: Adding voltage driver support for OMAP3
Thara Gopinath writes:
> This patch adds voltage driver support for OMAP3. The driver
> allows configuring the voltage controller and voltage
> processors during init and exports APIs to enable/disable
> voltage processors, scale voltage and reset voltage.
> The driver also maintains the global voltage table on a per
> VDD basis which contains the various voltages supported by the
> VDD along with per voltage dependent data like smartreflex
> n-target value, errminlimit and voltage processor errorgain.
> The driver allows scaling of VDD voltages either through
> "vc bypass method" or through "vp forceupdate method" the
> choice being configurable through the board file.
>
> This patch contains code originally in linux omap pm branch
> smartreflex driver. Major contributors to this driver are
> Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
> Nishant Menon, Kevin Hilman.
>
> Signed-off-by: Thara Gopinath
[...]
> +/**
> + * get_curr_vdd_voltage : Gets the current non-auto-compensated voltage
> + * @vdd : the VDD for which current voltage info is needed
> + *
> + * API to get the current non-auto-compensated voltage for a VDD.
> + * Returns 0 in case of error else returns the current voltage for the VDD.
> + */
> +unsigned long get_curr_voltage(int vdd)
> +{
> + struct omap_opp *opp;
> + unsigned long freq;
> +
> + if (check_voltage_domain(vdd)) {
> + pr_warning("%s: VDD %d does not exist!\n", __func__, vdd);
> + return 0;
> + }
> +
> + freq = vdd_info[vdd].volt_clk->rate;
> + opp = opp_find_freq_ceil(vdd_info[vdd].opp_type, &freq);
> + if (IS_ERR(opp)) {
> + pr_warning("%s: Unable to find OPP for VDD%d freq%ld\n",
> + __func__, vdd + 1, freq);
> + return 0;
> + }
> +
> + /*
> + * Use higher freq voltage even if an exact match is not available
> + * we are probably masking a clock framework bug, so warn
> + */
> + if (unlikely(freq != vdd_info[vdd].volt_clk->rate))
> + pr_warning("%s: Available freq %ld != dpll freq %ld.\n",
> + __func__, freq, vdd_info[vdd].volt_clk->rate);
> +
> + return opp_get_voltage(opp);
> +}
Rather than having to do an OPP lookup each time based on current clock
rate, why not just store the current voltage into vdd_info and
update it whenever it changes. This function could then just return
that value.
Kevin
--
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/8] OMAP3: PM: Adding smartreflex driver support.
Thara Gopinath writes:
> SmartReflex modules do adaptive voltage control for real-time
> voltage adjustments. With Smartreflex the power supply voltage
> can be adapted to the silicon performance(manufacturing process,
> temperature induced performance, age induced performance etc).
>
> There are differnet classes of smartreflex implementation.
> Class-0: Manufacturing Test Calibration
> Class-1: Boot-Time Software Calibration
> Class-2: Continuous Software Calibration
> Class-3: Continuous Hardware Calibration
> Class-4: Fully Integrated Power Management
>
> OMAP3 has two smartreflex modules one associated with VDD1 and the
> other associated with VDD2.
> This patch adds support for smartreflex driver. The driver is designed
> for Class-1 , Class-2 and Class-3 support and is a platform driver.
> Smartreflex driver can be enabled through a Kconfig option
> "SmartReflex support" under "System type"->"TI OMAP implementations" menu.
>
> Smartreflex autocompensation feature can be enabled runtime through
> a debug fs option.
> To enable smartreflex autocompensation feature
> echo 1 > /debugfs/pm_debug/Smartreflex/SR/autocomp
> To disable smartreflex autocompensation feature
> echo 0 > /debugfs/pm_debug/Smartreflex/SR/autocomp
>
> This patch contains code originally in linux omap pm branch.
> Major contributors to this driver are
> Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
> Nishant Menon, Kevin Hilman.
>
> Signed-off-by: Thara Gopinath
> ---
> arch/arm/mach-omap2/Makefile |1 +
> arch/arm/mach-omap2/pm-debug.c|3 +-
> arch/arm/mach-omap2/smartreflex.c | 934
> +
[...]
> diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
> index 6cac981..4280006 100644
> --- a/arch/arm/mach-omap2/pm-debug.c
> +++ b/arch/arm/mach-omap2/pm-debug.c
> @@ -162,7 +162,7 @@ void omap2_pm_dump(int mode, int resume, unsigned int us)
>
> static void pm_dbg_regset_store(u32 *ptr);
>
> -struct dentry *pm_dbg_dir;
> +struct dentry *pm_dbg_dir, *pm_dbg_main_dir;
>
> static int pm_dbg_init_done;
>
> @@ -606,6 +606,7 @@ static int __init pm_dbg_init(void)
> &sleep_while_idle, &pm_dbg_option_fops);
> (void) debugfs_create_file("wakeup_timer_seconds", S_IRUGO | S_IWUGO, d,
> &wakeup_timer_seconds, &pm_dbg_option_fops);
> + pm_dbg_main_dir = d;
> pm_dbg_init_done = 1;
>
> return 0;
Not clear what this change is doing in this patch. I think this belongs
with PATCH 8/8.
Kevin
--
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: On the APIs for Enabling and Disabling Wakeup capability.
"Basak, Partha" writes: > Benoit/Kevin, > >> -Original Message- >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >> Sent: Friday, June 18, 2010 8:29 PM >> To: Kalliguddi, Hema >> Cc: Cousson, Benoit; Basak, Partha; p...@pwsan.com; Nayak, Rajendra; >> linux-omap@vger.kernel.org >> Subject: Re: On the APIs for Enabling and Disabling Wakeup capability. >> >> "Kalliguddi, Hema" writes: >> >> > Hi Benoit, >> > >> > I have 2 cases in usb for the need of separate API for setting the auto >> idle bit. >> > >> > 1. Below the link for omap3430TRM. Please refer 24.1.5.4.2 and >> 24.1.5.4.3 there is note not to set smart >> > idle and autoidle bit simultaneously. Suggestion is to set the auto idle >> 0 before setting smart idle. Then set to 1. >> >> Maybe this sequence should be enforced by the hwmod code itself, >> rather than the knowledge living in the driver. >> >> However, based on the errata below, auto-idle will always be zero so >> the there should be no conflict in setting smart-idle and auto-idle >> simultaneously today. >> >> > This applicable for omap4 as well. I don't have the omap4430 pblic TRM >> to share. >> > http://focus.ti.com/pdfs/wtbu/SWPU223D_Final_EPDF_06_07_2010.pdf >> > >> > 2. There is a Errata in OMAP3 errata #1.59 that If auto idle is set then >> the USB can't wakeup the system by >> > usb external events. The suggested workaround is to disable the autoIdle >> for omap3. >> >> This one could be handled at init time in usb-musb.c by setting >> HWMOD_NO_OCP_AUTOIDLE for the hwmod with a comment summarizing this >> errata. >> >> Note also that Errata 1.166 is another one related to MUSB auto-idle >> and we have a workaround in the PM branch to ensure that MUSB >> auto-idle is disabled in the idle path since it may be re-enabled >> after an off-mode transition. >> > Few questions: > 1. Are you mentioning about the following patch: > http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=865f0e0b1dd25899fe30eee5c8f1dba420eea177? No, this is a totally unrelated problem related to a specific init sequene. > Though this patch allows clearing of AutoIdle bit(signified by > HWMOD_INIT_NO_IDLE) while remaining in Idle state, it does not allow > the reverse, i.e. setting back the AutoIdle bit, while still remaining > in Idle state. The use-case for setting the auto-idle bit while leaving the device in idle have not been described. > 2. Changing the hwmod flags (oh->flags) is acceptable in run-time. Correct? For errata workarounds, in device/SoC init code yes. In drivers, no. Drivers should not have any knowledge of hwmod internals. > 3. I believe, SysConfig settings have been a tricky area because of > different h/w-errata. Instead of looking into particular errata, as > and when they come in time to time and explore how to fit them in the > framework, would it not be more useful to provide a more generic > framework to operate on the SysConfig settings? Of course, as you > suggested, the preferred approach would be to absorb the changes in > the omap_device/hw-mod layer as much as possible. But unfortunately, > that may not be sufficient in all situations. For this kind of thing, I strongly prefer to better understand the specific errata that require the special settings. History suggests that having an API to modify sysconfig means it would get used not just for errata workarounds but also because "it doesn't work unless I do this." We *really* need to better understand the reasons behind these special cases. Kevin -- 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] select NOP_USB_XCEIV for OMAP4
David Anders writes: > Add select statement to force selection of NOP_USB_XCEIV for OMAP4. > > Signed-off-by: David Anders > --- > drivers/usb/musb/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig > index cfd38ed..e4624bc 100644 > --- a/drivers/usb/musb/Kconfig > +++ b/drivers/usb/musb/Kconfig > @@ -11,6 +11,7 @@ config USB_MUSB_HDRC > depends on (USB || USB_GADGET) > depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523)) > select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) > + select NOP_USB_XCEIV if ARCH_OMAP4 > select TWL4030_USB if MACH_OMAP_3430SDP > select USB_OTG_UTILS > tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' Shouldn't this be a board-specific option, and not set for every OMAP4-based config? Kevin -- 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] select NOP_USB_XCEIV for OMAP4
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Wednesday, June 23, 2010 3:33 PM > To: Anders, David > Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Gupta, Ajay > Kumar; felipe.ba...@nokia.com > Subject: Re: [PATCH] select NOP_USB_XCEIV for OMAP4 > > David Anders writes: > > > Add select statement to force selection of NOP_USB_XCEIV for OMAP4. > > > > Signed-off-by: David Anders > > --- > > drivers/usb/musb/Kconfig |1 + > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig > > index cfd38ed..e4624bc 100644 > > --- a/drivers/usb/musb/Kconfig > > +++ b/drivers/usb/musb/Kconfig > > @@ -11,6 +11,7 @@ config USB_MUSB_HDRC > > depends on (USB || USB_GADGET) > > depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523)) > > select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) > > + select NOP_USB_XCEIV if ARCH_OMAP4 > > select TWL4030_USB if MACH_OMAP_3430SDP > > select USB_OTG_UTILS > > tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' > > Shouldn't this be a board-specific option, and not set for every > OMAP4-based config? > As I understand it, any of the omap4 devices that are using the Inventra need to have at a minimum of the NOP USB Transceiver. Enabling the NOP transceiver doesn't preclude the use of other external transceivers. The NOP USB Transceiver will still need to be registered in the board-specific machine file therefore doesn't impact a board that doesn't use it. Dave -- 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] select NOP_USB_XCEIV for OMAP4
Op 23 jun 2010, om 22:33 heeft Kevin Hilman het volgende geschreven: > David Anders writes: > >> Add select statement to force selection of NOP_USB_XCEIV for OMAP4. >> >> Signed-off-by: David Anders >> --- >> drivers/usb/musb/Kconfig |1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig >> index cfd38ed..e4624bc 100644 >> --- a/drivers/usb/musb/Kconfig >> +++ b/drivers/usb/musb/Kconfig >> @@ -11,6 +11,7 @@ config USB_MUSB_HDRC >> depends on (USB || USB_GADGET) >> depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523)) >> select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) >> +select NOP_USB_XCEIV if ARCH_OMAP4 >> select TWL4030_USB if MACH_OMAP_3430SDP >> select USB_OTG_UTILS >> tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' > > Shouldn't this be a board-specific option, and not set for every > OMAP4-based config? If that's true, why do the davinci and blackfin archs force it? regards, Koen -- 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] select NOP_USB_XCEIV for OMAP4
Hello. David Anders wrote: Add select statement to force selection of NOP_USB_XCEIV for OMAP4. Signed-off-by: David Anders [...] diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index cfd38ed..e4624bc 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,6 +11,7 @@ config USB_MUSB_HDRC depends on (USB || USB_GADGET) depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if ARCH_OMAP4 But where usb_nop_xceiv_register() is called? WBR, Sergei -- 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] select NOP_USB_XCEIV for OMAP4
Hello. Koen Kooi wrote: Add select statement to force selection of NOP_USB_XCEIV for OMAP4. Signed-off-by: David Anders --- drivers/usb/musb/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index cfd38ed..e4624bc 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,6 +11,7 @@ config USB_MUSB_HDRC depends on (USB || USB_GADGET) depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if ARCH_OMAP4 select TWL4030_USB if MACH_OMAP_3430SDP select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' Shouldn't this be a board-specific option, and not set for every OMAP4-based config? If that's true, why do the davinci and blackfin archs force it? DaVincis have an integrated transceiver. WBR, Sergei -- 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 11/11] staging: ti dspbridge: enable driver building
On Wed, Jun 23, 2010 at 04:14:00PM +0300, Ohad Ben-Cohen wrote: > From: Omar Ramirez Luna > > Add Kconfig + Makefile for TI's DSP Bridge driver > and expose it to the staging menu. > > Signed-off-by: Omar Ramirez Luna > Signed-off-by: Kanigeri, Hari > Signed-off-by: Ameya Palande > Signed-off-by: Guzman Lugo, Fernando > Signed-off-by: Hebbar, Shivananda > Signed-off-by: Ramos Falcon, Ernesto > Signed-off-by: Felipe Contreras > Signed-off-by: Anna, Suman > Signed-off-by: Gupta, Ramesh > Signed-off-by: Gomez Castellanos, Ivan > Signed-off-by: Andy Shevchenko > Signed-off-by: Armando Uribe De Leon > Signed-off-by: Deepak Chitriki > Signed-off-by: Menon, Nishanth > Signed-off-by: Phil Carmody > Signed-off-by: Ohad Ben-Cohen > --- > drivers/staging/Kconfig |2 + > drivers/staging/Makefile |1 + > drivers/staging/tidspbridge/Kconfig | 88 > ++ > drivers/staging/tidspbridge/Makefile | 34 + > 4 files changed, 125 insertions(+), 0 deletions(-) > create mode 100644 drivers/staging/tidspbridge/Kconfig > create mode 100644 drivers/staging/tidspbridge/Makefile > > > diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig > index 3de4bca..c9e8215 100644 > --- a/drivers/staging/Kconfig > +++ b/drivers/staging/Kconfig > @@ -153,5 +153,9 @@ source "drivers/staging/easycap/Kconfig" > > source "drivers/staging/solo6x10/Kconfig" > > +source "drivers/staging/tidspbridge/Kconfig" > + > +source "drivers/staging/tidspbridge/Kconfig" > + > endif # !STAGING_EXCLUDE_BUILD > endif # STAGING > diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile > index b28d820..952b64e 100644 > --- a/drivers/staging/Makefile > +++ b/drivers/staging/Makefile > @@ -57,3 +57,4 @@ obj-$(CONFIG_TOUCHSCREEN_MRSTOUCH) += mrst-touchscreen/ > obj-$(CONFIG_MSM_STAGING)+= msm/ > obj-$(CONFIG_EASYCAP)+= easycap/ > obj-$(CONFIG_SOLO6X10) += solo6x10/ > +obj-$(CONFIG_TIDSPBRIDGE)+= tidspbridge/ > diff --git a/drivers/staging/tidspbridge/Kconfig > b/drivers/staging/tidspbridge/Kconfig > new file mode 100644 > index 000..37fa2b1 > --- /dev/null > +++ b/drivers/staging/tidspbridge/Kconfig > @@ -0,0 +1,88 @@ > +# > +# DSP Bridge Driver Support > +# > + > +menuconfig TIDSPBRIDGE > + tristate "DSP Bridge driver" > + default n The default is always 'n' so you don't need this. Also, this enables the driver to be built on x86, which fails horribly, and I don't think is what you really want to have happen :) So I need some more Kconfig changes here, care to redo just this one patch? I've applied all the others and they will show up in linux-next tomorrow. thanks, greg k-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: [PATCH] select NOP_USB_XCEIV for OMAP4
On 6/23/2010 4:10 PM, Anders, David wrote: Shouldn't this be a board-specific option, and not set for every OMAP4-based config? As I understand it, any of the omap4 devices that are using the Inventra need to have at a minimum of the NOP USB Transceiver. Enabling the NOP transceiver doesn't preclude the use of other external transceivers. The NOP USB Transceiver will still need to be registered in the board-specific machine file therefore doesn't impact a board that doesn't use it. The OMAP4 TRM states: "The high-speed USB OTG controller supports a single USB port, which uses the ULPI interface mode, to connect to an off-chip transceiver (12-pin/8-bit data SDR mode) and to connect on D+/D- (+ID) USB bus thanks to an embedded USB-HS OTG PHY." So I read this as you can use either the on-chip PHY or an external PHY. Therefore, if you did opt to use an external PHY I am not sure I understand why the NOP transceiver I still needed. The OMAP4 an external configuration looks the same as OMAP3 to me... Cheers Jon -- 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] select NOP_USB_XCEIV for OMAP4
On 6/23/2010 4:12 PM, Koen Kooi wrote: Shouldn't this be a board-specific option, and not set for every OMAP4-based config? If that's true, why do the davinci and blackfin archs force it? DaVinci only has an internal PHY, I don't think that there is anyway to use an external PHY with DaVinci like you can with OMAP4. Not sure about blackfin... Jon -- 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] select NOP_USB_XCEIV for OMAP4
Koen Kooi wrote: > Op 23 jun 2010, om 22:33 heeft Kevin Hilman het volgende geschreven: > > David Anders writes: > > > >> Add select statement to force selection of NOP_USB_XCEIV for OMAP4. > >> > >> Signed-off-by: David Anders > >> --- > >> drivers/usb/musb/Kconfig |1 + > >> 1 files changed, 1 insertions(+), 0 deletions(-) > >> > >> diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig > >> index cfd38ed..e4624bc 100644 > >> --- a/drivers/usb/musb/Kconfig > >> +++ b/drivers/usb/musb/Kconfig > >> @@ -11,6 +11,7 @@ config USB_MUSB_HDRC > >>depends on (USB || USB_GADGET) > >>depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523)) > >>select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) > >> + select NOP_USB_XCEIV if ARCH_OMAP4 > >>select TWL4030_USB if MACH_OMAP_3430SDP > >>select USB_OTG_UTILS > >>tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' > > > > Shouldn't this be a board-specific option, and not set for every > > OMAP4-based config? > > If that's true, why do the davinci and blackfin archs force it? > Kevin's right. For OMAP4 at least, this is something that is probably' best left up to the board to select. For the davinci's and blackfins, they don't have an option. They have a fully transparent internal PHY which doesn't need any configuring. However, with the OMAP4, you could potentially use an external ULPI transceiver. This can be another transparent PHY for which we could select the NOP_XCEIV. Or it could be something like the PHY in the TWL5030 which may need configuring over an I2C interface. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] OMAP: add runtime PM support at bus-level
This series introduces runtime PM support at the platform bus level for OMAP. In a nutshell, when using the runtime PM API for any device with an assocated omap_device (and hwmod), the omap device API will be used to handle the hardware-level power management of that device, including managing clocks, etc. Today, most drivers handle this by manually enabling/disabling their clocks when needed. With this series (and an omap_device/hwmod for each device) direct clock managment can be removed from the driver in favor of using the runtime PM API. This series applies on top v2.6.35-rc2 + Tony's omap-fixes branch and is also available in the pm-wip/runtime branch of my linux-omap-pm git tree: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Kevin Hilman (3): OMAP: PM: initial runtime PM core support OMAP: PM: use omap_device API for suspend/resume OMAP1: PM: add simple runtime PM layer to manage clocks arch/arm/mach-omap1/Makefile |2 +- arch/arm/mach-omap1/pm_bus.c | 77 arch/arm/mach-omap2/Makefile |7 ++- arch/arm/mach-omap2/pm_bus.c | 133 ++ 4 files changed, 217 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap1/pm_bus.c create mode 100644 arch/arm/mach-omap2/pm_bus.c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP: PM: initial runtime PM core support
Implement the new runtime PM framework as a thin layer on top of the
omap_device API. Since we don't have an OMAP-specific bus, override
the runtime PM hooks for the platform_bus for the OMAP specific
implementation.
While the runtime PM API has three main states (idle, suspend, resume)
This version treats idle and suspend the same way by implementing both
on top of omap_device_disable(), which follows closely with how driver
are currently using clock enable/disable calls. Longer-termm
pm_runtime_idle() could take other constraints into consideration to
make the decision, but the current
Device driver ->runtime_suspend() hooks are called just before the
device is disabled (via omap_device_idle()), and device driver
->runtime_resume() hooks are called just after device has been
enabled (via omap_device_enable().)
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/Makefile |7 +++-
arch/arm/mach-omap2/pm_bus.c | 72 ++
2 files changed, 78 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/pm_bus.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ea52b03..8ed47ea 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -46,12 +46,17 @@ obj-$(CONFIG_ARCH_OMAP2)+= sdrc2xxx.o
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o \
+ pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
+ifeq ($(CONFIG_PM_VERBOSE),y)
+CFLAGS_pm_bus.o+= -DDEBUG
+endif
+
endif
# PRCM
diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
new file mode 100644
index 000..69acaa5
--- /dev/null
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -0,0 +1,72 @@
+/*
+ * Runtime PM support code for OMAP
+ *
+ * Author: Kevin Hilman, Deep Root Systems, LLC
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#ifdef CONFIG_PM_RUNTIME
+int platform_pm_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *odev = to_omap_device(pdev);
+ int r, ret = 0;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ if (dev->driver->pm && dev->driver->pm->runtime_suspend)
+ ret = dev->driver->pm->runtime_suspend(dev);
+ if (!ret && omap_device_is_valid(odev)) {
+ r = omap_device_idle(pdev);
+ WARN_ON(r);
+ }
+
+ return ret;
+};
+
+int platform_pm_runtime_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *odev = to_omap_device(pdev);
+ int r, ret = 0;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ if (omap_device_is_valid(odev)) {
+ r = omap_device_enable(pdev);
+ WARN_ON(r);
+ }
+
+ if (dev->driver->pm && dev->driver->pm->runtime_resume)
+ ret = dev->driver->pm->runtime_resume(dev);
+
+ return ret;
+};
+
+int platform_pm_runtime_idle(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *odev = to_omap_device(pdev);
+ int ret;
+
+ ret = pm_runtime_suspend(dev);
+ dev_dbg(dev, "%s [%d]\n", __func__, ret);
+
+ return 0;
+};
+#endif /* CONFIG_PM_RUNTIME */
+
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] OMAP: PM: use omap_device API for suspend/resume
Hook into the platform bus methods for suspend and resume and
use the omap_device API to automatically idle and enable the
device on suspend and resume.
This allows device drivers to get rid of direct management of their
clocks in their suspend/resume paths, and let omap_device do it for
them.
We currently use the _noirq (late suspend, early resume) versions of
the suspend/resume methods to ensure that the device is not disabled
too early for any drivers also using the _noirq methods.
NOTE: only works for devices with omap_hwmod support.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm_bus.c | 61 ++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
index 69acaa5..3787da8 100644
--- a/arch/arm/mach-omap2/pm_bus.c
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -70,3 +70,64 @@ int platform_pm_runtime_idle(struct device *dev)
};
#endif /* CONFIG_PM_RUNTIME */
+#ifdef CONFIG_SUSPEND
+int platform_pm_suspend_noirq(struct device *dev)
+{
+ struct device_driver *drv = dev->driver;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *odev = to_omap_device(pdev);
+ int ret = 0;
+
+ if (!drv)
+ return 0;
+
+ if (drv->pm) {
+ if (drv->pm->suspend_noirq)
+ ret = drv->pm->suspend_noirq(dev);
+ }
+
+ if (omap_device_is_valid(odev)) {
+ if (odev->flags & OMAP_DEVICE_NO_BUS_SUSPEND) {
+ dev_dbg(dev, "no automatic bus-level system resume.\n");
+ return 0;
+ }
+
+ dev_dbg(dev, "%s\n", __func__);
+ omap_device_idle(pdev);
+ } else {
+ dev_dbg(dev, "not an omap_device\n");
+ }
+
+ return ret;
+}
+
+int platform_pm_resume_noirq(struct device *dev)
+{
+ struct device_driver *drv = dev->driver;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *odev = to_omap_device(pdev);
+ int ret = 0;
+
+ if (omap_device_is_valid(odev)) {
+ if (odev->flags & OMAP_DEVICE_NO_BUS_SUSPEND) {
+ dev_dbg(dev, "no automatic bus-level system resume.\n");
+ return 0;
+ }
+
+ dev_dbg(dev, "%s\n", __func__);
+ omap_device_enable(pdev);
+ } else {
+ dev_dbg(dev, "not an omap_device\n");
+ }
+
+ if (!drv)
+ return 0;
+
+ if (drv->pm) {
+ if (drv->pm->resume_noirq)
+ ret = drv->pm->resume_noirq(dev);
+ }
+
+ return ret;
+}
+#endif /* CONFIG_SUSPEND */
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] OMAP1: PM: add simple runtime PM layer to manage clocks
On OMAP1, we do not have omap_device + omap_hwmod to manage the
device-specific idle, enable and shutdown. Instead, just
enable/disable device clocks automatically at the runtime PM level.
This allows drivers to not have any OMAP1 specific clock management
and allows them to simply use the runtime PM API to manage clocks.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap1/pm_bus.c | 77 ++
2 files changed, 78 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap1/pm_bus.c
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index ea231c7..fd4df71 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -12,7 +12,7 @@ obj-$(CONFIG_OMAP_MPU_TIMER) += time.o
obj-$(CONFIG_OMAP_32K_TIMER) += timer32k.o
# Power Management
-obj-$(CONFIG_PM) += pm.o sleep.o
+obj-$(CONFIG_PM) += pm.o sleep.o pm_bus.o
# DSP
obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
new file mode 100644
index 000..29d651a
--- /dev/null
+++ b/arch/arm/mach-omap1/pm_bus.c
@@ -0,0 +1,77 @@
+/*
+ * Runtime PM support code for OMAP1
+ *
+ * Author: Kevin Hilman, Deep Root Systems, LLC
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#ifdef CONFIG_PM_RUNTIME
+int platform_pm_runtime_suspend(struct device *dev)
+{
+ struct clk *iclk, *fclk;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ if (dev->driver->pm && dev->driver->pm->runtime_suspend)
+ ret = dev->driver->pm->runtime_suspend(dev);
+
+ fclk = clk_get(dev, "fck");
+ if (!IS_ERR(fclk)) {
+ clk_disable(fclk);
+ clk_put(fclk);
+ }
+
+ iclk = clk_get(dev, "ick");
+ if (!IS_ERR(iclk)) {
+ clk_disable(iclk);
+ clk_put(iclk);
+ }
+
+ return 0;
+};
+
+int platform_pm_runtime_resume(struct device *dev)
+{
+ int r, ret = 0;
+ struct clk *iclk, *fclk;
+
+ iclk = clk_get(dev, "ick");
+ if (!IS_ERR(iclk)) {
+ clk_enable(iclk);
+ clk_put(iclk);
+ }
+
+ fclk = clk_get(dev, "fck");
+ if (!IS_ERR(fclk)) {
+ clk_enable(fclk);
+ clk_put(fclk);
+ }
+
+ if (dev->driver->pm && dev->driver->pm->runtime_resume)
+ ret = dev->driver->pm->runtime_resume(dev);
+
+ return ret;
+};
+
+int platform_pm_runtime_idle(struct device *dev)
+{
+ ret = pm_runtime_suspend(dev);
+ dev_dbg(dev, "%s [%d]\n", __func__, ret);
+
+ return 0;
+};
+#endif /* CONFIG_PM_RUNTIME */
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/13] OMAP: CM, hwmod, omap_device fixes and updates
This is a series of fixes & updates mostly to hwmod and omap_device that are required for the on-going hwmod conversions and runtime PM conversion of drivers. While some of these are fixes, they are not urgent for 2.6.35 and can wait until the next merge window. This series applies on top of the runtime PM series just posted and is also available as the pm-wip/hwmods branch of my linux-omap-pm git tree: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git This has been tested with various hwmod & runtime PM conversions (UART, MMC, dmtimer) on OMAP2, OMAP3 and OMAP4. Kevin Benoit Cousson (2): OMAP: hwmod: Fix the missing braces OMAP2&3: hwmod: Remove _hwmod prefix in name string Kevin Hilman (10): OMAP24xx: CM: fix mask used for checking IDLEST status OMAP: hwmod: allow idle after HWMOD_INIT_NO_IDLE OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST OMAP: hwmod: add non-locking versions of enable and idle functions OMAP: hwmod: don't auto-disable hwmod when !CONFIG_PM_RUNTIME OMAP: omap_device: ensure hwmod tracks attached omap_device pointer OMAP: omap_device: add flag to disable automatic bus-level suspend/resume OMAP: create omap_devices for MPU, DSP, L3 OMAP: hwmod data: add class for DSP hwmods OMAP3: hwmod data: add data for OMAP3 IVA2 Rajendra Nayak (1): OMAP4: hwmod: Enable omap_device build for OMAP4 arch/arm/mach-omap2/cm.c |6 +- arch/arm/mach-omap2/devices.c |2 + arch/arm/mach-omap2/io.c | 55 ++- arch/arm/mach-omap2/omap_hwmod.c | 60 +--- arch/arm/mach-omap2/omap_hwmod_2420_data.c| 15 --- arch/arm/mach-omap2/omap_hwmod_2430_data.c| 15 --- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c| 51 ++--- arch/arm/mach-omap2/omap_hwmod_common_data.c |3 + arch/arm/mach-omap2/omap_hwmod_common_data.h |1 + arch/arm/plat-omap/Makefile |1 + arch/arm/plat-omap/include/plat/common.h |4 ++ arch/arm/plat-omap/include/plat/omap_device.h |5 ++ arch/arm/plat-omap/include/plat/omap_hwmod.h |2 + arch/arm/plat-omap/omap_device.c |8 +++- 14 files changed, 194 insertions(+), 34 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/13] OMAP24xx: CM: fix mask used for checking IDLEST status
On OMAP24xx, the polarity for the IDLEST bits is opposite of OMAP3. The mask used to check this was using the bit position instead of the bit mask. This patch fixes the problem by using the bit mask instead of the bit field. Cc: Paul Walmsley Signed-off-by: Kevin Hilman --- arch/arm/mach-omap2/cm.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/cm.c b/arch/arm/mach-omap2/cm.c index 2d83565..721c3b6 100644 --- a/arch/arm/mach-omap2/cm.c +++ b/arch/arm/mach-omap2/cm.c @@ -50,15 +50,15 @@ int omap2_cm_wait_module_ready(s16 prcm_mod, u8 idlest_id, u8 idlest_shift) cm_idlest_reg = cm_idlest_offs[idlest_id - 1]; + mask = 1 << idlest_shift; + if (cpu_is_omap24xx()) - ena = idlest_shift; + ena = mask; else if (cpu_is_omap34xx()) ena = 0; else BUG(); - mask = 1 << idlest_shift; - /* XXX should be OMAP2 CM */ omap_test_timeout(((cm_read_mod_reg(prcm_mod, cm_idlest_reg) & mask) == ena), MAX_MODULE_READY_TIME, i); -- 1.7.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/13] OMAP: hwmod: allow idle after HWMOD_INIT_NO_IDLE
If an omap_hwmod is setup using HWMOD_INIT_NO_IDLE flag, there is
currently way to idle it since omap_hwmod_idle() requires the hwmod to
be in the enabled state.
This patch adds a check to omap_hwmod_idle() so if the hwmod was has
the INIT_NO_IDLE flag, calling omap_hwmod_idle() will still succeed.
Cc: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 95c9a5f..ac75407 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -938,7 +938,13 @@ static int _enable(struct omap_hwmod *oh)
*/
static int _idle(struct omap_hwmod *oh)
{
- if (oh->_state != _HWMOD_STATE_ENABLED) {
+ /*
+* To idle, hwmod must be enabled, EXCEPT if hwmod was
+* initialized using the INIT_NO_IDLE flag. In this case it
+* will not yet be enabled so we have to allow it to be idled.
+*/
+ if ((oh->_state != _HWMOD_STATE_ENABLED) &&
+ !(oh->flags & HWMOD_INIT_NO_IDLE)) {
WARN(1, "omap_hwmod: %s: idle state can only be entered from "
"enabled state\n", oh->name);
return -EINVAL;
@@ -953,6 +959,9 @@ static int _idle(struct omap_hwmod *oh)
oh->_state = _HWMOD_STATE_IDLE;
+ /* Clear init flag which should only affect first call to idle */
+ oh->flags &= ~HWMOD_INIT_NO_IDLE;
+
return 0;
}
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/13] OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST
Since these hwmods do not have IDLEST, set the HWMOD_NO_IDLEST flag,
otherwise _enable() will fail due to failing _wait_target_ready().
Cc: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |9 ++---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |9 ++---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index e5530c5..a8b57a6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -65,7 +65,8 @@ static struct omap_hwmod omap2420_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l3_masters),
.slaves = omap2420_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l3_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
};
static struct omap_hwmod omap2420_l4_wkup_hwmod;
@@ -95,7 +96,8 @@ static struct omap_hwmod omap2420_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l4_core_masters),
.slaves = omap2420_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l4_core_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
};
/* Slave interfaces on the L4_WKUP interconnect */
@@ -115,7 +117,8 @@ static struct omap_hwmod omap2420_l4_wkup_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l4_wkup_masters),
.slaves = omap2420_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l4_wkup_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
};
/* Master interfaces on the MPU device */
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 0852d95..8b1f74b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -65,7 +65,8 @@ static struct omap_hwmod omap2430_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l3_masters),
.slaves = omap2430_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l3_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
};
static struct omap_hwmod omap2430_l4_wkup_hwmod;
@@ -97,7 +98,8 @@ static struct omap_hwmod omap2430_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l4_core_masters),
.slaves = omap2430_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l4_core_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
};
/* Slave interfaces on the L4_WKUP interconnect */
@@ -117,7 +119,8 @@ static struct omap_hwmod omap2430_l4_wkup_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l4_wkup_masters),
.slaves = omap2430_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l4_wkup_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
};
/* Master interfaces on the MPU device */
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 39b0c0e..e288b20 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -76,7 +76,8 @@ static struct omap_hwmod omap3xxx_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap3xxx_l3_masters),
.slaves = omap3xxx_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l3_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
};
static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
@@ -106,7 +107,8 @@ static struct omap_hwmod omap3xxx_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_core_masters),
.slaves = omap3xxx_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l4_core_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
};
/* Slave interfaces on the L4_PER interconnect */
@@ -126,7 +128,8 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_per_masters),
.slaves = omap3xxx_l4_per_slaves,
.slaves_cnt = ARRAY_
[PATCH 04/13] OMAP: hwmod: Fix the missing braces
From: Benoit Cousson
As reported by Sergei, a couple of braces were missing after
the WARM removal patch.
[07/22] OMAP: hwmod: Replace WARN by pr_warning if clock lookup failed
https://patchwork.kernel.org/patch/100756/
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Sergei Shtylyov
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index ac75407..3d11523 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -409,10 +409,11 @@ static int _init_main_clk(struct omap_hwmod *oh)
return 0;
oh->_clk = omap_clk_get_by_name(oh->main_clk);
- if (!oh->_clk)
+ if (!oh->_clk) {
pr_warning("omap_hwmod: %s: cannot clk_get main_clk %s\n",
oh->name, oh->main_clk);
return -EINVAL;
+ }
if (!oh->_clk->clkdm)
pr_warning("omap_hwmod: %s: missing clockdomain for %s.\n",
@@ -444,10 +445,11 @@ static int _init_interface_clks(struct omap_hwmod *oh)
continue;
c = omap_clk_get_by_name(os->clk);
- if (!c)
+ if (!c) {
pr_warning("omap_hwmod: %s: cannot clk_get
interface_clk %s\n",
oh->name, os->clk);
ret = -EINVAL;
+ }
os->_clk = c;
}
@@ -470,10 +472,11 @@ static int _init_opt_clks(struct omap_hwmod *oh)
for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++) {
c = omap_clk_get_by_name(oc->clk);
- if (!c)
+ if (!c) {
pr_warning("omap_hwmod: %s: cannot clk_get opt_clk
%s\n",
oh->name, oc->clk);
ret = -EINVAL;
+ }
oc->_clk = c;
}
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/13] OMAP2&3: hwmod: Remove _hwmod prefix in name string
From: Benoit Cousson
In the lastest OMAP4 hwmod data file, the _hwmod was removed
in order to save some memory space and because it does not
bring a lot.
Align OMAP2420, 2430 and 3430 data files with the same convention.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Rajendra Nayak
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 +++---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 +++---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a8b57a6..646386c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -59,7 +59,7 @@ static struct omap_hwmod_ocp_if *omap2420_l3_masters[] = {
/* L3 */
static struct omap_hwmod omap2420_l3_hwmod = {
- .name = "l3_hwmod",
+ .name = "l3_main",
.class = &l3_hwmod_class,
.masters= omap2420_l3_masters,
.masters_cnt= ARRAY_SIZE(omap2420_l3_masters),
@@ -90,7 +90,7 @@ static struct omap_hwmod_ocp_if *omap2420_l4_core_masters[] =
{
/* L4 CORE */
static struct omap_hwmod omap2420_l4_core_hwmod = {
- .name = "l4_core_hwmod",
+ .name = "l4_core",
.class = &l4_hwmod_class,
.masters= omap2420_l4_core_masters,
.masters_cnt= ARRAY_SIZE(omap2420_l4_core_masters),
@@ -111,7 +111,7 @@ static struct omap_hwmod_ocp_if *omap2420_l4_wkup_masters[]
= {
/* L4 WKUP */
static struct omap_hwmod omap2420_l4_wkup_hwmod = {
- .name = "l4_wkup_hwmod",
+ .name = "l4_wkup",
.class = &l4_hwmod_class,
.masters= omap2420_l4_wkup_masters,
.masters_cnt= ARRAY_SIZE(omap2420_l4_wkup_masters),
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 8b1f74b..b2100cf 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -59,7 +59,7 @@ static struct omap_hwmod_ocp_if *omap2430_l3_masters[] = {
/* L3 */
static struct omap_hwmod omap2430_l3_hwmod = {
- .name = "l3_hwmod",
+ .name = "l3_main",
.class = &l3_hwmod_class,
.masters= omap2430_l3_masters,
.masters_cnt= ARRAY_SIZE(omap2430_l3_masters),
@@ -92,7 +92,7 @@ static struct omap_hwmod_ocp_if *omap2430_l4_core_masters[] =
{
/* L4 CORE */
static struct omap_hwmod omap2430_l4_core_hwmod = {
- .name = "l4_core_hwmod",
+ .name = "l4_core",
.class = &l4_hwmod_class,
.masters= omap2430_l4_core_masters,
.masters_cnt= ARRAY_SIZE(omap2430_l4_core_masters),
@@ -113,7 +113,7 @@ static struct omap_hwmod_ocp_if *omap2430_l4_wkup_masters[]
= {
/* L4 WKUP */
static struct omap_hwmod omap2430_l4_wkup_hwmod = {
- .name = "l4_wkup_hwmod",
+ .name = "l4_wkup",
.class = &l4_hwmod_class,
.masters= omap2430_l4_wkup_masters,
.masters_cnt= ARRAY_SIZE(omap2430_l4_wkup_masters),
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index e288b20..ec6a5f8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -70,7 +70,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l3_masters[] = {
/* L3 */
static struct omap_hwmod omap3xxx_l3_hwmod = {
- .name = "l3_hwmod",
+ .name = "l3_main",
.class = &l3_hwmod_class,
.masters= omap3xxx_l3_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_l3_masters),
@@ -101,7 +101,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_core_masters[]
= {
/* L4 CORE */
static struct omap_hwmod omap3xxx_l4_core_hwmod = {
- .name = "l4_core_hwmod",
+ .name = "l4_core",
.class = &l4_hwmod_class,
.masters= omap3xxx_l4_core_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_core_masters),
@@ -122,7 +122,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_per_masters[]
= {
/* L4 PER */
static struct omap_hwmod omap3xxx_l4_per_hwmod = {
- .name = "l4_per_hwmod",
+ .name = "l4_per",
.class = &l4_hwmod_class,
.masters= omap3xxx_l4_per_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_per_masters),
@@ -143,7 +143,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_masters[]
= {
/* L4 WKUP */
static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
- .name = "l4_wkup_hwmod",
+ .name = "l4_wkup",
.class = &l4_hwmod_class,
.masters= omap3xxx_l4_w
[PATCH 06/13] OMAP: hwmod: add non-locking versions of enable and idle functions
Some hwmods may need to be idled/enabled in atomic context, so
non-locking versions of these functions are required.
Most users should not need these and usage of theses should be
controlled to understand why access is being done in atomic context.
For this reason, the non-locking functions are only exposed at the
hwmod level and not at the omap-device level.
The use-case that led to the need for the non-locking versions is
hwmods that are enabled/idled from within the core idle/suspend path.
Since interrupts are already disabled here, the mutex-based locking in
hwmod can sleep and will cause potential deadlocks.
Cc: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c | 32 ++---
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 3d11523..8b2b44a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1287,6 +1287,18 @@ int omap_hwmod_unregister(struct omap_hwmod *oh)
}
/**
+ * __omap_hwmod_enable - enable an omap_hwmod (non-locking version)
+ * @oh: struct omap_hwmod *
+ *
+ * Enable an omap_hwomd @oh. Intended to be called in rare cases
+ * where usage is required in atomic context.
+ */
+int __omap_hwmod_enable(struct omap_hwmod *oh)
+{
+ return _enable(oh);
+}
+
+/**
* omap_hwmod_enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -1301,12 +1313,26 @@ int omap_hwmod_enable(struct omap_hwmod *oh)
return -EINVAL;
mutex_lock(&omap_hwmod_mutex);
- r = _enable(oh);
+ r = __omap_hwmod_enable(oh);
mutex_unlock(&omap_hwmod_mutex);
return r;
}
+
+/**
+ * __omap_hwmod_idle - idle an omap_hwmod (non-locking)
+ * @oh: struct omap_hwmod *
+ *
+ * Idle an omap_hwomd @oh. Intended to be called in rare instances where
+ * used in atomic context.
+ */
+int __omap_hwmod_idle(struct omap_hwmod *oh)
+{
+ _idle(oh);
+ return 0;
+}
+
/**
* omap_hwmod_idle - idle an omap_hwmod
* @oh: struct omap_hwmod *
@@ -1319,9 +1345,7 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
if (!oh)
return -EINVAL;
- mutex_lock(&omap_hwmod_mutex);
- _idle(oh);
- mutex_unlock(&omap_hwmod_mutex);
+ __omap_hwmod_idle(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 0eccc09..9a3f4dc 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -486,7 +486,9 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh));
int omap_hwmod_late_init(void);
int omap_hwmod_enable(struct omap_hwmod *oh);
+int __omap_hwmod_enable(struct omap_hwmod *oh);
int omap_hwmod_idle(struct omap_hwmod *oh);
+int __omap_hwmod_idle(struct omap_hwmod *oh);
int omap_hwmod_shutdown(struct omap_hwmod *oh);
int omap_hwmod_enable_clocks(struct omap_hwmod *oh);
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/13] OMAP: hwmod: don't auto-disable hwmod when !CONFIG_PM_RUNTIME
When runtime PM is disabled, the pm_runtime_idle() and _enable() functions will be effectively noops and will not result in enable and idle calls at the hwmod level. In order for drivers to still work when runtime PM is disabled, ensure that all hwmods are left in an enabled state so that even without runtime PM management, they will still work. Signed-off-by: Kevin Hilman --- arch/arm/mach-omap2/omap_hwmod.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 8b2b44a..0184d74 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -1059,6 +1059,14 @@ static int _setup(struct omap_hwmod *oh) } } +#ifndef CONFIG_PM_RUNTIME + /* +* If runtime PM is not enabled, leave the device enabled +* since runtime PM will not be dynamically managing the device. +*/ + oh->flags |= HWMOD_INIT_NO_IDLE; +#endif + if (!(oh->flags & HWMOD_INIT_NO_IDLE)) _idle(oh); -- 1.7.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4
From: Rajendra Nayak Signed-off-by: Rajendra Nayak Signed-off-by: Benoit Cousson Cc: Paul Walmsley Signed-off-by: Kevin Hilman --- arch/arm/plat-omap/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 98f0191..9405831 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o # omap_device support (OMAP2+ only at the moment) obj-$(CONFIG_ARCH_OMAP2) += omap_device.o obj-$(CONFIG_ARCH_OMAP3) += omap_device.o +obj-$(CONFIG_ARCH_OMAP4) += omap_device.o obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o -- 1.7.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/13] OMAP: omap_device: ensure hwmod tracks attached omap_device pointer
The omap_hwmod struct has a field to track the omap_device that is attached to it, but it was not being assigned. Fix by assigning omap_device pointer when omap_device is built. Cc: Paul Walmsley Signed-off-by: Kevin Hilman --- arch/arm/plat-omap/omap_device.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index f899603..6614cba 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -359,8 +359,8 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id, struct omap_device *od; char *pdev_name2; struct resource *res = NULL; - int res_count; - struct omap_hwmod **hwmods; + int i, res_count; + struct omap_hwmod *oh, **hwmods; if (!ohs || oh_cnt == 0 || !pdev_name) return ERR_PTR(-EINVAL); @@ -416,6 +416,10 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id, else ret = omap_device_register(od); + /* each hwmod has a pointer to its attached omap_device */ + for (i = 0, oh = hwmods[0]; i < oh_cnt; i++, oh++) + oh->od = od; + if (ret) goto odbs_exit4; -- 1.7.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/13] OMAP: omap_device: add flag to disable automatic bus-level suspend/resume
As part of the runtime PM support, bus-level code can automatically
handle the enable/idle for each omap_device. There are, however, some
special cases where we don't want the bus-level layer to handle this,
and instead handle it manually.
Specific use cases are for omap_devices that are controlled
inside the idle path (like UART.)
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/include/plat/omap_device.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 3694b62..2cdbcdd 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -68,12 +68,16 @@ struct omap_device {
struct omap_device_pm_latency *pm_lats;
u32 dev_wakeup_lat;
u32 _dev_wakeup_lat_limit;
+ u32 flags;
u8 pm_lats_cnt;
s8 pm_lat_level;
u8 hwmods_cnt;
u8 _state;
};
+/* flags for struct omap_device */
+#define OMAP_DEVICE_NO_BUS_SUSPEND BIT(0)
+
/* Device driver interface (call via platform_data fn ptrs) */
int omap_device_enable(struct platform_device *pdev);
@@ -142,6 +146,7 @@ struct omap_device_pm_latency {
u32 flags;
};
+/* flags for struct omap_device_pm_latency */
#define OMAP_DEVICE_LATENCY_AUTO_ADJUST BIT(1)
/* Get omap_device pointer from platform_device pointer */
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/13] OMAP: create omap_devices for MPU, DSP, L3
Create simple omap_devices for the main processors and busses.
This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked at the device level.
So that these primary devices are available for early PM initialization,
they are created as early platform_devices.
Cc: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/devices.c|2 +
arch/arm/mach-omap2/io.c | 55 +-
arch/arm/plat-omap/include/plat/common.h |4 ++
3 files changed, 60 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 03e6c9e..62920ac 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -29,6 +30,7 @@
#include
#include
#include
+#include
#include "mux.h"
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3cfb425..ecebbbf 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -45,7 +45,7 @@
#include
#include "clockdomains.h"
-#include
+#include
/*
* The machine specific code may provide the extra mapping besides the
@@ -313,6 +313,58 @@ static int __init _omap2_init_reprogram_sdrc(void)
return v;
}
+static struct omap_device_pm_latency *pm_lats;
+
+static DEFINE_PER_CPU(struct device *, mpu_dev);
+static struct device *dsp_dev;
+static struct device *l3_dev;
+
+struct device *omap_get_mpu_device(void)
+{
+ mpu_dev = per_cpu(mpu_dev, smp_processor_id());
+ WARN_ON_ONCE(!mpu_dev);
+ return mpu_dev;
+}
+
+struct device *omap_get_dsp_device(void)
+{
+ WARN_ON_ONCE(!dsp_dev);
+ return dsp_dev;
+}
+
+struct device *omap_get_l3_device(void)
+{
+ WARN_ON_ONCE(!l3_dev);
+ return l3_dev;
+}
+
+static int _init_omap_device(struct omap_hwmod *oh, void *user)
+{
+ struct omap_device *od;
+ const char *name = oh->name;
+ struct device **new_dev = (struct device **)user;
+
+ od = omap_device_build(name, 0, oh, NULL, 0, pm_lats, 0, true);
+ if (WARN(IS_ERR(od), "Could not build omap_device for %s\n", name))
+ return -ENODEV;
+
+ *new_dev = &od->pdev.dev;
+
+ return 0;
+}
+
+/*
+ * Build omap_devices for processors and bus.
+ */
+static void omap_init_processor_devices(void)
+{
+ mpu_dev = per_cpu(mpu_dev, smp_processor_id());
+
+ omap_hwmod_for_each_by_class("mpu", _init_omap_device, &mpu_dev);
+ omap_hwmod_for_each_by_class("dsp", _init_omap_device, &dsp_dev);
+ omap_hwmod_for_each_by_class("l3", _init_omap_device, &l3_dev);
+}
+
void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
@@ -342,6 +394,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
omap_serial_early_init();
if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
omap_hwmod_late_init();
+ omap_init_processor_devices();
omap_pm_if_init();
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index d265018..0059dec 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -87,4 +87,8 @@ void omap2_set_globals_uart(struct omap_globals *);
} \
})
+struct device *omap_get_mpu_device(void);
+struct device *omap_get_dsp_device(void);
+struct device *omap_get_l3_device(void);
+
#endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/13] OMAP: hwmod data: add class for DSP hwmods
Add a new hwmod class for DSP devices. To be used when hwmods
are created for DSP on OMAP3 (a.k.a. IVA2.)
Cc: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod_common_data.c |3 +++
arch/arm/mach-omap2/omap_hwmod_common_data.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.c
b/arch/arm/mach-omap2/omap_hwmod_common_data.c
index 1e80b91..09f1e98 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c
@@ -66,3 +66,6 @@ struct omap_hwmod_class mpu_hwmod_class = {
.name = "mpu"
};
+struct omap_hwmod_class dsp_hwmod_class = {
+ .name = "dsp"
+};
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_common_data.h
index 3645a28..d03ebfa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.h
@@ -20,5 +20,6 @@
extern struct omap_hwmod_class l3_hwmod_class;
extern struct omap_hwmod_class l4_hwmod_class;
extern struct omap_hwmod_class mpu_hwmod_class;
+extern struct omap_hwmod_class dsp_hwmod_class;
#endif
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/13] OMAP3: hwmod data: add data for OMAP3 IVA2
Add hwmod data for DSP on OMAP3 (a.k.a. IVA2.)
Cc: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 31
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ec6a5f8..fe41089 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -32,6 +32,7 @@
*/
static struct omap_hwmod omap3xxx_mpu_hwmod;
+static struct omap_hwmod omap3xxx_iva2_hwmod;
static struct omap_hwmod omap3xxx_l3_hwmod;
static struct omap_hwmod omap3xxx_l4_core_hwmod;
static struct omap_hwmod omap3xxx_l4_per_hwmod;
@@ -168,12 +169,42 @@ static struct omap_hwmod omap3xxx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * IVA2_2 interface data
+ */
+
+/* IVA2 <- L3 interface */
+static struct omap_hwmod_ocp_if omap3xxx_l3__iva2 = {
+ .master = &omap3xxx_l3_hwmod,
+ .slave = &omap3xxx_iva2_hwmod,
+ .clk= "iva2_ck",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_iva2_masters[] = {
+ &omap3xxx_l3__iva2,
+};
+
+/*
+ * IVA2 (IVA2)
+ */
+
+static struct omap_hwmod omap3xxx_iva2_hwmod = {
+ .name = "dsp",
+ .class = &dsp_hwmod_class,
+ .main_clk = "iva2_ck",
+ .masters= omap3xxx_iva2_masters,
+ .masters_cnt= ARRAY_SIZE(omap3xxx_iva2_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+};
+
static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_l3_hwmod,
&omap3xxx_l4_core_hwmod,
&omap3xxx_l4_per_hwmod,
&omap3xxx_l4_wkup_hwmod,
&omap3xxx_mpu_hwmod,
+ &omap3xxx_iva2_hwmod,
NULL,
};
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 04/13] OMAP: hwmod: Fix the missing braces
Kevin Hilman wrote: > Sent: Wednesday, June 23, 2010 6:43 PM > To: linux-omap@vger.kernel.org > Cc: p...@pwsan.com; Cousson, Benoit; Sergei Shtylyov > Subject: [PATCH 04/13] OMAP: hwmod: Fix the missing braces > > From: Benoit Cousson > > As reported by Sergei, a couple of braces were missing after > the WARM removal patch. s/WARM/WARN? > > [07/22] OMAP: hwmod: Replace WARN by pr_warning if clock lookup failed > > https://patchwork.kernel.org/patch/100756/ > > Signed-off-by: Benoit Cousson > Cc: Paul Walmsley > Cc: Sergei Shtylyov > Signed-off-by: Kevin Hilman -- 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/13] OMAP: hwmod: Fix the missing braces
On Thu, 24 Jun 2010, Gadiyar, Anand wrote: > Kevin Hilman wrote: > > Sent: Wednesday, June 23, 2010 6:43 PM > > To: linux-omap@vger.kernel.org > > Cc: p...@pwsan.com; Cousson, Benoit; Sergei Shtylyov > > Subject: [PATCH 04/13] OMAP: hwmod: Fix the missing braces > > > > From: Benoit Cousson > > > > As reported by Sergei, a couple of braces were missing after > > the WARM removal patch. > > s/WARM/WARN? Thanks, just fixed that in the patch description. - 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] OMAP3: wait on IDLEST after enabling USBTLL fclk
On Mon, 21 Jun 2010, Paul Walmsley wrote: > On Sat, 19 Jun 2010, Gadiyar, Anand wrote: > > > Gadiyar, Anand wrote: > > > We need to wait on the IDLEST bit after the clocks are enabled > > > before attempting to access any register. > > > > > > Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait, > > > while the USBTLL f-clock ops uses clkops_omap2_dflt. If the > > > i-clock is enabled first, the clkops_omap2_dflt_wait is > > > short-circuited as the companion f-clock is not enabled. > > > This can cause a data abort if the IDLEST has not transitioned, > > > and we try to access a USBTLL register. > > > > > > Since the USBTLL i-clock and f-clock could be enabled in any order, > > > this is a bug. Fix it by changing the clkops for the f-clock. > > > > > > Signed-off-by: Anand Gadiyar > > It looks fine to me. I will queue it for a -rc branch. Will requeue this for 2.6.36 merge window since it is not a regression, and it seems that Linus wants regression fixes for the -rc series... - 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
[PATCH] OMAP: hwmod regression fix for 2.6.35-rc
Hi, This patch (intended for 2.6.35-rc) fixes a bad regression in 2.6.35-rc preventing the hwmod code from working. - Paul --- Benoit Cousson (1): OMAP: hwmod: Fix the missing braces arch/arm/mach-omap2/omap_hwmod.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: hwmod: Fix the missing braces
From: Benoit Cousson
As reported by Sergei, a couple of braces were missing after
the WARN removal patch.
[07/22] OMAP: hwmod: Replace WARN by pr_warning if clock lookup failed
https://patchwork.kernel.org/patch/100756/
Signed-off-by: Benoit Cousson
[p...@pwsan.com: fixed patch description per Anand's E-mail]
Signed-off-by: Paul Walmsley
Cc: Sergei Shtylyov
Cc: Anand Gadiyar
---
arch/arm/mach-omap2/omap_hwmod.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 95c9a5f..b7a4133 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -409,10 +409,11 @@ static int _init_main_clk(struct omap_hwmod *oh)
return 0;
oh->_clk = omap_clk_get_by_name(oh->main_clk);
- if (!oh->_clk)
+ if (!oh->_clk) {
pr_warning("omap_hwmod: %s: cannot clk_get main_clk %s\n",
oh->name, oh->main_clk);
return -EINVAL;
+ }
if (!oh->_clk->clkdm)
pr_warning("omap_hwmod: %s: missing clockdomain for %s.\n",
@@ -444,10 +445,11 @@ static int _init_interface_clks(struct omap_hwmod *oh)
continue;
c = omap_clk_get_by_name(os->clk);
- if (!c)
+ if (!c) {
pr_warning("omap_hwmod: %s: cannot clk_get
interface_clk %s\n",
oh->name, os->clk);
ret = -EINVAL;
+ }
os->_clk = c;
}
@@ -470,10 +472,11 @@ static int _init_opt_clks(struct omap_hwmod *oh)
for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++) {
c = omap_clk_get_by_name(oc->clk);
- if (!c)
+ if (!c) {
pr_warning("omap_hwmod: %s: cannot clk_get opt_clk
%s\n",
oh->name, oc->clk);
ret = -EINVAL;
+ }
oc->_clk = c;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
Nicolas Pitre wrote: > On Wed, 23 Jun 2010, Jamie Lokier wrote: > > > For other things like __switch_to and maybe cache maintenance calls, > > dmb() etc, I'd suggest first doing a generic asm mechanism like x86's > > "alternatives", keeping in mind that one of the alternatives has to be > > XIP friendly. > > You cannot be XIP friendly unless you rewrite the concerned function(s) > into a RAM page in order to modify it. And then of course you have to > play tricks with the linker so that the rewritten functions are > referenced with their final rewritten location. And that means of > course that the RAM location has to be a constant unless we introduce > some indirect function calls. And at that point we're not much better > than the proposed runtime test. > > Also, if you are interested by a XIP kernel, this usually means you have > a fairly highly customized kernel config. In this context it is > senseless to have runtime patching of the kernel. What you want in that > case is as much stuff as possible selected and optimized at compile > time, and anything you don't need configured out. I wasn't suggesting that XIP kernels do any run-time npatching. Sorry, I thought that was obvious. What I mean is to provide a set of macros, a bit like x86's alternatives macros, which take various asm fragments and the condition which would choose between them, and compiles to unconditional code if the condition is known at compile time (XIP or not), otherwise compiles to fixed, run-time conditional code on XIP (it could be conditional code or an indirect functional call), and on non-XIP compiles to patchable code with an alternate-table section. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] OMAP: PM: use omap_device API for suspend/resume
Hi Kevin,
On Mon, 21 Jun 2010, Kevin Hilman wrote:
> Paul Walmsley writes:
>
> > I guess the intent of your patch is to avoid having to patch in
> > omap_device_{idle,enable}() into a bunch of driver DPM suspend/resume
> > callbacks?
>
> Partially. Actually, I think many (most?) drivers can get rid of
> static suspend/resume paths all together and just use runtime PM.
>
> There are some cases though (MMC comes to mind, more on that below)
> where static suspend has some extra steps necessary and behaves
> differently than runtime PM.
It's not just MMC, any driver that can be in the middle of doing something
during DPM ->suspend() will need to have DPM suspend code to stop what
it's doing and quiesce the device before returning from the suspend
callback. Either that, or ->suspend() needs to return an error and block
the system suspend process...
> > If so, some comments:
> > - dev_pm_ops->suspend_noirq() is intended for use on devices with
> > shared interrupts.
>
> Just to clarify. The functions I'm overriding here is the bus
> functions (bus->pm->[suspend|resume]_noirq(), not any driver functions
OK, I see that now - this code was confusing in the patch's
platform_pm_suspend_noirq():
+ if (drv->pm) {
+ if (drv->pm->suspend_noirq)
+ ret = drv->pm->suspend_noirq(dev);
+ }
This is already done by the DPM core in
drivers/base/power/main.c:device_suspend_noirq() and will result in
re-executing the driver's suspend_noirq function, which is potentially
quite bad. Same thing for platform_pm_resume_noirq() in the patch.
> Indeed, shared IRQs were an intended usage, but I don't see that as a
> requirement. Indeed, Documentation/power/devices.txt even seems to
> suggest that the _noirq version is the place to turn the device "as
> off as possible:
>
> "For simple drivers, suspend might quiesce the device using class code
> and then turn its hardware as "off" as possible during suspend_noirq"
Further down in that file, it says:
"2. The suspend methods should quiesce the device to stop it from
performing I/O. They also may save the device registers and put it into
the
appropriate low-power state, depending on the bus type the device
is on, and they may enable wakeup events."
... and then:
"The majority of subsystems and device drivers need not implement
[the suspend_noirq] callback. However, bus types allowing devices to
share interrupt vectors, like PCI, generally need it; otherwise a driver
might encounter an error during the suspend phase by fielding a shared
interrupt generated by some other device after its own device had been
set to low power."
> > Right now the OMAP2+ codebase doesn't use any
> > shared interrupts for on-chip devices, as far as I can see. It
> > looks like you use ->suspend_noirq() to ensure your code runs after
> > the existing driver suspend functions.
>
> No. The primary reason for using _noirq() is that if any driver ever
> did use the _noirq() hooks (for any atomic activity, or late wakeup
> detection, etc.) the device will still be accessible.
>
> > Using ->suspend_noirq() for this purpose seems like a hack.
> > A better place for that code would be in a bus->pm->suspend()
> > callback, which will run after the device's dev_pm_ops->suspend()
> > callback.
>
> I originally put it in bus->pm->suspend, but moved it to
> bus->pm->suspend_noirq() since I didn't do a full audit so see
> if anything was using the _noirq hooks.
>
> If we want to have a requirement that no on-chip devices can use the
> _noirq hooks (or at least they can't touch hardware in those hooks)
> then I can move it back to bus->pm->suspend().
That sounds like the best argument for keeping these hooks in
_noirq() -- some driver writer may be likely to use suspend_noirq()
without understanding that they shouldn't... maybe we should add some code
that looks for this and warns.
But thinking about it further, it also seems possible that a handful of
OMAP drivers might use shared IRQs at some point in the future. DSS comes
to mind -- that really is a shared IRQ. So, _noirq() is fine, then.
> But personally, I would see that as an artificial requirement based on
> a very restrictive definiton of the _noirq() methods.
It's just the definition from the kernel documentation.
> > - It is not safe to call omap_device_{idle,enable}() from DPM
> > callbacks as the patch does, because they will race with runtime PM
> > calls to omap_device_{idle,enable}().
>
> No, they cannot race.
>
> Runtime PM transitions are prevented by the system PM core during a
> system PM transition. The system suspend path does a pm_runtime_get()
> for each device being suspended, and then does a _put() upon resume.
> (see drivers/base/power/main.c, grep for pm_runtime_)
Yes, you are correct in terms of my original statement. But the problem
-- and the race -- that I did a poor job of d
Re: [PATCH 10/13] OMAP: omap_device: add flag to disable automatic bus-level suspend/resume
Hi Kevin,
A few comments:
Your "add runtime PM support at bus-level" series has a unstated
dependency on this patch. If you fix one minor issue (below), it's
probably easiest if you merge it with that other series to avoid
cross-dependencies.
On Wed, 23 Jun 2010, Kevin Hilman wrote:
> As part of the runtime PM support, bus-level code can automatically
> handle the enable/idle for each omap_device. There are, however, some
> special cases where we don't want the bus-level layer to handle this,
> and instead handle it manually.
>
> Specific use cases are for omap_devices that are controlled
> inside the idle path (like UART.)
>
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/plat-omap/include/plat/omap_device.h |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
> b/arch/arm/plat-omap/include/plat/omap_device.h
> index 3694b62..2cdbcdd 100644
> --- a/arch/arm/plat-omap/include/plat/omap_device.h
> +++ b/arch/arm/plat-omap/include/plat/omap_device.h
> @@ -68,12 +68,16 @@ struct omap_device {
> struct omap_device_pm_latency *pm_lats;
> u32 dev_wakeup_lat;
> u32 _dev_wakeup_lat_limit;
> + u32 flags;
This should be a u8. Fix that and it is
Acked-by: Paul Walmsley
> u8 pm_lats_cnt;
> s8 pm_lat_level;
> u8 hwmods_cnt;
> u8 _state;
> };
>
> +/* flags for struct omap_device */
> +#define OMAP_DEVICE_NO_BUS_SUSPEND BIT(0)
> +
> /* Device driver interface (call via platform_data fn ptrs) */
>
> int omap_device_enable(struct platform_device *pdev);
> @@ -142,6 +146,7 @@ struct omap_device_pm_latency {
> u32 flags;
> };
>
> +/* flags for struct omap_device_pm_latency */
> #define OMAP_DEVICE_LATENCY_AUTO_ADJUST BIT(1)
>
> /* Get omap_device pointer from platform_device pointer */
> --
> 1.7.0.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
- 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
[RFC] mm: iommu: An API to unify IOMMU, CPU and device memory management
This patch contains the documentation for and the main header file of the API, termed the Virtual Contiguous Memory Manager. Its use would allow all of the IOMMU to VM, VM to device and device to IOMMU interoperation code to be refactored into platform independent code. Comments, suggestions and criticisms are welcome and wanted. Signed-off-by: Zach Pfeffer --- Documentation/vcm.txt | 583 include/linux/vcm.h | 1017 + 2 files changed, 1600 insertions(+), 0 deletions(-) create mode 100644 Documentation/vcm.txt create mode 100644 include/linux/vcm.h diff --git a/Documentation/vcm.txt b/Documentation/vcm.txt new file mode 100644 index 000..d29c757 --- /dev/null +++ b/Documentation/vcm.txt @@ -0,0 +1,583 @@ +What is this document about? + + +This document covers how to use the Virtual Contiguous Memory Manager +(VCMM), how the first implmentation works with a specific low-level +Input/Output Memory Management Unit (IOMMU) and the way the VCMM is used +from user-space. It also contains a section that describes why something +like the VCMM is needed in the kernel. + +If anything in this document is wrong please send patches to the +maintainer of this file, listed at the bottom of the document. + + +The Virtual Contiguous Memory Manager += + +The VCMM was built to solve the system-wide memory mapping issues that +occur when many bus-masters have IOMMUs. + +An IOMMU maps device addresses to physical addresses. It also insulates +the system from spurious or malicious device bus transactions and allows +fine-grained mapping attribute control. The Linux kernel core does not +contain a generic API to handle IOMMU mapped memory; device driver writers +must implement device specific code to interoperate with the Linux kernel +core. As the number of IOMMUs increases, coordinating the many address +spaces mapped by all discrete IOMMUs becomes difficult without in-kernel +support. + +The VCMM API enables device independent IOMMU control, virtual memory +manager (VMM) interoperation and non-IOMMU enabled device interoperation +by treating devices with or without IOMMUs and all CPUs with or without +MMUs, their mapping contexts and their mappings using common +abstractions. Physical hardware is given a generic device type and mapping +contexts are abstracted into Virtual Contiguous Memory (VCM) +regions. Users "reserve" memory from VCMs and "back" their reservations +with physical memory. + +Why the VCMM is Needed +-- + +Driver writers who control devices with IOMMUs must contend with device +control and memory management. Driver writers have a large device driver +API that they can leverage to control their devices, but they are lacking +a unified API to help them program mappings into IOMMUs and share those +mappings with other devices and CPUs in the system. + +Sharing is complicated by Linux's CPU centric VMM. The CPU centric model +generally makes sense because average hardware only contains a MMU for the +CPU and possibly a graphics MMU. If every device in the system has one or +more MMUs the CPU centric memory management (MM) programming model breaks +down. + +Abstracting IOMMU device programming into a common API has already begun +in the Linux kernel. It was built to abstract the difference between AMDs +and Intels IOMMUs to support x86 virtualization on both platforms. The +interface is listed in kernel/include/linux/iommu.h. It contains +interfaces for mapping and unmapping as well as domain management. This +interface has not gained widespread use outside the x86; PA-RISC, Alpha +and SPARC architectures and ARM and PowerPC platforms all use their own +mapping modules to control their IOMMUs. The VCMM contains an IOMMU +programming layer, but since its abstraction supports map management +independent of device control, the layer is not used directly. This +higher-level view enables a new kernel service, not just an IOMMU +interoperation layer. + +The General Idea: Map Management using Graphs +- + +Looking at mapping from a system-wide perspective reveals a general graph +problem. The VCMMs API is built to manage the general mapping graph. Each +node that talks to memory, either through an MMU or directly (physically +mapped) can be thought of as the device-end of a mapping edge. The other +edge is the physical memory (or intermediate virtual space) that is +mapped. + +In the direct mapped case the device is assigned a one-to-one MMU. This +scheme allows direct mapped devices to participate in general graph +management. + +The CPU nodes can also be brought under the same mapping abstraction with +the use of a light overlay on the existing VMM. This light overlay allows +VMM managed mappings to interoperate with the common API. The light +overlay enables this without substantial modifications to the
Re: [PATCH 02/13] OMAP: hwmod: allow idle after HWMOD_INIT_NO_IDLE
Hi Kevin,
something doesn't make sense in this patch...
On Wed, 23 Jun 2010, Kevin Hilman wrote:
> If an omap_hwmod is setup using HWMOD_INIT_NO_IDLE flag, there is
> currently way to idle it since omap_hwmod_idle() requires the hwmod to
> be in the enabled state.
The only thing that HWMOD_INIT_NO_IDLE does is prevent the hwmod from
being idled at the end of _setup(). By that time, the hwmod has already
been enabled, and its state has been set to _HWMOD_STATE_ENABLED. So
there shouldn't be anything preventing the hwmod from being idled at that
point?
Maybe the problem is that some hwmods were failing _wait_target_ready()
and so were never entering the ENABLED state? If so, that looks like it's
fixed appropriately by your patch 3.
> This patch adds a check to omap_hwmod_idle() so if the hwmod was has
> the INIT_NO_IDLE flag, calling omap_hwmod_idle() will still succeed.
>
> Cc: Paul Walmsley
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 11 ++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 95c9a5f..ac75407 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -938,7 +938,13 @@ static int _enable(struct omap_hwmod *oh)
> */
> static int _idle(struct omap_hwmod *oh)
> {
> - if (oh->_state != _HWMOD_STATE_ENABLED) {
> + /*
> + * To idle, hwmod must be enabled, EXCEPT if hwmod was
> + * initialized using the INIT_NO_IDLE flag. In this case it
> + * will not yet be enabled so we have to allow it to be idled.
> + */
> + if ((oh->_state != _HWMOD_STATE_ENABLED) &&
> + !(oh->flags & HWMOD_INIT_NO_IDLE)) {
> WARN(1, "omap_hwmod: %s: idle state can only be entered from "
>"enabled state\n", oh->name);
> return -EINVAL;
> @@ -953,6 +959,9 @@ static int _idle(struct omap_hwmod *oh)
>
> oh->_state = _HWMOD_STATE_IDLE;
>
> + /* Clear init flag which should only affect first call to idle */
> + oh->flags &= ~HWMOD_INIT_NO_IDLE;
- 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 05/13] OMAP2&3: hwmod: Remove _hwmod prefix in name string
Benoît,
one minor comment here:
On Wed, 23 Jun 2010, Kevin Hilman wrote:
> From: Benoit Cousson
>
> In the lastest OMAP4 hwmod data file, the _hwmod was removed
> in order to save some memory space and because it does not
> bring a lot.
> Align OMAP2420, 2430 and 3430 data files with the same convention.
Shouldn't we also synchronize the names of the structures as well? i.e.,
if the name is changed to "l3_main", shouldn't the name of the structure
also be changed from
static struct omap_hwmod omap2420_l3_hwmod = {
to
static struct omap_hwmod omap2420_l3_main_hwmod = {
(... as one example?)
- Paul
>
> Signed-off-by: Benoit Cousson
> Cc: Paul Walmsley
> Cc: Rajendra Nayak
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 +++---
> arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 +++---
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> index a8b57a6..646386c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> @@ -59,7 +59,7 @@ static struct omap_hwmod_ocp_if *omap2420_l3_masters[] = {
>
> /* L3 */
> static struct omap_hwmod omap2420_l3_hwmod = {
> - .name = "l3_hwmod",
> + .name = "l3_main",
> .class = &l3_hwmod_class,
> .masters= omap2420_l3_masters,
> .masters_cnt= ARRAY_SIZE(omap2420_l3_masters),
> @@ -90,7 +90,7 @@ static struct omap_hwmod_ocp_if *omap2420_l4_core_masters[]
> = {
>
> /* L4 CORE */
> static struct omap_hwmod omap2420_l4_core_hwmod = {
> - .name = "l4_core_hwmod",
> + .name = "l4_core",
> .class = &l4_hwmod_class,
> .masters= omap2420_l4_core_masters,
> .masters_cnt= ARRAY_SIZE(omap2420_l4_core_masters),
> @@ -111,7 +111,7 @@ static struct omap_hwmod_ocp_if
> *omap2420_l4_wkup_masters[] = {
>
> /* L4 WKUP */
> static struct omap_hwmod omap2420_l4_wkup_hwmod = {
> - .name = "l4_wkup_hwmod",
> + .name = "l4_wkup",
> .class = &l4_hwmod_class,
> .masters= omap2420_l4_wkup_masters,
> .masters_cnt= ARRAY_SIZE(omap2420_l4_wkup_masters),
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> index 8b1f74b..b2100cf 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> @@ -59,7 +59,7 @@ static struct omap_hwmod_ocp_if *omap2430_l3_masters[] = {
>
> /* L3 */
> static struct omap_hwmod omap2430_l3_hwmod = {
> - .name = "l3_hwmod",
> + .name = "l3_main",
> .class = &l3_hwmod_class,
> .masters= omap2430_l3_masters,
> .masters_cnt= ARRAY_SIZE(omap2430_l3_masters),
> @@ -92,7 +92,7 @@ static struct omap_hwmod_ocp_if *omap2430_l4_core_masters[]
> = {
>
> /* L4 CORE */
> static struct omap_hwmod omap2430_l4_core_hwmod = {
> - .name = "l4_core_hwmod",
> + .name = "l4_core",
> .class = &l4_hwmod_class,
> .masters= omap2430_l4_core_masters,
> .masters_cnt= ARRAY_SIZE(omap2430_l4_core_masters),
> @@ -113,7 +113,7 @@ static struct omap_hwmod_ocp_if
> *omap2430_l4_wkup_masters[] = {
>
> /* L4 WKUP */
> static struct omap_hwmod omap2430_l4_wkup_hwmod = {
> - .name = "l4_wkup_hwmod",
> + .name = "l4_wkup",
> .class = &l4_hwmod_class,
> .masters= omap2430_l4_wkup_masters,
> .masters_cnt= ARRAY_SIZE(omap2430_l4_wkup_masters),
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index e288b20..ec6a5f8 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -70,7 +70,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l3_masters[] = {
>
> /* L3 */
> static struct omap_hwmod omap3xxx_l3_hwmod = {
> - .name = "l3_hwmod",
> + .name = "l3_main",
> .class = &l3_hwmod_class,
> .masters= omap3xxx_l3_masters,
> .masters_cnt= ARRAY_SIZE(omap3xxx_l3_masters),
> @@ -101,7 +101,7 @@ static struct omap_hwmod_ocp_if
> *omap3xxx_l4_core_masters[] = {
>
> /* L4 CORE */
> static struct omap_hwmod omap3xxx_l4_core_hwmod = {
> - .name = "l4_core_hwmod",
> + .name = "l4_core",
> .class = &l4_hwmod_class,
> .masters= omap3xxx_l4_core_masters,
> .masters_cnt= ARRAY_SIZE(omap3xxx_l4_core_masters),
> @@ -122,7 +122,7 @@ static struct omap_hwmod_ocp_if
> *omap3xxx_l4_per_masters[] = {
>
> /* L4 PER */
> static struct omap_hwmod omap3xxx_l4_per_hwmod = {
> - .na
Re: [PATCH 06/13] OMAP: hwmod: add non-locking versions of enable and idle functions
Hi Kevin
On Wed, 23 Jun 2010, Kevin Hilman wrote:
> Some hwmods may need to be idled/enabled in atomic context, so
> non-locking versions of these functions are required.
>
> Most users should not need these and usage of theses should be
> controlled to understand why access is being done in atomic context.
> For this reason, the non-locking functions are only exposed at the
> hwmod level and not at the omap-device level.
>
> The use-case that led to the need for the non-locking versions is
> hwmods that are enabled/idled from within the core idle/suspend path.
> Since interrupts are already disabled here, the mutex-based locking in
> hwmod can sleep and will cause potential deadlocks.
I accept the use-case. But maybe it would be preferable to rename
_enable(), _idle(), _shutdown() to _omap_hwmod_{enable,idle,shutdown}() ?
That would avoid the need to add new functions that just call the existing
ones.
- Paul
>
> Cc: Paul Walmsley
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 32 ++---
> arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +
> 2 files changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 3d11523..8b2b44a 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -1287,6 +1287,18 @@ int omap_hwmod_unregister(struct omap_hwmod *oh)
> }
>
> /**
> + * __omap_hwmod_enable - enable an omap_hwmod (non-locking version)
> + * @oh: struct omap_hwmod *
> + *
> + * Enable an omap_hwomd @oh. Intended to be called in rare cases
> + * where usage is required in atomic context.
> + */
> +int __omap_hwmod_enable(struct omap_hwmod *oh)
> +{
> + return _enable(oh);
> +}
> +
> +/**
> * omap_hwmod_enable - enable an omap_hwmod
> * @oh: struct omap_hwmod *
> *
> @@ -1301,12 +1313,26 @@ int omap_hwmod_enable(struct omap_hwmod *oh)
> return -EINVAL;
>
> mutex_lock(&omap_hwmod_mutex);
> - r = _enable(oh);
> + r = __omap_hwmod_enable(oh);
> mutex_unlock(&omap_hwmod_mutex);
>
> return r;
> }
>
> +
> +/**
> + * __omap_hwmod_idle - idle an omap_hwmod (non-locking)
> + * @oh: struct omap_hwmod *
> + *
> + * Idle an omap_hwomd @oh. Intended to be called in rare instances where
> + * used in atomic context.
> + */
> +int __omap_hwmod_idle(struct omap_hwmod *oh)
> +{
> + _idle(oh);
> + return 0;
> +}
> +
> /**
> * omap_hwmod_idle - idle an omap_hwmod
> * @oh: struct omap_hwmod *
> @@ -1319,9 +1345,7 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
> if (!oh)
> return -EINVAL;
>
> - mutex_lock(&omap_hwmod_mutex);
> - _idle(oh);
> - mutex_unlock(&omap_hwmod_mutex);
> + __omap_hwmod_idle(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 0eccc09..9a3f4dc 100644
> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> @@ -486,7 +486,9 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh));
> int omap_hwmod_late_init(void);
>
> int omap_hwmod_enable(struct omap_hwmod *oh);
> +int __omap_hwmod_enable(struct omap_hwmod *oh);
> int omap_hwmod_idle(struct omap_hwmod *oh);
> +int __omap_hwmod_idle(struct omap_hwmod *oh);
> int omap_hwmod_shutdown(struct omap_hwmod *oh);
>
> int omap_hwmod_enable_clocks(struct omap_hwmod *oh);
> --
> 1.7.0.2
>
- 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 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4
Hi Rajendra On Wed, 23 Jun 2010, Kevin Hilman wrote: > From: Rajendra Nayak > Please add a brief patch changelog entry here. Maybe just say this is necessary for integration code using omap_device to work on OMAP4? > Signed-off-by: Rajendra Nayak > Signed-off-by: Benoit Cousson > Cc: Paul Walmsley > Signed-off-by: Kevin Hilman > --- > arch/arm/plat-omap/Makefile |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile > index 98f0191..9405831 100644 > --- a/arch/arm/plat-omap/Makefile > +++ b/arch/arm/plat-omap/Makefile > @@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o > # omap_device support (OMAP2+ only at the moment) > obj-$(CONFIG_ARCH_OMAP2) += omap_device.o > obj-$(CONFIG_ARCH_OMAP3) += omap_device.o > +obj-$(CONFIG_ARCH_OMAP4) += omap_device.o > > obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o > obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o > -- > 1.7.0.2 > - 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 2/8] MUSB: make non-OMAP platforms build with CONFIG_PM=y
On Thu, Jun 17, 2010 at 12:40:35PM +0200, ext Ajay Kumar Gupta wrote: From: Sergei Shtylyov Attempt to build MUSB driver with CONFIG_PM=y (e.g. in the OTG mode) on DaVinci results in these link errors: drivers/built-in.o: In function `musb_restore_context': led-triggers.c:(.text+0x714d8): undefined reference to `musb_platform_restore_context' drivers/built-in.o: In function `musb_save_context': led-triggers.c:(.text+0x71788): undefined reference to `musb_platform_save_context' This turned out to be caused by commit 9957dd97ec5e98dd334f87ade1d9a0b24d1f86eb (usb: musb: Fix compile error for omaps for musb_hdrc). Revert it, taking into account the rename of CONFIG_ARCH_OMAP34XX into CONFIG_ARCH_OMAP3 (which that commit fixed in a completely inappropriate way) and the recent addition of OMAP4 support. Signed-off-by: Sergei Shtylyov Signed-off-by: Ajay Kumar Gupta Acked-by: Felipe Balbi -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] musb: fix compilation warning in host only mode
On Thu, Jun 17, 2010 at 12:40:36PM +0200, ext Ajay Kumar Gupta wrote: +#ifdef CONFIG_USB_MUSB_HDRC_HCD + void __iomem*mbase = musb->mregs; +#endif then you add another ifdef to this file, which is already insane. I'd rather see you either keep the local variables and just fix what needs to be fixed, or use musb->mregs directly. -- balbi DefectiveByDesign.org -- 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] OMAP3: wait on IDLEST after enabling USBTLL fclk
Paul Walmsley wrote: > On Mon, 21 Jun 2010, Paul Walmsley wrote: > > On Sat, 19 Jun 2010, Gadiyar, Anand wrote: > > > Gadiyar, Anand wrote: > > > > We need to wait on the IDLEST bit after the clocks are enabled > > > > before attempting to access any register. > > > > > > > > Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait, > > > > while the USBTLL f-clock ops uses clkops_omap2_dflt. If the > > > > i-clock is enabled first, the clkops_omap2_dflt_wait is > > > > short-circuited as the companion f-clock is not enabled. > > > > This can cause a data abort if the IDLEST has not transitioned, > > > > and we try to access a USBTLL register. > > > > > > > > Since the USBTLL i-clock and f-clock could be enabled in any order, > > > > this is a bug. Fix it by changing the clkops for the f-clock. > > > > > > > > Signed-off-by: Anand Gadiyar > > > > It looks fine to me. I will queue it for a -rc branch. > > Will requeue this for 2.6.36 merge window since it is not a regression, > and it seems that Linus wants regression fixes for the -rc series... > I received a bug-report last Friday from some user of the recently-merged ohci-omap3 driver about a data-abort caused at driver load. This patch fixes that issue. This wasn't known to me when I originally submitted the patch, but looks like this is a problem caused in a driver that went in in the last merge window. So maybe this patch can go in in the -rc series. ;) It's your call. I'm not particular. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] USB: musb: suppress warning about unused flags
On Thu, Jun 17, 2010 at 12:40:37PM +0200, ext Ajay Kumar Gupta wrote: From: Jon Povey Wrap flags with uninitialized_var() to suppress this: drivers/usb/musb/cppi_dma.c:1158: warning: 'flags' may be used uninitialized in this function Signed-off-by: Jon Povey Signed-off-by: Ajay Kumar Gupta --- drivers/usb/musb/cppi_dma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c index 59dc3d3..e3753ba 100644 --- a/drivers/usb/musb/cppi_dma.c +++ b/drivers/usb/musb/cppi_dma.c @@ -1155,7 +1155,7 @@ irqreturn_t cppi_interrupt(int irq, void *dev_id) struct musb_hw_ep *hw_ep = NULL; u32 rx, tx; int i, index; - unsigned long flags; + unsigned long uninitialized_var(flags); I think the problem here is different. First of all, an IRQ of number 0 is valid and your locking would be broken in that case. Is there really any board that doesn't have the irq line routed ? To me it just looks that branching if (irq) is completely bogus. -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] usb: musb: fix Blackfin ulpi stubs
On Thu, Jun 17, 2010 at 12:40:38PM +0200, ext Ajay Kumar Gupta wrote: From: Mike Frysinger The new ulpi code defines fallback stubs for the Blackfin arch, but does so incorrectly leading to a build failure: drivers/usb/musb/musb_core.c:227: error: 'musb_ulpi_read' undeclared here (not in a function) drivers/usb/musb/musb_core.c:228: error: 'musb_ulpi_write' undeclared here (not in a function) Tweak the fallback stubs so that they do work as intended. Signed-off-by: Mike Frysinger Signed-off-by: Ajay Kumar Gupta Acked-by: Felipe Balbi -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] usb: musb: Enable the maximum supported burst mode for DMA
On Thu, Jun 17, 2010 at 12:40:39PM +0200, ext Ajay Kumar Gupta wrote: From: Hema HK Setting MUSB Burst Mode 3 automatically enables support for lower burst modes (BURST4, BURST8, BURST16 or bursts of unspecified length). There is no need to set these burst modes based on the packet size. Also enable the burst mode for both mode1 and mode0. This is a fix for buggy hardware - having the lower burst modes enabled can potentially cause lockups of the DMA engine used in OMAP2/3/4 chips. Signed-off-by: Hema HK Signed-off-by: Anand Gadiyar Signed-off-by: Ajay Kumar Gupta Acked-by: Felipe Balbi -- balbi DefectiveByDesign.org -- 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 7/8] musb: Kill board specific pinmux from driver file
On Thu, Jun 17, 2010 at 12:40:40PM +0200, ext Ajay Kumar Gupta wrote: From: Anand Gadiyar This pin-muxing is best done in the board files. The driver should not do this explicitly. Also, this code causes a warning to be thrown when OMAP2430 and OMAP3/4 support are enabled in the same kernel. Signed-off-by: Anand Gadiyar Signed-off-by: Ajay Kumar Gupta Acked-by: Felipe Balbi Note this is not a bugfix, so should wait until next merge window. -- balbi DefectiveByDesign.org -- 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 7/8] musb: Kill board specific pinmux from driver file
Felipe Balbi wrote: > On Thu, Jun 17, 2010 at 12:40:40PM +0200, ext Ajay Kumar Gupta wrote: > >From: Anand Gadiyar > > > >This pin-muxing is best done in the board files. The driver should > >not do this explicitly. > > > >Also, this code causes a warning to be thrown when OMAP2430 and OMAP3/4 > >support are enabled in the same kernel. > > > >Signed-off-by: Anand Gadiyar > >Signed-off-by: Ajay Kumar Gupta > > Acked-by: Felipe Balbi > > Note this is not a bugfix, so should wait until next merge window. > It's a bug-fix to the extent that it caused a WARN() to be triggered at bootup. But it's not serious and can wait. - Anand-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] musb_core: make disconnect and suspend interrupts work again
On Thu, Jun 17, 2010 at 12:40:34PM +0200, ext Ajay Kumar Gupta wrote: From: Sergei Shtylyov Commit 1c25fda4a09e8229800979986ef399401053b46e (usb: musb: handle irqs in the order dictated by programming guide) forgot to get rid of the old 'STAGE0_MASK' filter for calling musb_stage0_irq(), so now disconnect and suspend interrupts are effectively ignored... Signed-off-by: Sergei Shtylyov Cc: sta...@kernel.org Signed-off-by: Ajay Kumar Gupta Acked-by: Felipe Balbi -- balbi DefectiveByDesign.org -- 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 05/12] OMAP: create omap_devices for MPU, DSP, L3
>>-Original Message-
>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>Sent: Wednesday, June 23, 2010 11:17 PM
>>To: Gopinath, Thara
>>Cc: linux-omap@vger.kernel.org; Menon, Nishanth; Cousson, Benoit
>>Subject: Re: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
>>
>>"Gopinath, Thara" writes:
>>
>-Original Message-
>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: Wednesday, June 23, 2010 8:19 PM
>To: Gopinath, Thara
>Cc: linux-omap@vger.kernel.org; Menon, Nishanth; Cousson, Benoit
>Subject: Re: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
>
>"Gopinath, Thara" writes:
>
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, June 17, 2010 5:47 AM
To: linux-omap@vger.kernel.org
Cc: Menon, Nishanth; Gopinath, Thara; Cousson, Benoit
Subject: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
Create simple omap_devices for the main processors and busses.
This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked at the omap_device and
hwmod level.
Because these omap_devices are based on platform_devices, they cannot
be created until the driver core has been initialized. Therefore, move
the init of these into a device_initcall(). Also, OMAP PM init cannot
be done until after this step as it depends on the OPP layer.
Signed-off-by: Kevin Hilman
>[...]
>
+
+static int __init omap2_late_common_init(void)
+{
+ omap_init_processor_devices();
+
/* initialize the opp table if board file has not done so */
omap3_pm_init_opp_table();
+ omap_pm_if_init();
+
+ return 0;
+}
+device_initcall(omap2_late_common_init);
>> Hello Kevin,
>>
>> Any particular reason for making this a late init and not keeping
>> this a part of init_common_hw? The reason is the board files also
>> have an option of calling/ overriding omap3_pm_init_opp_table. This
>> happens really early in init_irq. (Refer board_3430sdp.c). So if a
>> board file calls into omap3_pm_init_opp_table, the opp
>> initializations will happen before the omap_device pointers are
>> build for mpu, iva and l3. So the dev pointers stored as part of
>> dev_opp tables will be screwed up. My personal preference would be
>> to call the omap_init_processor_devices just after
>> hwmod_late_init. This will remove any race conditions as above.
>
>I agree, I changed this yesterday and the current pm-wip/hwmods is
>doing exactly this.
>
>The initial reason for the late initcall was because omap_device_build
>creates platform_devices and devices, but the driver core was not
>yet initialized at this point.
>
>To fix, I now create these devices as early platform devices so that
>the init sequence can remain the same.
>
>I'll be posting an updated version of this series today.
>>>
>>> But then early platform devices do not create a dev pointer. So you do
>>> two initializations, eh?
>>
>>The early platform_device indeed has a struct device (it is a struct
>>inside the platfor_device.) The difference is that the struct device
>>has not been fully initialized (no device_add() has been called.)
>>
>>For our purposes here, that is perfectly OK, as all that matters is that
>>there is a unique pointer to be used in the OPP layer.
Ok. I also think that the initcalls for voltage and sr_device should be moved
back to the original.
The order of initialization should be as follows.
1. Build the generic omap devices (like mpu, l3, dsp etc) (part of
init_common_hw)
2. Initialize the opp structures. (part of init_common_hw)
3. Intialize the voltage layer. (arch_initcall)
4. Initialize the smartreflex device layer(subsys initcall)
5. Initialize the smartreflex srive.(late initcall)
Regards
Thara
--
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 11/13] OMAP: create omap_devices for MPU, DSP, L3
Hi Kevin,
some comments below -
On Wed, 23 Jun 2010, Kevin Hilman wrote:
> Create simple omap_devices for the main processors and busses.
>
> This is required to support the forth-coming device-based OPP
> approach, where OPPs are managed and tracked at the device level.
>
> So that these primary devices are available for early PM initialization,
> they are created as early platform_devices.
The idea sounds good, but -
>
> Cc: Paul Walmsley
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/devices.c|2 +
> arch/arm/mach-omap2/io.c | 55
> +-
> arch/arm/plat-omap/include/plat/common.h |4 ++
> 3 files changed, 60 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 03e6c9e..62920ac 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -29,6 +30,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mux.h"
>
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index 3cfb425..ecebbbf 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -45,7 +45,7 @@
>
> #include
> #include "clockdomains.h"
> -#include
> +#include
>
> /*
> * The machine specific code may provide the extra mapping besides the
> @@ -313,6 +313,58 @@ static int __init _omap2_init_reprogram_sdrc(void)
> return v;
> }
>
> +static struct omap_device_pm_latency *pm_lats;
> +
> +static DEFINE_PER_CPU(struct device *, mpu_dev);
> +static struct devicee *dsp_dev;
> +static struct device *l3_dev;
> +
> +struct device *omap_get_mpu_device(void)
> +{
> + mpu_dev = per_cpu(mpu_dev, smp_processor_id());
Looks like this will trash the per-CPU mpu_dev on SMP. You'll need to
rename one of these two mpu_devs.
Also, won't the use of smp_processor_id() mean that this will just return
the struct device * for the MPU that is running this code? So on a
two-CPU system, it would be either CPU 0 or 1, randomly. I guess one
solution would be to pass in the processor ID to omap_get_mpu_device().
> + WARN_ON_ONCE(!mpu_dev);
> + return mpu_dev;
> +}
> +
> +struct device *omap_get_dsp_device(void)
> +{
> + WARN_ON_ONCE(!dsp_dev);
> + return dsp_dev;
> +}
> +
> +struct device *omap_get_l3_device(void)
> +{
> + WARN_ON_ONCE(!l3_dev);
> + return l3_dev;
> +}
> +
> +static int _init_omap_device(struct omap_hwmod *oh, void *user)
> +{
> + struct omap_device *od;
> + const char *name = oh->name;
> + struct device **new_dev = (struct device **)user;
> +
> + od = omap_device_build(name, 0, oh, NULL, 0, pm_lats, 0, true);
> + if (WARN(IS_ERR(od), "Could not build omap_device for %s\n", name))
> + return -ENODEV;
> +
> + *new_dev = &od->pdev.dev;
> +
> + return 0;
> +}
> +
> +/*
> + * Build omap_devices for processors and bus.
> + */
> +static void omap_init_processor_devices(void)
> +{
> + mpu_dev = per_cpu(mpu_dev, smp_processor_id());
(same issues as above)
> +
> + omap_hwmod_for_each_by_class("mpu", _init_omap_device, &mpu_dev);
This won't work on SMP - it will use the same mpu_dev variable for each
MPU, so mpu_dev will contain the struct device * for the last MPU hwmod
iterated over.
Also, there is a hidden assumption that the hwmods of class "mpu" will be
iterated over in the order that the per_cpu() variable expects...
> + omap_hwmod_for_each_by_class("dsp", _init_omap_device, &dsp_dev);
> + omap_hwmod_for_each_by_class("l3", _init_omap_device, &l3_dev);
If there is more than one hwmod in these classes, these will lose the
omap_device pointers for all but the final omap_hwmod iterated over.
It's probably easier to just call omap_hwmod_lookup()/_init_omap_device()
directly and forget about omap_hwmod_for_each_by_class() for the above
two cases - maybe all three...
> +}
> +
> void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
>struct omap_sdrc_params *sdrc_cs1)
> {
> @@ -342,6 +394,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
> *sdrc_cs0,
> omap_serial_early_init();
> if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
> omap_hwmod_late_init();
> + omap_init_processor_devices();
> omap_pm_if_init();
> if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
> omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
> diff --git a/arch/arm/plat-omap/include/plat/common.h
> b/arch/arm/plat-omap/include/plat/common.h
> index d265018..0059dec 100644
> --- a/arch/arm/plat-omap/include/plat/common.h
> +++ b/arch/arm/plat-omap/include/plat/common.h
> @@ -87,4 +87,8 @@ void omap2_set_globals_uart(struct omap_globals *);
> } \
> })
>
> +struct device
RE: [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk
Hi Tony, what do you think on this one? -rc or .36? - Paul On Thu, 24 Jun 2010, Gadiyar, Anand wrote: > Paul Walmsley wrote: > > On Mon, 21 Jun 2010, Paul Walmsley wrote: > > > On Sat, 19 Jun 2010, Gadiyar, Anand wrote: > > > > Gadiyar, Anand wrote: > > > > > We need to wait on the IDLEST bit after the clocks are enabled > > > > > before attempting to access any register. > > > > > > > > > > Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait, > > > > > while the USBTLL f-clock ops uses clkops_omap2_dflt. If the > > > > > i-clock is enabled first, the clkops_omap2_dflt_wait is > > > > > short-circuited as the companion f-clock is not enabled. > > > > > This can cause a data abort if the IDLEST has not transitioned, > > > > > and we try to access a USBTLL register. > > > > > > > > > > Since the USBTLL i-clock and f-clock could be enabled in any order, > > > > > this is a bug. Fix it by changing the clkops for the f-clock. > > > > > > > > > > Signed-off-by: Anand Gadiyar > > > > > > It looks fine to me. I will queue it for a -rc branch. > > > > Will requeue this for 2.6.36 merge window since it is not a regression, > > and it seems that Linus wants regression fixes for the -rc series... > > > > I received a bug-report last Friday from some user of the recently-merged > ohci-omap3 driver about a data-abort caused at driver load. This patch > fixes that issue. > > This wasn't known to me when I originally submitted the patch, but looks > like this is a problem caused in a driver that went in in the last merge > window. So maybe this patch can go in in the -rc series. ;) > > It's your call. I'm not particular. - 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 2/3] OMAP: PM: use omap_device API for suspend/resume
Hi Kevin,
aside from these comments:
http://marc.info/?l=linux-omap&m=127735008820992&w=2
one other minor issue -
On Wed, 23 Jun 2010, Kevin Hilman wrote:
> Hook into the platform bus methods for suspend and resume and
> use the omap_device API to automatically idle and enable the
> device on suspend and resume.
>
> This allows device drivers to get rid of direct management of their
> clocks in their suspend/resume paths, and let omap_device do it for
> them.
>
> We currently use the _noirq (late suspend, early resume) versions of
> the suspend/resume methods to ensure that the device is not disabled
> too early for any drivers also using the _noirq methods.
>
> NOTE: only works for devices with omap_hwmod support.
>
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/pm_bus.c | 61
> ++
> 1 files changed, 61 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
> index 69acaa5..3787da8 100644
> --- a/arch/arm/mach-omap2/pm_bus.c
> +++ b/arch/arm/mach-omap2/pm_bus.c
> @@ -70,3 +70,64 @@ int platform_pm_runtime_idle(struct device *dev)
> };
> #endif /* CONFIG_PM_RUNTIME */
>
> +#ifdef CONFIG_SUSPEND
> +int platform_pm_suspend_noirq(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + struct platform_device *pdev = to_platform_device(dev);
> + struct omap_device *odev = to_omap_device(pdev);
> + int ret = 0;
> +
> + if (!drv)
> + return 0;
> +
> + if (drv->pm) {
> + if (drv->pm->suspend_noirq)
> + ret = drv->pm->suspend_noirq(dev);
> + }
> +
> + if (omap_device_is_valid(odev)) {
> + if (odev->flags & OMAP_DEVICE_NO_BUS_SUSPEND) {
> + dev_dbg(dev, "no automatic bus-level system resume.\n");
I guess this should read "suspend" above?
> + return 0;
> + }
> +
> + dev_dbg(dev, "%s\n", __func__);
> + omap_device_idle(pdev);
> + } else {
> + dev_dbg(dev, "not an omap_device\n");
> + }
> +
> + return ret;
> +}
> +
> +int platform_pm_resume_noirq(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + struct platform_device *pdev = to_platform_device(dev);
> + struct omap_device *odev = to_omap_device(pdev);
> + int ret = 0;
> +
> + if (omap_device_is_valid(odev)) {
> + if (odev->flags & OMAP_DEVICE_NO_BUS_SUSPEND) {
> + dev_dbg(dev, "no automatic bus-level system resume.\n");
> + return 0;
> + }
> +
> + dev_dbg(dev, "%s\n", __func__);
> + omap_device_enable(pdev);
> + } else {
> + dev_dbg(dev, "not an omap_device\n");
> + }
> +
> + if (!drv)
> + return 0;
> +
> + if (drv->pm) {
> + if (drv->pm->resume_noirq)
> + ret = drv->pm->resume_noirq(dev);
> + }
> +
> + return ret;
> +}
> +#endif /* CONFIG_SUSPEND */
> --
> 1.7.0.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
- 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 11/13] OMAP: create omap_devices for MPU, DSP, L3
Hi Kevin, one other thought. On Thu, 24 Jun 2010, Paul Walmsley wrote: > On Wed, 23 Jun 2010, Kevin Hilman wrote: > > > Create simple omap_devices for the main processors and busses. > > > > This is required to support the forth-coming device-based OPP > > approach, where OPPs are managed and tracked at the device level. If these omap_devices are only to deal with OPPs, you might only need one omap_device for the MPU subsystem for OMAP4, since I think both cores receive the same clock. That might simplify this patch for the current timeframe. - 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 11/13] OMAP: create omap_devices for MPU, DSP, L3
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul
> Walmsley
> Sent: Thursday, June 24, 2010 11:57 AM
> To: Kevin Hilman
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH 11/13] OMAP: create omap_devices for MPU, DSP, L3
>
> Hi Kevin,
>
> some comments below -
>
> On Wed, 23 Jun 2010, Kevin Hilman wrote:
>
> > Create simple omap_devices for the main processors and busses.
> >
> > This is required to support the forth-coming device-based OPP
> > approach, where OPPs are managed and tracked at the device level.
> >
> > So that these primary devices are available for early PM initialization,
> > they are created as early platform_devices.
>
> The idea sounds good, but -
>
> >
> > Cc: Paul Walmsley
> > Signed-off-by: Kevin Hilman
> > ---
> > arch/arm/mach-omap2/devices.c|2 +
> > arch/arm/mach-omap2/io.c | 55
> > +-
> > arch/arm/plat-omap/include/plat/common.h |4 ++
> > 3 files changed, 60 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > index 03e6c9e..62920ac 100644
> > --- a/arch/arm/mach-omap2/devices.c
> > +++ b/arch/arm/mach-omap2/devices.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -29,6 +30,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "mux.h"
> >
> > diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> > index 3cfb425..ecebbbf 100644
> > --- a/arch/arm/mach-omap2/io.c
> > +++ b/arch/arm/mach-omap2/io.c
> > @@ -45,7 +45,7 @@
> >
> > #include
> > #include "clockdomains.h"
> > -#include
> > +#include
> >
> > /*
> > * The machine specific code may provide the extra mapping besides the
> > @@ -313,6 +313,58 @@ static int __init _omap2_init_reprogram_sdrc(void)
> > return v;
> > }
> >
> > +static struct omap_device_pm_latency *pm_lats;
> > +
> > +static DEFINE_PER_CPU(struct device *, mpu_dev);
> > +static struct devicee *dsp_dev;
> > +static struct device *l3_dev;
> > +
> > +struct device *omap_get_mpu_device(void)
> > +{
> > + mpu_dev = per_cpu(mpu_dev, smp_processor_id());
>
> Looks like this will trash the per-CPU mpu_dev on SMP. You'll need to
> rename one of these two mpu_devs.
>
> Also, won't the use of smp_processor_id() mean that this will just return
> the struct device * for the MPU that is running this code? So on a
> two-CPU system, it would be either CPU 0 or 1, randomly. I guess one
> solution would be to pass in the processor ID to omap_get_mpu_device().
>
MPUSS and both CPU's are clocked from same clock source, so above assumption
still work on OMAP4.
> > + WARN_ON_ONCE(!mpu_dev);
> > + return mpu_dev;
> > +}
> > +
> > +struct device *omap_get_dsp_device(void)
> > +{
> > + WARN_ON_ONCE(!dsp_dev);
> > + return dsp_dev;
> > +}
> > +
> > +struct device *omap_get_l3_device(void)
> > +{
> > + WARN_ON_ONCE(!l3_dev);
> > + return l3_dev;
> > +}
> > +
> > +static int _init_omap_device(struct omap_hwmod *oh, void *user)
> > +{
> > + struct omap_device *od;
> > + const char *name = oh->name;
> > + struct device **new_dev = (struct device **)user;
> > +
> > + od = omap_device_build(name, 0, oh, NULL, 0, pm_lats, 0, true);
> > + if (WARN(IS_ERR(od), "Could not build omap_device for %s\n", name))
> > + return -ENODEV;
> > +
> > + *new_dev = &od->pdev.dev;
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * Build omap_devices for processors and bus.
> > + */
> > +static void omap_init_processor_devices(void)
> > +{
> > + mpu_dev = per_cpu(mpu_dev, smp_processor_id());
>
> (same issues as above)
>
> > +
> > + omap_hwmod_for_each_by_class("mpu", _init_omap_device, &mpu_dev);
>
> This won't work on SMP - it will use the same mpu_dev variable for each
> MPU, so mpu_dev will contain the struct device * for the last MPU hwmod
> iterated over.
>
> Also, there is a hidden assumption that the hwmods of class "mpu" will be
> iterated over in the order that the per_cpu() variable expects...
>
> > + omap_hwmod_for_each_by_class("dsp", _init_omap_device, &dsp_dev);
> > + omap_hwmod_for_each_by_class("l3", _init_omap_device, &l3_dev);
>
> If there is more than one hwmod in these classes, these will lose the
> omap_device pointers for all but the final omap_hwmod iterated over.
>
> It's probably easier to just call omap_hwmod_lookup()/_init_omap_device()
> directly and forget about omap_hwmod_for_each_by_class() for the above
> two cases - maybe all three...
>
> > +}
> > +
> > void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
> > struct omap_sdrc_params *sdrc_cs1)
> > {
> > @@ -342,6 +394,7 @@ void __init omap2_init_common_hw(struct
> > omap_sdrc_params *sdrc_cs0,
> > omap_serial_early_init();
> > if (cpu_is_omap24xx() || cpu_is_omap
