Re: [PATCH] dspbridge: Simplify Atoi() method
On Wed, Feb 10, 2010 at 4:02 AM, Omar Ramirez Luna wrote:
>> Try to use simple_strtol() kernel native method instead.
> strtol or strtoul?
I don't know for sure, see below.
>> However, there are opened questions:
>> - why type of Atoi() is s32 if the sign is used only to detect base?
This is the question about l vs ul.
>> + } else if (*pch&& (pch[strlen(pch) - 1] | 0x20 == 'h')) {
>
> perhaps tolower(x)
Yep, I saw only internal macro in lib/vsprintf.c, but totally forgot
about ctype.h.
--
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: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation
No Comments.
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Wednesday, February 10, 2010 12:09 PM
> To: G.N, Vijayakumar
> Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath; Turquette, Mike;
> khil...@deeprootsystems.com
> Subject: RE: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider
> limitation
>
> On Wed, 10 Feb 2010, G.N, Vijayakumar wrote:
>
> > Thanks :)
>
> I had to fix a few minor issues with the patch. Here's the patch as
> applied. Please advise if there are any further comments.
>
>
> - Paul
>
> From d88ef2155dce7a7d995e6dea37433d1643827553 Mon Sep 17 00:00:00 2001
> From: Mike Turquette
> Date: Tue, 9 Feb 2010 23:26:45 -0700
> Subject: [PATCH] OMAP3630: Clock: Workaround for DPLL HS divider limitation
>
> This patch implements a workaround for the DPLL HS divider limitation
> in OMAP3630 as given by Errata ID: i556.
>
> Errata:
> When PWRDN bit is set, it resets the internal HSDIVIDER divide-by value (Mx).
> The reset value gets loaded instead of the previous value.
> The following HSDIVIDERs exhibit above behavior:
> . DPLL4 : M6 / M5 / M4 / M3 / M2 (CM_CLKEN_PLL[31:26] register bits)
> . DPLL3 : M3 (CM_CLKEN_PLL[12] register bit).
>
> Work Around:
> It is mandatory to apply the following sequence to ensure the write
> value will
> be loaded in DPLL HSDIVIDER FSM:
> The global sequence when using PWRDN bit is the following:
> . Disable Mx HSDIVIDER clock output related functional clock enable bits
> (in CM_FCLKEN_xxx / CM_ICLKEN_xxx)
> . Enable PWRDN bit of HSDIVIDER
> . Disable PWRDN bit of HSDIVIDER
> . Read current HSDIVIDER register value
> . Write different value in HSDIVIDER register
> . Write expected value in HSDIVIDER register
> . Enable Mx HSDIVIDER clock output related functional clocks
> (CM_FCLKEN_xxx / CM_ICLKEN_xxx)
>
> Signed-off-by: Mike Turquette
> Signed-off-by: Vishwanath BS
> Signed-off-by: Vijaykumar GN
> [p...@pwsan.com: updated patch to apply; made workaround function static;
> marked as being 36xx-specific]
> Signed-off-by: Paul Walmsley
> ---
> arch/arm/mach-omap2/clock34xx.c | 42
> ++
> arch/arm/mach-omap2/clock34xx.h |3 ++
> arch/arm/mach-omap2/clock34xx_data.c | 19 +++
> 3 files changed, 64 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
> index 37da629..ea6c2d6 100644
> --- a/arch/arm/mach-omap2/clock34xx.c
> +++ b/arch/arm/mach-omap2/clock34xx.c
> @@ -150,6 +150,48 @@ const struct clkops clkops_omap3430es2_hsotgusb_wait
> = {
> .find_companion = omap2_clk_dflt_find_companion,
> };
>
> +/**
> + * omap36xx_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
> + * from HSDivider PWRDN problem Implements Errata ID: i556.
> + * @clk: DPLL output struct clk
> + *
> + * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck,
> + * dpll4_m5_ck & dpll4_m6_ck dividers gets loaded with reset
> + * valueafter their respective PWRDN bits are set. Any dummy write
> + * (Any other value different from the Read value) to the
> + * corresponding CM_CLKSEL register will refresh the dividers.
> + */
> +static int omap36xx_pwrdn_clk_enable_with_hsdiv_restore(struct clk *clk)
> +{
> + u32 dummy_v, orig_v, clksel_shift;
> + int ret;
> +
> + /* Clear PWRDN bit of HSDIVIDER */
> + ret = omap2_dflt_clk_enable(clk);
> +
> + /* Restore the dividers */
> + if (!ret) {
> + clksel_shift = __ffs(clk->parent->clksel_mask);
> + orig_v = dummy_v = __raw_readl(clk->parent->clksel_reg);
> +
> + /* Write any other value different from the Read value */
> + dummy_v ^= (1 << clksel_shift);
> + __raw_writel(dummy_v, clk->parent->clksel_reg);
> +
> + /* Write the original divider */
> + __raw_writel(orig_v, clk->parent->clksel_reg);
> + }
> +
> + return ret;
> +}
> +
> +const struct clkops clkops_omap36xx_pwrdn_with_hsdiv_wait_restore = {
> + .enable = omap36xx_pwrdn_clk_enable_with_hsdiv_restore,
> + .disable= omap2_dflt_clk_disable,
> + .find_companion = omap2_clk_dflt_find_companion,
> + .find_idlest= omap2_clk_dflt_find_idlest,
> +};
> +
> const struct clkops clkops_noncore_dpll_ops = {
> .enable = omap3_noncore_dpll_enable,
> .disable= omap3_noncore_dpll_disable,
> diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
> index e61e653..b9c65f5 100644
> --- a/arch/arm/mach-omap2/clock34xx.h
> +++ b/arch/arm/mach-omap2/clock34xx.h
> @@ -26,4 +26,7 @@ extern const struct clkops clkops_noncore_dpll_ops;
> extern const struct clkops clkops_am35xx_ipss_module_wait;
> extern const struct clkops clkops_am35xx_ipss_wait;
>
> +/* OMAP36xx-specific clkops */
> +extern const struct clkops clkops_omap36xx_pwrdn_with_hsdiv_wait_restore;
> +
> #endif
> diff --git
RE: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation
On Wed, 10 Feb 2010, G.N, Vijayakumar wrote:
> Thanks :)
I had to fix a few minor issues with the patch. Here's the patch as
applied. Please advise if there are any further comments.
- Paul
>From d88ef2155dce7a7d995e6dea37433d1643827553 Mon Sep 17 00:00:00 2001
From: Mike Turquette
Date: Tue, 9 Feb 2010 23:26:45 -0700
Subject: [PATCH] OMAP3630: Clock: Workaround for DPLL HS divider limitation
This patch implements a workaround for the DPLL HS divider limitation
in OMAP3630 as given by Errata ID: i556.
Errata:
When PWRDN bit is set, it resets the internal HSDIVIDER divide-by value (Mx).
The reset value gets loaded instead of the previous value.
The following HSDIVIDERs exhibit above behavior:
. DPLL4 : M6 / M5 / M4 / M3 / M2 (CM_CLKEN_PLL[31:26] register bits)
. DPLL3 : M3 (CM_CLKEN_PLL[12] register bit).
Work Around:
It is mandatory to apply the following sequence to ensure the write
value will
be loaded in DPLL HSDIVIDER FSM:
The global sequence when using PWRDN bit is the following:
. Disable Mx HSDIVIDER clock output related functional clock enable bits
(in CM_FCLKEN_xxx / CM_ICLKEN_xxx)
. Enable PWRDN bit of HSDIVIDER
. Disable PWRDN bit of HSDIVIDER
. Read current HSDIVIDER register value
. Write different value in HSDIVIDER register
. Write expected value in HSDIVIDER register
. Enable Mx HSDIVIDER clock output related functional clocks
(CM_FCLKEN_xxx / CM_ICLKEN_xxx)
Signed-off-by: Mike Turquette
Signed-off-by: Vishwanath BS
Signed-off-by: Vijaykumar GN
[p...@pwsan.com: updated patch to apply; made workaround function static;
marked as being 36xx-specific]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock34xx.c | 42 ++
arch/arm/mach-omap2/clock34xx.h |3 ++
arch/arm/mach-omap2/clock34xx_data.c | 19 +++
3 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 37da629..ea6c2d6 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -150,6 +150,48 @@ const struct clkops clkops_omap3430es2_hsotgusb_wait = {
.find_companion = omap2_clk_dflt_find_companion,
};
+/**
+ * omap36xx_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
+ * from HSDivider PWRDN problem Implements Errata ID: i556.
+ * @clk: DPLL output struct clk
+ *
+ * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck,
+ * dpll4_m5_ck & dpll4_m6_ck dividers gets loaded with reset
+ * valueafter their respective PWRDN bits are set. Any dummy write
+ * (Any other value different from the Read value) to the
+ * corresponding CM_CLKSEL register will refresh the dividers.
+ */
+static int omap36xx_pwrdn_clk_enable_with_hsdiv_restore(struct clk *clk)
+{
+ u32 dummy_v, orig_v, clksel_shift;
+ int ret;
+
+ /* Clear PWRDN bit of HSDIVIDER */
+ ret = omap2_dflt_clk_enable(clk);
+
+ /* Restore the dividers */
+ if (!ret) {
+ clksel_shift = __ffs(clk->parent->clksel_mask);
+ orig_v = dummy_v = __raw_readl(clk->parent->clksel_reg);
+
+ /* Write any other value different from the Read value */
+ dummy_v ^= (1 << clksel_shift);
+ __raw_writel(dummy_v, clk->parent->clksel_reg);
+
+ /* Write the original divider */
+ __raw_writel(orig_v, clk->parent->clksel_reg);
+ }
+
+ return ret;
+}
+
+const struct clkops clkops_omap36xx_pwrdn_with_hsdiv_wait_restore = {
+ .enable = omap36xx_pwrdn_clk_enable_with_hsdiv_restore,
+ .disable= omap2_dflt_clk_disable,
+ .find_companion = omap2_clk_dflt_find_companion,
+ .find_idlest= omap2_clk_dflt_find_idlest,
+};
+
const struct clkops clkops_noncore_dpll_ops = {
.enable = omap3_noncore_dpll_enable,
.disable= omap3_noncore_dpll_disable,
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index e61e653..b9c65f5 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -26,4 +26,7 @@ extern const struct clkops clkops_noncore_dpll_ops;
extern const struct clkops clkops_am35xx_ipss_module_wait;
extern const struct clkops clkops_am35xx_ipss_wait;
+/* OMAP36xx-specific clkops */
+extern const struct clkops clkops_omap36xx_pwrdn_with_hsdiv_wait_restore;
+
#endif
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index d9d5b2e..caa6a41 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -3358,6 +3358,25 @@ int __init omap3xxx_clk_init(void)
}
}
+ if (cpu_is_omap3630()) {
+ /*
+* For 3630: override clkops_omap2_dflt_wait for the
+* clocks affected from PWRDN reset Limitation
+*/
+ dpll3_m3x2_ck.ops =
+
RE: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation
Thanks :) > -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Wednesday, February 10, 2010 11:55 AM > To: G.N, Vijayakumar > Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath; Turquette, Mike; > khil...@deeprootsystems.com > Subject: RE: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider > limitation > > Hello Vijayakumar, > > On Wed, 10 Feb 2010, G.N, Vijayakumar wrote: > > > > From: Paul Walmsley [mailto:p...@pwsan.com] > > > > > > Shouldn't there also be a: > > > > > > dummy_v &= clk->parent->clksel_mask; > > > > > > here to avoid writing to reserved bits? > > > > XOR with "0x00" will always retains the original values, hence I don't see > > any > requirement of mask. > > > > Example: > > For CM_CLKSEL1_PLL > > > > clksel_mask: > > #define OMAP3430_DIV_DPLL3_MASK (0x1f << > 16) > > > > clksel_shift = __ffs(clk->parent->clksel_mask); becomes 16 > > > > (1 << clksel_shift) will become (1 << 16) > > > > XOR operator will only change the Divisor's LSB 1st bit to it's negated > > value. > > > > Hence we will be always changing the Divisor's LSB 1's bit and hence > > the value written will be different one from the existing value and won't > > be > touching any reserved fileds. > > OK, thanks, looks like I misread the code. Queued for 2.6.34. > > > - 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: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation
Hello Vijayakumar, On Wed, 10 Feb 2010, G.N, Vijayakumar wrote: > > From: Paul Walmsley [mailto:p...@pwsan.com] > > > > Shouldn't there also be a: > > > > dummy_v &= clk->parent->clksel_mask; > > > > here to avoid writing to reserved bits? > > XOR with "0x00" will always retains the original values, hence I don't see > any requirement of mask. > > Example: > For CM_CLKSEL1_PLL > > clksel_mask: > #define OMAP3430_DIV_DPLL3_MASK (0x1f << 16) > > clksel_shift = __ffs(clk->parent->clksel_mask); becomes 16 > > (1 << clksel_shift) will become (1 << 16) > > XOR operator will only change the Divisor's LSB 1st bit to it's negated value. > > Hence we will be always changing the Divisor's LSB 1's bit and hence > the value written will be different one from the existing value and won't be > touching any reserved fileds. OK, thanks, looks like I misread the code. Queued for 2.6.34. - 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: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Wednesday, February 10, 2010 11:33 AM
> To: G.N, Vijayakumar
> Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath; Turquette, Mike;
> khil...@deeprootsystems.com
> Subject: Re: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider
> limitation
>
> Hello Mike, Vijayakumar,
>
> one comment below.
>
>
> On Tue, 9 Feb 2010, G.N, Vijayakumar wrote:
>
> > From: Mike Turquette
> > Date: Fri, 5 Feb 2010 19:09:52 +0530
> > Subject: [PATCH] OMAP3630: Clock: Workaround for DPLL HS divider limitation
> >
> > This patch implements a workaround for the DPLL HS divider limitation
> > in OMAP3630 as given by Errata ID: i556.
> >
> > Errata:
> > When PWRDN bit is set, it resets the internal HSDIVIDER divide-by value
> > (Mx).
> > The reset value gets loaded instead of the previous value.
> > The following HSDIVIDERs exhibit above behavior:
> > . DPLL4 : M6 / M5 / M4 / M3 / M2 (CM_CLKEN_PLL[31:26] register bits)
> > . DPLL3 : M3 (CM_CLKEN_PLL[12] register bit).
> >
> > Work Around:
> > It is mandatory to apply the following sequence to ensure the write
> > value will
> > be loaded in DPLL HSDIVIDER FSM:
> > The global sequence when using PWRDN bit is the following:
> > . Disable Mx HSDIVIDER clock output related functional clock enable bits
> > (in CM_FCLKEN_xxx / CM_ICLKEN_xxx)
> > . Enable PWRDN bit of HSDIVIDER
> > . Disable PWRDN bit of HSDIVIDER
> > . Read current HSDIVIDER register value
> > . Write different value in HSDIVIDER register
> > . Write expected value in HSDIVIDER register
> > . Enable Mx HSDIVIDER clock output related functional clocks
> > (CM_FCLKEN_xxx / CM_ICLKEN_xxx)
> >
> > Signed-off-by: Mike Turquette
> > Signed-off-by: Vishwanath BS
> > Signed-off-by: Vijaykumar GN
> > ---
> > arch/arm/mach-omap2/clock34xx.c | 41
> ++
> > arch/arm/mach-omap2/clock34xx.h |1 +
> > arch/arm/mach-omap2/clock34xx_data.c | 20
> > 3 files changed, 62 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-
> omap2/clock34xx.c
> > index c1c1b93..1e6297f 100644
> > --- a/arch/arm/mach-omap2/clock34xx.c
> > +++ b/arch/arm/mach-omap2/clock34xx.c
> > @@ -133,6 +133,47 @@ const struct clkops
> clkops_omap3430es2_hsotgusb_wait = {
> > .find_companion = omap2_clk_dflt_find_companion,
> > };
> >
> > +/**
> > + * omap3_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
> > + * from HSDivider PWRDN problem Implements Errata ID: i556.
> > + * @clk: DPLL output struct clk
> > + *
> > + * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck,
> dpll4_m5_ck
> > + * & dpll4_m6_ck dividers gets loaded with reset valueafter their
> > respective
> > + * PWRDN bits are set.
> > + * Any dummy write (Any other value different from the Read value) to the
> > + * corresponding CM_CLKSEL register will refresh the dividers.
> > + */
> > +int omap3_pwrdn_clk_enable_with_hsdiv_restore(struct clk *clk)
> > +{
> > + u32 dummy_v, orig_v, clksel_shift;
> > + int ret;
> > +
> > + /* Enable PWRDN bit of HSDIVIDER */
> > + ret = omap2_dflt_clk_enable(clk);
> > +
> > + /* Restore the dividers */
> > + if (!ret) {
> > + clksel_shift = __ffs(clk->parent->clksel_mask);
> > + orig_v = dummy_v = __raw_readl(clk->parent->clksel_reg);
> > +
> > + /* Write any other value different from the Read value */
> > + dummy_v ^= (1 << clksel_shift);
>
> Shouldn't there also be a:
>
> dummy_v &= clk->parent->clksel_mask;
>
> here to avoid writing to reserved bits?
XOR with "0x00" will always retains the original values, hence I don't see any
requirement of mask.
Example:
For CM_CLKSEL1_PLL
clksel_mask:
#define OMAP3430_DIV_DPLL3_MASK (0x1f << 16)
clksel_shift = __ffs(clk->parent->clksel_mask); becomes 16
(1 << clksel_shift) will become (1 << 16)
XOR operator will only change the Divisor's LSB 1st bit to it's negated value.
Hence we will be always changing the Divisor's LSB 1's bit and hence
the value written will be different one from the existing value and won't be
touching any reserved fileds.
>
> > + __raw_writel(dummy_v, clk->parent->clksel_reg);
> > +
> > + /* Write the original divider */
> > + __raw_writel(orig_v, clk->parent->clksel_reg);
> > + }
> > + return ret;
> > +}
> > +
> > +const struct clkops clkops_omap3_pwrdn_with_hsdiv_wait_restore = {
> > + .enable = omap3_pwrdn_clk_enable_with_hsdiv_restore,
> > + .disable= omap2_dflt_clk_disable,
> > + .find_companion = omap2_clk_dflt_find_companion,
> > + .find_idlest= omap2_clk_dflt_find_idlest,
> > +};
> > +
> > const struct clkops omap3_clkops_noncore_dpll_ops = {
> > .enable = omap3_noncore_dpll_enable,
> > .disable= omap3_noncore_dpll_disable,
> > diff --git a/arch/arm/mach-omap2/cl
Re: [PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation
Hello Mike, Vijayakumar,
one comment below.
On Tue, 9 Feb 2010, G.N, Vijayakumar wrote:
> From: Mike Turquette
> Date: Fri, 5 Feb 2010 19:09:52 +0530
> Subject: [PATCH] OMAP3630: Clock: Workaround for DPLL HS divider limitation
>
> This patch implements a workaround for the DPLL HS divider limitation
> in OMAP3630 as given by Errata ID: i556.
>
> Errata:
> When PWRDN bit is set, it resets the internal HSDIVIDER divide-by value (Mx).
> The reset value gets loaded instead of the previous value.
> The following HSDIVIDERs exhibit above behavior:
> . DPLL4 : M6 / M5 / M4 / M3 / M2 (CM_CLKEN_PLL[31:26] register bits)
> . DPLL3 : M3 (CM_CLKEN_PLL[12] register bit).
>
> Work Around:
> It is mandatory to apply the following sequence to ensure the write
> value will
> be loaded in DPLL HSDIVIDER FSM:
> The global sequence when using PWRDN bit is the following:
> . Disable Mx HSDIVIDER clock output related functional clock enable bits
> (in CM_FCLKEN_xxx / CM_ICLKEN_xxx)
> . Enable PWRDN bit of HSDIVIDER
> . Disable PWRDN bit of HSDIVIDER
> . Read current HSDIVIDER register value
> . Write different value in HSDIVIDER register
> . Write expected value in HSDIVIDER register
> . Enable Mx HSDIVIDER clock output related functional clocks
> (CM_FCLKEN_xxx / CM_ICLKEN_xxx)
>
> Signed-off-by: Mike Turquette
> Signed-off-by: Vishwanath BS
> Signed-off-by: Vijaykumar GN
> ---
> arch/arm/mach-omap2/clock34xx.c | 41
> ++
> arch/arm/mach-omap2/clock34xx.h |1 +
> arch/arm/mach-omap2/clock34xx_data.c | 20
> 3 files changed, 62 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
> index c1c1b93..1e6297f 100644
> --- a/arch/arm/mach-omap2/clock34xx.c
> +++ b/arch/arm/mach-omap2/clock34xx.c
> @@ -133,6 +133,47 @@ const struct clkops clkops_omap3430es2_hsotgusb_wait = {
> .find_companion = omap2_clk_dflt_find_companion,
> };
>
> +/**
> + * omap3_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
> + * from HSDivider PWRDN problem Implements Errata ID: i556.
> + * @clk: DPLL output struct clk
> + *
> + * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck, dpll4_m5_ck
> + * & dpll4_m6_ck dividers gets loaded with reset valueafter their respective
> + * PWRDN bits are set.
> + * Any dummy write (Any other value different from the Read value) to the
> + * corresponding CM_CLKSEL register will refresh the dividers.
> + */
> +int omap3_pwrdn_clk_enable_with_hsdiv_restore(struct clk *clk)
> +{
> + u32 dummy_v, orig_v, clksel_shift;
> + int ret;
> +
> + /* Enable PWRDN bit of HSDIVIDER */
> + ret = omap2_dflt_clk_enable(clk);
> +
> + /* Restore the dividers */
> + if (!ret) {
> + clksel_shift = __ffs(clk->parent->clksel_mask);
> + orig_v = dummy_v = __raw_readl(clk->parent->clksel_reg);
> +
> + /* Write any other value different from the Read value */
> + dummy_v ^= (1 << clksel_shift);
Shouldn't there also be a:
dummy_v &= clk->parent->clksel_mask;
here to avoid writing to reserved bits?
> + __raw_writel(dummy_v, clk->parent->clksel_reg);
> +
> + /* Write the original divider */
> + __raw_writel(orig_v, clk->parent->clksel_reg);
> + }
> + return ret;
> +}
> +
> +const struct clkops clkops_omap3_pwrdn_with_hsdiv_wait_restore = {
> + .enable = omap3_pwrdn_clk_enable_with_hsdiv_restore,
> + .disable= omap2_dflt_clk_disable,
> + .find_companion = omap2_clk_dflt_find_companion,
> + .find_idlest= omap2_clk_dflt_find_idlest,
> +};
> +
> const struct clkops omap3_clkops_noncore_dpll_ops = {
> .enable = omap3_noncore_dpll_enable,
> .disable= omap3_noncore_dpll_disable,
> diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
> index 313efc0..29ef390 100644
> --- a/arch/arm/mach-omap2/clock34xx.h
> +++ b/arch/arm/mach-omap2/clock34xx.h
> @@ -21,5 +21,6 @@ extern const struct clkops clkops_omap3430es2_ssi_wait;
> extern const struct clkops clkops_omap3430es2_hsotgusb_wait;
> extern const struct clkops clkops_omap3430es2_dss_usbhost_wait;
> extern const struct clkops omap3_clkops_noncore_dpll_ops;
> +extern const struct clkops clkops_omap3_pwrdn_with_hsdiv_wait_restore;
>
> #endif
> diff --git a/arch/arm/mach-omap2/clock34xx_data.c
> b/arch/arm/mach-omap2/clock34xx_data.c
> index 8728f1f..9d11d53 100644
> --- a/arch/arm/mach-omap2/clock34xx_data.c
> +++ b/arch/arm/mach-omap2/clock34xx_data.c
> @@ -3240,6 +3240,26 @@ int __init omap3xxx_clk_init(void)
> }
> }
>
> + if (cpu_is_omap3630()) {
> +
> + /*
> + * For 3630: override clkops_omap2_dflt_wait for the
> + * clocks affected from PWRDN reset Limitation
> + */
> + dpll3_m3x2_ck.ops =
> +
RE: Ubuntu installation on omap
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Niamathullah sharief > Sent: Wednesday, February 10, 2010 7:30 AM > > On Tue, Feb 9, 2010 at 8:37 PM, Robert Nelson > wrote: > > On Tue, Feb 9, 2010 at 3:41 AM, Niamathullah sharief > wrote: > >> Hi, > >> I am trying to install ubuntu on my beagleboard. i installed > >> successfully and it is booting fine. But after booting the graphics > >> which i get is not good. It has some graphics problem. > > > > Ahh, what kind of graphic problems? > it is like working without graphics driver Is'nt http://groups.google.com/group/beagleboard/ having more folks Who can specifically help on beagleboard? Could we take the discussion there? Regards, Nishanth Menon -- 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: Ubuntu installation on omap
On Tue, Feb 9, 2010 at 8:37 PM, Robert Nelson wrote: > On Tue, Feb 9, 2010 at 3:41 AM, Niamathullah sharief > wrote: >> Hi, >> I am trying to install ubuntu on my beagleboard. i installed >> successfully and it is booting fine. But after booting the graphics >> which i get is not good. It has some graphics problem. > > Ahh, what kind of graphic problems? it is like working without graphics driver > >> And how can >> work on ubuntu in board with my mouse and keyboard? If i insert mouse >> and keyboard to board it is not working. only my serial port is >> working. just i am getting login screen in my monitor.Please help me. > > Are you using a certified USB 2.0 Hub? Kernel version? Yes i am using perfect. If i give lsmod in serial, i am not not getting anything. no modules running > > As a quick verification test, use one of my demo images listed here: > > http://elinux.org/BeagleBoardUbuntu#Demo_Image > > Which have been tested on multiple Beagles (Bx's,Cx's..) > > Regards, > -- > Robert Nelson > http://www.rcn-ee.com/ > -- 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] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes
Hi, >-Original Message- >From: Felipe Contreras [mailto:felipe.contre...@gmail.com] >Sent: Tuesday, February 09, 2010 5:48 PM >To: Guzman Lugo, Fernando >Cc: Ameya Palande; linux-omap@vger.kernel.org; Ramirez Luna, Omar; Menon, >Nishanth; Chitriki Rudramuni, Deepak; felipe.contre...@nokia.com; ext- >phil.2.carm...@nokia.com >Subject: Re: [PATCH] DSPBRIDGE: Prevent memory corruption in >DRV_ProcFreeDMMRes > >On Tue, Feb 9, 2010 at 10:22 PM, Guzman Lugo, Fernando >wrote: >> The root problem here is that remove the DMM element should be in >PROC_UnMap but in PROC_UnReserveMemory, because apart of the problem your >are seeing about memory corruption if the application does a >PROC_ReserveMemory and then it finished unexpectedly the resource cleanup >wont be able to unreserved the memory because there is no a DMMres element >in process context struct, the same applies in the case of application >calls PROC_ReserveMemory, PROC_Map, PROC_UnMap but fails to do the >PROC_UnReserveMemory. > >No, that's a completely different issue, but also valid. > >> So the right solution should be: >> >> 1 .- Remove DRV_InsertDMMResElement function from PROC_Map and put it on >PROC_ReserveMemory. >> >> 2.- Keep DRV_UpdateDMMResElement function in PROC_Map. >> >> 3.- Remove DRV_RemoveDMMResElement function from PROC_UnMap and put it on >ROC_UnReserveMemory function. >> >> 4.- Clear dmmAllocated flag in PROC_UnMap: >> >> pDMMRes->dmmAllocated = 0; > >At this point there's an obvious question; what's the point of >reserving a memory region and not mapping it? > >I remember the answer from Hari was: some clients prefer to reserve a >big region once, and map parts of it continuously. I have my doubts >that the use-case even works with the current code-base. But assuming >it does work, your proposed changes would break it. Resource cleanup does not support that even without my proposed changes. I just proposed a solution which fixes two issues in one patch. Moreover if this change is merged when the second issue be fixed this patch will not needed anymore, so why don't merge the patch which fixes both errors at this moment? Anyway, if you want to include this patch, the only comments we have is: >+ * PROC_UnMap will free memory allocated to p_cur_res >+ * pointer. So we need to save following data for the >+ * execution of PROC_UnReserveMemory() >+ */ >+ void *h_processor = p_cur_res->hProcessor; You could use hProcessor store in p_ctxt instead of p_cur_res, so that you don't need to save hProcessor. >+ u32 dsp_res_addr = p_cur_res->ulDSPResAddr; >+ >+ status = PROC_UnMap(p_cur_res->hProcessor, >+ (void *)p_cur_res->ulDSPAddr, p_ctxt); > >It would be much easier to merge the two functions into one. Yes, I am agreed. > >Anyway, please re-read Ameya's description carefully. > >-- >Felipe Contreras -- 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] dspbridge: Simplify Atoi() method
Hi,
On 2/3/2010 4:14 AM, Andy Shevchenko wrote:
From: Andy Shevchenko
Try to use simple_strtol() kernel native method instead.
strtol or strtoul?
However, there are opened questions:
- why type of Atoi() is s32 if the sign is used only to detect base?
- should we really to check hex integers like DEAD0123h?
- how many spaces could lead token?
Signed-off-by: Andy Shevchenko
---
drivers/dsp/bridge/rmgr/dbdcd.c | 42 +-
1 files changed, 6 insertions(+), 36 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/dbdcd.c b/drivers/dsp/bridge/rmgr/dbdcd.c
index caa57f1..fe2ed57 100644
--- a/drivers/dsp/bridge/rmgr/dbdcd.c
+++ b/drivers/dsp/bridge/rmgr/dbdcd.c
@@ -1002,50 +1002,20 @@ DSP_STATUS DCD_UnregisterObject(IN struct DSP_UUID
*pUuid,
*/
static s32 Atoi(char *pszBuf)
{
- s32 result = 0;
char *pch = pszBuf;
- char c;
- char first;
- s32 base = 10;
- s32 len;
+ s32 base = 0;
while (isspace(*pch))
pch++;
- first = *pch;
- if (first == '-' || first == '+') {
+ if (*pch == '-' || *pch == '+') {
+ base = 10;
pch++;
- } else {
- /* Determine if base 10 or base 16 */
- len = strlen(pch);
- if (len> 1) {
- c = pch[1];
- if ((*pch == '0'&& (c == 'x' || c == 'X'))) {
- base = 16;
- pch += 2;
- }
- c = pch[len - 1];
- if (c == 'h' || c == 'H')
- base = 16;
-
- }
- }
-
- while (isdigit(c = *pch) || ((base == 16)&& isxdigit(c))) {
- result *= base;
- if ('A'<= c&& c<= 'F') {
- c = c - 'A' + 10;
- } else {
- if ('a'<= c&& c<= 'f')
- c = c - 'a' + 10;
- else
- c -= '0';
- }
- result += c;
- ++pch;
+ } else if (*pch&& (pch[strlen(pch) - 1] | 0x20 == 'h')) {
perhaps tolower(x)
otherwise: (pch[strlen(pch) - 1] | 0x20 == 'h')
should be ((pch[strlen(pch) - 1] | 0x20) == 'h')
+ base = 16;
}
- return result;
+ return simple_strtoul(pch, NULL, base);
}
/*
- omar
--
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] DSPBRIDGE: Fix to avoid possible recursive locking
This patch fixes possible recursive locking detection.The implementation
in which the spinlock is acquired and released is rectified in WMD_MSG_Get()
to avoid locking contention.
Added SYNC_EnterCS() and SYNC_LeaveCS()in WMD_MSG_Get()function.
Cc: Ameya Palande
Cc: Omar Ramirez Luna
Cc: Nishanth Menon
Signed-off-by: Deepak Chitriki
---
drivers/dsp/bridge/wmd/msg_sm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
index 50201e5..8faf5ad 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -300,8 +300,10 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
if (LST_IsEmpty(hMsgQueue->msgUsedList))
SYNC_ResetEvent(hMsgQueue->hSyncEvent);
else {
+ (void)SYNC_LeaveCS(hMsgMgr->hSyncCS);
NTFY_Notify(hMsgQueue->hNtfy,
DSP_NODEMESSAGEREADY);
+ (void)SYNC_EnterCS(hMsgMgr->hSyncCS);
SYNC_SetEvent(hMsgQueue->hSyncEvent);
}
@@ -352,8 +354,10 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
hMsgQueue->refCount--;
/* Reset the event if there are still queued messages */
if (!LST_IsEmpty(hMsgQueue->msgUsedList)) {
+ (void)SYNC_LeaveCS(hMsgMgr->hSyncCS);
NTFY_Notify(hMsgQueue->hNtfy,
DSP_NODEMESSAGEREADY);
+ (void)SYNC_EnterCS(hMsgMgr->hSyncCS);
SYNC_SetEvent(hMsgQueue->hSyncEvent);
}
/* Exit critical section */
--
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[V2 1/3]: Update Platform files for SPI
On Tue, Feb 9, 2010 at 4:07 PM, Tony Lindgren wrote: > * Grant Likely [100209 14:38]: >> On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren wrote: >> > * Hemanth V [100203 02:19]: >> >> From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001 >> >> From: Hemanth V >> >> Date: Fri, 27 Nov 2009 14:22:30 +0530 >> >> Subject: [PATCH] Update platform files >> >> >> >> This patch updates platform files for >> >> fifo, slave support >> >> >> >> Signed-off-by: Hemanth V >> > >> > This should get merged via the spi-devel list with the other patches. >> > >> > Acked-by: Tony Lindgren >> >> Personally, I prefer not to carry arch/* changes in my next-spi >> branch, since it means that my pull requests are less obvious for >> Linus and there is greater chance of conflict. >> >> But if you still really want me to merge it through my tree, (or if >> getting the patches out of order will break things) then I'll pick it >> up. Just let me know. > > OK, if you ack it, I'll add the header into omap for-next. That > might break git bisect for some configurations depending in which > order the patches get pulled by Linus.. git bisect breakage is breakage enough. :-) You're right. I should pick this one up. I can see that now that I've had my tea and I'm no longer grumpy. > I guess eventually this header should not live under plat. Any reason the header cannot be moved to include/linux/spi/ now? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes
On Tue, Feb 9, 2010 at 10:22 PM, Guzman Lugo, Fernando wrote: > The root problem here is that remove the DMM element should be in PROC_UnMap > but in PROC_UnReserveMemory, because apart of the problem your are seeing > about memory corruption if the application does a PROC_ReserveMemory and then > it finished unexpectedly the resource cleanup wont be able to unreserved the > memory because there is no a DMMres element in process context struct, the > same applies in the case of application calls PROC_ReserveMemory, PROC_Map, > PROC_UnMap but fails to do the PROC_UnReserveMemory. No, that's a completely different issue, but also valid. > So the right solution should be: > > 1 .- Remove DRV_InsertDMMResElement function from PROC_Map and put it on > PROC_ReserveMemory. > > 2.- Keep DRV_UpdateDMMResElement function in PROC_Map. > > 3.- Remove DRV_RemoveDMMResElement function from PROC_UnMap and put it on > ROC_UnReserveMemory function. > > 4.- Clear dmmAllocated flag in PROC_UnMap: > > pDMMRes->dmmAllocated = 0; At this point there's an obvious question; what's the point of reserving a memory region and not mapping it? I remember the answer from Hari was: some clients prefer to reserve a big region once, and map parts of it continuously. I have my doubts that the use-case even works with the current code-base. But assuming it does work, your proposed changes would break it. It would be much easier to merge the two functions into one. Anyway, please re-read Ameya's description carefully. -- Felipe Contreras -- 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: hsmmc: fix memory leak
* Aaro Koskinen [100208 04:29]:
> The platform data allocated with kmalloc() will become unreachable once
> the init is complete, so it should be freed. The problem was discovered
> by kmemleak.
Looks like this is safe to do as platform_device_add_data does kmemdup
on the data.
BTW, if you want to create a version for 2.6.33, we should still have
enough time to queue it as a fix. It's a very limited size leak though,
but still a leak.
Regards,
Tony
> Signed-off-by: Aaro Koskinen
> ---
> arch/arm/mach-omap2/hsmmc.c |7 ++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
> index 1156b28..9ad2295 100644
> --- a/arch/arm/mach-omap2/hsmmc.c
> +++ b/arch/arm/mach-omap2/hsmmc.c
> @@ -145,6 +145,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
> *controllers)
> {
> struct omap2_hsmmc_info *c;
> int nr_hsmmc = ARRAY_SIZE(hsmmc_data);
> + int i;
>
> if (cpu_is_omap2430()) {
> control_pbias_offset = OMAP243X_CONTROL_PBIAS_LITE;
> @@ -171,7 +172,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
> *controllers)
> GFP_KERNEL);
> if (!mmc) {
> pr_err("Cannot allocate memory for mmc device!\n");
> - return;
> + goto done;
> }
>
> if (c->name)
> @@ -256,6 +257,10 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
> *controllers)
> continue;
> c->dev = mmc->dev;
> }
> +
> +done:
> + for (i = 0; i < nr_hsmmc; i++)
> + kfree(hsmmc_data[i]);
> }
>
> #endif
> --
> 1.5.6.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH[V2 1/3]: Update Platform files for SPI
* Grant Likely [100209 14:38]: > On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren wrote: > > * Hemanth V [100203 02:19]: > >> From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001 > >> From: Hemanth V > >> Date: Fri, 27 Nov 2009 14:22:30 +0530 > >> Subject: [PATCH] Update platform files > >> > >> This patch updates platform files for > >> fifo, slave support > >> > >> Signed-off-by: Hemanth V > > > > This should get merged via the spi-devel list with the other patches. > > > > Acked-by: Tony Lindgren > > Personally, I prefer not to carry arch/* changes in my next-spi > branch, since it means that my pull requests are less obvious for > Linus and there is greater chance of conflict. > > But if you still really want me to merge it through my tree, (or if > getting the patches out of order will break things) then I'll pick it > up. Just let me know. OK, if you ack it, I'll add the header into omap for-next. That might break git bisect for some configurations depending in which order the patches get pulled by Linus.. I guess eventually this header should not live under plat. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH[V2 1/3]: Update Platform files for SPI
On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren wrote: > * Hemanth V [100203 02:19]: >> From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001 >> From: Hemanth V >> Date: Fri, 27 Nov 2009 14:22:30 +0530 >> Subject: [PATCH] Update platform files >> >> This patch updates platform files for >> fifo, slave support >> >> Signed-off-by: Hemanth V > > This should get merged via the spi-devel list with the other patches. > > Acked-by: Tony Lindgren Personally, I prefer not to carry arch/* changes in my next-spi branch, since it means that my pull requests are less obvious for Linus and there is greater chance of conflict. But if you still really want me to merge it through my tree, (or if getting the patches out of order will break things) then I'll pick it up. Just let me know. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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] OMAP3: PM: remove TWL4030 A2S script before reboot
Hi,
* Mike Turquette [100203 11:42]:
> Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is
> necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting
> in the sleep script being executed on TWL4030. This usually results in
> VDD1 & VDD2 voltage collapse while ROM code is executing, followed by an
> MPU Watch Dog reset or worse, an irrecoverable hang.
The first patch is OK is for Samuel, but this needs to be updated
against Paul's clock changes. One comment below too.
> Signed-off-by: Mike Turquette
> ---
> arch/arm/mach-omap2/clock34xx.c | 15 +++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
> index 0d30e53..0d6d1d6 100644
> --- a/arch/arm/mach-omap2/clock34xx.c
> +++ b/arch/arm/mach-omap2/clock34xx.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -311,6 +312,8 @@ struct clk_functions omap2_clk_functions = {
> */
> void omap2_clk_prepare_for_reboot(void)
> {
> + int err = 0;
> +
> /* REVISIT: Not ready for 343x */
> #if 0
> u32 rate;
> @@ -321,6 +324,18 @@ void omap2_clk_prepare_for_reboot(void)
> rate = clk_get_rate(sclk);
> clk_set_rate(vclk, rate);
> #endif
> +
> + /*
> + * PRCM on OMAP3 will drive SYS_OFFMODE low during DPLL3 warm reset.
> + * This causes Gaia sleep script to execute, usually killing VDD1 and
> + * VDD2 while code is running. WA is to disable the sleep script
> + * before warm reset.
> + */
> +#ifdef CONFIG_TWL4030_POWER
> + err = twl4030_remove_script(TWL4030_SLEEP_SCRIPT);
> + if (err)
> + pr_err("twl4030: error trying to disable sleep script!\n");
> +#endif
This needs to work in cases where we have multiple companion chips
compiled in. You may have twl4030 support compiled in, but no twl4030
hardware on the board. It needs to be based on I2C detected chips during
init somehow.
In the omap for-next branch we already support booting 2420, 34xx, 36xx
and 4430 with the same kernel binary. So please update accordingly.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH[V2 1/3]: Update Platform files for SPI
* Hemanth V [100203 02:19]:
> From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001
> From: Hemanth V
> Date: Fri, 27 Nov 2009 14:22:30 +0530
> Subject: [PATCH] Update platform files
>
> This patch updates platform files for
> fifo, slave support
>
> Signed-off-by: Hemanth V
This should get merged via the spi-devel list with the other patches.
Acked-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/devices.c |5 +
> arch/arm/plat-omap/include/plat/mcspi.h | 29 -
> 2
> files changed, 33 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 733d3dc..79b5396 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -282,6 +282,7 @@ static inline void omap_init_sti(void) {}
>
> static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
> .num_cs = 4,
> + .force_cs_mode = 1,
> };
>
> static struct resource omap2_mcspi1_resources[] = {
> @@ -304,6 +305,10 @@ static struct platform_device omap2_mcspi1 = {
>
> static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
> .num_cs = 2,
> + .mode = OMAP2_MCSPI_MASTER,
> + .dma_mode = 0,
> + .force_cs_mode = 0,
> + .fifo_depth = 0,
> };
>
> static struct resource omap2_mcspi2_resources[] = {
> diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
> b/arch/arm/plat-omap/include/plat/mcspi.h
> index 1254e49..ffda0a1 100644
> --- a/arch/arm/plat-omap/include/plat/mcspi.h
> +++ b/arch/arm/plat-omap/include/plat/mcspi.h
> @@ -1,8 +1,35 @@
> #ifndef _OMAP2_MCSPI_H
> #define _OMAP2_MCSPI_H
>
> +#define OMAP2_MCSPI_MASTER 0
> +#define OMAP2_MCSPI_SLAVE1
> +
> +/**
> + * struct omap2_mcspi_platform_config - McSPI controller configuration + *
> @num_cs: Number of chip selects or channels supported
> + * @mode: SPI is master or slave
> + * @dma_mode: Use only DMA for data transfers
> + * @force_cs_mode: Use force chip select mode or auto chip select mode + *
> @fifo_depth: FIFO depth in bytes, max value 64
> + *
> + * @dma_mode when set to 1 uses only dma for data transfers
> + * else the default behaviour is to use PIO mode for transfer
> + * size of 8 bytes or less. This mode is useful when mcspi
> + * is configured as slave
> + *
> + * @force_cs_mode when set to 1 allows continuous transfer of multiple + *
> spi
> words without toggling the chip select line.
> + *
> + * @fifo_depth when set to non zero values enables FIFO. fifo_depth + *
> should
> be set as a multiple of buffer size used for read/write. + */
> +
> struct omap2_mcspi_platform_config {
> - unsigned short num_cs;
> + u8 num_cs;
> + u8 mode;
> + u8 dma_mode;
> + u8 force_cs_mode;
> + unsigned short fifo_depth;
> };
>
> struct omap2_mcspi_device_config {
> --
> 1.5.6.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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] Allow change timing values to wait slow devices bring up before try register an interface to IP-Config (used on some drivers using Multi-purpose USB Networking Framework)
Hi, * Tiago Maluta [100206 15:28]: > I'd like to know if this patch could be considered an general use or > an particular case. This is Linux generic, so it should get sent to linux-usb and net lists instead. Regards, Tony > > --tm > > Signed-off-by: Tiago Maluta > --- > drivers/net/usb/Kconfig | 17 + > net/ipv4/ipconfig.c |4 ++-- > 2 files changed, 19 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig > index 32d9356..5b84e57 100644 > --- a/drivers/net/usb/Kconfig > +++ b/drivers/net/usb/Kconfig > @@ -127,6 +127,23 @@ config USB_USBNET > To compile this driver as a module, choose M here: the > module will be called usbnet. > > + > +config USB_USBNETDEVICE_DELAY_PRE > + int "Define the friendly delay before opening net devices " > + depends on USB_USBNET > + default 500 > + help > + Some devices may not work due to a delay from hardware bring the > interface > + up. This value added a delay before search and register the > interface. > + > +config USB_USBNETDEVICE_DELAY_POST > + int "Define the friendly delay after opening net devices " > + depends on USB_USBNET > + default 1 > + help > + Some devices may not work due to a delay from hardware bring the > interface > + up. This value added a delay before search and register the > interface. > + > config USB_NET_AX8817X > tristate "ASIX AX88xxx Based USB 2.0 Ethernet Adapters" > depends on USB_USBNET > diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c > index 10a6a60..3faac07 100644 > --- a/net/ipv4/ipconfig.c > +++ b/net/ipv4/ipconfig.c > @@ -86,8 +86,8 @@ > #endif > > /* Define the friendly delay before and after opening net devices */ > -#define CONF_PRE_OPEN500 /* Before opening: 1/2 second */ > -#define CONF_POST_OPEN 1 /* After opening: 1 second */ > +#define CONF_PRE_OPENCONFIG_USB_USBNETDEVICE_DELAY_PRE > /* Before > opening. Default 1/2 second */ > +#define CONF_POST_OPEN CONFIG_USB_USBNETDEVICE_DELAY_POST > /* After > opening. Default 1 second */ > > /* Define the timeout for waiting for a DHCP/BOOTP/RARP reply */ > #define CONF_OPEN_RETRIES2 /* (Re)open devices twice */ > -- > 1.6.4.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 -- 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] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes
Hi, >-Original Message- >From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >ow...@vger.kernel.org] On Behalf Of Felipe Contreras >Sent: Tuesday, February 09, 2010 6:30 AM >To: Ameya Palande >Cc: linux-omap@vger.kernel.org; Ramirez Luna, Omar; Menon, Nishanth; >Chitriki Rudramuni, Deepak; felipe.contre...@nokia.com; ext- >phil.2.carm...@nokia.com >Subject: Re: [PATCH] DSPBRIDGE: Prevent memory corruption in >DRV_ProcFreeDMMRes > >On Mon, Feb 8, 2010 at 10:25 PM, Ameya Palande >wrote: >> Background: bridge_close() has the responsibility to cleanup all the >> resources allocated by user space process. One of those resources is >> DMMRes which is used for tracking DMM resource allocation done in >> PROC_Map() and PROC_UnMap(). >> >> DRV_ProcFreeDMMRes() function was used for cleaning up DMMRes has >following >> problems which are fixed by this patch: >> >> 1. It access and modifies pDMMRes pointer when it is already freed by >> PROC_UnMap() >> 2. Instead of passing ulDSPAddr it passes ulDSPResAddr to PROC_UnMap() >which >> will not retrive correct DMMRes element. > >This patch is doing the right thing to me, however, it's a bit >difficult to review because it's doing many changes at once. > >Personally I would > 1) Fix the wrong dereferences in DRV_ProcFreeDMMRes >[at this point the bug should be fixed] >[the leaks would be freed by the outer loop] > > 2) Fix the wrong PROC_UnMap address passed in DRV_ProcFreeDMMRes > 3) Remove the unnecessary outer loop in DRV_RemoveAllDMMResElements >[at this point the code would actually make sense] > > 4) Merge DRV_ProcFreeDMMRes into DRV_RemoveAllDMMResElements > 5) Improve coding style > >The end result would be the same, but easier to see what's going on :) > >Cheers. > >-- >Felipe Contreras The root problem here is that remove the DMM element should be in PROC_UnMap but in PROC_UnReserveMemory, because apart of the problem your are seeing about memory corruption if the application does a PROC_ReserveMemory and then it finished unexpectedly the resource cleanup wont be able to unreserved the memory because there is no a DMMres element in process context struct, the same applies in the case of application calls PROC_ReserveMemory, PROC_Map, PROC_UnMap but fails to do the PROC_UnReserveMemory. So the right solution should be: 1 .- Remove DRV_InsertDMMResElement function from PROC_Map and put it on PROC_ReserveMemory. 2.- Keep DRV_UpdateDMMResElement function in PROC_Map. 3.- Remove DRV_RemoveDMMResElement function from PROC_UnMap and put it on ROC_UnReserveMemory function. 4.- Clear dmmAllocated flag in PROC_UnMap: pDMMRes->dmmAllocated = 0; 5 .- in the function DRV_ProcFreeDMMRes, call PROC_UnMap "if (pDMMRes->dmmAllocated)" and always call PROC_UnReserveMemory not in this point is not needed the save hProcessor nor ulDSPResAddr addresses. 6 .- cleanup DRV_RemoveAllDMMResElements function (while loop is not needed). Regards, Fernando. >-- >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] DSPBRIDGE: Add BRD_SLEEP_TRANSITION in PROC_GetState
>From 40d5863c3d3f4091761fef8bff581d2a7b1f32fa Mon Sep 17 00:00:00 2001 From: Ernesto Ramos Date: Tue, 2 Feb 2010 20:30:19 -0600 Subject: [PATCH] DSPBRIDGE: Add BRD_SLEEP_TRANSITION in PROC_GetState. When PROC_GetState checks for BRD status it is not taking into account the state BRD_SLEEP_TRANSITION and it is returning DSP_EFAIL when this happens, which is wrong. This fix adds this check to return ProcStatus as PROC_RUNNING and status DSP_SOK when this happens. Signed-off-by: Ernesto Ramos --- drivers/dsp/bridge/rmgr/proc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c index a1d06dc..553c9a7 100644 --- a/drivers/dsp/bridge/rmgr/proc.c +++ b/drivers/dsp/bridge/rmgr/proc.c @@ -802,6 +802,7 @@ DSP_STATUS PROC_GetState(DSP_HPROCESSOR hProcessor, case BRD_STOPPED: pProcStatus->iState = PROC_STOPPED; break; + case BRD_SLEEP_TRANSITION: case BRD_DSP_HIBERNATION: /* Fall through */ case BRD_RUNNING: -- 1.5.4.5 -- 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
SR2:VDD autocomp is not active ::: BeagleBoard Halts
Hi all, I have the following very odd observation, can anyone please elaborate on why this could be happening and possible solutions to it. When running beagleboard with android image, After running a userspace application for a while the board prints the following: SR2:VDD autocomp is not active and simply halts!!!.. Note: Smart reflex is enabled in the linux kernel... Any help would be appreciated... Thanks Best Regards Mai -- 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] DSPBRIDGE: Validate node handle from user
>-Original Message-
>From: Ameya Palande [mailto:ameya.pala...@nokia.com]
>Sent: Tuesday, February 09, 2010 11:32 AM
>To: Ramos Falcon, Ernesto
>Cc: linux-omap@vger.kernel.org; Contreras Felipe (Nokia-D/Helsinki); Doyu
>Hiroshi (Nokia-D/Helsinki)
>Subject: Re: [PATCH] DSPBRIDGE: Validate node handle from user
>
>Hi Ernesto,
>
>On Tue, 2010-02-09 at 18:08 +0100, ext Ramos Falcon, Ernesto wrote:
>> From 8310b586b025b0703c3951560849c4ea0250b6e1 Mon Sep 17 00:00:00 2001
>> From: Ernesto Ramos
>> Date: Fri, 29 Jan 2010 16:21:59 -0600
>> Subject: [PATCH] DSPBRIDGE: Validate node handle from user.
>>
>> Add checks to validate the node handles received from user.
>>
>> Signed-off-by: Ernesto Ramos
>> ---
>> drivers/dsp/bridge/pmgr/wcd.c | 91 -
>> drivers/dsp/bridge/rmgr/node.c | 174 +-
>-
>> 2 files changed, 146 insertions(+), 119 deletions(-)
>>
>> diff --git a/drivers/dsp/bridge/pmgr/wcd.c
>b/drivers/dsp/bridge/pmgr/wcd.c
>> index 74654dc..2e6eeb0 100644
>> --- a/drivers/dsp/bridge/pmgr/wcd.c
>> +++ b/drivers/dsp/bridge/pmgr/wcd.c
>> @@ -1066,6 +1066,24 @@ u32 PROCWRAP_Stop(union Trapped_Args *args, void
>*pr_ctxt)
>> return retVal;
>> }
>>
>> +bool validate_node_handle(struct NODE_OBJECT *hNode, void *pr_ctxt)
>> +{
>> + bool retVal = false;
>> + struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
>> + struct NODE_RES_OBJECT *pNode = pCtxt->pNodeList;
>> +
>> + if (hNode == (struct NODE_OBJECT *) DSP_HGPPNODE)
>> + retVal = true;
>> +
>> + while (pNode && !retVal) {
>> + if (hNode == pNode->hNode)
>
>If you have several nodes allocated by user space, then what you are
>validating here is for any node! Is that ok?
>
>This validation and design itself doesn't look good to me. If we don't
>want to trust user space, then instead of checking the node handle in
>every function it is better to store all user space specific date inside
>pr_context and use it from there.
>
The user can launch several nodes, how are we going to know which node handle
to use?
I think we may need to receive at least one index or id to the node handle.
>Cheers,
>Ameya.
--
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] DSPBRIDGE: Validate Processor Handle from user
>-Original Message- >From: Ameya Palande [mailto:ameya.pala...@nokia.com] >Sent: Tuesday, February 09, 2010 11:27 AM >To: Ramos Falcon, Ernesto >Cc: linux-omap@vger.kernel.org; Contreras Felipe (Nokia-D/Helsinki); Doyu >Hiroshi (Nokia-D/Helsinki) >Subject: Re: [PATCH] DSPBRIDGE: Validate Processor Handle from user > >Hi Ernesto, > >On Tue, 2010-02-09 at 18:07 +0100, ext Ramos Falcon, Ernesto wrote: >> From 07b9f6d30c9d363ba0c4cefded8068662e1048c4 Mon Sep 17 00:00:00 2001 >> From: Ernesto Ramos >> Date: Wed, 3 Feb 2010 19:43:31 -0600 >> Subject: [PATCH] DSPBRIDGE: Validate Processor Handle from user. >> >> Add check to validate the Processor handle received >> from user. >> >> Signed-off-by: Ernesto Ramos >> --- >> drivers/dsp/bridge/pmgr/wcd.c | 86 - >> drivers/dsp/bridge/rmgr/proc.c | 280 ++ >-- >> 2 files changed, 179 insertions(+), 187 deletions(-) > >My understanding: In bridge_open() we allocate a new process_context and >store it in filp->private_data which can't be modified / tampered by >user space. > >If this understanding is correct, then why we need to perform any >validation on data hold be process_context pointer stored in >flip->private_data? > >If you don't trust hProcessor handle received from user space arguments >then instead of using that we can just use pCtxt->hProcessor! > Agree. We plan to remove the Proc Attach and remove the parameter hProcessor handle passed to the user but we have not done it yet because it may impact the API. >I don't understand why we need validation so NACK from my side. > We have had some cases where we receive an invalid proc handle from user which resulted in kernel panic. >Cheers, >Ameya. -- 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] DSPBRIDGE: Validate stream handle from user
Hi Ernesto,
On Tue, 2010-02-09 at 18:09 +0100, ext Ramos Falcon, Ernesto wrote:
> From 991bd676e160a5500cb511a78afcac838ff003e4 Mon Sep 17 00:00:00 2001
> From: Ernesto Ramos
> Date: Fri, 29 Jan 2010 20:00:26 -0600
> Subject: [PATCH] DSPBRIDGE: Validate stream handle from user.
>
> Add checks to verify strm handle from user.
>
> Signed-off-by: Ernesto Ramos
> ---
> drivers/dsp/bridge/pmgr/wcd.c | 42 +
> drivers/dsp/bridge/rmgr/strm.c | 134 ---
> 2 files changed, 97 insertions(+), 79 deletions(-)
>
> diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
> index 2e6eeb0..78c7acd 100644
> --- a/drivers/dsp/bridge/pmgr/wcd.c
> +++ b/drivers/dsp/bridge/pmgr/wcd.c
> @@ -1517,6 +1517,22 @@ func_cont:
> return status;
> }
>
> +
> +bool validate_strm_handle(struct STRM_OBJECT *hStrm, void *pr_ctxt)
> +{
> + bool retVal = false;
> + struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
> + struct STRM_RES_OBJECT *pStrm = pCtxt->pSTRMList;
> +
> + while (pStrm && !retVal) {
> + if (hStrm == pStrm->hStream)
If you have several streams allocated by user space, then what you are
validating here is for any node! Is that ok?
This validation and design itself doesn't look good to me. If we don't
want to trust user space, then instead of checking the stream handle in
every function it is better to store all user space specific date inside
pr_context and use it from there.
Cheers,
Ameya.
--
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] DSPBRIDGE: Validate node handle from user
Hi Ernesto,
On Tue, 2010-02-09 at 18:08 +0100, ext Ramos Falcon, Ernesto wrote:
> From 8310b586b025b0703c3951560849c4ea0250b6e1 Mon Sep 17 00:00:00 2001
> From: Ernesto Ramos
> Date: Fri, 29 Jan 2010 16:21:59 -0600
> Subject: [PATCH] DSPBRIDGE: Validate node handle from user.
>
> Add checks to validate the node handles received from user.
>
> Signed-off-by: Ernesto Ramos
> ---
> drivers/dsp/bridge/pmgr/wcd.c | 91 -
> drivers/dsp/bridge/rmgr/node.c | 174 +--
> 2 files changed, 146 insertions(+), 119 deletions(-)
>
> diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
> index 74654dc..2e6eeb0 100644
> --- a/drivers/dsp/bridge/pmgr/wcd.c
> +++ b/drivers/dsp/bridge/pmgr/wcd.c
> @@ -1066,6 +1066,24 @@ u32 PROCWRAP_Stop(union Trapped_Args *args, void
> *pr_ctxt)
> return retVal;
> }
>
> +bool validate_node_handle(struct NODE_OBJECT *hNode, void *pr_ctxt)
> +{
> + bool retVal = false;
> + struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
> + struct NODE_RES_OBJECT *pNode = pCtxt->pNodeList;
> +
> + if (hNode == (struct NODE_OBJECT *) DSP_HGPPNODE)
> + retVal = true;
> +
> + while (pNode && !retVal) {
> + if (hNode == pNode->hNode)
If you have several nodes allocated by user space, then what you are
validating here is for any node! Is that ok?
This validation and design itself doesn't look good to me. If we don't
want to trust user space, then instead of checking the node handle in
every function it is better to store all user space specific date inside
pr_context and use it from there.
Cheers,
Ameya.
--
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] DSPBRIDGE: Validate Processor Handle from user
Hi Ernesto, On Tue, 2010-02-09 at 18:07 +0100, ext Ramos Falcon, Ernesto wrote: > From 07b9f6d30c9d363ba0c4cefded8068662e1048c4 Mon Sep 17 00:00:00 2001 > From: Ernesto Ramos > Date: Wed, 3 Feb 2010 19:43:31 -0600 > Subject: [PATCH] DSPBRIDGE: Validate Processor Handle from user. > > Add check to validate the Processor handle received > from user. > > Signed-off-by: Ernesto Ramos > --- > drivers/dsp/bridge/pmgr/wcd.c | 86 - > drivers/dsp/bridge/rmgr/proc.c | 280 > ++-- > 2 files changed, 179 insertions(+), 187 deletions(-) My understanding: In bridge_open() we allocate a new process_context and store it in filp->private_data which can't be modified / tampered by user space. If this understanding is correct, then why we need to perform any validation on data hold be process_context pointer stored in flip->private_data? If you don't trust hProcessor handle received from user space arguments then instead of using that we can just use pCtxt->hProcessor! I don't understand why we need validation so NACK from my side. Cheers, Ameya. -- 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] DSPBRIDGE: Validate stream handle from user
>From 991bd676e160a5500cb511a78afcac838ff003e4 Mon Sep 17 00:00:00 2001
From: Ernesto Ramos
Date: Fri, 29 Jan 2010 20:00:26 -0600
Subject: [PATCH] DSPBRIDGE: Validate stream handle from user.
Add checks to verify strm handle from user.
Signed-off-by: Ernesto Ramos
---
drivers/dsp/bridge/pmgr/wcd.c | 42 +
drivers/dsp/bridge/rmgr/strm.c | 134 ---
2 files changed, 97 insertions(+), 79 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 2e6eeb0..78c7acd 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1517,6 +1517,22 @@ func_cont:
return status;
}
+
+bool validate_strm_handle(struct STRM_OBJECT *hStrm, void *pr_ctxt)
+{
+ bool retVal = false;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
+ struct STRM_RES_OBJECT *pStrm = pCtxt->pSTRMList;
+
+ while (pStrm && !retVal) {
+ if (hStrm == pStrm->hStream)
+ retVal = true;
+ pStrm = pStrm->next;
+ }
+
+ return retVal;
+}
+
/*
* STRMWRAP_AllocateBuffer
*/
@@ -1526,6 +1542,10 @@ u32 STRMWRAP_AllocateBuffer(union Trapped_Args *args,
void *pr_ctxt)
u8 **apBuffer = NULL;
u32 uNumBufs = args->ARGS_STRM_ALLOCATEBUFFER.uNumBufs;
+ if (!validate_strm_handle(args->ARGS_STRM_ALLOCATEBUFFER.hStream,
+ pr_ctxt))
+ return DSP_EHANDLE;
+
if (uNumBufs > MAX_BUFS)
return DSP_EINVALIDARG;
@@ -1555,6 +1575,9 @@ u32 STRMWRAP_AllocateBuffer(union Trapped_Args *args,
void *pr_ctxt)
*/
u32 STRMWRAP_Close(union Trapped_Args *args, void *pr_ctxt)
{
+ if (!validate_strm_handle(args->ARGS_STRM_CLOSE.hStream, pr_ctxt))
+ return DSP_EHANDLE;
+
return STRM_Close(args->ARGS_STRM_CLOSE.hStream, pr_ctxt);
}
@@ -1567,6 +1590,9 @@ u32 STRMWRAP_FreeBuffer(union Trapped_Args *args, void
*pr_ctxt)
u8 **apBuffer = NULL;
u32 uNumBufs = args->ARGS_STRM_FREEBUFFER.uNumBufs;
+ if (!validate_strm_handle(args->ARGS_STRM_FREEBUFFER.hStream, pr_ctxt))
+ return DSP_EHANDLE;
+
if (uNumBufs > MAX_BUFS)
return DSP_EINVALIDARG;
@@ -1605,6 +1631,9 @@ u32 STRMWRAP_GetInfo(union Trapped_Args *args, void
*pr_ctxt)
struct DSP_STREAMINFO user;
struct DSP_STREAMINFO *temp;
+ if (!validate_strm_handle(args->ARGS_STRM_GETINFO.hStream, pr_ctxt))
+ return DSP_EHANDLE;
+
cp_fm_usr(&strmInfo, args->ARGS_STRM_GETINFO.pStreamInfo, status, 1);
temp = strmInfo.pUser;
@@ -1627,6 +1656,9 @@ u32 STRMWRAP_Idle(union Trapped_Args *args, void *pr_ctxt)
{
u32 retVal;
+ if (!validate_strm_handle(args->ARGS_STRM_IDLE.hStream, pr_ctxt))
+ return DSP_EHANDLE;
+
retVal = STRM_Idle(args->ARGS_STRM_IDLE.hStream,
args->ARGS_STRM_IDLE.bFlush);
@@ -1640,6 +1672,9 @@ u32 STRMWRAP_Issue(union Trapped_Args *args, void
*pr_ctxt)
{
DSP_STATUS status = DSP_SOK;
+ if (!validate_strm_handle(args->ARGS_STRM_ISSUE.hStream, pr_ctxt))
+ return DSP_EHANDLE;
+
if (!args->ARGS_STRM_ISSUE.pBuffer)
return DSP_EPOINTER;
@@ -1699,6 +1734,9 @@ u32 STRMWRAP_Reclaim(union Trapped_Args *args, void
*pr_ctxt)
u32 dwArg;
u32 ulBufSize;
+ if (!validate_strm_handle(args->ARGS_STRM_RECLAIM.hStream, pr_ctxt))
+ return DSP_EHANDLE;
+
status = STRM_Reclaim(args->ARGS_STRM_RECLAIM.hStream, &pBufPtr,
&ulBytes, &ulBufSize, &dwArg);
cp_to_usr(args->ARGS_STRM_RECLAIM.pBufPtr, &pBufPtr, status, 1);
@@ -1724,6 +1762,10 @@ u32 STRMWRAP_RegisterNotify(union Trapped_Args *args,
void *pr_ctxt)
GT_0trace(WCD_debugMask, GT_ENTER,
"NODEWRAP_RegisterNotify: entered\n");
+ if (!validate_strm_handle(args->ARGS_STRM_REGISTERNOTIFY.hStream,
+ pr_ctxt))
+ return DSP_EHANDLE;
+
/* Initialize the notification data structure */
notification.psName = NULL;
notification.handle = NULL;
diff --git a/drivers/dsp/bridge/rmgr/strm.c b/drivers/dsp/bridge/rmgr/strm.c
index 6be8083..2da6bf0 100644
--- a/drivers/dsp/bridge/rmgr/strm.c
+++ b/drivers/dsp/bridge/rmgr/strm.c
@@ -121,16 +121,11 @@ DSP_STATUS STRM_AllocateBuffer(struct STRM_OBJECT *hStrm,
u32 uSize,
GT_4trace(STRM_debugMask, GT_ENTER, "STRM_AllocateBuffer: hStrm: 0x%x\t"
"uSize: 0x%x\tapBuffer: 0x%x\tuNumBufs: 0x%x\n",
hStrm, uSize, apBuffer, uNumBufs);
- if (MEM_IsValidHandle(hStrm, STRM_SIGNATURE)) {
- /*
-* Allocate from segment specified at time of stream open.
-*/
- if (uSize == 0)
- status = DSP_ESIZE;
-
- } else {
- status = DSP_EH
[PATCH] DSPBRIDGE: Validate node handle from user
>From 8310b586b025b0703c3951560849c4ea0250b6e1 Mon Sep 17 00:00:00 2001
From: Ernesto Ramos
Date: Fri, 29 Jan 2010 16:21:59 -0600
Subject: [PATCH] DSPBRIDGE: Validate node handle from user.
Add checks to validate the node handles received from user.
Signed-off-by: Ernesto Ramos
---
drivers/dsp/bridge/pmgr/wcd.c | 91 -
drivers/dsp/bridge/rmgr/node.c | 174 +--
2 files changed, 146 insertions(+), 119 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 74654dc..2e6eeb0 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1066,6 +1066,24 @@ u32 PROCWRAP_Stop(union Trapped_Args *args, void
*pr_ctxt)
return retVal;
}
+bool validate_node_handle(struct NODE_OBJECT *hNode, void *pr_ctxt)
+{
+ bool retVal = false;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
+ struct NODE_RES_OBJECT *pNode = pCtxt->pNodeList;
+
+ if (hNode == (struct NODE_OBJECT *) DSP_HGPPNODE)
+ retVal = true;
+
+ while (pNode && !retVal) {
+ if (hNode == pNode->hNode)
+ retVal = true;
+ pNode = pNode->next;
+ }
+
+ return retVal;
+}
+
/*
* NODEWRAP_Allocate
*/
@@ -1140,6 +1158,10 @@ u32 NODEWRAP_AllocMsgBuf(union Trapped_Args *args, void
*pr_ctxt)
if (!args->ARGS_NODE_ALLOCMSGBUF.uSize)
return DSP_ESIZE;
+ if (!validate_node_handle(args->ARGS_NODE_ALLOCMSGBUF.hNode,
+ pr_ctxt))
+ return DSP_EHANDLE;
+
if (args->ARGS_NODE_ALLOCMSGBUF.pAttr) {/* Optional argument */
cp_fm_usr(&attr, args->ARGS_NODE_ALLOCMSGBUF.pAttr, status, 1);
if (DSP_SUCCEEDED(status))
@@ -1148,6 +1170,7 @@ u32 NODEWRAP_AllocMsgBuf(union Trapped_Args *args, void
*pr_ctxt)
}
/* IN OUT argument */
cp_fm_usr(&pBuffer, args->ARGS_NODE_ALLOCMSGBUF.pBuffer, status, 1);
+
if (DSP_SUCCEEDED(status)) {
status = NODE_AllocMsgBuf(args->ARGS_NODE_ALLOCMSGBUF.hNode,
args->ARGS_NODE_ALLOCMSGBUF.uSize,
@@ -1166,6 +1189,11 @@ u32 NODEWRAP_ChangePriority(union Trapped_Args *args,
void *pr_ctxt)
GT_0trace(WCD_debugMask, GT_ENTER,
"NODEWRAP_ChangePriority: entered\n");
+
+ if (!validate_node_handle(args->ARGS_NODE_CHANGEPRIORITY.hNode,
+ pr_ctxt))
+ return DSP_EHANDLE;
+
retVal = NODE_ChangePriority(args->ARGS_NODE_CHANGEPRIORITY.hNode,
args->ARGS_NODE_CHANGEPRIORITY.iPriority);
@@ -1186,6 +1214,13 @@ u32 NODEWRAP_Connect(union Trapped_Args *args, void
*pr_ctxt)
GT_0trace(WCD_debugMask, GT_ENTER, "NODEWRAP_Connect: entered\n");
+ if (!validate_node_handle(args->ARGS_NODE_CONNECT.hNode,
+ pr_ctxt) ||
+ !validate_node_handle(args->ARGS_NODE_CONNECT.hOtherNode,
+ pr_ctxt)) {
+ status = DSP_EHANDLE;
+ goto func_cont;
+ }
/* Optional argument */
if (pSize) {
if (get_user(cbDataSize, pSize))
@@ -1211,6 +1246,7 @@ u32 NODEWRAP_Connect(union Trapped_Args *args, void
*pr_ctxt)
pAttrs = &attrs;
}
+
if (DSP_SUCCEEDED(status)) {
status = NODE_Connect(args->ARGS_NODE_CONNECT.hNode,
args->ARGS_NODE_CONNECT.uStream,
@@ -1233,6 +1269,11 @@ u32 NODEWRAP_Create(union Trapped_Args *args, void
*pr_ctxt)
u32 retVal;
GT_0trace(WCD_debugMask, GT_ENTER, "NODEWRAP_Create: entered\n");
+
+ if (!validate_node_handle(args->ARGS_NODE_CREATE.hNode,
+ pr_ctxt))
+ return DSP_EHANDLE;
+
retVal = NODE_Create(args->ARGS_NODE_CREATE.hNode);
return retVal;
@@ -1246,6 +1287,11 @@ u32 NODEWRAP_Delete(union Trapped_Args *args, void
*pr_ctxt)
u32 retVal;
GT_0trace(WCD_debugMask, GT_ENTER, "NODEWRAP_Delete: entered\n");
+
+ if (!validate_node_handle(args->ARGS_NODE_DELETE.hNode,
+ pr_ctxt))
+ return DSP_EHANDLE;
+
retVal = NODE_Delete(args->ARGS_NODE_DELETE.hNode, pr_ctxt);
return retVal;
@@ -1259,6 +1305,14 @@ u32 NODEWRAP_FreeMsgBuf(union Trapped_Args *args, void
*pr_ctxt)
DSP_STATUS status = DSP_SOK;
struct DSP_BUFFERATTR *pAttr = NULL;
struct DSP_BUFFERATTR attr;
+
+ if (!args->ARGS_NODE_FREEMSGBUF.pBuffer)
+ return DSP_EPOINTER;
+
+ if (!validate_node_handle(args->ARGS_NODE_FREEMSGBUF.hNode,
+ pr_ctxt))
+ return DSP_EHANDLE;
+
if (args->ARGS_NODE_FREEMSGBUF.pAttr) { /* Optional argument */
cp_fm_usr(&attr, args->ARGS_NODE_FREEMSGBUF.pAttr, status, 1);
if (DSP_SUCCEEDED(status))
@@ -1266,9 +1320,6 @@ u32 NODE
[PATCH] DSPBRIDGE: Validate Processor Handle from user
>From 07b9f6d30c9d363ba0c4cefded8068662e1048c4 Mon Sep 17 00:00:00 2001
From: Ernesto Ramos
Date: Wed, 3 Feb 2010 19:43:31 -0600
Subject: [PATCH] DSPBRIDGE: Validate Processor Handle from user.
Add check to validate the Processor handle received
from user.
Signed-off-by: Ernesto Ramos
---
drivers/dsp/bridge/pmgr/wcd.c | 86 -
drivers/dsp/bridge/rmgr/proc.c | 280 ++--
2 files changed, 179 insertions(+), 187 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 78c7acd..020abbc 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -608,6 +608,7 @@ u32 PROCWRAP_Ctrl(union Trapped_Args *args, void *pr_ctxt)
args->ARGS_PROC_CTRL.pArgs;
u8 *pArgs = NULL;
DSP_STATUS status = DSP_SOK;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_3trace(WCD_debugMask, GT_ENTER,
"PROCWRAP_Ctrl: entered args:\n 0x%x"
@@ -615,6 +616,10 @@ u32 PROCWRAP_Ctrl(union Trapped_Args *args, void *pr_ctxt)
args->ARGS_PROC_CTRL.hProcessor,
args->ARGS_PROC_CTRL.dwCmd,
args->ARGS_PROC_CTRL.pArgs);
+ if (args->ARGS_PROC_CTRL.hProcessor != pCtxt->hProcessor) {
+ status = DSP_EHANDLE;
+ goto func_end;
+ }
if (pSize) {
if (get_user(cbDataSize, pSize)) {
status = DSP_EFAIL;
@@ -669,6 +674,7 @@ u32 PROCWRAP_EnumNode_Info(union Trapped_Args *args, void
*pr_ctxt)
DSP_HNODE aNodeTab[MAX_NODES];
u32 uNumNodes;
u32 uAllocated;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_5trace(WCD_debugMask, GT_ENTER,
"PROCWRAP_EnumNode_Info:entered args:\n0x"
@@ -680,6 +686,9 @@ u32 PROCWRAP_EnumNode_Info(union Trapped_Args *args, void
*pr_ctxt)
args->ARGS_PROC_ENUMNODE_INFO.puNumNodes,
args->ARGS_PROC_ENUMNODE_INFO.puAllocated);
+ if (args->ARGS_PROC_ENUMNODE_INFO.hProcessor != pCtxt->hProcessor)
+ return DSP_EHANDLE;
+
if (!args->ARGS_PROC_ENUMNODE_INFO.uNodeTabSize)
return DSP_ESIZE;
@@ -702,9 +711,13 @@ u32 PROCWRAP_EnumNode_Info(union Trapped_Args *args, void
*pr_ctxt)
u32 PROCWRAP_FlushMemory(union Trapped_Args *args, void *pr_ctxt)
{
DSP_STATUS status;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_0trace(WCD_debugMask, GT_ENTER, "PROCWRAP_FlushMemory: entered\n");
+ if (args->ARGS_PROC_FLUSHMEMORY.hProcessor != pCtxt->hProcessor)
+ return DSP_EHANDLE;
+
if (args->ARGS_PROC_FLUSHMEMORY.ulFlags > PROC_WRBK_INV_ALL)
return DSP_EINVALIDARG;
@@ -722,10 +735,14 @@ u32 PROCWRAP_FlushMemory(union Trapped_Args *args, void
*pr_ctxt)
u32 PROCWRAP_InvalidateMemory(union Trapped_Args *args, void *pr_ctxt)
{
DSP_STATUS status;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_0trace(WCD_debugMask, GT_ENTER,
"PROCWRAP_InvalidateMemory:entered\n");
+ if (args->ARGS_PROC_INVALIDATEMEMORY.hProcessor != pCtxt->hProcessor)
+ return DSP_EHANDLE;
+
status = PROC_InvalidateMemory(
args->ARGS_PROC_INVALIDATEMEMORY.hProcessor,
args->ARGS_PROC_INVALIDATEMEMORY.pMpuAddr,
@@ -741,6 +758,7 @@ u32 PROCWRAP_EnumResources(union Trapped_Args *args, void
*pr_ctxt)
{
DSP_STATUS status = DSP_SOK;
struct DSP_RESOURCEINFO pResourceInfo;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_4trace(WCD_debugMask, GT_ENTER,
"PROCWRAP_EnumResources: entered args:\n"
@@ -751,6 +769,9 @@ u32 PROCWRAP_EnumResources(union Trapped_Args *args, void
*pr_ctxt)
args->ARGS_PROC_ENUMRESOURCES.pResourceInfo,
args->ARGS_PROC_ENUMRESOURCES.uResourceInfoSize);
+ if (args->ARGS_PROC_ENUMRESOURCES.hProcessor != pCtxt->hProcessor)
+ return DSP_EHANDLE;
+
if (args->ARGS_PROC_ENUMRESOURCES.uResourceInfoSize <
sizeof(struct DSP_RESOURCEINFO))
return DSP_ESIZE;
@@ -774,8 +795,13 @@ u32 PROCWRAP_GetState(union Trapped_Args *args, void
*pr_ctxt)
{
DSP_STATUS status;
struct DSP_PROCESSORSTATE procStatus;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
+
GT_0trace(WCD_debugMask, GT_ENTER, "PROCWRAP_GetState: entered\n");
+ if (args->ARGS_PROC_GETSTATE.hProcessor != pCtxt->hProcessor)
+ return DSP_EHANDLE;
+
if (args->ARGS_PROC_GETSTATE.uStateInfoSize <
sizeof(struct DSP_PROCESSORSTATE))
return DSP_ESIZE;
@@ -794,9 +820,13 @@ u32 PROCWRAP_GetTrace(union Trapped_Args *args, void
*pr_ctxt)
{
DSP_STATUS status;
u8 *pBuf;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_0trace(WCD_debugMask, GT_ENTER, "PROCWRAP_Ge
DSPBRIDGE: Add BRD_SLEEP_TRANSITION in PROC_GetState
>From 40d5863c3d3f4091761fef8bff581d2a7b1f32fa Mon Sep 17 00:00:00 2001 From: Ernesto Ramos Date: Tue, 2 Feb 2010 20:30:19 -0600 Subject: [PATCH] DSPBRIDGE: Add BRD_SLEEP_TRANSITION in PROC_GetState. When PROC_GetState checks for BRD status it is not taking into account the state BRD_SLEEP_TRANSITION and it is returning DSP_EFAIL when this happens, which is wrong. This fix adds this check to return ProcStatus as PROC_RUNNING and status DSP_SOK when this happens. Signed-off-by: Ernesto Ramos --- drivers/dsp/bridge/rmgr/proc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c index a1d06dc..553c9a7 100644 --- a/drivers/dsp/bridge/rmgr/proc.c +++ b/drivers/dsp/bridge/rmgr/proc.c @@ -802,6 +802,7 @@ DSP_STATUS PROC_GetState(DSP_HPROCESSOR hProcessor, case BRD_STOPPED: pProcStatus->iState = PROC_STOPPED; break; + case BRD_SLEEP_TRANSITION: case BRD_DSP_HIBERNATION: /* Fall through */ case BRD_RUNNING: -- 1.5.4.5 -- 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: linux-next: manual merge of the omap_dss2 tree with the omap tree
* Tomi Valkeinen [100208 01:23]:
> On Mon, 2010-02-08 at 07:25 +0100, ext Stephen Rothwell wrote:
> > Hi Tomi,
> >
> > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > arch/arm/mach-omap2/board-am3517evm.c between commit
> > 13560d875d67c06239c82a6148c1b87075701fe9 ("AM3517: Enable basic I2C
> > Support") from the omap tree and commit
> > 56a3d0235cd50d14d7bd4d45e55d192aa0e78cac ("OMAP: AM3517: Enable DSS2 for
> > AM3517EVM board") from the omap_dss2 tree.
> >
> > Juts overlapping additions. I fixed it up (see below) and can carry the
> > fix as necessary.
>
> Thanks. I guess we can't properly fix this until the patch from omap
> tree goes into mainline.
Let's move the AM3517 DSS2 board patch from Tomi's tree to omap for-next
tree.
> Tony, do you think this current way, in which we have board file changes
> in both linux-omap and the dss tree, is best we can do? Or should all
> the board file changes go through linux-omap? I fear that we will have
> conflicts with every new board.
Yeah we should just move the conflicting files into omap for-next. The board
file changes conflict easily when new platform device init code is being
added.
Tomi, how about you ack and let me know about the patches (or git branch)
you want me to add into omap for-next? Otherwise I'll assume anything
DSS2 related is yours.
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: omap3evm: Doesn't boot at 4fa42e46
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev > Sent: Tuesday, February 09, 2010 9:02 PM > To: linux-omap@vger.kernel.org > Subject: omap3evm: Doesn't boot at 4fa42e46 > > Hi all, > > Just updated my repo to the commit: > > commit 4fa42e4679324b0e3c54fb509535eea3923ccb63 > Merge: e599f12 c446167 > Author: Tony Lindgren > Date: Thu Feb 4 20:07:44 2010 -0800 > > The kernel builds fine; but doesn't boot on the OMAP3EVM. > > I have been able to trace the code until rest_init(); but > will need to restart debugging. > There seems to be an exception during execution. > > Will continue to dig further. This is just an FYI. > The kernel panics during I2C init in function omap3_evm_i2c_init() during this call: omap_register_i2c_bus(2, 400, NULL, 0); I see that there isn't any difference between omap3_evm_i2c_init() and omap3430_i2c_init(). Has anyone tried the booting 3430SDP at this commit? ...just trying to understand if this is a board specific issue OR is it a generic OMAP3 issue before I try bisect. ~sanjeev > Best regards, > Sanjeev > -- > 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
RE: [PATCH] OMAP3: Serial: Improved sleep logic
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 04 February, 2010 23:20
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH] OMAP3: Serial: Improved sleep logic
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> Only RX interrupt will now kick the sleep prevent timer. In
>addition, TX
>> fifo status is checked before disabling clocks, this will
>prevent occasional
>> garbage being printed on serial line. Smartidle is also
>disabled while
>> entering idle if we have data in the transmit buffer,
>because having this
>> enabled will prevent wakeups from the TX interrupt, and this causes
>> pauses while sending large blocks of data.
>>
>> Signed-off-by: Tero Kristo
>
>After doing some more testing with this, something is not quite right
>still. I haven't taken the time to debug further, but with this patch
>on top of the current PM branch, the timer seems to expire and disable
>clocks whether or not there is UART activity.
This seems to be caused by the buggy timer usage inside serial.c. The code uses
jiffy timers for expire checks, and this is actually invalid inside
omap_sram_idle. Jiffy timer is stopped inside the ARM idle entry (cpu_idle ->
tick_nohz_stop_sched_tick()). This causes the jiffies value to be the same when
we enter idle, and while we are resuming idle, thus making the timer to expire
at rather random time. If you sleep for 4 seconds and wake using serial, the
device enters sleep again after one second. This can be fixed by using
ktime_get() instead of jiffy timer, as ktime_get() uses directly HW 32k tick
timer. I'll hack together a version of this code where I use ktime_get() for
the sleep expiry checks and see if it fixes this issue.
>In particular, using a UART1 console on OMAP3EVM, I notice that while
>typing longer commands (that take more that seconds to type),
>I notice that I loose chars in the middle of typing. /me doesn't like.
>
>So I won't be applying this to the PM branch until we can figure out
>what's happening here.
>
>Kevin
>
>> ---
>> arch/arm/mach-omap2/serial.c | 19 +++
>> 1 files changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/serial.c
>b/arch/arm/mach-omap2/serial.c
>> index 777e802..e11dfe9 100644
>> --- a/arch/arm/mach-omap2/serial.c
>> +++ b/arch/arm/mach-omap2/serial.c
>> @@ -317,7 +317,8 @@ static void omap_uart_allow_sleep(struct
>omap_uart_state *uart)
>> if (!uart->clocked)
>> return;
>>
>> -omap_uart_smart_idle_enable(uart, 1);
>> +if (serial_read_reg(uart->p, UART_LSR) & UART_LSR_TEMT)
>> +omap_uart_smart_idle_enable(uart, 1);
>> uart->can_sleep = 1;
>> del_timer(&uart->timer);
>> }
>> @@ -335,7 +336,11 @@ void omap_uart_prepare_idle(int num)
>>
>> list_for_each_entry(uart, &uart_list, node) {
>> if (num == uart->num && uart->can_sleep) {
>> -omap_uart_disable_clocks(uart);
>> +if (serial_read_reg(uart->p, UART_LSR) &
>> +UART_LSR_TEMT)
>> +omap_uart_disable_clocks(uart);
>> +else
>> +omap_uart_smart_idle_enable(uart, 0);
>> return;
>> }
>> }
>> @@ -407,8 +412,14 @@ int omap_uart_can_sleep(void)
>> static irqreturn_t omap_uart_interrupt(int irq, void *dev_id)
>> {
>> struct omap_uart_state *uart = dev_id;
>> +u8 lsr;
>>
>> -omap_uart_block_sleep(uart);
>> +lsr = serial_read_reg(uart->p, UART_LSR);
>> +/* Check for receive interrupt */
>> +if (lsr & UART_LSR_DR)
>> +omap_uart_block_sleep(uart);
>> +if (lsr & UART_LSR_TEMT && uart->can_sleep)
>> +omap_uart_smart_idle_enable(uart, 1);
>>
>> return IRQ_NONE;
>> }
>> --
>> 1.5.4.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
>--
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: Serial: Improved sleep logic
>-Original Message-
>From: ext Tony Lindgren [mailto:t...@atomide.com]
>Sent: 04 February, 2010 18:11
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH] OMAP3: Serial: Improved sleep logic
>
>* tero.kri...@nokia.com [100203 23:59]:
>>
>>
>> >-Original Message-
>> >From: ext Tony Lindgren [mailto:t...@atomide.com]
>> >Sent: 03 February, 2010 19:50
>> >To: Kristo Tero (Nokia-D/Tampere)
>> >Cc: linux-omap@vger.kernel.org
>> >Subject: Re: [PATCH] OMAP3: Serial: Improved sleep logic
>> >
>> >* Tero Kristo [100202 01:38]:
>> >> From: Tero Kristo
>> >>
>> >> Only RX interrupt will now kick the sleep prevent timer. In
>> >addition, TX
>> >> fifo status is checked before disabling clocks, this will
>> >prevent occasional
>> >> garbage being printed on serial line. Smartidle is also
>> >disabled while
>> >> entering idle if we have data in the transmit buffer,
>> >because having this
>> >> enabled will prevent wakeups from the TX interrupt, and
>this causes
>> >> pauses while sending large blocks of data.
>> >
>> >Sounds this is for 2.6.34 merge window and does not contain anything
>> >that needs to be fixed for 2.6.33.
>>
>> Yeah, this only fixes a couple of annoying issues, but
>nothing fatal. Also improves power efficiency in some cases
>which is a nice to have feature, and basically eases the
>development of PM code as the UART does not block the system
>from sleeping always.
>
>Yeah cool. Separate issue, but I wonder if we should also clear
>the the first rx character from the fifo to avoid corrupting
>the console. Only when the uart clocks are off and and
>we get a key press. Would be easy to do just do with one
>serial_read_reg(uart->p, UART_RX)..
Yeah, I can try to add this change to the code and see what happens.
>
>Tony
>
>>
>> -Tero
>>
>> >
>> >Regards,
>> >
>> >Tony
>> >
>> >
>> >> Signed-off-by: Tero Kristo
>> >> ---
>> >> arch/arm/mach-omap2/serial.c | 19 +++
>> >> 1 files changed, 15 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/arch/arm/mach-omap2/serial.c
>> >b/arch/arm/mach-omap2/serial.c
>> >> index 777e802..e11dfe9 100644
>> >> --- a/arch/arm/mach-omap2/serial.c
>> >> +++ b/arch/arm/mach-omap2/serial.c
>> >> @@ -317,7 +317,8 @@ static void omap_uart_allow_sleep(struct
>> >omap_uart_state *uart)
>> >> if (!uart->clocked)
>> >> return;
>> >>
>> >> - omap_uart_smart_idle_enable(uart, 1);
>> >> + if (serial_read_reg(uart->p, UART_LSR) & UART_LSR_TEMT)
>> >> + omap_uart_smart_idle_enable(uart, 1);
>> >> uart->can_sleep = 1;
>> >> del_timer(&uart->timer);
>> >> }
>> >> @@ -335,7 +336,11 @@ void omap_uart_prepare_idle(int num)
>> >>
>> >> list_for_each_entry(uart, &uart_list, node) {
>> >> if (num == uart->num && uart->can_sleep) {
>> >> - omap_uart_disable_clocks(uart);
>> >> + if (serial_read_reg(uart->p, UART_LSR) &
>> >> + UART_LSR_TEMT)
>> >> + omap_uart_disable_clocks(uart);
>> >> + else
>> >> + omap_uart_smart_idle_enable(uart, 0);
>> >> return;
>> >> }
>> >> }
>> >> @@ -407,8 +412,14 @@ int omap_uart_can_sleep(void)
>> >> static irqreturn_t omap_uart_interrupt(int irq, void *dev_id)
>> >> {
>> >> struct omap_uart_state *uart = dev_id;
>> >> + u8 lsr;
>> >>
>> >> - omap_uart_block_sleep(uart);
>> >> + lsr = serial_read_reg(uart->p, UART_LSR);
>> >> + /* Check for receive interrupt */
>> >> + if (lsr & UART_LSR_DR)
>> >> + omap_uart_block_sleep(uart);
>> >> + if (lsr & UART_LSR_TEMT && uart->can_sleep)
>> >> + omap_uart_smart_idle_enable(uart, 1);
>> >>
>> >> return IRQ_NONE;
>> >> }
>> >> --
>> >> 1.5.4.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
>> >
>--
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
omap3evm: Doesn't boot at 4fa42e46
Hi all, Just updated my repo to the commit: commit 4fa42e4679324b0e3c54fb509535eea3923ccb63 Merge: e599f12 c446167 Author: Tony Lindgren Date: Thu Feb 4 20:07:44 2010 -0800 The kernel builds fine; but doesn't boot on the OMAP3EVM. I have been able to trace the code until rest_init(); but will need to restart debugging. There seems to be an exception during execution. Will continue to dig further. This is just an FYI. Best regards, Sanjeev -- 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: Ubuntu installation on omap
On Tue, Feb 9, 2010 at 3:41 AM, Niamathullah sharief wrote: > Hi, > I am trying to install ubuntu on my beagleboard. i installed > successfully and it is booting fine. But after booting the graphics > which i get is not good. It has some graphics problem. Ahh, what kind of graphic problems? > And how can > work on ubuntu in board with my mouse and keyboard? If i insert mouse > and keyboard to board it is not working. only my serial port is > working. just i am getting login screen in my monitor.Please help me. Are you using a certified USB 2.0 Hub? Kernel version? As a quick verification test, use one of my demo images listed here: http://elinux.org/BeagleBoardUbuntu#Demo_Image Which have been tested on multiple Beagles (Bx's,Cx's..) Regards, -- Robert Nelson http://www.rcn-ee.com/ -- 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: OMAP3 Slave McSPI driver
Thanks Hemanth, I'll give it a try with 2.6.29 kernel. Do the patches support McSPI RX interrupt? Or McSPI FIFO full interrupt? Upon receipt of such interrupts, slave client could issue a spi_read. Thanks gilles Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -Original Message- From: V, Hemanth Sent: Tuesday, February 09, 2010 1:59 PM To: Talis, Gilles; linux-omap@vger.kernel.org Cc: spi-devel-gene...@lists.sourceforge.net Subject: Re: OMAP3 Slave McSPI driver - Original Message - From: "Talis, Gilles" To: Sent: Tuesday, February 09, 2010 3:06 PM Subject: OMAP3 Slave McSPI driver > Hi, > > My customer is using Android 2.6.29 kernel from OMAPZOOM and is looking > for support for slave mode on the SPI driver. > I saw there were patches for this feature sent to this list, but I was > wondering if those patches were tested on 2.6.29. > These patches have not been specifically tested on 29 kernel, but you could give it a shot. Pl also look at the latest patches (V2) posted. > I am also looking for some kind of API usage guidelines. How to setup the > slave mode and how is OMAP notified that data have been received from > external master device? My customer plans to use this driver in interrupt > mode (no DMA needed). > To set any mcspi controller to slave mode, you need to modify arch/arm/mach-omap2/devices.c file and set mode to OMAP2_MCSPI_SLAVE. Typically gpio is used by master to notify the slave that it is ready to transfer data. On gpio interrupt slave client could issue spi_read/spi_write commands. Two modes are supported i.e PIO and DMA. Any specific reason not to use DMA mode. Thanks Hemanth > Thanks > Gilels. > > > > Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve > Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 > > > > -- > 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 50/57] OMAP3: CLOCK: Add capability to change rate of dpll4_m5_ck_3630
Add necessary clk_sel definitions to clock framework to allow changing
dpll4_m5_ck_3630 rate. This is used by the ISP driver.
Signed-off-by: Vimarsh Zutshi
---
arch/arm/mach-omap2/clock34xx_data.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index f85e33a..8f15f18 100755
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -937,6 +937,8 @@ static struct clk dpll4_m5_ck_3630 __initdata = {
.clksel_shift = OMAP3430_CLKSEL_CAM_SHIFT,
.clksel = div32_dpll4_clksel,
.clkdm_name = "dpll4_clkdm",
+ .set_rate = &omap2_clksel_set_rate,
+ .round_rate = &omap2_clksel_round_rate,
.recalc = &omap2_clksel_recalc,
};
--
1.5.6.5
--
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: OMAP3 Slave McSPI driver
- Original Message - From: "Talis, Gilles" To: Sent: Tuesday, February 09, 2010 3:06 PM Subject: OMAP3 Slave McSPI driver Hi, My customer is using Android 2.6.29 kernel from OMAPZOOM and is looking for support for slave mode on the SPI driver. I saw there were patches for this feature sent to this list, but I was wondering if those patches were tested on 2.6.29. These patches have not been specifically tested on 29 kernel, but you could give it a shot. Pl also look at the latest patches (V2) posted. I am also looking for some kind of API usage guidelines. How to setup the slave mode and how is OMAP notified that data have been received from external master device? My customer plans to use this driver in interrupt mode (no DMA needed). To set any mcspi controller to slave mode, you need to modify arch/arm/mach-omap2/devices.c file and set mode to OMAP2_MCSPI_SLAVE. Typically gpio is used by master to notify the slave that it is ready to transfer data. On gpio interrupt slave client could issue spi_read/spi_write commands. Two modes are supported i.e PIO and DMA. Any specific reason not to use DMA mode. Thanks Hemanth Thanks Gilels. Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -- 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
Re: [PATCH] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes
On Mon, Feb 8, 2010 at 10:25 PM, Ameya Palande wrote: > Background: bridge_close() has the responsibility to cleanup all the > resources allocated by user space process. One of those resources is > DMMRes which is used for tracking DMM resource allocation done in > PROC_Map() and PROC_UnMap(). > > DRV_ProcFreeDMMRes() function was used for cleaning up DMMRes has following > problems which are fixed by this patch: > > 1. It access and modifies pDMMRes pointer when it is already freed by > PROC_UnMap() > 2. Instead of passing ulDSPAddr it passes ulDSPResAddr to PROC_UnMap() which > will not retrive correct DMMRes element. This patch is doing the right thing to me, however, it's a bit difficult to review because it's doing many changes at once. Personally I would 1) Fix the wrong dereferences in DRV_ProcFreeDMMRes [at this point the bug should be fixed] [the leaks would be freed by the outer loop] 2) Fix the wrong PROC_UnMap address passed in DRV_ProcFreeDMMRes 3) Remove the unnecessary outer loop in DRV_RemoveAllDMMResElements [at this point the code would actually make sense] 4) Merge DRV_ProcFreeDMMRes into DRV_RemoveAllDMMResElements 5) Improve coding style The end result would be the same, but easier to see what's going on :) Cheers. -- Felipe Contreras -- 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 14/17] OMAP: DSS2: move enable/disable/suspend/resume
On Tue, 2010-02-09 at 11:15 +0100, ext Grazvydas Ignotas wrote:
> On Mon, Feb 8, 2010 at 5:57 PM, Tomi Valkeinen
> wrote:
> > Move enable/disable/suspend/resume from omap_dss_device to
> > omap_dss_driver.
> >
> > This is part of a larger patch-set, which moves the control from omapdss
> > driver to the display driver.
> >
> > Signed-off-by: Tomi Valkeinen
> > ---
>
>
>
> > diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
> > b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
> > index f297a46..c6e4a7e 100644
> > --- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
> > +++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
> > @@ -262,18 +262,20 @@ static const struct omap_video_timings
> > tpo_td043_timings = {
> >.vbp= 34,
> > };
> >
> > -static int tpo_td043_enable(struct omap_dss_device *dssdev)
> > +static int generic_panel_power_on(struct omap_dss_device *dssdev)
>
> I guess you meant tpo_td043_power_on/tpo_td043_power_off?
Yes, copy paste error =)
> I'll try to test your both series later this week.
Thanks.
Tomi
--
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
[PATCHV3] OMAP3630: Clock: Workaround for DPLL HS divider limitation
From: Mike Turquette
Date: Fri, 5 Feb 2010 19:09:52 +0530
Subject: [PATCH] OMAP3630: Clock: Workaround for DPLL HS divider limitation
This patch implements a workaround for the DPLL HS divider limitation
in OMAP3630 as given by Errata ID: i556.
Errata:
When PWRDN bit is set, it resets the internal HSDIVIDER divide-by value (Mx).
The reset value gets loaded instead of the previous value.
The following HSDIVIDERs exhibit above behavior:
. DPLL4 : M6 / M5 / M4 / M3 / M2 (CM_CLKEN_PLL[31:26] register bits)
. DPLL3 : M3 (CM_CLKEN_PLL[12] register bit).
Work Around:
It is mandatory to apply the following sequence to ensure the write
value will
be loaded in DPLL HSDIVIDER FSM:
The global sequence when using PWRDN bit is the following:
. Disable Mx HSDIVIDER clock output related functional clock enable bits
(in CM_FCLKEN_xxx / CM_ICLKEN_xxx)
. Enable PWRDN bit of HSDIVIDER
. Disable PWRDN bit of HSDIVIDER
. Read current HSDIVIDER register value
. Write different value in HSDIVIDER register
. Write expected value in HSDIVIDER register
. Enable Mx HSDIVIDER clock output related functional clocks
(CM_FCLKEN_xxx / CM_ICLKEN_xxx)
Signed-off-by: Mike Turquette
Signed-off-by: Vishwanath BS
Signed-off-by: Vijaykumar GN
---
arch/arm/mach-omap2/clock34xx.c | 41 ++
arch/arm/mach-omap2/clock34xx.h |1 +
arch/arm/mach-omap2/clock34xx_data.c | 20
3 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index c1c1b93..1e6297f 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -133,6 +133,47 @@ const struct clkops clkops_omap3430es2_hsotgusb_wait = {
.find_companion = omap2_clk_dflt_find_companion,
};
+/**
+ * omap3_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
+ * from HSDivider PWRDN problem Implements Errata ID: i556.
+ * @clk: DPLL output struct clk
+ *
+ * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck, dpll4_m5_ck
+ * & dpll4_m6_ck dividers gets loaded with reset valueafter their respective
+ * PWRDN bits are set.
+ * Any dummy write (Any other value different from the Read value) to the
+ * corresponding CM_CLKSEL register will refresh the dividers.
+ */
+int omap3_pwrdn_clk_enable_with_hsdiv_restore(struct clk *clk)
+{
+ u32 dummy_v, orig_v, clksel_shift;
+ int ret;
+
+ /* Enable PWRDN bit of HSDIVIDER */
+ ret = omap2_dflt_clk_enable(clk);
+
+ /* Restore the dividers */
+ if (!ret) {
+ clksel_shift = __ffs(clk->parent->clksel_mask);
+ orig_v = dummy_v = __raw_readl(clk->parent->clksel_reg);
+
+ /* Write any other value different from the Read value */
+ dummy_v ^= (1 << clksel_shift);
+ __raw_writel(dummy_v, clk->parent->clksel_reg);
+
+ /* Write the original divider */
+ __raw_writel(orig_v, clk->parent->clksel_reg);
+ }
+ return ret;
+}
+
+const struct clkops clkops_omap3_pwrdn_with_hsdiv_wait_restore = {
+ .enable = omap3_pwrdn_clk_enable_with_hsdiv_restore,
+ .disable= omap2_dflt_clk_disable,
+ .find_companion = omap2_clk_dflt_find_companion,
+ .find_idlest= omap2_clk_dflt_find_idlest,
+};
+
const struct clkops omap3_clkops_noncore_dpll_ops = {
.enable = omap3_noncore_dpll_enable,
.disable= omap3_noncore_dpll_disable,
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 313efc0..29ef390 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -21,5 +21,6 @@ extern const struct clkops clkops_omap3430es2_ssi_wait;
extern const struct clkops clkops_omap3430es2_hsotgusb_wait;
extern const struct clkops clkops_omap3430es2_dss_usbhost_wait;
extern const struct clkops omap3_clkops_noncore_dpll_ops;
+extern const struct clkops clkops_omap3_pwrdn_with_hsdiv_wait_restore;
#endif
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index 8728f1f..9d11d53 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -3240,6 +3240,26 @@ int __init omap3xxx_clk_init(void)
}
}
+ if (cpu_is_omap3630()) {
+
+ /*
+* For 3630: override clkops_omap2_dflt_wait for the
+* clocks affected from PWRDN reset Limitation
+*/
+ dpll3_m3x2_ck.ops =
+ &clkops_omap3_pwrdn_with_hsdiv_wait_restore;
+ dpll4_m2x2_ck.ops =
+ &clkops_omap3_pwrdn_with_hsdiv_wait_restore;
+ dpll4_m3x2_ck.ops =
+ &clkops_omap3_pwrdn_with_hsdiv_wait_restore;
+ dpll4_m4x2_ck.ops =
+ &clkops_omap3_pwrdn_with_hs
Re: Ubuntu installation on omap
I followed thid only. In that i have this doubts On Tue, Feb 9, 2010 at 3:24 PM, Jochen Terbeck wrote: > See http://www.elinux.org/BeagleBoardUbuntu > > > Niamathullah sharief schrieb: >> Hi, >> I am trying to install ubuntu on my beagleboard. i installed >> successfully and it is booting fine. But after booting the graphics >> which i get is not good. It has some graphics problem. And how can >> work on ubuntu in board with my mouse and keyboard? If i insert mouse >> and keyboard to board it is not working. only my serial port is >> working. just i am getting login screen in my monitor.Please help me. >> -- >> 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
Re: [PATCH 14/17] OMAP: DSS2: move enable/disable/suspend/resume
On Mon, Feb 8, 2010 at 5:57 PM, Tomi Valkeinen wrote:
> Move enable/disable/suspend/resume from omap_dss_device to
> omap_dss_driver.
>
> This is part of a larger patch-set, which moves the control from omapdss
> driver to the display driver.
>
> Signed-off-by: Tomi Valkeinen
> ---
> diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
> b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
> index f297a46..c6e4a7e 100644
> --- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
> +++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
> @@ -262,18 +262,20 @@ static const struct omap_video_timings
> tpo_td043_timings = {
> .vbp = 34,
> };
>
> -static int tpo_td043_enable(struct omap_dss_device *dssdev)
> +static int generic_panel_power_on(struct omap_dss_device *dssdev)
I guess you meant tpo_td043_power_on/tpo_td043_power_off?
I'll try to test your both series later this week.
--
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
Ubuntu installation on omap
Hi, I am trying to install ubuntu on my beagleboard. i installed successfully and it is booting fine. But after booting the graphics which i get is not good. It has some graphics problem. And how can work on ubuntu in board with my mouse and keyboard? If i insert mouse and keyboard to board it is not working. only my serial port is working. just i am getting login screen in my monitor.Please help me. -- 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
OMAP3 Slave McSPI driver
Hi, My customer is using Android 2.6.29 kernel from OMAPZOOM and is looking for support for slave mode on the SPI driver. I saw there were patches for this feature sent to this list, but I was wondering if those patches were tested on 2.6.29. I am also looking for some kind of API usage guidelines. How to setup the slave mode and how is OMAP notified that data have been received from external master device? My customer plans to use this driver in interrupt mode (no DMA needed). Thanks Gilels. Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -- 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] Input: ads7846: add regulator support
Mark Brown wrote: > On Fri, Feb 05, 2010 at 10:45:09PM +0200, Mike Rapoport wrote: >> On Thu, Feb 4, 2010 at 6:21 PM, Mark Brown > >>> The bodge I'm thinking of would do something like log an error and >>> substitute in a dummy regulator when regulator_get() would have failed >>> so that the driver sees behaviour equivalent to the stubbed regulator >>> API if the bodge is active. A central thing seems much more sensible >>> here - there's nothing specific to this driver going on here and having >>> the API behave in a consistent manner seems good. > >> I agree that such approach have more sense than checking for -ENODEV >> in each and every driver that uses the regulator framework. I just >> wonder, if there should be some mechanism that can switch the >> substitution of the dummy regulators on and off. And if yes, how >> should the platform code communicate with the regulator core the need >> for such dummy regulators... > > So, having thought about this a bit more we actually have two different > use cases here. One is where you've got a system which has software > controllable regulators for everything but may not have plumbed in all > the supplies, the other is for systems where only a very few supplies > are on software controlled regulators which are just trying to save the > hassle of hooking up the bulk of the supplies to fixed voltage > regulators. These two use cases should probably be handled differently > - the first one is really expected to have all the supplies hooked up > and so should warn when using the bodge regulator but the warning isn't > helpful in the second case. Sounds right to me. > We already have some support for boards to set up the API in the form of > regulator_set_full_constraints() so we could do something similar for > dummy regulators, or create a new single API to set a bunch of options > via a struct which is probably less hassle going forward. Struct sounds more reasonable that just a call to e.g. regulator_warn_dummy_fixed_regulator :) > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
