RE: [PATCH 1/2] Added board-3630.c file.
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Pais, Allen
> Sent: Monday, October 26, 2009 2:43 AM
> To: linux-omap@vger.kernel.org
> Subject: [PATCH 1/2] Added board-3630.c file.
>
> From 553ee2299d0ea6493e8587e7cc832361646f81a7 Mon Sep 17 00:00:00 2001
> From: Allen Pais
> Date: Mon, 26 Oct 2009 12:50:17 +0530
> Subject: [PATCH 1/2] Added board-3630.c file.
>
> The following sequence of patch set is to adds minimal OMAP3630 board
> support to OMAP GIT.
> This patch is tested on TI's OMAP3630 SDP.
>
> OMAP 3630 is an ARM Cortex A8 based Multimedia Application processor. For
> more
> information please visit:
> http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=61
> 23&navigation
> Id=12836&contentId=52606
>
> Signed-off-by: Allen Pais
> ---
> arch/arm/mach-omap2/board-3630sdp.c | 188
> +++
> 1 files changed, 188 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-omap2/board-3630sdp.c
>
> diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-
> omap2/board-3630sdp.c
> new file mode 100644
> index 000..d3ddbd1
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-3630sdp.c
> @@ -0,0 +1,188 @@
> +/*
> + * linux/arch/arm/mach-omap2/board-3630sdp.c
> + * Copyright (C) 2007 Texas Instruments
2007 I don't recollect 3630 in 2007.
> + * Modified from mach-omap2/board-generic.c
> + * Initial code: Allen Pais
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "mmc-twl4030.h"
> +#include "sdram-micron-mt46h32m32lf-6.h"
> +
> +/* 3630SDP has Qwerty keyboard*/
> +static int board_keymap[] = {
> + KEY(0, 0, KEY_E),
> + KEY(1, 0, KEY_R),
> + KEY(2, 0, KEY_T),
> + KEY(3, 0, KEY_HOME),
> + KEY(6, 0, KEY_I),
> + KEY(7, 0, KEY_LEFTSHIFT),
> + KEY(0, 1, KEY_D),
> + KEY(1, 1, KEY_F),
> + KEY(2, 1, KEY_G),
> + KEY(3, 1, KEY_SEND),
> + KEY(6, 1, KEY_K),
> + KEY(7, 1, KEY_ENTER),
> + KEY(0, 2, KEY_X),
> + KEY(1, 2, KEY_C),
> + KEY(2, 2, KEY_V),
> + KEY(3, 2, KEY_END),
> + KEY(6, 2, KEY_DOT),
> + KEY(7, 2, KEY_CAPSLOCK),
> + KEY(0, 3, KEY_Z),
> + KEY(1, 3, KEY_KPPLUS),
> + KEY(2, 3, KEY_B),
> + KEY(3, 3, KEY_F1),
> + KEY(6, 3, KEY_O),
> + KEY(7, 3, KEY_SPACE),
> + KEY(0, 4, KEY_W),
> + KEY(1, 4, KEY_Y),
> + KEY(2, 4, KEY_U),
> + KEY(3, 4, KEY_F2),
> + KEY(4, 4, KEY_VOLUMEUP),
> + KEY(6, 4, KEY_L),
> + KEY(7, 4, KEY_LEFT),
> + KEY(0, 5, KEY_S),
> + KEY(1, 5, KEY_H),
> + KEY(2, 5, KEY_J),
> + KEY(3, 5, KEY_F3),
> + KEY(5, 5, KEY_VOLUMEDOWN),
> + KEY(6, 5, KEY_M),
> + KEY(4, 5, KEY_ENTER),
> + KEY(7, 5, KEY_RIGHT),
> + KEY(0, 6, KEY_Q),
> + KEY(1, 6, KEY_A),
> + KEY(2, 6, KEY_N),
> + KEY(3, 6, KEY_BACKSPACE),
> + KEY(6, 6, KEY_P),
> + KEY(7, 6, KEY_UP),
> + KEY(6, 7, KEY_SELECT),
> + KEY(7, 7, KEY_DOWN),
> + KEY(0, 7, KEY_PROG1), /*MACRO 1 */
> + KEY(1, 7, KEY_PROG2), /*MACRO 2 */
> + KEY(2, 7, KEY_PROG3), /*MACRO 3 */
> + KEY(3, 7, KEY_PROG4), /*MACRO 4 */
> + 0
> +};
NAK. Could we follow the same issue with zoom2 -> break the keypad into a
Separate one and use it instead? Same for all reused zoom2 components..
> +
> +static struct matrix_keymap_data board_map_data = {
> + .keymap = board_keymap,
> + .keymap_size= ARRAY_SIZE(board_keymap),
> +};
> +
> +static struct twl4030_keypad_data sdp3630_kp_twl4030_data = {
> + .keymap_data= &board_map_data,
> + .rows = 8,
> + .cols = 8,
> + .rep= 1,
> +};
> +
> +static struct omap_board_config_kernel sdp3630_config[] __initdata = {
> +};
> +
> +
> +static int sdp3630_batt_table[] = {
> +/* 0 C*/
> +30800, 29500, 28300, 27100,
> +26000, 24900, 23900, 22900, 22000, 21100, 20300, 19400, 18700, 17900,
> +17200, 16500, 15900, 15300, 14700, 14100, 13600, 13100, 12600, 12100,
> +11600, 11200, 10800, 10400, 1, 9630, 9280, 8950, 8620, 8310,
> +8020, 7730, 7460, 7200, 6950, 6710, 6470, 6250, 6040, 5830,
> +5640, 5450, 5260, 5090, 4920, 4760, 4600, 4450, 4310, 4170,
> +4040, 3910, 3790, 3670, 3550
> +};
> +
> +static struct twl4030_bci_platform_data sdp3630_bci_data = {
> + .battery_tmp_tbl= sdp3630_batt_table,
> + .tblsize= ARRAY_SIZE(sdp3630_batt_table),
> +};
> +
> +static struct twl4030_usb_data sdp3630_usb_data = {
> + .usb_mode = T2_USB_MODE_ULPI,
> +};
> +
> +static void __init omap_sdp3630_init_irq(void)
>
RE: [PATCH 2/2] Accomodate the board file change in Kconfig
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Pais, Allen > Sent: Monday, October 26, 2009 2:43 AM > To: linux-omap@vger.kernel.org > Subject: [PATCH 2/2] Accomodate the board file change in Kconfig > > From 0599ed35fde00cd84681e5d8f9a57a797fae1270 Mon Sep 17 00:00:00 2001 > From: Allen Pais > Date: Mon, 26 Oct 2009 12:51:02 +0530 > Subject: [PATCH 2/2] Accomodate the board file change in Kconfig > > > Signed-off-by: Allen Pais > --- > arch/arm/mach-omap2/Kconfig |4 > arch/arm/mach-omap2/Makefile |1 + > 2 files changed, 5 insertions(+), 0 deletions(-) > Please merge this to patch 1/2 I think we could have this as part of the 1/2 Which was to introduce 3630sdp support. 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: [PATCH] [OMAP] GPIO Module is reset during initialization
> -Original Message-
> From: Varadarajan, Charu Latha
> Sent: Monday, October 26, 2009 5:52 AM
> To: Menon, Nishanth; m...@felipebalbi.com
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [PATCH] [OMAP] GPIO Module is reset during initialization
>
> -snippet
> >>>>
> >>>> && attemp)
> >>>>
> >>>>> +udelay(1);
> >>>>
> >>>> i guess cpu_relax() is better here.
> >> I guess cpu_relax is not required because this part of code is called
> only
> >> from
> >> board file during boot-up. Hence this would be the only code to be
> >> executed.
> What is your opinion on this?
Cpu_relax is still the better way of doing it.
> >>>>
> >>>>> +attempt++;
> >>>>>
> >>>>> attempt--;
> >>>>>
> >>>>cant we improve this code as following:
> >>>{
> >>>u8 attempts = 25;
> >>>/* Software Reset of GPIO module */
> >>>__raw_writel(0x0002, bank->base
> >>>+ OMAP24XX_GPIO_SYSCONFIG);
> >>>/* wait for reset to be done */
> >>>while (((__raw_readl(bank->base +
> >>>OMAP24XX_GPIO_SYSSTATUS) & 0x1) == 0)
> >>>&& attempts) {
> >>>cpu_relax();
> >>>if (attempts % 5)
> >>>udelay(1);
> >>>attempts--;
> >>>}
> >>>
> >>>allows the kernel to do somethin else while we also ensure we have a 5
> >>>usec guarenteed delay before giving up..
> >> Doesn't modulo operation cost more in terms of performance? Any
> specific
> >> reason for specific 5 microseconds?
> >You could replace it with >> operator if you like and use 2^x multiples..
> >I am just sticking 5 us there based on your original code..
> >so the same logic over here I suppose.. unless I missed something?
> I was using attempts as 5, as my intension was to attempt only 5 times and
> not
> in terms of usec as I could not find any details in any document for
> maximum
> time for the bit to get set/reset. According to your code, it would
> attempt to read
> the register 25 times with a delay of 5 microseconds min during worst case
> scenario.
Please find the h/w timeout value and resubmit the patch..
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: [PATCH] [OMAP] GPIO Module disable if all pins inactive
> From: Varadarajan, Charu Latha
> Sent: Monday, October 26, 2009 4:07 AM
>
> #endif
> + if (cpu_is_omap24xx() || cpu_is_omap34xx() ||
> cpu_is_omap44xx()) {
> + if (!bank->>gpio_status) {
> + ctrl = __raw_readl(bank->>base +
> OMAP24XX_GPIO_CTRL);
> + /* Module is enabled, clocks are not gated */
> + ctrl &= 0xFFFE;
> + __raw_writel(ctrl, bank->>base +
> OMAP24XX_GPIO_CTRL);
> + }
> + bank->>gpio_status |= 1 << offset;
> + }
> >>> why do this every time a gpio is enabled? why not do this iff gpio was
> >>> never used before.. how about the following:
> >> The module is enabled only when gpio_status indicates that no GPIO
> >> in that module is currently active and the GPIO being requested is the
> 1st one
> >> to be active in that module.
> >> Each module would be disabled in free() API when all GPIOs in a
> particular module
> >> becomes inactive. The module is re-enabled in request() API when a GPIO
> is
> >> requested from the module that was previously disabled.
> >Thanks.
> Welcome
> >>> if (!bank->>gpio_status && (cpu_is_omap24xx() || cpu_is_omap34xx() ||
> >>> cpu_is_omap44xx())) {
> >>>u32 ctrl = __raw_readl(bank->>base + OMAP24XX_GPIO_CTRL);
> >>>/* Module is enabled, clocks are not gated */
> >>>ctrl &= 0xFFFE;
> >>>__raw_writel(ctrl, bank->>base + OMAP24XX_GPIO_CTRL);
> >>> }
> >>> bank->>gpio_status |= 1 << offset;
> >> Why to touch gpio_status if not used (for other than 34xx/24xx/44xx
> cases)?
> >either the gpio_status should be under a #ifdef for 34xx when defining
> >or it should be usable by all. what it does now is do both.
> gpio_status is not used under #ifdef for 34xx. It is used only with
> cpu_is_omap
> (34xx/24xx/44xx). Should we use both #ifdef and cpu_is_omap together? Why?
> But I don't see that approach in LO. For eg., usage of dbck_enable_mask is
> used only with cpu_is_omap and is not declared under #ifdef.
Please see [1] saved_datain is an example of why I think gpio.c could go thru a
cleanup ;) already in #ifdef in line 1908, in line 1925, we add a new #ifdef
under a #ifdef :D.. err...
Ok this piece of code is not perfect..
Regards,
Nishanth Menon
[1]
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=arch/arm/plat-omap/gpio.c;h=487bea7b5605fe366064d792d0c9cc8aed1eac63;hb=0bbf5337f2f2957775051a3caf60b66d3306c815#l174
--
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] GPIO Module is reset during initialization
> From: Varadarajan, Charu Latha
> Sent: Monday, October 26, 2009 4:26 AM
> To: Menon, Nishanth; m...@felipebalbi.com
>
> >Felipe Balbi had written, on 10/23/2009 05:56 PM, the following:
> >> On Fri, Oct 23, 2009 at 09:25:29PM +0530, ch...@ti.com wrote:
> >>> From: Charulatha V
> >>>
> >>> During initialization, GPIO module is reset using soft reset bit
> >>> of SYSCONFIG register
> >>>
> >>> Signed-off-by: Charulatha V
> >>> ---
> >>> arch/arm/plat-omap/gpio.c | 12 +++-
> >>> 1 files changed, 11 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> >>> index 2304a5d..4579650 100644
> >>> --- a/arch/arm/plat-omap/gpio.c
> >>> +++ b/arch/arm/plat-omap/gpio.c
> >>> @@ -21,6 +21,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>> +#include
> >>>
> >>> #include
> >>> #include
> >>> @@ -1670,7 +1671,7 @@ static int __init _omap_gpio_init(void)
> >>> }
> >>> #endif
> >>> for (i = 0; i < gpio_bank_count; i++) {
> >>> -int j, gpio_count = 16;
> >>> +int j, gpio_count = 16, attempt = 0;
> >>
> >> decrementing is better, so:
> Okay
> >>
> >> attempt = 1000
> >please move attempt out of here to the {} for 3430.. Warning for OMAP1.
> Okay
> >>
> >>>
> >>> bank = &gpio_bank[i];
> >>> spin_lock_init(&bank->lock);
> >>> @@ -1698,6 +1699,15 @@ static int __init _omap_gpio_init(void)
> >>> static const u32 non_wakeup_gpios[] = {
> >>> 0xe203ffc0, 0x08700040
> >>> };
> >>> +
> >>> +/* Software Reset of GPIO module */
> >>> +__raw_writel(0x0002, bank->base +
> OMAP24XX_GPIO_SYSCONFIG);
> >>> +while (((__raw_readl(bank->base +
> OMAP24XX_GPIO_SYSSTATUS)
> >>> +& 0x1) == 0) && attempt < 5) {
> >>
> >> && attemp)
> >>
> >>> +udelay(1);
> >>
> >> i guess cpu_relax() is better here.
> I guess cpu_relax is not required because this part of code is called only
> from
> board file during boot-up. Hence this would be the only code to be
> executed.
> >>
> >>> +attempt++;
> >>>
> >>> attempt--;
> >>>
> >>cant we improve this code as following:
> >{
> >u8 attempts = 25;
> >/* Software Reset of GPIO module */
> >__raw_writel(0x0002, bank->base
> >+ OMAP24XX_GPIO_SYSCONFIG);
> >/* wait for reset to be done */
> >while (((__raw_readl(bank->base +
> >OMAP24XX_GPIO_SYSSTATUS) & 0x1) == 0)
> >&& attempts) {
> >cpu_relax();
> >if (attempts % 5)
> >udelay(1);
> >attempts--;
> >}
> >
> >allows the kernel to do somethin else while we also ensure we have a 5
> >usec guarenteed delay before giving up..
> Doesn't modulo operation cost more in terms of performance? Any specific
> reason for specific 5 microseconds?
You could replace it with >> operator if you like and use 2^x multiples.. I am
just sticking 5 us there based on your original code.. so the same logic over
here I suppose.. unless I missed something?
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: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0
> -Original Message- > From: G, Manjunath Kondaiah > Sent: Monday, October 26, 2009 3:40 AM > To: Menon, Nishanth; linux-omap@vger.kernel.org > Cc: Imberton Guilhem; Mike Chan; Nayak, Rajendra; Roger Quadros; Kalle > Jokiniemi; Reddy, Teerth; Kevin Hilman; Paul Walmsley; Hogander Jouni > Subject: RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0 > > > As per your comments for other patches when ever there is udelay usage, > cpu_relax is the better option. I see there are lot of udelay(...) calls > used in this patch. Why can't you use cpu_relax() or schedule(). > Any specific reason? > Don’t really want to do cpu_relax in irq_locked context.. if you look at the code flow, the call from cpu_idle is in irq_locked.. Further this delay is part of bring up form saved context where there is nothing else scheduled + we don’t want anything else scheduled (and causing a change in scheduling decision). So unfortunately, unlike standard drivers, this cannot use the same reasoning. Regards, Nishanth Menon
RE: [PATCH]Omap3630: Add hsmmc related checks
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Chikkature Rajashekar, Madhusudhan
> Sent: Thursday, October 22, 2009 2:13 PM
>
> > From: Tony Lindgren [mailto:t...@atomide.com]
> > Sent: Thursday, October 22, 2009 12:44 PM
> >
> > * Madhusudhan Chikkature [091022 10:38]:
> > > From 661b13474a7af62c54f7df7a33a818c5e782cc59 Mon Sep 17 00:00:00 2001
> > > From: Madhu
> > > Date: Wed, 21 Oct 2009 16:16:31 -0400
> > > Subject: [PATCH] Omap3630: Add HSMMC related checks.
> > >
> > > Add omap3630 conditional checks to devices.c to allow HSMMC3 addition
> > and
> > > mux configuration for HSMMC1/2.
> > >
> > > Signed-off-by: Madhusudhan Chikkature
> > > ---
> > > arch/arm/mach-omap2/devices.c |5 +++--
> > > 1 files changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-
> > omap2/devices.c
> > > index 7d4513b..1fdfc7f 100644
> > > --- a/arch/arm/mach-omap2/devices.c
> > > +++ b/arch/arm/mach-omap2/devices.c
> > > @@ -575,7 +575,7 @@ static inline void omap2_mmc_mux(struct
> > > omap_mmc_platform_data *mmc_controller,
> > > }
> > > }
> > >
> > > - if (cpu_is_omap3430()) {
> > > + if (cpu_is_omap3430() || cpu_is_omap3630()) {
> > > if (controller_nr == 0) {
> > > omap_cfg_reg(N28_3430_MMC1_CLK);
> > > omap_cfg_reg(M27_3430_MMC1_CMD);
> >
> > How about using cpu_is_omap34xx() here instead? It's more future proof.
> >
> > Regards,
> >
> > Tony
> >
> Yes. That makes sense. I will submit V2.
>
> Regards,
> Madhu
>
> > > @@ -642,7 +642,8 @@ void __init omap2_init_mmc(struct
> > omap_mmc_platform_data
> > > **mmc_data,
> > > irq = INT_24XX_MMC2_IRQ;
> > > break;
> > > case 2:
> > > - if (!cpu_is_omap44xx() && !cpu_is_omap34xx())
> > > + if (!cpu_is_omap44xx() && !cpu_is_omap34xx()
> > > + && !cpu_is_omap3630())
!cpu_is_omap3630() is redundant here.. please consider for your v2.
> > > return;
> > > base = OMAP3_MMC3_BASE;
> > > irq = INT_34XX_MMC3_IRQ;
> > > --
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: [PATCH 2/2] OMAP3:clk: introduce DPLL4 jtype support
> From: Woodruff, Richard > Sent: Tuesday, October 20, 2009 9:48 AM > > > > From: Aguirre Rodriguez, Sergio Alberto > > Sent: Tuesday, October 20, 2009 9:16 AM > > > > + * lookup_dco_sddiv -j-type DPLL4 compensation variables > > > > Put a space before the j-type, and add better description. > > Doesn't clarify what it really does IMHO: > > > > Something like: > > "* lookup_dco_sddiv - Set j-type DPLL4 compensation variables" > > For 45nm it was necessary to use a different DPLL IP for DPLL4 (dpllj). > The other DPLLs are same which was used in 65nm (dpllm). The register > interface is slightly different. > > Code could have said is type A or B, but simple choice was to follow > internal name convention. > Any comments on a neat handling of condition where clk->parent is NULL? A BUG_ON(!clk->parent) is good? 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: [PATCH] omap: 3630: update is_chip variable
> -Original Message-
> From: Pandita, Vikram
> Sent: Monday, October 19, 2009 5:25 PM
> To: Woodruff, Richard; linux-omap@vger.kernel.org
>
> >From: Woodruff, Richard
> >
> >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> >> ow...@vger.kernel.org] On Behalf Of Pandita, Vikram
> >
> >> diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-
> >> omap/include/mach/cpu.h
> >> index 7cb0556..05a0a33 100644
> >> --- a/arch/arm/plat-omap/include/mach/cpu.h
> >> +++ b/arch/arm/plat-omap/include/mach/cpu.h
> >> @@ -454,6 +454,7 @@ IS_OMAP_TYPE(3430, 0x3430)
> >> #define CHIP_IS_OMAP3430ES2 (1 << 4)
> >> #define CHIP_IS_OMAP3430ES3_0 (1 << 5)
> >> #define CHIP_IS_OMAP3430ES3_1 (1 << 6)
> >
> >Should we add a little space for 3430 to grow? Current TRM already
> defines a 3.1.2. For this version
> >changes are transparent to software. IIRC mostly internal cell tweaks to
> allow for expanded
> >operating range.
> >
> >The CONTROL.CONTROL_IDCODE value is 0x0B6D 602F for OMAP34xx ES1.0.
> >The CONTROL.CONTROL_IDCODE value is 0x1B7A E02F for OMAP34xx ES2.0.
> >The CONTROL.CONTROL_IDCODE value is 0x2B7A E02F for OMAP34xx ES2.1.
> >The CONTROL.CONTROL_IDCODE value is 0x3B7A E02F for OMAP34xx ES3.0.
> >The CONTROL.CONTROL_IDCODE value is 0x4B7A E02F for OMAP34xx ES3.1.
> >The CONTROL.CONTROL_IDCODE value is 0x7B7A E02F for OMAP34xx ES3.1.2.
> >
> >> +#define CHIP_IS_OMAP3630ES1 (1 << 7)
>
> In that case we have to be careful.
> "arch/arm/plat-omap/include/mach/cpu.h"
> struct omap_chip_id {
> u8 oc;
> u8 type;
> };
>
> Type is u8 and we already are using the 8th bit now (1<<7)
> So a type u8 -> u16 will also be needed.
>
Requesting a u32 to try future proofing?
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: [U-Boot] [PATCH 0/3] enable CONFIG_NET_MULTI for LAN91C96
> -Original Message- > From: Ben Warren [mailto:biggerbadder...@gmail.com] > Sent: Friday, October 16, 2009 11:30 AM > Nishanth Menon wrote: > > Based on the discussion[1] here is the patchset > > > > Patchset is based on [2], and tested on SDP3430. > > Other platforms would be prefered to be > > build/tested/fixed as required > > > > Nishanth Menon (3): > > NET: LAN91C96 CONFIG_NET_MULTIify > > TI OMAP3: SDP3430 FIX NET_MULTI Warning > > LAN91C96: Enable NET_MULTI LAN driver > > > > > On first pass review, this looks great! There are a few things I'd like > to do to improve the driver, but it has nothing to do with converting to > NET_MULTI. > > I'm going to fire up a net-next branch this weekend and will try to > apply it there. Gee thanks.. Having very less knowledge on lan91c96 itself, I can help be the guinea pig for testing on SDP3430 at least :) Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
RE: [RFC][Patch V1] OMAP3: Mux Changes.
Hi Allen,
a) A simple comment to all my comments: why cant we have these in bootloader
and just simply leave the mux file alone?
b) Are you doing this for a specific platform or are they generic 3630 pin mux
changes?
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
> Sent: Thursday, October 15, 2009 7:24 AM
> To: Pais, Allen; Aguirre Rodriguez, Sergio Alberto; linux-omap
> Cc: Chikkature Rajashekar, Madhusudhan; Pandita, Vikram; Gadiyar, Anand;
> Cousson, Benoit; Felipe Balbi; Kevin Hilman; Premi, Sanjeev; Shilimkar,
> Santosh; Tony Lindgren
> Subject: RE: [RFC][Patch V1] OMAP3: Mux Changes.
>
> Please send your patch using git send email. And generate your patch using
> git format patch
>
> > -Original Message-
> > From: Pais, Allen
> > Sent: Thursday, October 15, 2009 4:38 AM
> >
> > Please ignore my previous mail.
> >
> > Muxes for OMAP 3630.
> >
> > Signed-off-by: Allen Pais diff --git
> a/arch/arm/mach-
> > omap2/mux.c b/arch/arm/mach-omap2/mux.c index b5fac32..93abb74 100644
>
>
> > --- a/arch/arm/mach-omap2/mux.c
> > +++ b/arch/arm/mach-omap2/mux.c
> > @@ -551,6 +551,42 @@ MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
> > MUX_CFG_34XX("AF26_34XX_SYS_NIRQ", 0x1E0,
> > OMAP3_WAKEUP_EN | OMAP34XX_PIN_INPUT_PULLUP |
> > OMAP34XX_MUX_MODE0)
> > +
> > +/*Muxes for 3630 */
> > +MUX_CFG_34XX("H26_3630_DSS_DATA18", 0x100,
> > + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> > +MUX_CFG_34XX("H25_3630_DSS_DATA19", 0x102,
> > + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> > +MUX_CFG_34XX("E28_3630_DSS_DATA20", 0x104,
> > + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> > +MUX_CFG_34XX("J26_3630_DSS_DATA21", 0x106,
> > + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> > +MUX_CFG_34XX("AC27_3630_DSS_DATA22", 0x108,
> > + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> > +MUX_CFG_34XX("AC28_3630_DSS_DATA23", 0x10A,
> > + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> Why cant I do this in Board file?
I Really typed that??? Dumb me.. apologies on the noise.. I had meant
bootloader..
> > +
> > +MUX_CFG_34XX("AF9_3630_ETKD8", 0x5EC,
> > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
> > +MUX_CFG_34XX("AG9_3630_ETKD9", 0x5EE,
> > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
> > +MUX_CFG_34XX("AG7_3630_ETKD12", 0x5F0,
> > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
> Why am I doing this?
> > +
> > +MUX_CFG_34XX("AA25_3630_UART2_TX", 0x178,
> > + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> > +MUX_CFG_34XX("AD25_3630_UART2_RX", 0x17A,
> > + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> > +MUX_CFG_34XX("AB25_3630_UART2_RTS", 0x176,
> > + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> > +MUX_CFG_34XX("AB26_3630_UART2_CTS", 0x174,
> > + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> Please explain..
> > +
> > +MUX_CFG_34XX("H20_UART3_RX_IRRX", 0x19E,
> > + OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
> > +MUX_CFG_34XX("H21_UART3_TX_IRTX", 0x1A0,
> > + OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
> > +
> > };
> ??
> >
> > #define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
> > diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat-
> > omap/include/mach/mux.h
> > index 0f49d2d..8d8cbe1 100644
> > --- a/arch/arm/plat-omap/include/mach/mux.h
> > +++ b/arch/arm/plat-omap/include/mach/mux.h
> > @@ -890,6 +890,32 @@ enum omap34xx_index {
> >
> > /* SYS_NIRQ T2 INT1 */
> > AF26_34XX_SYS_NIRQ,
> > +
> > + /*Muxes for 3630*/
> > + K28_3630_CAM_D6,
> > + L28_3630_CAM_D7,
> > + K27_3630_CAM_D8,
> > + L27_3630_CAM_D9,
> > +
> > + H26_3630_DSS_DATA18,
> > + H25_3630_DSS_DATA19,
> > + E28_3630_DSS_DATA20,
> > + J26_3630_DSS_DATA21,
> > + AC27_3630_DSS_DATA22,
> > + AC28_3630_DSS_DATA23,
> > +
> > + AF9_3630_ETKD8,
> > + AG9_3630_ETKD9,
> > + AG7_3630_ETK12,
> > +
> > + AA25_3630_UART2_TX,
> > + AD25_3630_UART2_RX,
> > + AB25_3630_UART2_RTS,
> > + AB26_3630_UART2_CTS,
> > +
> > + H20_UART3_RX_IRRX,
> > + H21_UART3_TX_IRTX,
> > +
> > };
> >
> > struct omap_mux_cfg {
> --
> 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
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: [RFC][Patch V1] OMAP3: Mux Changes.
Please send your patch using git send email. And generate your patch using git
format patch
> -Original Message-
> From: Pais, Allen
> Sent: Thursday, October 15, 2009 4:38 AM
>
> Please ignore my previous mail.
>
> Muxes for OMAP 3630.
>
> Signed-off-by: Allen Pais diff --git a/arch/arm/mach-
> omap2/mux.c b/arch/arm/mach-omap2/mux.c index b5fac32..93abb74 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -551,6 +551,42 @@ MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
> MUX_CFG_34XX("AF26_34XX_SYS_NIRQ", 0x1E0,
> OMAP3_WAKEUP_EN | OMAP34XX_PIN_INPUT_PULLUP |
> OMAP34XX_MUX_MODE0)
> +
> +/*Muxes for 3630 */
> +MUX_CFG_34XX("H26_3630_DSS_DATA18", 0x100,
> + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("H25_3630_DSS_DATA19", 0x102,
> + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("E28_3630_DSS_DATA20", 0x104,
> + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("J26_3630_DSS_DATA21", 0x106,
> + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AC27_3630_DSS_DATA22", 0x108,
> + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AC28_3630_DSS_DATA23", 0x10A,
> + OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
Why cant I do this in Board file?
> +
> +MUX_CFG_34XX("AF9_3630_ETKD8", 0x5EC,
> + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AG9_3630_ETKD9", 0x5EE,
> + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AG7_3630_ETKD12", 0x5F0,
> + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
Why am I doing this?
> +
> +MUX_CFG_34XX("AA25_3630_UART2_TX", 0x178,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AD25_3630_UART2_RX", 0x17A,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AB25_3630_UART2_RTS", 0x176,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AB26_3630_UART2_CTS", 0x174,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
Please explain..
> +
> +MUX_CFG_34XX("H20_UART3_RX_IRRX", 0x19E,
> + OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("H21_UART3_TX_IRTX", 0x1A0,
> + OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +
> };
??
>
> #define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
> diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat-
> omap/include/mach/mux.h
> index 0f49d2d..8d8cbe1 100644
> --- a/arch/arm/plat-omap/include/mach/mux.h
> +++ b/arch/arm/plat-omap/include/mach/mux.h
> @@ -890,6 +890,32 @@ enum omap34xx_index {
>
> /* SYS_NIRQ T2 INT1 */
> AF26_34XX_SYS_NIRQ,
> +
> + /*Muxes for 3630*/
> + K28_3630_CAM_D6,
> + L28_3630_CAM_D7,
> + K27_3630_CAM_D8,
> + L27_3630_CAM_D9,
> +
> + H26_3630_DSS_DATA18,
> + H25_3630_DSS_DATA19,
> + E28_3630_DSS_DATA20,
> + J26_3630_DSS_DATA21,
> + AC27_3630_DSS_DATA22,
> + AC28_3630_DSS_DATA23,
> +
> + AF9_3630_ETKD8,
> + AG9_3630_ETKD9,
> + AG7_3630_ETK12,
> +
> + AA25_3630_UART2_TX,
> + AD25_3630_UART2_RX,
> + AB25_3630_UART2_RTS,
> + AB26_3630_UART2_CTS,
> +
> + H20_UART3_RX_IRRX,
> + H21_UART3_TX_IRTX,
> +
> };
>
> struct omap_mux_cfg {
--
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: [U-Boot] NET: SDP3430: trouble with shifting from LAN9C916 to SMC91XX driver
Ben, > -Original Message- > From: Ben Warren [mailto:biggerbadder...@gmail.com] > Sent: Thursday, October 15, 2009 12:06 AM > To: Menon, Nishanth [..] > > include/configs/omap5912osk.h > > include/configs/omap730p2.h > > to confirm a non ti board which uses this legacy chip, I tried > > building B2, and yep, I see the same warning which was plaguing me > > :(.. > > > > Do let me know if there are alternatives available. > > > > > The alternative that most immediately jumps to mind is for you to > convert the LAN91C96 driver to NET_MULTI :) It's pretty easy to do and > would help the "community" in a big way. :D - why do I get the feeling "I thought u'd say so" ;).. yep.. started a link in omapedia for OMAP3 TODOs I could think of Regards, Nishanth Menon Ref: [1] http://omappedia.org/wiki/OMAP3_U-Boot_TODO PS: Dirk, I think you might ask me to post it elsewhere.. lets discuss that on a different thread if any.. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
RE: Discussion: OMAP: PM: opp table handling
> -Original Message- > From: Cousson, Benoit > Sent: Wednesday, October 14, 2009 11:06 AM > To: Pandita, Vikram; linux-omap@vger.kernel.org > > >From: Pandita, Vikram > > > > > >Proposals for OPP table handling for OMAP34xx/35xx/36xx/44xx > > > >Thanks to all the community members for taking time for this discussion. > >This will aid upsteaming of 35xx/36xx/44xx in coming future. > > > >Attendees: Kevin Hilman, Paul, Nishant M, Santosh, Madhu, Benoit, > Rajendra, > >Benoit, Vikram > > > >Problem Statement: > > OMAP34xx has certain opp requirements (3420/3430/3440) > > OMAP35xx reuses the opp's from 34xx > > OMAP36xx has a totally new set of opps > > OMAP44xx has a totally new set of opps > > > >Solution: > > Align on a common approach to take for the Opp table definitions. > > > >Define Separate Tables for each family as follows: > >Step 1: Go with this approach: > > 3420(65nm) : new arrays [defer for now] > > 3430/35xx(65nm) : new arrays ** > > 3440(65nm) : new arrays [defer for now] > > 3630(45nm) : new arrays > > Omap4(45nm) : new arrays > > > > * new arrays = (mpu, dsp, l3) > > ** Check this valid flag. Kevin can take this base on comments > > http://marc.info/?l=linux-omap&m=125512448216071&w=2 > > between 3430/35xx, opp's can be managed with a flag and same > >table re-used > > 35xx has requirement for 720Mhz opp > > > >Step 2: > >Kevin suggestion: > >Define accessor APIs get the OPPs > >Check Users of accessor API > > DVFS > > constraints > > sysfs debug > > Define accessor api's eg: > > index = get_opp(VDD1_OPP1); > > num = get_max_opp(VDD1); > > set_opp(index); > > I think we should as well change the naming and use the less confusing > naming we are using on OMAP3630/4430. > OPPs are now named using the performance delta from the nominal frequency. > OPP25, OPP50, OPP80, OPP100, OPP120... NAK for two reasons: a) h/w changes language of OPP definitions every other silicons -> OPP100 is not more informative than OPP1 or OPPX for that matter - with proper comments, even something like /* OPP25 - 25% of nominal performance */ #define VDD1_OPP_RELLLY_SLOW_OPP 1 Makes sense. b) if you look at discussion - we really DON'T want to use OPP definitions anymore - we would like folks to use frequency for precisely that reason - it is frequency that matters in the system. c) the field for OPP idx is probably redundant once we have proper APIs in place. > > Regards, > Benoit > > >Step 3: > > Paul suggestion: > > VSEL values in opp table should be in terms of voltage > > Non TWL IC's need this > > > >Step4: > > Paul suggestion: > > VDD1 VDD2 dependencies for different chips > > Inter-connect load predictor is absent on omap3 and hence VDD1-vdd2 > >dependency > > OMAP4 > > interconnect loading can be measured from registers > > Multi-cores dependency > > > >Step 5: > > Paul suggestion: > > Board files adding OPPs, Modifying OPPs > > Eg: Pendora passing its own opp > > 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: [PATCH] [RFC] omap: 3630: default cpu_is_omap3630 to zero
> -Original Message- > From: Pandita, Vikram > Sent: Monday, October 12, 2009 4:08 PM > > > >> -Original Message- > >> From: Pandita, Vikram > >> Sent: Monday, October 12, 2009 3:51 PM > >> > >> make default cpu_is_omap3630() return zero > >> > >> Signed-off-by: Vikram Pandita > >> --- > >> arch/arm/plat-omap/include/mach/cpu.h |2 ++ > >> 1 files changed, 2 insertions(+), 0 deletions(-) > >> > >> diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- > >> omap/include/mach/cpu.h > >> index da9e8f8..940946e 100644 > >> --- a/arch/arm/plat-omap/include/mach/cpu.h > >> +++ b/arch/arm/plat-omap/include/mach/cpu.h > >> @@ -322,6 +322,7 @@ IS_OMAP_TYPE(3430, 0x3430) > >> #define cpu_is_omap2423() 0 > >> #define cpu_is_omap2430() 0 > >> #define cpu_is_omap3430() 0 > >> +#define cpu_is_omap3630() 0 > >> > >> /* > >> * Whether we have MULTI_OMAP1 or not, we still need to distinguish > >> @@ -386,6 +387,7 @@ IS_OMAP_TYPE(3430, 0x3430) > >>(omap3_has_sgx()) & \ > >>(!omap3_has_iva())) > >> # define cpu_is_omap3530 (cpu_is_omap3430()) > >> +# undef cpu_is_omap3630() > >> # define cpu_is_omap3630()is_omap363x() > >> #endif > >Dumb question: why is this needed? cpu_is_omap3530,15,25,03 don't seems > to declare these.. > > If in some file, you want to distinguish between 3630 vs 3430, > and the build is for 3430 only, then cpu_is_omap3630() should return 0. > > Eg: opp table allocation based on run time check > > Omap35xx may also need it for the opp in future I guess. Could you add them in a single patch please? 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: [PATCH] [RFC] omap: 3630: default cpu_is_omap3630 to zero
> -Original Message- > From: Pandita, Vikram > Sent: Monday, October 12, 2009 3:51 PM > > make default cpu_is_omap3630() return zero > > Signed-off-by: Vikram Pandita > --- > arch/arm/plat-omap/include/mach/cpu.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- > omap/include/mach/cpu.h > index da9e8f8..940946e 100644 > --- a/arch/arm/plat-omap/include/mach/cpu.h > +++ b/arch/arm/plat-omap/include/mach/cpu.h > @@ -322,6 +322,7 @@ IS_OMAP_TYPE(3430, 0x3430) > #define cpu_is_omap2423()0 > #define cpu_is_omap2430()0 > #define cpu_is_omap3430()0 > +#define cpu_is_omap3630()0 > > /* > * Whether we have MULTI_OMAP1 or not, we still need to distinguish > @@ -386,6 +387,7 @@ IS_OMAP_TYPE(3430, 0x3430) > (omap3_has_sgx()) & \ > (!omap3_has_iva())) > # define cpu_is_omap3530 (cpu_is_omap3430()) > +# undef cpu_is_omap3630() > # define cpu_is_omap3630() is_omap363x() > #endif Dumb question: why is this needed? cpu_is_omap3530,15,25,03 don't seems to declare these.. 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: [RFC][PATCH] OMAP3: introduce OMAP3630
> -Original Message- > From: Aguirre Rodriguez, Sergio Alberto > Sent: Thursday, October 08, 2009 9:31 AM > To: Menon, Nishanth; linux-omap > Cc: Chikkature Rajashekar, Madhusudhan; Pandita, Vikram; Pais, Allen; > Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Premi, Sanjeev; Shilimkar, > Santosh; Tony Lindgren > Subject: RE: [RFC][PATCH] OMAP3: introduce OMAP3630 > > Nishanth, > > > -----Original Message- > > From: Menon, Nishanth > > Sent: Wednesday, October 07, 2009 11:47 PM > > To: linux-omap > > Cc: Menon, Nishanth; Chikkature Rajashekar, Madhusudhan; > > Pandita, Vikram; Pais, Allen; Gadiyar, Anand; Cousson, > > Benoit; Kevin Hilman; Premi, Sanjeev; Shilimkar, Santosh; > > Aguirre Rodriguez, Sergio Alberto; Tony Lindgren > > Subject: [RFC][PATCH] OMAP3: introduce OMAP3630 > > > > Device intro: > > OMAP3630 is the latest in the family of OMAP3 devices > > and among the changes it introduces are: > > > > New OPP levels for new voltage and frequency levels. a bunch of > > Bug fixes to various modules feature additions, notably with ISP, > > sDMA etc. > > > > Details about the chip is available here: > > http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?t > > emplateId=6123&navigationId=12836&contentId=52606 > > > > Strategy used: > > Strategy to introduce this device into Linux was discussed here: > > Ref: http://marc.info/?t=12534330343&r=1&w=2 > > > > Two approaches were available: > > a) Consider 3630 generation of devices as a new family of silicon > > b) Consider 3630 as an offshoot of 3430 family of devices > > > > As a common consensus, (b) seems to be more valid for 3630 as: > > * There are changes which are easily handled by looking at rev > > * Most of existing 34xx infrastructure can be reused(almost 90%+) > > - so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx()) > > all over the place > > And how about cpu_is_omap3() ? > > That would be valid across 34xx (zoom2, n900), 35xx (beagle, pandora), and > 36xx (zoom3). > > IMO, returning positive in a 3630/3530 to cpu_is_omap34xx() could make the > code > quite unreadable. > > 1. If you need to do something 34xx specific, then use cpu_is_34xx() > 2. If your code is valid for all 34xx, 35xx, 36xx, then why not using > cpu_is_omap3() ? > > What do you think? Not at this stage, lets bring in rename over time once 35xx changes from Sanjeev are also in.. > > > - lesser chance of bugs due to reuse of proven code flow > > - 36xx specific handling can still be done where required > > within the existing infrastructure > > > > NOTE: > > * If additional 34xx series are added, OMAP3430_REV_ES can be > > added on top of the existing 3630 ones are renumbered > > > > This patch was tested on SDP3430. > > Maybe this should say: > > This patch didn't broke SDP3430. > No. it means what it says -> I tested this patch and booted the l-o kernel on SDP3430==> OMAP3430 is fine. 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: X-loader / U-Boot query
> -Original Message- > From: Gary Thomas [mailto:g...@mlbassoc.com] > Sent: Thursday, October 08, 2009 10:17 AM > To: Menon, Nishanth > Cc: Adam Machalek; linux-omap@vger.kernel.org > Subject: Re: X-loader / U-Boot query > > On 10/08/2009 09:14 AM, Menon, Nishanth wrote: > >> -Original Message- > >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > >> ow...@vger.kernel.org] On Behalf Of Adam Machalek > >> Sent: Thursday, October 08, 2009 9:47 AM > >> To: Gary Thomas > >> Cc: linux-omap@vger.kernel.org > >> Subject: Re: X-loader / U-Boot query > >> > >> The problem is located in u-boot/cpu/arm_cortexa8/omap3/mem.c > >> > >> Function do_sdrc_init() > >> > >> There is an assumption that the RAM size on each CS is maximum of 128M. > >> See this line: > >> > >> writel(RASWIDTH_13BITS | CASWIDTH_10BITS | ADDRMUXLEGACY | > >>RAMSIZE_128 | BANKALLOCATION | B32NOT16 | B32NOT16 | > >>DEEPPD | DDR_SDRAM,&sdrc_base->cs[cs].mcfg); > >> > > This discussion should really be taken to u-boot mailing list. Yes, any > additional patches would be good to have.. > > Where is that list?? I did ask this question in the original > email... Please see [1] and the specific list [2] and also see [3] Regards, Nishanth Menon Ref: [1] http://www.google.com/search?sourceid=navclient&ie=UTF-8&rlz=1T4GGLL_enUS306US306&q=u-boot+mailing+list [2] http://lists.denx.de/mailman/listinfo/u-boot [3] http://www.denx.de/wiki/U-Boot -- 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: X-loader / U-Boot query
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Adam Machalek > Sent: Thursday, October 08, 2009 9:47 AM > To: Gary Thomas > Cc: linux-omap@vger.kernel.org > Subject: Re: X-loader / U-Boot query > > The problem is located in u-boot/cpu/arm_cortexa8/omap3/mem.c > > Function do_sdrc_init() > > There is an assumption that the RAM size on each CS is maximum of 128M. > See this line: > > writel(RASWIDTH_13BITS | CASWIDTH_10BITS | ADDRMUXLEGACY | > RAMSIZE_128 | BANKALLOCATION | B32NOT16 | B32NOT16 | > DEEPPD | DDR_SDRAM, &sdrc_base->cs[cs].mcfg); > This discussion should really be taken to u-boot mailing list. Yes, any additional patches would be good to have.. 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: [RFC][PATCH] OMAP3: introduce OMAP3630
> -Original Message- > From: Pais, Allen > Sent: Thursday, October 08, 2009 10:04 AM > To: Menon, Nishanth; Premi, Sanjeev > > Nishanth, > > Would there be CONFIG_ARCH_OMAP3630? There is no need for it. > > ________ > From: Menon, Nishanth > Sent: Thursday, October 08, 2009 9:40 AM > To: Premi, Sanjeev > Cc: Pandita, Vikram; Shilimkar, Santosh; linux-omap; Chikkature Rajashekar, > Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; > Aguirre Rodriguez, Sergio Alberto; Tony Lindgren > Subject: Re: [RFC][PATCH] OMAP3: introduce OMAP3630 Stop top posting please. 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: [PATCH] OMAP3: PM: Fix VDD2 OPP1 issue
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Thursday, October 08, 2009 9:58 AM
> To: Menon, Nishanth
> Cc: Reddy, Teerth; linux-omap@vger.kernel.org
> Subject: Re: [PATCH] OMAP3: PM: Fix VDD2 OPP1 issue
>
> Nishanth Menon writes:
>
> > Reddy, Teerth had written, on 10/08/2009 04:21 AM, the following:
> >> From 144669d941a432875db37ae9431847f6753e566e Mon Sep 17 00:00:00 2001
> >> From: Teerth Reddy
> >> Date: Wed, 9 Sep 2009 11:01:04 +0530
> >> Subject: [PATCH] ARM: OMAP3: PM: Fix VDD2 OPP1 issue
> >>
> >> This patch fixes the VDD2 OPP1 issue. The patch has change
> >> which does not allow VDD2 OPP setting to 1.VDD2 should not be put at
> >> OPP1 as this is not a supported OPP for VDD2
> >>
> >> Signed-off-by: Teerth Reddy
> >> ---
> >> arch/arm/mach-omap2/pm.c |2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> >> index fec7d00..d0e03c4 100644
> >> --- a/arch/arm/mach-omap2/pm.c
> >> +++ b/arch/arm/mach-omap2/pm.c
> >> @@ -195,7 +195,7 @@ static ssize_t vdd_opp_store(struct kobject *kobj,
> struct kobj_attribute *attr,
> >>}
> >>resource_set_opp_level(VDD1_OPP, value, flags);
> >>} else if (attr == &vdd2_opp_attr) {
> >> - if (value < 1 || value > 3) {
> >> + if (value < 2 || value > 3) {
> >>printk(KERN_ERR "vdd_opp_store: Invalid value\n");
> >>return -EINVAL;
> >>}
> > this is not scalable. we should be able to disable OPPs for each OPP
> > from the OPP array. with different silicons, we could have the same
> > OPP enabled/disabled. NAK -> need to handle based on
> > mpu_opps[vale].rate ==0
>
> Agreed that the current code is not scalable, but that was a problem
> before Teerth's fix.
>
> The proposed patch is a bugfix to existing code and should be merged
> after my comments are addressed.
>
> Then, the scalability issues can be addressed separately.
>
Ok, reverting my objection.
Will try to do a follow up patch -> essentially let program_opp make that
decision IMHO.
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
mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Kevin Hilman > > >>> W17_7XX_USB_VBUSI, > >>> + > >>> + /* MMC */ > >>> + MMC_7XX_CMD, > >>> + MMC_7XX_CLK, > >>> + MMC_7XX_DAT0, > >> > >> probably a dumb question -> but should'nt these go off to bootloader > >> perhaps? > >> > > > > Perhaps, although we use either EOL (for HTC Wizard) or Haret to boot, > > and they don't set up the right mux configuration for our board. > > > > This way though, we don't have to worry about the boot loader -- we > > can set it up right regardless of who boots us. > > I agree with Cory. > > I prefer that mux settings go into the kernel, even if they are setup > in the bootloader already. It's better to have redundancy than wonder > what to do if changing boot loaders. > Probably opening up a can of worms.. Are the rules different for OMAP3? Should'nt we have all mux done at kernel so that kernel is loader independent? 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: VDD2 setting question
Koen, > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Koen Kooi > Sent: Monday, August 03, 2009 9:49 AM > To: Linux OMAP Users > Subject: VDD2 setting question > I'm to trying to lower VDD2 on beagleboard to something slightly below > 1V instead of the current slightly above 1V setting, but I'm having a VDD2 is tied to OMAP voltage, am I right? OPP2 and OPP3 are respectively at 1.15 and 1.06 or there abouts if I am not wrong -> since VDD2 essentially drives core domain (including L3 and SDRAM as a result), you really don't want to move the voltage lower without considering the implications. Smartreflex is the guy who can measure various points on OMAP and decide if the voltage can safely be lowered without impacting device behavior. > hard time figuring out how to do that in the linux-omap (non-PM) tree. > I grepped in (admittedly 2.6.29) arch/arm/mach-omap2 and it only > returned hits that seem to be related to smartreflex. Now, enabling If you still insist on doing this, see arch/arm/mach-omap2/omap3-opp.h > And the most important question: > > o Would a patch to lower the default value of VDD2 be accepted into > the tree? Can it be lowered globally or should it be guarded with an > machine_is_omap3beagle() clause? I don't think this is even valid. 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: [PATCH 1/3] [OMAP:I2C]Bug in reading the RXSTAT/TXSTAT values from the I2C_BUFFSTAT register
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Sonasath, Moiz
> Sent: Tuesday, July 14, 2009 4:18 PM
> To: linux-omap@vger.kernel.org
> Cc: Kamat, Nishant; Paul Walmsley
> Subject: [PATCH 1/3] [OMAP:I2C]Bug in reading the RXSTAT/TXSTAT values
> from the I2C_BUFFSTAT register
>
>
> Fix bug in reading the I2C_BUFFSTAT register for getting byte count on
> RX/TX interrupt.
>
> On Interrupt: I2C_STAT[RDR],
> read 'RXSTAT' from I2C_BUFFSTAT[8-13]
> On Interrupt: I2C_STAT[XDR]
> read 'TXSTAT' from I2C_BUFFSTAT[0-5]
>
> Signed-off-by: Moiz Sonasath
> Signed-off-by: Jagadeesh Pakaravoor
> Signed-off-by: Vikram andita
> ---
> drivers/i2c/busses/i2c-omap.c | 14 --
> 1 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index ad8d201..d280acf 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -692,9 +692,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
> if (dev->fifo_size) {
> if (stat & OMAP_I2C_STAT_RRDY)
> num_bytes = dev->fifo_size;
> - else
> - num_bytes = omap_i2c_read_reg(dev,
> - OMAP_I2C_BUFSTAT_REG);
> + else/* read RXSTAT on RDR interrupt */
> + num_bytes = (omap_i2c_read_reg(dev,
> + OMAP_I2C_BUFSTAT_REG)
> + >> 8) & 0x3F;
> }
> while (num_bytes) {
> num_bytes--;
> @@ -731,9 +732,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
> if (dev->fifo_size) {
> if (stat & OMAP_I2C_STAT_XRDY)
> num_bytes = dev->fifo_size;
> - else
> - num_bytes = omap_i2c_read_reg(dev,
> - OMAP_I2C_BUFSTAT_REG);
> + else/* read TXSTAT on XDR interrupt */
> + num_bytes = (omap_i2c_read_reg(dev,
> + OMAP_I2C_BUFSTAT_REG))
Minor - Remove that extra ().. ^^
> + & 0x3F;
> }
> while (num_bytes) {
> num_bytes--;
Acked-by: Nishanth Menon
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: [PATCH 2/3] [OMAP:I2C]In case of a NACK|ARDY|AL return from the ISR
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Sonasath, Moiz
> Sent: Tuesday, July 14, 2009 4:20 PM
> To: linux-omap@vger.kernel.org
> Cc: Kamat, Nishant; Paul Walmsley
> Subject: [PATCH 2/3] [OMAP:I2C]In case of a NACK|ARDY|AL return from the
> ISR
>
>
> In case of a NACK or ARDY or AL interrupt, complete the request.
> There is no need to service the RRDY/RDR or XRDY/XDR interrupts.
>
> Refer TRM SWPU114: Figure 18-31.I2C Master Transmitter Mode, Interrupt
> Method,
> in F/S and HS Modes
>
> http://focus.ti.com/pdfs/wtbu/SWPU114T_PrelimFinalEPDF_06_25_2009.pdf
>
> Signed-off-by: Moiz Sonasath
> Signed-off-by: Vikram Pandita
> ---
> drivers/i2c/busses/i2c-omap.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index d280acf..05b5e4c 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -685,8 +685,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
> err |= OMAP_I2C_STAT_AL;
> }
> if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
> - OMAP_I2C_STAT_AL))
> + OMAP_I2C_STAT_AL)) {
> omap_i2c_complete_cmd(dev, err);
> + return IRQ_HANDLED;
> + }
What is the status of IRQ_STAT register? Who will clear that if we return
immediately from ISR? Isr will be reinvoked and we'd handle the same anyways..
I think this conflicts with [1]
Regards,
Nishanth Menon
Ref:
[1] http://patchwork.kernel.org/patch/32332/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] DSPBRIDGE: Fix macros that break when inside an if/else
Phil,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Phil Carmody
> Sent: Tuesday, July 14, 2009 6:03 AM
>
> On Fri, 2009-07-10 at 01:51 +0200, ext Guzman Lugo, Fernando wrote:
> > Thanks for the patch, it only has indentation problems, this is the
> checkpatch output:
> >
> > WARNING: suspect code indent for conditional statements (8, 12)
> > #34: FILE: drivers/dsp/bridge/pmgr/wcd.c:152:
> > + if (DSP_SUCCEEDED(status)) {\
> > + if (unlikely((src) == NULL) || \
> >
> > WARNING: line over 80 characters
> > #36: FILE: drivers/dsp/bridge/pmgr/wcd.c:154:
> > + unlikely(copy_from_user(dest, src, (elements) *
> sizeof(*(dest) { \
> >
> > WARNING: suspect code indent for conditional statements (8, 12)
> > #46: FILE: drivers/dsp/bridge/pmgr/wcd.c:164:
> > + if (DSP_SUCCEEDED(status)) {\
> > + if (unlikely((dest) == NULL) ||
> \
> >
> > WARNING: line over 80 characters
> > #48: FILE: drivers/dsp/bridge/pmgr/wcd.c:166:
> > + unlikely(copy_to_user(dest, src, (elements) *
> sizeof(*(src) { \
> >
> > total: 0 errors, 4 warnings, 48 lines checked
> >
> > Could you please fix that warning please?
>
> I suspect the only way to fix those warnings would either introduce
> other warnings, or \
Gentle query: Have we already tried this or is it just a suspicion?
> would \
> lead \
> to \
> utterly \
> unread- \
> able \
> code.
>
> If you check how and why the original TI-originated version of the code
> does not follow the linux coding standards, the difficulties we would
> have making a warning-free patch of it should be apparent.
Past is past. The idea was not to introduce anymore warning code.
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
marc info dead?
Hi, Dunno if anyone noticed, but kinda think http://marc.info/?l=linux-omap linked from: http://vger.kernel.org/vger-lists.html#linux-omap seems to show only from 2009-06-15 mails.. http://www.mail-archive.com/linux-omap@vger.kernel.org/ seems to show fine.. 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: [PATCH v2 1/1] i2c:OMAP3:Errata workaround for spurious RDR event
Paul, Ulrik, Just adding my view to this discussion: > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Paul Walmsley > Sent: Tuesday, June 23, 2009 9:05 PM > To: Hald, Ulrik Bech > Cc: Pakaravoor, Jagadeesh; linux-omap@vger.kernel.org > Subject: RE: [PATCH v2 1/1] i2c:OMAP3:Errata workaround for spurious RDR > event > > > > > > > > > + u8 stat2 = 0; > > > > > > + stat2 = omap_i2c_read_reg(dev, > > > > > > OMAP_I2C_STAT_REG); > > > > > > + if (stat2 & OMAP_I2C_STAT_BB) > > > > > > + return IRQ_HANDLED; > > > > > > > > > > Why use stat2? Why not just test stat again? > > > > > > > > Stat is read at the beginning of the ISR, what if BB bit gets > > > > cleared/set a while later, not along with RDR, as a corner case? > > > > > > If that is possible, then the comment in this patch needs to be > changed: > > > > > > > + /* 3430 I2C Errata 1.15 > > > > + * RDR could be set when the bus is busy, then > > > > + * ignore the interrupt, and clear the bit. > > > > + */ > > > > > > This implies that the state of the BB bit is important when the RDR > bit is > > > set. The closest sample we have for that is the contents of the > 'stat' > > > variable. > > > > > If I understand it correctly, you're concerned that the wording of the > > comment lets one think, that the state of the bus is critical at the > > moment the RDR interrupt is set? I guess you're right about that, since > > the wording could be a little misleading. > > My concern is that the comment and the code seem to conflict. > > > The point of the errata workaround is only to prevent handling of the > > RDR interrupt, if the bus is busy at the time when the RDR is to be > > handled. It doesn't matter if BB has been set/cleared before that. > > > > So maybe, the wording of the comment should be: > > > > /* 3430 I2C Errata 1.15, 2430 I2C Errata 1.67: > > * RDR should not be handled when bus is busy */ > > > > ? > > Yes, that is better. > > > > > If we keep it this way, re-reading the register; what could be the > > > > potential problem? > > > > > > It doesn't match the definition of the erratum as expressed in the > > > comment. Is it possible for the RDR bit to be erroneously set when BB > = > > > 0? > > > > Yes, the nature of the errata is that the RDR interrupt could be > > spurious. Although, if the bus is not busy and the RDR is set > > erroneously (there are no bytes in the FIFO to be drained), then the > > normal isr code would just leave and do nothing, which is what we also > > need in the errata work around. > > Okay. So it looks like there is a unfixable race here. Is it possible > for BB to be 0 during the stat2 read, then for BB to go to 1 immediately > afterwards? Then the rest of the RDR handler would be entered. If this > is possible, what will the ISR do -- will it hang? > > If this assessment of the problem is accurate, the stat2 read shrinks > the race window, and then indeed seems useful. > > a) why would bus be busy? - answer bus is busy before a transaction starts - each transaction is an atomic operation. If someone goofs around with signal while a master is sending/receiving data, there is AL(Arbitration Lost).. not Bus busy. b) Look at the flow in TRM figure 18-13 I2C Master Reciever Mode, interrupt mode -> where does BB get checked by the h/w? Not in the middle of the transaction.. Apologies if I am wrong, so am not entirely following the discussion here.. 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: [PATCH] [RFC][OMAP3:I2C]Workaround for OMAP3430 I2C silicon errata 1.153
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Igor Mazanov
> Sent: Tuesday, June 23, 2009 4:43 PM
> To: linux-omap@vger.kernel.org
> Subject: Re: [PATCH] [RFC][OMAP3:I2C]Workaround for OMAP3430 I2C silicon
> errata 1.153
>
> /*
> * Is there a bug in the OMAP5910 I2C controller? It
> * generates a bunch of fake XRDY interrupts under high load.
> * As result, there is a very high chance to have a situation
> * when dev->buf_len = 0 already, but I2C_CNT != 0. So, there
> * is no ARDY irq then, no complete_cmd, controller timed out
> * issues...
> *
> * Workaround:
> *
> * When we get XRDY interrupt without transmit underflow flag
> * (XUDF bit in the I2C_STAT register), delay for 100 microsecs
> * and ignore it.
> *
> * We write data into I2C_DATA register in case of transmit
> * underflow condition ONLY.
> */
> if (stat & OMAP_I2C_STAT_XRDY) {
> if (!(stat & OMAP_I2C_STAT_XUDF)) {
> udelay(100);
> continue;
> } else {
> w = 0;
> if (dev->buf_len) {
> w = *dev->buf++;
> dev->buf_len--;
> if (dev->buf_len) {
> w |= *dev->buf++ << 8;
> dev->buf_len--;
> }
> omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
> } else {
> dev_err(dev->dev, "XRDY IRQ while no "
> "data to send\n");
> break;
> }
> continue;
> }
> }
>
Could you submit a patch please?
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: [PATCH] [RFC][OMAP3:I2C]Workaround for OMAP3430 I2C silicon errata 1.153
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Kamat, Nishant
> Sent: Tuesday, June 23, 2009 12:55 PM
>
> > > @@ -647,7 +679,7 @@ omap_i2c_isr(int this_irq, void *dev_id)
> > > while ((stat = (omap_i2c_read_reg(dev,
> > OMAP_I2C_STAT_REG))) & bits) {
> > > dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat);
> > > if (count++ == 100) {
> > > - dev_warn(dev->dev, "Too much work in
> > one IRQ\n");
> > > + dev_dbg(dev->dev, "Too much work in one IRQ\n");
> >
> > Should stay as dev_warn I think.
> >
>
> When I2C is used to transfer a large number of bytes continuously (e.g.
> during some camera sensor firmware update), we hit the max count more
> often now (because of the delay introduced by the workaround
> implementation). In this case, its undesirable to see the dev_warn
> messages fill up the console. Changing this to dev_dbg means that this
> message is not printed in the expected case.
Just wondering on this -> cant I do a multibyte write upto 255 bytes? Is
count==100 not enough given that we used buffered writes? The real question is
this:
Are devices expected to trigger retry logic to the extent where the error
condition is triggered?
I think this might be an indication of something else being at fault with the
sensor /configuration of sensor - hiding the error messages by moving warn->dbg
is not correct IMHO.
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: [PATCH] [RFC][OMAP3:I2C]Workaround for OMAP3430 I2C silicon errata 1.153
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Sonasath, Moiz > Sent: Monday, June 22, 2009 7:50 PM > To: linux-omap@vger.kernel.org > Cc: Pandita, Vikram > Subject: [PATCH] [RFC][OMAP3:I2C]Workaround for OMAP3430 I2C silicon > errata 1.153 > > This patch includes the workarround for I2C Errata 1.153: When an XRDY/XDR > is hit, wait for XUDF before writing data to DATA_REG Is this workaround valid for omap2430 also? 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: [PATCH 1/1] i2c:OMAP3:Errata workaround for spurious RDR event
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Ulrik Bech Hald > Sent: Monday, June 22, 2009 11:25 PM > To: linux-omap@vger.kernel.org > Cc: Hald, Ulrik Bech > Subject: [PATCH 1/1] i2c:OMAP3:Errata workaround for spurious RDR event > > Under certain rare conditions, I2C_STAT[13].RDR bit may be set, > and the corresponding interrupt fire, even when there is no > data in the receive FIFO, or the I2C data transfer is still > ongoing. These spurious RDR events must be ignored by the > software. Is this workaround valid for omap2430 also? 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: OMAP3 ISP and camera drivers (update 2)
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
> Sent: Monday, June 22, 2009 5:22 PM
> > Thank you Sergio. So you mean that I can buy OMAP Zoom target board
> > with MT or OV sensor on it sooner or later? cool!
>
> AFAIK, when you buy the Zoom Target platform, you can only have OV3640
> sensor. BUT you could hack the board to include another sensor (Maybe
> consulting Logic people could clarify this).
>
> In Zoom1, I'll be able just to test the OV3640 sensor, which is the one I
> have available here.
>
> On 3430SDP, is where I do have MT9P012 sensor (5MP RAW sensor) connected
> in parallel, and an OV3640 (Smart sensor, but driver is using it as RAW
> sensor currently only) in CSI2 interface.
>
Curious: Thought we had two sensors: OV3640[1] on zoom1 and a 8MP sensor on
zoom2[2] -> am I wrong in saying that the connectors are compatible since both
are CSI2[3]?
SDP3430[4] supports MT9p012(CPI) and ov3640(CSI2).. as long as someone can put
a sensor with the right connectors and voltage checks, they should be "plug and
play" - at least from a h/w perspective ;)
Regards,
Nishanth Menon
Ref:
[1] http://www.ovt.com/products/part_detail.php?id=26
[2] https://www.omapzoom.org/gf/project/omapzoom/wiki/?pagename=WhatIsZoom2
[3]
https://www.omapzoom.com/gf/project/omapandroid/mailman/?_forum_action=ForumMessageBrowse&thread_id=1912&action=ListThreads&mailman_id=22
[4]
http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=12013&contentId=28741#sdp
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
Re: [U-Boot] [PATCH 1/3] OMAP3 I2C Fix the sampling clock.
> -Original Message- > From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] > Sent: Saturday, June 20, 2009 8:19 PM > To: Tom Rix > Cc: u-boot@lists.denx.de; Menon, Nishanth; dirk.be...@googlemail.com > Subject: Re: [U-Boot] [PATCH 1/3] OMAP3 I2C Fix the sampling clock. > I'll add a mandatory condition > this code MUST be test on omap2 too > > I think the TI's dev could help on this Would have been great if we had functional omap2 support in mainline - 2420/2430.. I don't even have one of those boards around :( Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] I2C Add initial support for TWL4030
> -Original Message-
> From: Tom Rix [mailto:tom@windriver.com]
> Sent: Thursday, June 18, 2009 11:14 PM
> To: u-boot@lists.denx.de; Menon, Nishanth; dirk.be...@googlemail.com
> Cc: Tom Rix
> Subject: [PATCH 2/3] I2C Add initial support for TWL4030
>
> +++ b/include/twl4030.h
> +/* POWER */
> +#define TWL4030_CHIP_BACKUP 0x4b
> +#define TWL4030_CHIP_INT 0x4b
> +#define TWL4030_CHIP_PM_MASTER 0x4b
> +#define TWL4030_CHIP_PM_RECEIVER 0x4b
> +#define TWL4030_CHIP_RTC 0x4b
> +#define TWL4030_CHIP_SECURED_REG 0x4b
> +
> +/* Register base addresses */
> +
> +/* USB */
> +#define TWL4030_BASEADD_USB 0x
> +/* AUD */
> +#define TWL4030_BASEADD_AUDIO_VOICE 0x
> +#define TWL4030_BASEADD_GPIO 0x0098
> +#define TWL4030_BASEADD_INTBR0x0085
> +#define TWL4030_BASEADD_PIH 0x0080
> +#define TWL4030_BASEADD_TEST 0x004C
> +/* AUX */
> +#define TWL4030_BASEADD_INTERRUPTS 0x00B9
> +#define TWL4030_BASEADD_LED 0x00EE
> +#define TWL4030_BASEADD_MADC 0x
> +#define TWL4030_BASEADD_MAIN_CHARGE 0x0074
> +static inline int twl4030_i2c_write_u8(u8 chip_no, u8 val, u8 reg)
> +{
Could you add a little more documentation what I should use for chip_no etc?
My main problem when I think as a first time looker, is trying to understand
Which #defines should I be using where? I really do not want to see half a
dozen repeated emails on the list asking for this info
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] TWL4030 Add power reset button
> -Original Message- > From: Tom Rix [mailto:tom@windriver.com] > Sent: Thursday, June 18, 2009 11:14 PM > To: u-boot@lists.denx.de; Menon, Nishanth; dirk.be...@googlemail.com > Cc: Tom Rix > Subject: [PATCH 3/3] TWL4030 Add power reset button Acked-by: Nishanth Menon Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] OMAP3 I2C Fix the sampling clock.
> -Original Message-
> From: Tom Rix [mailto:tom@windriver.com]
> Sent: Thursday, June 18, 2009 11:14 PM
> To: u-boot@lists.denx.de; Menon, Nishanth; dirk.be...@googlemail.com
> Cc: Tom Rix
> Subject: [PATCH 1/3] OMAP3 I2C Fix the sampling clock.
Acked-by: Nishanth Menon
There is one comment below though..
>
>
> Signed-off-by: Tom Rix
> ---
> drivers/i2c/omap24xx_i2c.c | 34 +++-
> include/asm-arm/arch-omap3/i2c.h | 54
> +-
> 2 files changed, 74 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
> index 6784603..ecdf1f2 100644
> --- a/drivers/i2c/omap24xx_i2c.c
> +++ b/drivers/i2c/omap24xx_i2c.c
> @@ -31,7 +31,29 @@ static void flush_fifo(void);
>
> void i2c_init (int speed, int slaveadd)
> {
> - u16 scl;
> + int psc, scll, sclh;
> +
> + /* Only handle standard and fast speeds */
> + if ((speed != OMAP_I2C_STANDARD) &&
> + (speed != OMAP_I2C_FAST_MODE)) {
> + printf("Error : I2C unsupported speed %d\n", speed);
> + return;
> + }
> +
We may want to bring the HSI2C support back in though
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ZOOM1 Add power reset button
> -Original Message-
> From: Tom [mailto:tom@windriver.com]
> Sent: Friday, June 12, 2009 4:57 PM
> To: Jean-Christophe PLAGNIOL-VILLARD
> Cc: u-boot@lists.denx.de; Menon, Nishanth
> Subject: Re: [U-Boot] [PATCH 4/4] ZOOM1 Add power reset button
>
> >> */
> >> void twl4030_power_reset_init(void)
> >> {
> >> -#ifdef CONFIG_OMAP3_ZOOM2
> >> +#if defined(CONFIG_OMAP3_ZOOM2) || defined(CONFIG_OMAP3_ZOOM1)
> >>
> > I think it will be better to avoid board specifc code in the driver
> > unless it's the only solution
> >
> >
> I think this is zoom1 and zoom2 specific.
> I could add this function to each of their board files.
> I was trying to avoid that.
>>> + if (twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, &val,
>>> + TWL4030_PM_MASTER_P1_SW_EVENTS)) {
>>> + printf("Error:TWL4030: failed to read the power register\n");
>>> + printf("Could not initialize hardware reset\n");
>>> + } else {
>>> + val |= TWL4030_PM_MASTER_SW_EVENTS_STOPON_PWRON;
>>> + if (twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, val,
>>> +TWL4030_PM_MASTER_P1_SW_EVENTS)) {
Why is this zoom1 and zoom2 specific? You are playing with PM Master registers
causing a board reset right? It should in theory work for beagleboard also.. am
I wrong?
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
RE: [PATCH 1/2] Serial: Define IRQ flags for 8250 driver
Regards,
Nishanth Menon
> -Original Message-
> From: Pandita, Vikram
> Sent: Friday, June 12, 2009 9:50 AM
> To: Menon, Nishanth; felipe.ba...@nokia.com
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [PATCH 1/2] Serial: Define IRQ flags for 8250 driver
>
>
>
> >-----Original Message-
> >From: Menon, Nishanth
> >Sent: Friday, June 12, 2009 9:46 AM
> >To: felipe.ba...@nokia.com
> >Cc: Pandita, Vikram; linux-omap@vger.kernel.org
> >Subject: RE: [PATCH 1/2] Serial: Define IRQ flags for 8250 driver
> >
> >> -Original Message-
> >> From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
> >> Sent: Friday, June 12, 2009 1:38 AM
> >> To: Menon, Nishanth
> >> Cc: Pandita, Vikram; linux-omap@vger.kernel.org
> >> Subject: Re: [PATCH 1/2] Serial: Define IRQ flags for 8250 driver
> >>
> >> On Fri, Jun 12, 2009 at 03:46:37AM +0200, ext Menon, Nishanth wrote:
> >> >
> >> > > -Original Message-
> >> > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> >> > > ow...@vger.kernel.org] On Behalf Of Pandita, Vikram
> >> > > Sent: Thursday, June 11, 2009 7:50 PM
> >> > > To: linux-omap@vger.kernel.org
> >> > > Cc: Pandita, Vikram
> >> > > Subject: [PATCH 1/2] Serial: Define IRQ flags for 8250 driver
> >> > >
> >> > >
> >> > > + /* Get IRQ Trigger Flag */
> >> > > + if (up->port.flags & UPF_IRQ_TRIG_RISING)
> >> > > + irq_flags |= IRQF_TRIGGER_RISING;
> >> > > + else if (up->port.flags & UPF_IRQ_TRIG_FALLING)
> >> > > + irq_flags |= IRQF_TRIGGER_FALLING;
> >> > > + else if (up->port.flags & UPF_IRQ_TRIG_HIGH)
> >> > > + irq_flags |= IRQF_TRIGGER_HIGH;
> >> > > + else if (up->port.flags & UPF_IRQ_TRIG_LOW)
> >> > > + irq_flags |= IRQF_TRIGGER_LOW;
> >> > > +
> >> > Blame it on my dislike for nested if elseif, but...
> >> > irq_flags |=
> >> > (up->port.flags & UPF_IRQ_TRIG_RISING)? IRQF_TRIGGER_RISING :
> >> > (up->port.flags & UPF_IRQ_TRIG_FALLING)? IRQF_TRIGGER_FALLING :
> >> > (up->port.flags & IRQF_TRIGGER_HIGH)? IRQF_TRIGGER_HIGH :
> >> > (up->port.flags & UPF_IRQ_TRIG_LOW)? IRQF_TRIGGER_LOW : 0;
> >> >
> >> > Makes sense?
> >>
> >> switch (up->port.flags & UPF_IRQ_FLAGS_MASK) {
> >> case UPF_IRQ_TRIG_RISING:
> >>irq_flags |= IRQF_TRIGGER_RISING;
> >>break;
> >> case UPF_IRQ_TRIG_FALLING:
> >>irq_flags |= IRQF_TRIGGER_FALLING;
> >>break;
> >> case UPF_IRQ_TRIG_HIGH:
> >>irq_flags |= IRQF_TRIGGER_HIGH;
> >>break;
> >> case UPF_IRQ_TRIG_LOW:
> >>irq_flags |= IRQF_TRIGGER_LOW;
> >>break;
> >> default:
> >>printk(KERN_ERR "Unsupported flag\n");
> >>return -EINVAL;
> >> }
> >>
> >Better :) infact, if the port.flags = UPF_IRQ_TRIG_LOW |
> UPF_IRQ_TRIG_HIGH it might be better to
> >return -EINVAL, which Felipe's change does :).
>
> Needs more investigation as to how current boards using 8250 driver do not
> pass any flag (maybe just SHARED flag) and they still work. Maybe some
> default taken by request_irq()
>
> In short NO_ need to return failure as no flag is a valid use case.
Replacing switch (up->port.flags & UPF_IRQ_FLAGS_MASK)
With
#define UPF_IRQ_LEVEL_FLAGS_MASK \
(UPF_IRQ_TRIG_RISING | UPF_IRQ_TRIG_FALLING |\
UPF_IRQ_TRIG_HIGH | UPF_IRQ_TRIG_LOW)
switch (up->port.flags & UPF_IRQ_LEVEL_FLAGS_MASK) {
will allow for valid -EINVAL return.
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: [PATCH 1/2] Serial: Define IRQ flags for 8250 driver
> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
> Sent: Friday, June 12, 2009 1:38 AM
> To: Menon, Nishanth
> Cc: Pandita, Vikram; linux-omap@vger.kernel.org
> Subject: Re: [PATCH 1/2] Serial: Define IRQ flags for 8250 driver
>
> On Fri, Jun 12, 2009 at 03:46:37AM +0200, ext Menon, Nishanth wrote:
> >
> > > -Original Message-
> > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > > ow...@vger.kernel.org] On Behalf Of Pandita, Vikram
> > > Sent: Thursday, June 11, 2009 7:50 PM
> > > To: linux-omap@vger.kernel.org
> > > Cc: Pandita, Vikram
> > > Subject: [PATCH 1/2] Serial: Define IRQ flags for 8250 driver
> > >
> > >
> > > + /* Get IRQ Trigger Flag */
> > > + if (up->port.flags & UPF_IRQ_TRIG_RISING)
> > > + irq_flags |= IRQF_TRIGGER_RISING;
> > > + else if (up->port.flags & UPF_IRQ_TRIG_FALLING)
> > > + irq_flags |= IRQF_TRIGGER_FALLING;
> > > + else if (up->port.flags & UPF_IRQ_TRIG_HIGH)
> > > + irq_flags |= IRQF_TRIGGER_HIGH;
> > > + else if (up->port.flags & UPF_IRQ_TRIG_LOW)
> > > + irq_flags |= IRQF_TRIGGER_LOW;
> > > +
> > Blame it on my dislike for nested if elseif, but...
> > irq_flags |=
> > (up->port.flags & UPF_IRQ_TRIG_RISING)? IRQF_TRIGGER_RISING :
> > (up->port.flags & UPF_IRQ_TRIG_FALLING)? IRQF_TRIGGER_FALLING :
> > (up->port.flags & IRQF_TRIGGER_HIGH)? IRQF_TRIGGER_HIGH :
> > (up->port.flags & UPF_IRQ_TRIG_LOW)? IRQF_TRIGGER_LOW : 0;
> >
> > Makes sense?
>
> switch (up->port.flags & UPF_IRQ_FLAGS_MASK) {
> case UPF_IRQ_TRIG_RISING:
> irq_flags |= IRQF_TRIGGER_RISING;
> break;
> case UPF_IRQ_TRIG_FALLING:
> irq_flags |= IRQF_TRIGGER_FALLING;
> break;
> case UPF_IRQ_TRIG_HIGH:
> irq_flags |= IRQF_TRIGGER_HIGH;
> break;
> case UPF_IRQ_TRIG_LOW:
> irq_flags |= IRQF_TRIGGER_LOW;
> break;
> default:
> printk(KERN_ERR "Unsupported flag\n");
> return -EINVAL;
> }
>
Better :) infact, if the port.flags = UPF_IRQ_TRIG_LOW | UPF_IRQ_TRIG_HIGH it
might be better to return -EINVAL, which Felipe's change does :).
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: [PATCH 1/2] Serial: Define IRQ flags for 8250 driver
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Pandita, Vikram > Sent: Thursday, June 11, 2009 7:50 PM > To: linux-omap@vger.kernel.org > Cc: Pandita, Vikram > Subject: [PATCH 1/2] Serial: Define IRQ flags for 8250 driver > > > + /* Get IRQ Trigger Flag */ > + if (up->port.flags & UPF_IRQ_TRIG_RISING) > + irq_flags |= IRQF_TRIGGER_RISING; > + else if (up->port.flags & UPF_IRQ_TRIG_FALLING) > + irq_flags |= IRQF_TRIGGER_FALLING; > + else if (up->port.flags & UPF_IRQ_TRIG_HIGH) > + irq_flags |= IRQF_TRIGGER_HIGH; > + else if (up->port.flags & UPF_IRQ_TRIG_LOW) > + irq_flags |= IRQF_TRIGGER_LOW; > + Blame it on my dislike for nested if elseif, but... irq_flags |= (up->port.flags & UPF_IRQ_TRIG_RISING)? IRQF_TRIGGER_RISING : (up->port.flags & UPF_IRQ_TRIG_FALLING)? IRQF_TRIGGER_FALLING : (up->port.flags & IRQF_TRIGGER_HIGH)? IRQF_TRIGGER_HIGH : (up->port.flags & UPF_IRQ_TRIG_LOW)? IRQF_TRIGGER_LOW : 0; Makes sense? 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: [U-Boot] [PATCH 1/4] OMAP3 I2C Fix the sampling clock.
> -Original Message- > From: Tom [mailto:tom@windriver.com] > Sent: Wednesday, June 10, 2009 9:44 PM > > This is a repeat story of what happened in linux-omap and kernel. We had > a similar discussion in [1] and related patch [2] to change equations. I > have the same reservations with this patch: > > a) using speed as default does not scale for all board combinations. > > b) need flexible option to provide scll and sclh on a platform basis. > > Regards, > > Nishanth Menon > > Ref: > > [1] http://marc.info/?t=12354086592&r=1&w=2 > > [2] http://marc.info/?l=linux-omap&m=122770723311340&w=2 > > > Do you think this could be handled with just config files? > Or maybe like fsl_i2c does by passing clk data through the global_data ? #defines in config header file might be a viable option.. Though the gd might be cleaner I think.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ZOOM2 Add power reset button
> -Original Message- > From: Heiko Schocher [mailto:h...@denx.de] > Sent: Wednesday, June 10, 2009 1:22 PM > > > > Regarding Dirk's and Heiko's comment: > > A) How about board/omap3/common/power.c to drivers/power/twl4030.c > > I don;t know, if this "board/omap3/common/power.c" is identical > with twl4030 ... ? The objective of power.c was to have only to have power related code for all omap3 platforms -> but currently there is only power_init_r function which is twl4030 compatible chips -> hence makes sense to break it out. > > > On patch C: > > B) introduce a new header in include/twl4030.h from Tom's patch > > Remove drivers/i2c/twl4030_i2c.c from the patch instead add: > > #define TWLL4030_READ_U8(MODULE, VAL,REG)\ > > i2c_read((MODULE), (REG), 1, (VAL), 1) > > #define TWLL4030_WRITE_U8(MODULE, VAL,REG)\ > > i2c_read((MODULE), (REG), 1, (VAL), 1) > > to include/twl4030.h in the patch. > > Maybe an option ... thats why I think it is no i2c driver ... > > > C) on [PATCH 3/4] ZOOM2 Add power reset button > > The change should go to corresponding board file -> for zoom1 or zoom2. > > or in "drivers/power/twl4030.c", if it is for all zoom* boards identical. > Yes - it can belong there I agree. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ZOOM2 Add power reset button
> -Original Message- > From: Peter Tyser [mailto:pty...@xes-inc.com] > Sent: Wednesday, June 10, 2009 11:26 AM > > > >>> --- a/drivers/i2c/twl4030_i2c.c > > > >> All other drivers in drivers/i2c are host adapter drivers. Ie they > > > >> implement i2c_read(), i2c_write(), i2c_probe(), and i2c_init(). > The > > > >> twl4030_i2c.c driver doesn't seem to fit this mold. Perhaps it > would > > > be > > > >> better placed in drivers/misc or a new drivers/power directory > similar > > > >> to Linux? > > > > > > > > This function probably belongs to board/omap3/common/power.c -> or > even > > > better to the board file itself? > > > > > > I was about to mention the opposite ;) > > > > > > Jean-Christophe asked to move the code from power.c to driver > directory > > > > > > http://lists.denx.de/pipermail/u-boot/2009-May/052400.html > > > > > > If you follow above discussion, I was fine with power.c. If we get now > > > a twl4030_i2c.c, we should merge the code from power.c into it, too > > > (where ever it will be located and named, then). > > > > > This IMHO is the right approach -> but the real question is where in > drivers/ directory? How about drivers/i2c/chips and moving the current > drivers/i2c/* to drivers/i2c/busses - following the kernel organization? > > I'd vote against creating a drivers/i2c/chips directory. I believe this > directory is deprecated in the Linux kernel and they'd prefer drivers be > put in the proper driver/ directory. I'd vote to follow this > convention in U-Boot too. > > I'm not familiar with the device or what features you plan on supporting > so I can't speak to whether it'd fit better in drivers/power, > drivers/misc, somewhere omap3/board specific, etc. > How about this: Regarding Dirk's and Heiko's comment: A) How about board/omap3/common/power.c to drivers/power/twl4030.c On patch [PATCH 2/4] I2C Add initial support for TWL4030: B) introduce a new header in include/twl4030.h from Tom's patch Remove drivers/i2c/twl4030_i2c.c from the patch instead add: #define TWLL4030_READ_U8(MODULE, VAL,REG)\ i2c_read((MODULE), (REG), 1, (VAL), 1) #define TWLL4030_WRITE_U8(MODULE, VAL,REG)\ i2c_read((MODULE), (REG), 1, (VAL), 1) to include/twl4030.h in the patch. C) on [PATCH 3/4] ZOOM2 Add power reset button The change should go to corresponding board file -> for zoom1 or zoom2. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ZOOM2 Add power reset button
> -Original Message- > From: Dirk Behme [mailto:dirk.be...@googlemail.com] > Sent: Wednesday, June 10, 2009 10:44 AM > >>> --- a/drivers/i2c/twl4030_i2c.c > >> All other drivers in drivers/i2c are host adapter drivers. Ie they > >> implement i2c_read(), i2c_write(), i2c_probe(), and i2c_init(). The > >> twl4030_i2c.c driver doesn't seem to fit this mold. Perhaps it would > be > >> better placed in drivers/misc or a new drivers/power directory similar > >> to Linux? > > > > This function probably belongs to board/omap3/common/power.c -> or even > better to the board file itself? > > I was about to mention the opposite ;) > > Jean-Christophe asked to move the code from power.c to driver directory > > http://lists.denx.de/pipermail/u-boot/2009-May/052400.html > > If you follow above discussion, I was fine with power.c. If we get now > a twl4030_i2c.c, we should merge the code from power.c into it, too > (where ever it will be located and named, then). > This IMHO is the right approach -> but the real question is where in drivers/ directory? How about drivers/i2c/chips and moving the current drivers/i2c/* to drivers/i2c/busses - following the kernel organization? Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] I2C Add initial support for TWL4030
> -Original Message- > From: Tom Rix [mailto:tom@windriver.com] > Sent: Wednesday, June 10, 2009 7:54 AM > To: u-boot@lists.denx.de > Cc: dirk.be...@googlemail.com; Menon, Nishanth; Tom Rix > Subject: [PATCH 2/4] I2C Add initial support for TWL4030 > > --- > drivers/i2c/Makefile |1 + > drivers/i2c/twl4030_i2c.c | 37 > include/twl4030.h | 221 This is an interesting area -> in kernel we used to have i2c/busses and i2c/chips -> u-boot has drivers/i2c which probably is equivalent to i2c/busses -> should we create subdirectories there? In the current form, this driver does not fit into drivers/i2c if I am not wrong.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] OMAP3 I2C Fix the sampling clock.
> -Original Message-
> From: Tom Rix [mailto:tom@windriver.com]
> Sent: Wednesday, June 10, 2009 7:54 AM
>
> void i2c_init (int speed, int slaveadd)
> {
> - u16 scl;
> + int psc, iclk, scll, sclh;
> +
> + /* Only handle standard and fast speeds */
> + if ((speed != OMAP_I2C_STANDARD) &&
> + (speed != OMAP_I2C_FAST_MODE)) {
> + printf("Error : I2C unsupported speed %d\n", speed);
> + return;
> + }
> +
> + /*
> + * Calculate the prescalar to go from from the function clock
> + * to the internal sampling clock, 12MHz.
> + */
> + psc = I2C_PSC_MAX;
> + while (psc >= I2C_PSC_MIN) {
> + iclk = I2C_IP_CLK / (psc + 1);
> + if (1200 <= iclk)
> + break;
> + psc--;
> + }
> + if (psc < I2C_PSC_MIN) {
> + printf("Error : I2C unsupported prescalar %d\n", psc);
> + return;
> + }
> +
> + /*
> + * How the low and high time periods are calculated
> + * See the OMAP3xxx Reference Manual for more details
> + *
> + * tlow + thigh = 1 / speed
> + * thigh = tlow, nice square wave..
> + *
> + * tlow = 1 / (2 * speed) = (scll + 7) / iclk;
> + * scll + 7 = iclk / 2 * speed
> + * sclh + 5 = iclk / 2 * speed
> + */
> + scll = sclh = iclk / (2 * speed);
> + scll -= 7;
> + sclh -= 5;
> + if ((scll < 0) || (sclh < 0)) {
> + printf("Error : I2C initializing clock\n");
> + return;
> + }
>
> writew(0x2, I2C_SYSC); /* for ES2 after soft reset */
> udelay(1000);
> @@ -42,12 +84,10 @@ void i2c_init (int speed, int slaveadd)
> udelay (5);
This is a repeat story of what happened in linux-omap and kernel. We had a
similar discussion in [1] and related patch [2] to change equations. I have the
same reservations with this patch:
a) using speed as default does not scale for all board combinations.
b) need flexible option to provide scll and sclh on a platform basis.
Regards,
Nishanth Menon
Ref:
[1] http://marc.info/?t=12354086592&r=1&w=2
[2] http://marc.info/?l=linux-omap&m=122770723311340&w=2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ZOOM2 Add power reset button
> -Original Message-
> From: Peter Tyser [mailto:pty...@xes-inc.com]
> Sent: Wednesday, June 10, 2009 9:27 AM
> > diff --git a/drivers/i2c/twl4030_i2c.c b/drivers/i2c/twl4030_i2c.c
> > index 774f813..549f974 100644
> > --- a/drivers/i2c/twl4030_i2c.c
> > +++ b/drivers/i2c/twl4030_i2c.c
> > @@ -35,3 +35,25 @@ static inline int twl4030_i2c_read_u8(u8 chip_no, u8
> *val, u8 reg)
> > return i2c_read(chip_no, reg, 1, val, 1);
> > }
> >
> > +/*
> > + * Power Reset
> > + */
> > +void twl4030_power_reset_init(void)
> > +{
> > +#ifdef CONFIG_OMAP3_ZOOM2
> > + u8 val = 0;
> > + if (twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, &val,
> > + TWL4030_PM_MASTER_P1_SW_EVENTS)) {
> > + printf("Error:TWL4030: failed to read the power register\n");
> > + printf("Could not initialize hardware reset\n");
> > + } else {
> > + val |= TWL4030_PM_MASTER_SW_EVENTS_STOPON_PWRON;
> > + if (twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, val,
> > +TWL4030_PM_MASTER_P1_SW_EVENTS)) {
> > + printf("Error:TWL4030: failed to write the power
> register\n");
> > + printf("Could not initialize hardware reset\n");
> > + }
> > + }
> > +#endif
> > +}
> > +
>
> All other drivers in drivers/i2c are host adapter drivers. Ie they
> implement i2c_read(), i2c_write(), i2c_probe(), and i2c_init(). The
> twl4030_i2c.c driver doesn't seem to fit this mold. Perhaps it would be
> better placed in drivers/misc or a new drivers/power directory similar
> to Linux?
This function probably belongs to board/omap3/common/power.c -> or even better
to the board file itself?
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
RE: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Hiroshi DOYU > Sent: Monday, June 08, 2009 6:34 AM > To: Ramirez Luna, Omar > Cc: ameya.pala...@nokia.com; linux-omap@vger.kernel.org; > felipe.contre...@gmail.com > Subject: Re: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl > http://marc.info/?l=linux-omap&m=124201773423892&w=2 > > for the second one about 128 byte alignment. let me know your > thought/plan on it. How about enabling this[1] under a configurable option? Though this is a strong check, currently components such as ti-openmax IL does a padded allocation to ignore overwrite of buffer region which might be at risk. The check is desirable, but should have an option to disable it, if so desired. Regards, Nishanth Menon Ref: [1] http://marc.info/?l=linux-omap&m=124201773423892&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [ANNOUNCE] Temporary L-B tree for bridge 2.6.29
> -Original Message- > From: Kanigeri, Hari > Sent: Wednesday, May 20, 2009 3:15 PM > > As Omar mentioned this is temporary staging and this will be moved to > omapzoom portal in a Week or two. This version of tidspbridge has the open > source PM framework. > > Myself and Omar will act as maintainers. > So salient points: a) Based on linux-omap pm branch - same as what Ameya's tree does.. b) Will eventually be hosted at omapzoom portal c) Maintainers -> Omar and Hari So how about Ameya's tree @ [1]? - Looking for some sort of suggestions here :).. what are the focus of each of these trees now? Regards, Nishanth Menon Ref: [1] http://gitorious.org/tidspbridge/ -- 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: [ANNOUNCE] Temporary L-B tree for bridge 2.6.29
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > In the mean time you can clone from: > git://gitorious.org/ti-dspbridge/linux-bridge.git How does this stand with [1] - are we saying that the above will be new tidspbridge tree? Who is the maintainer? Regards, Nishanth Menon Ref: [1] http://gitorious.org/tidspbridge/ -- 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: Issues with PM Branch
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Abraham Arce > > > The non-USB related hang looks like the problem when using smartreflex > > without SRF. If you disable smartreflex, or use smartreflex with SRF > > you should boot past that hang. > > > > For MUSB, it has not yet been validated on the PM branch. > > Thanks Kevin... I have disabled SmartReflex, it is booting now but > after some time of interaction, console will become unresponsive, > commands won't be executed > > # ps -aux > ^C > > Is there any setting I should set up before in menuconfig? sysfs? > You may want to check with a ramdisk first -> just to ensure you are not mixing up any NFS server timeouts 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: trouble with alsa, wolfson, and TI OMAP35xx McBSP
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of twebb > Sent: Wednesday, April 22, 2009 12:58 PM > Problem 2: > Test tone is being presented by the user application, providing a 1Khz > tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left > channel is quiet. The data seems to slip back and forth from left to > right channel. This is reproducable and verified with a scope trace. I recollect this issue from years back of OSS driver -> i2s is configured as dual phase - mcbsp sends data on both edges, and if the data write happen on the wrong edge for the wrong phase, we might get mix up.. if I recollect right, configuration for mcbsp was done as a single phase with the right edge as a trigger for transfer, the transfer size was set as 32 bytes (both channels).. this essentially guarentees that mcbsp will never mix up channels. 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: [PATCH 0/7] OMAP4: Patch series
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh > Sent: Tuesday, April 21, 2009 8:13 AM > To: linux-omap@vger.kernel.org > Subject: [PATCH 0/7] OMAP4: Patch series > > Following is the patch series to enable basic board support for OMAP4430. > The patches are generated against mainline version 2.6.30 -rc2. The kernel > is validated on the OMAP4430 software simulator platform. http://git.omapzoom.org/?p=repo/u-boot.git;a=summary -> do we have OMAP4 patchset somewhere? 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: Unable to mount android rootfs
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of harish.hanumantha...@wipro.com > Sent: Thursday, April 16, 2009 7:41 AM > To: linux-omap@vger.kernel.org > Subject: Unable to mount android rootfs > > I am trying to get android up on omapzoom I.I am using the latest source > synced from android site. From the console logs captured looks like > mounting of rootfs is not mounted completely due to mmc driver errors. > Any help on how to proceed further will be appreciated Could you take the omapzoom android and related kernel question to [1] - just to ensure you have the right audience? Regards, Nishanth Menon Ref: [1] https://omapzoom.org/gf/project/omapandroid/mailman -- 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: 2.6.29 and SDP3430
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Woodruff, Richard > Sent: Thursday, April 09, 2009 8:00 AM > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > ow...@vger.kernel.org] On Behalf Of Jarkko Nikula > > Sent: Thursday, April 09, 2009 2:04 AM > > > > just messing around with tony's master branch on SDP3430, just did a > > > defconfig and a build with 2007q3-51 codesourcery compiler, I see it > > > hang around: > > > > > Kernels built with this compiler stuck into delay loop calibration. > > No idea why, but 2008q3-66 was working for me. Using the following: arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2008q3-72) 4.3.2 I am past the lockup on calibration, but it now gets stuck as follows: NET: Registered protocol family 15 RPC: Registered udp transport module. RPC: Registered tcp transport module. Disabling unused clock "gpt2_ick" Disabling unused clock "gpt2_fck" Disabling unused clock "wdt2_ick" Disabling unused clock "wdt2_fck" Disabling unused clock "dpll4_m6x2_ck" Disabling unused clock "dpll4_m5x2_ck" Disabling unused clock "dpll3_m3x2_ck" Disabling unused clock "sys_clkout1" variant c rev 1 implementor 41 architecture 3 part 30 variant c rev 1 regulator_init_complete: incomplete constraints, leaving VAUX3 on > > I wonder if the timer stopped ticking. If you connect with emulator take > a look at GPT1 registers and see if time base is moving. > > Another quick test is to shut off tickles, nohz=off. nohz=off did not work with either 2007q3 or 2008q3.. have'nt looked at the GPT regs though.. 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: i2c_omap: arbitration lost
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto > Sent: Monday, April 06, 2009 5:34 PM > To: linux-omap@vger.kernel.org > Subject: i2c_omap: arbitration lost > > <3>i2c_omap i2c_omap.2: Arbitration lost > i2c_omap i2c_omap.2: Arbitration lost > <3>ov3640 2-003c: read from offset 0x300b error -5 > ov3640 2-003c: read from offset 0x300b error -5 > <3>ov3640 2-003c: Unable to detect sensor, err -19 > ov3640 2-003c: Unable to detect sensor, err -19 > > Is anybody else having the same problem? Do you see i2c errors during twl5030 operations? did you try enable i2c-dev and try some i2cdev access to other devices? Arbitration Lost happens only in a multi-master scenario -> two masters (OMAP and someone else) trying to talk on the bus at the same time - so did you try some platform like SDP3430-VG5.0 or so.. 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: tidspbridge git repository
> -Original Message-
> From: Ameya Palande [mailto:2am...@gmail.com]
> Sent: Monday, March 23, 2009 1:23 PM
> tidspbridge patchset is now rebased on kevin's pm-2.6.28 branch.
Thanks. Just for everyone's reference, project link is [1], and git link is [2]
Steps to get the latest tidspbridge based on linux-omap-pm (2.6.28):
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
git checkout -b pm-2.6.28 --track origin/pm-2.6.28
git fetch git://gitorious.org/tidspbridge/mainline.git tidspbridge:tidspbridge
git checkout tidspbridge
Just did a basic compile and insmod+rmmod. No data transfers :(...
Regards,
Nishanth Menon
Ref:
[1] http://gitorious.org/projects/tidspbridge/repos/mainline/logs/tidspbridge
[2] git://gitorious.org/tidspbridge/mainline.git
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
RE: tidspbridge git repository
> -Original Message- > From: Ameya Palande [mailto:2am...@gmail.com] > Sent: Monday, March 23, 2009 9:58 AM > > When I try to fetch pm-2.6.28 from Kevin's tree I always get > following error: > > error: Unable to find 58d4e18530da1ca4020c1046709b7d8cdadc639c under > http://www.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git > Cannot obtain needed blob 58d4e18530da1ca4020c1046709b7d8cdadc639c > while processing commit a0c296df7fc41bd1e3f209c1bece0ba2ec30bc81. > fatal: Fetch failed. > > Command string: > git fetch http://www.kernel.org/pub/scm/linux/kernel/git/khilman/linux- > omap-pm.git > pm-2.6.28:pm-2.6.28 > Git protocol works... http seems broken.. Regards, Nishanth Menon
RE: tidspbridge git repository
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of ameya.pala...@nokia.com > Sent: Monday, March 23, 2009 9:42 AM > To: t...@atomide.com > Cc: linux-omap@vger.kernel.org; hiroshi.d...@nokia.com > Subject: tidspbridge git repository > > I have collected latest patches for tidspbridge at: > git://gitorious.org/tidspbridge/mainline.git > > Branch is: tidspbridge > > It is based on your pm branch. Is'nt the old PM branch moved to Kevin's tree[1]? Regards, Nishanth Menon Ref: [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=shortlog;h=pm-2.6.28 -- 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: test
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto > Sent: Thursday, March 19, 2009 4:51 PM > To: linux-omap@vger.kernel.org > Subject: test Aaah, Few folks hitting: Generating server: linux-omap@vger.kernel.org vger.kernel.org # In case you disagree, send the ENTIRE message plus this error message to ; S1758343AbZCRQ3X> #SMTP# Anyone seen similar issues recently? 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: [PATCH 1/1] DSPBRIDGE Fix flush_workque
> -Original Message- > From: Gupta, Ramesh > Sent: Thursday, March 19, 2009 6:25 AM > To: linux-omap@vger.kernel.org > Cc: Menon, Nishanth; Kanigeri, Hari; Varide, Nischal; Guzman Lugo, > Fernando > Subject: [PATCH 1/1] DSPBRIDGE Fix flush_workque > > From a8aabc6233329998d0ac62be42ade5a77f03ef2a Mon Sep 17 00:00:00 2001 > From: Ramesh Gupta > Date: Thu, 19 Mar 2009 09:56:30 +0530 > Subject: [PATCH 1/1] DSPBRIDGE Fix flush_workque > > Observed some crash with flush_workque after > multiple load and unload. > Replaced flush_workque with destroy_workque > > Signed-off-by: Varide Nischal Thanks Ramesh. Tested-by: Nishanth Menon Test h/w: SDP3430. - OMAP3430 ES3.0 Test iteration: (bootargs mem=122M) ./bridgedriver.ko phys_mempool_base=0x87A0 phys_mempool_size=0x0060 base_img=dsp/baseimage.dof rmmod bridgedriver -- Num iterations: 30K 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: [PATCH 1/1] DSPBRIDGE: Set __GFP_RECLAIMABLE for reloading bridge module
> -Original Message- > From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] > Sent: Thursday, March 19, 2009 11:38 AM > To: Kanigeri, Hari > Cc: Guzman Lugo, Fernando; ameya.pala...@nokia.com; Menon, Nishanth; > Gupta, Ramesh; linux-omap@vger.kernel.org; Hiroshi DOYU > Subject: [PATCH 1/1] DSPBRIDGE: Set __GFP_RECLAIMABLE for reloading bridge > module > > To restart DSP system after DSP crash, reloading bridge module is > necessary and a high order page allocation may fail after long use > time because of memory fragmentation. To avoid this, mark it as > reclaimable for immediate reloading. > > Signed-off-by: Hiroshi DOYU Thanks Hiroshi. Tested-by: Nishanth Menon Test h/w: SDP3430. - OMAP3430 ES3.0 Test iteration: insmod ./bridgedriver.ko shm_size=0x40 phys_mempool_base=0 base_img=/lib/dsp/baseimage.dof rmmod bridgedriver -- Num iterations: 25K 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: dma_alloc_coherent fragmentation
Hi Hiroshi, > -Original Message- > From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] > Sent: Thursday, March 19, 2009 8:43 AM > > > What would happen with __GFP_RECLAIMABLE for dma_alloc_coherent()? As per [1], GFP_TEMPORARY might be the right approach.. but yes, Changing dummy to do: dma_alloc_coherent(NULL, b[i].size, &b[i].phy, GFP_TEMPORARY); Seems to resolve the issue with the dummy driver. The question however still remains: For a driver to allocate a memory which is not temporary in nature we'd recommend GFP_KERNEL. But as part of the exit sequence the driver will deallocate that memory and as part of init sequence, reallocate. Given that the memory is not reclaimed immediately, it looks like the only way to ensure that would be to do GFP_KERNEL | __GFP_RECLAIMABLE (which essentially is the definition of GFP_TEMPORARY). Regards, Nishanth Menon Ref: [1] http://lkml.indiana.edu/hypermail/linux/kernel/0705.2/0638.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: dma_alloc_coherent fragmentation
> -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Wednesday, March 18, 2009 9:25 PM > To: Kamat, Nishant > Cc: linux-arm-ker...@lists.arm.linux.org.uk; Menon, Nishanth; linux- > o...@vger.kernel.org; Ramirez Luna, Omar; Kanigeri, Hari; Guzman Lugo, > Fernando; Kevin Hilman; 2am...@gmail.com > Subject: Re: dma_alloc_coherent fragmentation > Make sure you're up to date with fixes to the ioremap code, specifically > 24f11ec001920f1cfaeeed8e8b55725d900bbb56. This is not in 2.6.28, > 2.6.29-rc1, 2.6.29-rc2, but is in -rc3 and later. 2.6.29 itself hasn't > been released yet so I don't know what "seems to happen on 2.6.28 and > 2.6.29" actually means because its nonsense. Apologies on the confusion. For this issue, the pertinent tree would be the master branch of [1] linux-omap tree which is synced to 2.6.29-rc8. And yes, the mentioned commit ID is part of the git log. Relevant test code and report of the crash is in [2]. Additional observation in [3] Regards, Nishanth Menon Ref: [1] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git [2] http://marc.info/?l=linux-omap&m=123719772811746&w=2 [3] http://marc.info/?l=linux-omap&m=123722460022336&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] tidspbridge: remove revision history
> -Original Message- > From: Trilok Soni [mailto:soni.tri...@gmail.com] > Sent: Wednesday, March 18, 2009 8:26 AM > To: David Brownell > Cc: Felipe Contreras; Menon, Nishanth; Kanigeri, Hari; linux- > o...@vger.kernel.org; Hiroshi DOYU; Ameya Palande; Guzman Lugo, Fernando > Subject: Re: [PATCH] tidspbridge: remove revision history > > >> > >> I have no idea why I'm in that list. > >> > > > > These short names looks like are given to TI internal developers not > > the open-source contributors to this code. So, "ag" can mean "Amit > > Agrawal" or "Andy Grover" or anything else... > > > > Better to remove these short names from the revision history, it > > doesn't have any meaning. > > > > Nishanth probably can put some points here. > Cards on table: I have never been involved personally on DSPBridge :(.. It is just this: as a developer we all contribute to something so that our legacy remains in some form.. Agreed various other motivations exist ;).. But personally, it feels good to see a tiny contribution being part of something else and being acknowledged for it.. do we as a community say: a) Lets kick all those oldies out.. They were yesteryear material, we can afford to forget them now. OR do we say b) Lets find who those guys are and ask them how they want to acknowledged here.. I mean, we all hate dirty code.. and I personally agree to Felipe's point that much of the old time revision history is eating bytespace and eyespace :(.. At the same time, I guess we still retain the old courtesy b/w one code hack to another :D.. 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: [PATCH] tidspbridge: remove revision history
> -Original Message- > From: Kanigeri, Hari > Sent: Tuesday, March 17, 2009 3:32 PM > To: Felipe Contreras; Menon, Nishanth > Cc: linux-omap@vger.kernel.org; Hiroshi DOYU; Ameya Palande; Guzman Lugo, > Fernando > Subject: RE: [PATCH] tidspbridge: remove revision history > > > > Contributors can be specified as such: a contributors section > > at the top. No need to keep the revision history just for that. > > -- This looks like the way to go. Ack, I think we could collate those in revision history to Contributor's section? 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: [PATCH] tidspbridge: remove revision history
Hi Felipe,
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Tuesday, March 17, 2009 11:17 AM
> To: Menon, Nishanth
> Cc: linux-omap@vger.kernel.org; Kanigeri, Hari; Hiroshi DOYU; Ameya
> Palande; Guzman Lugo, Fernando
> Subject: Re: [PATCH] tidspbridge: remove revision history
>
> >> - *! Revision History:
> >> - *!
> >> - *! 24-Feb-2003 vp: Code Review Updates.
> >> - *! 18-Oct-2002 sb: Ported to Linux platform.
> >> - *! 03-Jul-2001 rr: Removed kfuncs.h because of build errors.
> >> - *! 07-Dec-1999 ag: Fxn error now causes a WinCE DebugBreak;
> >> - *! 30-Aug-1999 ag: Now uses GP_printf for printf and error.
> >> - *!
> > But we did not have git history 1999-2003. we planning on loosing these
> contribs?
>
> Only if you want dspbridge to be merged which as time passes it's
> becoming more clear that you don't. I'm not a kernel developer, but I
Errr.. Not my attempt at a flame war ;).. But then, I am not sure if my comment
meant anything of the sort :)...
> would challenge you to find a diver that has 1000 lines of revision
> history in the source code.
>
> >> - *! 30-Aug-1999 ag: Now uses GP_printf for printf and error.
>
> Not printk? I assume this is not related to Linux then.
>
>
> Are we going to find an issue at some point in time that we'll say: oh
> crap! if only we had the revision history log we could solve it!
Errr... in the old times of cvs kernel, before we shifted to bitkeeper and
later to git, rev history was unfortunately necessary to maintain some sort of
acknowledgement of contributions. Just greping linux-omap master branch " grep
-Ri "Revision History" drivers/|cut -d ":" -f1|wc -l" shows me 227 files of
similar drivers- legacy - agreed. I think bridge is in such a legacy driver.
If any new changes are done, it makes no sense to introduce an entry in the
revision history - agreed. These driver files have a history and folks have
done some work to make it useful, to remove their contributions would be, IMHO,
our disregard for what ever they did (good or bad).. ;) But then, that is just
my opinion..
Note: There are folks whose contributions are reduced to "vp" "rr" "sp" etc.. I
personally have no clue who they are but I guess they would rather be in git
log than in anonymous initials if given a choice today..
>
> I doubt that, the revision history is useless without the actual
> changes. These lines are just introducing noise.
>
DSPBridge has definitely a long way to go before being merged into mainline
kernel. Coding standard is one part of the story. Is this part of a code
cleanup effort to prep the code for merge to kernel? I think I have seen tons
of discussion on this previously.. If we are planning on prepping this driver
for mainline integration that is another discussion and this patch probably is
a tiny fragment to that. The bunch of history starts at [1] though..
Regards,
Nishanth Menon
Ref:
[1] http://marc.info/?l=linux-omap&w=4&r=10&s=dspbridge&q=b
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
dma_alloc_coherent fragmentation
Looping in linux-arm ML: Discussion Ref: [1](linux-omap mailing list) While working with Linux OMAP kernel[2] we found that on allocating 4 meg chunks using dma_alloc_coherent and de-allocating with dma_free_coherent in a loop using a test driver[7], the memory is getting fragmented as shown by Ameya's observation [3] finally resulting in dump_stack due to lack of pages. Searching through previous archives, found [4] which seem to imply that allocating chunks greater than 1 page could cause fragmentation. I wonder why we see this even if we allocate and free the memory in sequence as in [5]. This seems to happen on 2.6.28 and 2.6.29 but not on the 2.6.27 based kernel[6]. Regards, Nishanth Menon Ref: [1] http://marc.info/?t=12371977912&r=1&w=2 [2] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git [3] http://marc.info/?l=linux-omap&m=123722460022336&w=2 [4] http://lkml.indiana.edu/hypermail/linux/kernel/0706.0/0370.html [5] http://marc.info/?l=linux-omap&m=123719772811746&w=2 [6] http://git.omapzoom.com/?p=repo/omapkernel.git; [7] http://marc.info/?l=linux-omap&m=123719772811746&q=p3
RE: [PATCH] tidspbridge: remove revision history
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Felipe Contreras > Sent: Tuesday, March 17, 2009 12:06 AM > To: linux-omap@vger.kernel.org > Cc: Kanigeri, Hari; Hiroshi DOYU; Ameya Palande; Guzman Lugo, Fernando; > Felipe Contreras > Subject: [PATCH] tidspbridge: remove revision history > > No need for that with git. > diff --git a/drivers/dsp/bridge/gen/_gt_para.c > b/drivers/dsp/bridge/gen/_gt_para.c > index 181fe41..b363590 100644 > --- a/drivers/dsp/bridge/gen/_gt_para.c > +++ b/drivers/dsp/bridge/gen/_gt_para.c > @@ -24,14 +24,6 @@ > * etc. into a fully bound image. Thus, GT_assert() can be retained > in > * a program for which GT_?trace() has been compiled out. > * > - *! Revision History: > - *! > - *! 24-Feb-2003 vp: Code Review Updates. > - *! 18-Oct-2002 sb: Ported to Linux platform. > - *! 03-Jul-2001 rr: Removed kfuncs.h because of build errors. > - *! 07-Dec-1999 ag: Fxn error now causes a WinCE DebugBreak; > - *! 30-Aug-1999 ag: Now uses GP_printf for printf and error. > - *! But we did not have git history 1999-2003. we planning on loosing these contribs? 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: dma_alloc_coherent bug?
> -Original Message- > From: Ameya Palande [mailto:2am...@gmail.com] > Sent: Monday, March 16, 2009 7:30 PM > To: Menon, Nishanth > Cc: Gupta, Ramesh; Kevin Hilman; linux-omap@vger.kernel.org; Ramirez Luna, > Omar; Kanigeri, Hari; Ameya Palande; Guzman Lugo, Fernando > Subject: Re: dma_alloc_coherent bug? > > There seems to be a bug some where inside DMA / VM area which is > causing this fragmentation. > > Any clue?? Russell mentioned sometime back: http://lkml.indiana.edu/hypermail/linux/kernel/0706.0/0370.html So I suppose dma_alloc_coherent for > 1page size(4096) is bad? If so hmm.. I am guessing audio driver and others do use dma_alloc_coherent.. I tried my dummy driver on omapzoom master and it seemd to work fine there for 10K iterations :(.. should'nt the same fragmentation hit there too? Any clues? Regards, Nishanth Menon
RE: Regarding OMAP-3430 LCD Display
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Sabine Käß > Sent: Friday, March 13, 2009 1:50 PM > To: linux-omap@vger.kernel.org > Subject: Re: Regarding OMAP-3430 LCD Display > I have a similar problem which I won't explicate here because this list is > for > Linux on OMAP ;-) ... but can you tell me, WHO I may ask something about > programming the OMAP without operating system?? > Please contact your technical representative within TI for the same. 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: Bridge issue #3! dma_alloc_coherent causing crash - pm branch
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Friday, March 13, 2009 2:35 AM > Sounds like a memory leak in the bridge driver to me. I suggest you > enable memory leak debugging. In Kconfig > >Kernel Hacking --> Kernel debugging > > Enable 'Debug slab memory allocations' and its child 'Memory leak > debugging'. > > Or, you could switch to the SLUB allocator which has some more flexible > debug options which can be controlled at boot-time from the cmdline. > > While you are in the Kernel debugging menu, make sure you enable > 'Verbose BUG()' and 'Verbose kernel errors'. This will ensure that > any memory leaks will be dumped with some extra debug output. Thanks. Yep, it does sound like a mem leak... will keep the list posted as we progress. 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
Bridge issue #3! dma_alloc_coherent causing crash - pm branch
Hi Folks, I seem to be having (mis?)fortune of hitting every single roadblock on the way.. After applying patches for list_del and the ioremap, I am attempting to loadup bridge in another (and hopefully the last possible way): insmod ./bridgedriver.ko shm_size=0x40 phys_mempool_base=0 base_img=/lib/dsp/baseimage.dof to do this I need a large enough dma_alloc_coherent pool. So, I changed CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=10 from 2 to get myself enough space for the driver to do dma_alloc_coherent. Over some 20-30 iterations, I hit the following crash! I added trace printks to every single dma_alloc_coherent and frees in the bridge driver, and the alloc and frees match - so no obvious leaks or pointer corruptions.. So, I wrote (yet another) dummy driver which allocates and frees the memory in the same order as the bridge does. The dummy driver functions correctly and does not crash after few 100s of iterations even! Now, interestingly at the start of every new iterations, the dummy driver gets the same virtual-physical address pair, but in the case of the bridge driver, the addresses change. I suspect that is a symptom of the problem though I do not know the reason why.. Insights are most welcome.. Details: Codebase: l-o pm branch + gitorious + ioremap patch= http://marc.info/?l=linux-omap&m=123689459826837&w=2 (should be in pm branch soon) + autoload patch = http://marc.info/?l=linux-omap&m=123687157321175&w=2 + list-del patch = http://marc.info/?l=linux-omap&m=123686780114707&w=2 (should be in pm branch soon) Bootargs: console=ttyS0,115200n8 noinitrd ip=dhcp root=/dev/nfs rw nfsroot=128.247.75.1:/home/fs/sdp3430,nolock,wsize=1024,rsize=1024 mem=64M (not that 64M matters in this case) Error: <4>insmod: page allocation failure. order:10, mode:0xd0 insmod: page allocation failure. order:10, mode:0xd0 [] [] (dump_stack+0x0/0x14) (dump_stack+0x0/0x14) from [] from [] (__alloc_pages_internal+0x384/0x39c) (__alloc_pages_internal+0x384/0x39c) [] [] (__alloc_pages_internal+0x0/0x39c) (__alloc_pages_internal+0x0/0x39c) from [] from [] (__dma_alloc+0x170/0x3c4) (__dma_alloc+0x170/0x3c4) [] [] (__dma_alloc+0x0/0x3c4) (__dma_alloc+0x0/0x3c4) from [] from [] (dma_alloc_coherent+0x58/0x64) (dma_alloc_coherent+0x58/0x64) [] [] (dma_alloc_coherent+0x0/0x64) (dma_alloc_coherent+0x0/0x64) from [] from [] (MEM_AllocPhysMem+0xc4/0xe4 [bridgedriver]) (MEM_AllocPhysMem+0xc4/0xe4 [bridgedriver]) r7:c1bfdc5c r7:c1bfdc5c r6:48306a00 r6:48306a00 r5:c48aa000 r5:c48aa000 r4:bf11fe60 r4:bf11fe60 [] [] (MEM_AllocPhysMem+0x0/0xe4 [bridgedriver]) (MEM_AllocPhysMem+0x0/0xe4 [bridgedriver]) from [] from [] (DRV_RequestResources+0x2c0/0) (DRV_RequestResources+0x2c0/0x370 [bridgedriver]) r7:48307000 r7:48307000 r6:48306a00 r6:48306a00 r5:c48aa000 r5:c48aa000 r4:8000 r4:8000 [] [] (DRV_RequestResources+0x0/0x370 [bridgedriver]) (DRV_RequestResources+0x0/0x370 [bridgedriver]) from [] from [] (DSP_Init+0x68/0xf0) (DSP_Init+0x68/0xf0 [bridgedriver]) [] [] (DSP_Init+0x0/0xf0 [bridgedriver]) (DSP_Init+0x0/0xf0 [bridgedriver]) from [] from [] (bridge_init+0x38c/0x3f4 [bridgedriver]) (bridge_init+0x38c/0x3f4 [bridgedriver]) r6:bf11f750 r6:bf11f750 r5:1dcd6500 r5:1dcd6500 r4:bf120068 r4:bf120068 [] [] (bridge_init+0x0/0x3f4 [bridgedriver]) (bridge_init+0x0/0x3f4 [bridgedriver]) from [] from [] (do_one_initcall+0x64/0x198) (do_one_initcall+0x64/0x198) r8:c002df28 r8:c002df28 r7: r7: r6:4023a000 r6:4023a000 r5:bf11fa00 r5:bf11fa00 r4:c03aa340 r4:c03aa340 [] [] (do_one_initcall+0x0/0x198) (do_one_initcall+0x0/0x198) from [] from [] (sys_init_module+0x98/0x188) (sys_init_module+0x98/0x188) [] [] (sys_init_module+0x0/0x188) (sys_init_module+0x0/0x188) from [] from [] (ret_fast_syscall+0x0/0x2c) (ret_fast_syscall+0x0/0x2c) r7:0080 r7:0080 r6: r6: r5:000b r5:000b r4: r4: Mem-info: Mem-info: Normal per-cpu: Normal per-cpu: CPU0: hi: 18, btch: 3 usd: 2 CPU0: hi: 18, btch: 3 usd: 2 Active_anon:0 active_file:0 inactive_anon:201 inactive_file:25 unevictable:0 dirty:0 writeback:0 unstable:0 free:14210 slab:468 mapped:0 pagetables:31 bounce:0 Active_anon:0 active_file:0 inactive_anon:201 inactive_file:25 unevictable:0 dirty:0 writeback:0 unstable:0 free:14210 slab:468 mapped:0 pagetables:31 bounce:0 Normal free:56840kB min:1016kB low:1268kB high:1524kB active_anon:0kB inactive_anon:804kB active_file:0kB inactive_file:100kB unevictable:0kB present:65024kB pages_scanned:0 allo Normal free:56840kB min:1016kB low:1268kB high:1524kB active_anon:0kB inactive_anon:804kB active_file:0kB inactive_file:100kB unevictable:0kB present:65024kB pages_scanned:0 allo lowmem_reserve[]:lowmem_reserve[]: 0 0 0 0 Normal: Normal: 144*4kB 144*4kB 141*8kB 141*8kB 96*16kB 96*16kB 73*32kB 73*32kB 39*64kB 39*64kB 11*128kB 11*128kB 15*256kB 15*256kB 11*512kB 11*512kB 15*1024kB 15*1024kB 11*2048B = 56840kB 25 total pagecache pages
RE: [PATCH] DSPBRIDGE Fix for auto image load updated
> -Original Message- > From: Gupta, Ramesh > Sent: Thursday, March 12, 2009 5:25 PM > To: linux-omap@vger.kernel.org > Cc: Menon, Nishanth; Kanigeri, Hari > Subject: [PATCH] DSPBRIDGE Fix for auto image load updated > > From 757beb63e8e66c168231dd990440816fc5789d6c Mon Sep 17 00:00:00 2001 > From: Ramesh Gupta > Date: Thu, 12 Mar 2009 09:32:31 -0500 > Subject: [PATCH] DSPBRIDGE Fix for auto image load updated > Resending as the previous patch was not applyng cleanly. > This is updated patch to fix the auto image loading while bridgedriver > initialization. > > Signed-off-by: Ramesh Gupta G Tested-by: Nishanth Menon Might be a good idea to push to dspbridge gitorious 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: ioremap bug? (was RE: DSPBRIDGE: segmentation fault after reloading dspbridge several times due to a memory leak.)
Kevin, Richard, > -Original Message- > From: Menon, Nishanth > > > -Original Message- > > From: Woodruff, Richard > > Sent: Thursday, March 12, 2009 9:33 PM > > > > This rings a bell from a couple months back. I've not followed the > thread > > but recall a recent fix to ioremap. > > > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg08836.html > > > Ouch.. commit 24f11ec001920f1cfaeeed8e8b55725d900bbb56[1] is what you are > speaking of? That commit is not present in pm branch :( > Aye.. cherry-pick saves the day (yet again).. script runs without a hitch.. (though I admire the simple code that Tomi had put for the proving the same).. Anyone know of any more similar memory - kmalloc/ioremap/dma_alloc_coherent/vm surprises since 2.6.28? ;) but that would be pretty lazy me I guess..:D 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: ioremap bug? (was RE: DSPBRIDGE: segmentation fault after reloading dspbridge several times due to a memory leak.)
> -Original Message- > From: Woodruff, Richard > Sent: Thursday, March 12, 2009 9:33 PM > To: Menon, Nishanth; Kevin Hilman > Cc: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; Kanigeri, Hari; > Lakhani, Amish; Gupta, Ramesh; Ameya Palande > Subject: RE: ioremap bug? (was RE: DSPBRIDGE: segmentation fault after > reloading dspbridge several times due to a memory leak.) > > Some more isolation: > > The l-o master branch does not have an issue, only the pm branch seems > to have > > the problem - probably some commit(s?) missing in pm branch. Since > bridge is > > based off the pm branch, wont make sense to regress on it :(. > > This rings a bell from a couple months back. I've not followed the thread > but recall a recent fix to ioremap. > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg08836.html > Ouch.. commit 24f11ec001920f1cfaeeed8e8b55725d900bbb56[1] is what you are speaking of? That commit is not present in pm branch :( Regards, Nishanth Menon Ref: 1. http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=24f11ec001920f1cfaeeed8e8b55725d900bbb56 -- 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: ioremap bug? (was RE: DSPBRIDGE: segmentation fault after reloading dspbridge several times due to a memory leak.)
Kevin,
Some more isolation:
The l-o master branch does not have an issue, only the pm branch seems to have
the problem - probably some commit(s?) missing in pm branch. Since bridge is
based off the pm branch, wont make sense to regress on it :(.
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Thursday, March 12, 2009 7:27 PM
> To: Menon, Nishanth
> Cc: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; Kanigeri, Hari;
> Woodruff, Richard; Lakhani, Amish; Gupta, Ramesh; Ameya Palande
> Subject: Re: ioremap bug? (was RE: DSPBRIDGE: segmentation fault after
> reloading dspbridge several times due to a memory leak.)
> Which of these physical addresses causes an increasing virtual
> address? The addresses in the 0x48xx (L4, L4_WKUP) range should
> just trigger static mapping via the arch-specific ioremap, so those
> should always map to the same virt address.
>
> Could you do the experiment with a smaller number of mappings? Maybe
> just one at a time of the non L4 mappings? Probably starting with
> only the BASE,SIZE mapping.
>
Attached is the patch for pm branch.
Codebase:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
git checkout -b pm --track origin/pm
git branch iotest-pm
git apply 0001-MISC-dummy-driver-to-test-ioremap.patch
make omap_3430sdp_defconfig
make uImage && make modules
bootargs: console=ttyS0,115200n8 noinitrd ip=dhcp root=/dev/nfs rw
nfsroot=:,nolock,wsize=1024,rsize=1024 mem=64M
I reorganized the driver from the previous version I had send, so that we can
provide base address,size and number of io_remaps to try as module params. And
tested with the following shell script:
#!/bin/bash
slee()
{
echo "Sleep "
#sleep 5
}
try=1
while [ $try -lt 13 ]; do
i=0
while [ $i -lt 100 ]; do
echo "insmod $i base=0x8700 size=0x60 try=$try"
insmod ./dummy.ko base=0x8700 size=0x60 try=$try
if [ $? -ne 0 ]; then
echo "QUIT IN INSMOD $i"
exit 1;
fi
slee
echo "rmmod $i"
rmmod dummy
if [ $? -ne 0 ]; then
echo "QUIT IN RMMOD $i"
exit 1;
fi
i=`expr $i + 1`
slee
done
try=$(( $try + 1 ))
done
Result:
insmod 21 base=0x8700 size=0x60 try=1
vmap allocation failed: use vmalloc= to increase size.
Map[0] - virt=0x phy=0x8700 size=0x0060
Allocation failed idx=0
insmod: cannot insert `./dummy.ko': Cannot allocate memory (-1): Cannot
allocate memory
QUIT IN INSMOD 21
In terms of virtual addresses generated:
0xCD80
0xCE00
0xCE80
0xCF00
0xCF80
0xD000
0xD080
0xD100
...
[iteration 20] 0xD780
The next one fails.
The same patch will apply on linux-omap master branch also, but patching
drivers/misc/Makefile will break with my patch - need to trivial hand merge it..
commitIDs tested against:
linux-omap master: cc2b459c066361098704c586f3134c3c3ac13be3 (the entire script
runs through)
linux-omap pm: 4f422d583e2e233c19eb20754b8cfad6ed9e460a (the script fails
around 21st iteration with try=1)
Regards,
Nishanth Menon
0001-MISC-dummy-driver-to-test-ioremap.patch
Description: 0001-MISC-dummy-driver-to-test-ioremap.patch
RE: ioremap bug? (was RE: DSPBRIDGE: segmentation fault after reloading dspbridge several times due to a memory leak.)
> -Original Message- > From: Menon, Nishanth > Sent: Thursday, March 12, 2009 6:53 PM > To: Menon, Nishanth; Guzman Lugo, Fernando; linux-omap@vger.kernel.org > Cc: Kanigeri, Hari; Woodruff, Richard; Lakhani, Amish; Gupta, Ramesh; > Ameya Palande > Subject: RE: ioremap bug? (was RE: DSPBRIDGE: segmentation fault after > reloading dspbridge several times due to a memory leak.) > > > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > ow...@vger.kernel.org] On Behalf Of Menon, Nishanth > > Sent: Thursday, March 12, 2009 6:40 PM > > To: Guzman Lugo, Fernando; linux-omap@vger.kernel.org > > Cc: Kanigeri, Hari; Woodruff, Richard; Lakhani, Amish; Gupta, Ramesh; > > Ameya Palande > > Subject: ioremap bug? (was RE: DSPBRIDGE: segmentation fault after > > reloading dspbridge several times due to a memory leak.) > > > console output where you can see the address increasing. > > > > I duplicated this with the following dummy driver which ioremaps as per > > the same allocations that the bridge driver would have done: > > > > #include > > #include > > #include > > #include > > #include > > > > #define BASE 0x8700 > > #define SIZE 0x60 > > > Just an update (thanks to Fernando in pointing this out) > 0x8700, 0x60, fails with same error > 0x8800, 0x60, fails with same error Wrong attempt!! Should have tried: 0x8710, 0x60 - this worked > 0x8700, 0x70 - went thru 300 odd iterations without error!! This means that if I keep end address constant, it is fine.. with this hypothesis, I tried 0x8720, 0x50 - this also worked Implying the start address and size of the first allocation in my dummy driver did not have a factor in the test failure, but just the end address of the ioremap! 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: ioremap bug? (was RE: DSPBRIDGE: segmentation fault after reloading dspbridge several times due to a memory leak.)
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Menon, Nishanth > Sent: Thursday, March 12, 2009 6:40 PM > To: Guzman Lugo, Fernando; linux-omap@vger.kernel.org > Cc: Kanigeri, Hari; Woodruff, Richard; Lakhani, Amish; Gupta, Ramesh; > Ameya Palande > Subject: ioremap bug? (was RE: DSPBRIDGE: segmentation fault after > reloading dspbridge several times due to a memory leak.) > > console output where you can see the address increasing. > > I duplicated this with the following dummy driver which ioremaps as per > the same allocations that the bridge driver would have done: > > #include > #include > #include > #include > #include > > #define BASE 0x8700 > #define SIZE 0x60 > Just an update (thanks to Fernando in pointing this out) 0x8700, 0x60, fails with same error 0x8800, 0x60, fails with same error 0x8700, 0x70 - went thru 300 odd iterations without error!! Mebbe this sequence is triggering a bug? 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
ioremap bug? (was RE: DSPBRIDGE: segmentation fault after reloading dspbridge several times due to a memory leak.)
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Guzman Lugo, Fernando
> Sent: Thursday, March 12, 2009 2:04 AM
> To: linux-omap@vger.kernel.org
> Subject: DSPBRIDGE: segmentation fault after reloading dspbridge several
> times due to a memory leak.
> Reloading the dspbridge several times I am getting a Segmentation
> fault. Seeing the log it seems that the memory was exhausted
>
> The error happens when ioremap is called
>
> void MEM_ExtPhysPoolInit(u32 poolPhysBase, u32 poolSize)
> {
> u32 poolVirtBase;
>
> /* get the virtual address for the physical memory pool passed
> */
> poolVirtBase = (u32)ioremap(poolPhysBase, poolSize);
> .
>
> Putting some printk's and printing the address returned by ioremap, I
> realized that address returned by ioremap each time I reload the dspbridge
> is different, in fact the address is increasing. I also put a printk where
> iounmap is called to make sure it is called and yes it is actually called.
> However testing with a kernel + bridge for linux 23x I always get the same
> address for pool memory. Any idea what the problem is? I have included the
> console output where you can see the address increasing.
I duplicated this with the following dummy driver which ioremaps as per the
same allocations that the bridge driver would have done:
#include
#include
#include
#include
#include
#define BASE 0x8700
#define SIZE 0x60
struct mem_s{
void * vir;
u32 phy;
u32 size;
};
struct mem_s b[]={
{0,BASE,SIZE},
{0,0x48306000,4096},
{0,0x48004000,4096},
{0,0x48094000,4096},
{0,0x48002000,4096},
{0,0x5c7f8000,98304},
{0,0x5ce0,32768},
{0,0x5cf04000,81920},
{0,0x48005000,4096},
{0,0x48307000,4096},
{0,0x48306a00,4096},
{0,0x5d00,4096},
};
static int __init dummy_init(void)
{
int i;
for (i=0;i<(sizeof(b)/sizeof(struct mem_s));i++) {
b[i].vir = ioremap(b[i].phy,b[i].size);
if(b[i].vir == NULL) {
printk(KERN_ERR "Allocation failed idx=%d\n",i);
/* Free up all the prev allocs */
i--;
while(i>=0) {
iounmap(b[i].vir);
i--;
}
return -ENOMEM;
}
}
return 0;
}
module_init(dummy_init);
static void __exit dummy_exit(void)
{
int i;
for (i=0;i<(sizeof(b)/sizeof(struct mem_s));i++) {
iounmap(b[i].vir);
}
}
module_exit(dummy_exit);
MODULE_LICENSE("GPL");
Regression script:
#!/bin/bash
i=0
slee()
{
echo "Sleep "
#sleep 5
}
while [ $i -lt 100 ]; do
echo "insmod $i"
insmod ./dummy.ko
if [ $? -ne 0 ]; then
echo "QUIT IN INSMOD $i"
exit 1;
fi
slee
echo "rmmod $i"
rmmod dummy
if [ $? -ne 0 ]; then
echo "QUIT IN RMMOD $i"
exit 1;
fi
i=`expr $i + 1`
slee
done
after around 38 iterations:
<4>vmap allocation failed: use vmalloc= to increase size.
vmap allocation failed: use vmalloc= to increase size.
<3>Allocation failed idx=0
Allocation failed idx=0
However cat /proc/meminfo after this error is:
cat /proc/meminfo
MemTotal: 61920 kB
MemFree: 56900 kB
Buffers: 0 kB
Cached: 2592 kB
SwapCached:0 kB
Active: 1920 kB
Inactive: 1252 kB
Active(anon):580 kB
Inactive(anon):0 kB
Active(file): 1340 kB
Inactive(file): 1252 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 616 kB
Mapped: 688 kB
Slab: 1296 kB
SReclaimable:480 kB
SUnreclaim: 816 kB
PageTables: 96 kB
NFS_Unstable: 0 kB
Bounce:0 kB
WritebackTmp: 0 kB
CommitLimit: 30960 kB
Committed_AS: 2932 kB
VmallocTotal: 319488 kB
VmallocUsed: 8 kB
VmallocChunk: 319448 kB
We seem to have more than enough vmalloc space according to this.. am I right
in thinking this is a kernel vmalloc handling issue?
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: [PATCH 1/1] DSPBRIDGE Fix for image autoload
> -Original Message- > From: Gupta, Ramesh > Sent: Thursday, March 12, 2009 10:31 AM > To: Menon, Nishanth; linux-omap@vger.kernel.org > Cc: Kanigeri, Hari; Guzman Lugo, Fernando > Subject: RE: [PATCH 1/1] DSPBRIDGE Fix for image autoload > > > > > > -----Original Message- > > > From: Menon, Nishanth > > > Sent: Thursday, March 12, 2009 9:39 AM > > > To: Gupta, Ramesh; linux-omap@vger.kernel.org > > > Cc: Kanigeri, Hari; Guzman Lugo, Fernando > > > Subject: RE: [PATCH 1/1] DSPBRIDGE Fix for image autoload > > > > > > > -Original Message- > > > > From: Gupta, Ramesh > > > > Sent: Thursday, March 12, 2009 8:01 AM > > > > To: Menon, Nishanth; linux-omap@vger.kernel.org > > > > Cc: Kanigeri, Hari; Guzman Lugo, Fernando > > > > Subject: RE: [PATCH 1/1] DSPBRIDGE Fix for image autoload > > > > > > > > I have tried this on linux-omap pm branch . This can be > > applied on > > > > top > > > of > > > > my DVFS > > > > Patches earlier. > > > > > > > Your patch does not apply clean :( > > > $ wget -O ramesh.auto.patch "http://marc.info/?l=linux- > > > omap&m=123683598308417&q=raw" > > > $ vim ramesh.auto.patch (edited to remove the linux-omap trailer) $ > > > patch -p1<./ramesh.auto.patch --dry-run patching file > > > drivers/dsp/bridge/rmgr/drv_interface.c > > > Hunk #1 succeeded at 400 (offset -5 lines). > > > Hunk #2 succeeded at 408 (offset -5 lines). > > > Hunk #3 succeeded at 450 with fuzz 1 (offset -5 lines). > > > Hunk #4 succeeded at 470 (offset -5 lines). > > > Hunk #5 succeeded at 655 (offset -5 lines). > > > > > > Could you rebase your patch against the following: > > > git clone > > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap- > > > 2.6.git > > > cd linux-omap-2.6.git > > > git checkout -b pm --track origin/pm > > > git fetch git://gitorious.org/lk/mainline.git > > > tidspbridge-pm:tidspbridge- pm git checkout tidspbridge-pm > > git merge > > > pm > > > > > > And the patch does not work :( > > What is your code base? It does work for me. As stated above: git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git cd linux-omap-2.6.git git checkout -b pm --track origin/pm git fetch git://gitorious.org/lk/mainline.gittidspbridge-pm:tidspbridge- pm git checkout tidspbridge-pm git merge pm 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: [PATCH 1/1] DSPBRIDGE Fix for image autoload
> -Original Message- > From: Menon, Nishanth > Sent: Thursday, March 12, 2009 9:39 AM > To: Gupta, Ramesh; linux-omap@vger.kernel.org > Cc: Kanigeri, Hari; Guzman Lugo, Fernando > Subject: RE: [PATCH 1/1] DSPBRIDGE Fix for image autoload > > > -Original Message- > > From: Gupta, Ramesh > > Sent: Thursday, March 12, 2009 8:01 AM > > To: Menon, Nishanth; linux-omap@vger.kernel.org > > Cc: Kanigeri, Hari; Guzman Lugo, Fernando > > Subject: RE: [PATCH 1/1] DSPBRIDGE Fix for image autoload > > > > I have tried this on linux-omap pm branch . This can be applied on top > of > > my DVFS > > Patches earlier. > > > Your patch does not apply clean :( > $ wget -O ramesh.auto.patch "http://marc.info/?l=linux- > omap&m=123683598308417&q=raw" > $ vim ramesh.auto.patch (edited to remove the linux-omap trailer) > $ patch -p1<./ramesh.auto.patch --dry-run > patching file drivers/dsp/bridge/rmgr/drv_interface.c > Hunk #1 succeeded at 400 (offset -5 lines). > Hunk #2 succeeded at 408 (offset -5 lines). > Hunk #3 succeeded at 450 with fuzz 1 (offset -5 lines). > Hunk #4 succeeded at 470 (offset -5 lines). > Hunk #5 succeeded at 655 (offset -5 lines). > > Could you rebase your patch against the following: > git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap- > 2.6.git > cd linux-omap-2.6.git > git checkout -b pm --track origin/pm > git fetch git://gitorious.org/lk/mainline.git tidspbridge-pm:tidspbridge- > pm > git checkout tidspbridge-pm > git merge pm And the patch does not work :( # insmod ./bridgedriver.ko phys_mempool_base=0x8700 phys_mempool_size=0x60 base_img=dsp/baseimage.dof <4>[ cut here ] [ cut here ] <4>WARNING: at arch/arm/plat-omap/omap-pm-srf.c:241 omap_pm_cpu_set_freq+0x20/0x44() WARNING: at arch/arm/plat-omap/omap-pm-srf.c:241 omap_pm_cpu_set_freq+0x20/0x44() Modules linked in:Modules linked in: bridgedriver(+) bridgedriver(+) [last unloaded: bridgedriver] [last unloaded: bridgedriver] [] [] (dump_stack+0x0/0x14) (dump_stack+0x0/0x14) from [] from [] (warn_on_slowpath+0x4c/0x68) (warn_on_slowpath+0x4c/0x68) [] [] (warn_on_slowpath+0x0/0x68) (warn_on_slowpath+0x0/0x68) from [] from [] (omap_pm_cpu_set_freq+0x20/0x44) (omap_pm_cpu_set_freq+0x20/0x44) r6:8000 r6:8000 r5:80008010 r5:80008010 r4:c3dc5b08 r4:c3dc5b08 [] [] (omap_pm_cpu_set_freq+0x0/0x44) (omap_pm_cpu_set_freq+0x0/0x44) from [] from [] (PROC_Load+0x2c8/0x40c [bridgedriver]) (PROC_Load+0x2c8/0x40c [bridgedriver]) [] [] (PROC_Load+0x0/0x40c [bridgedriver]) (PROC_Load+0x0/0x40c [bridgedriver]) from [] from [] (PROC_AutoStart+0x174/0x1c4 [bridgedriver) (PROC_AutoStart+0x174/0x1c4 [bridgedriver]) [] [] (PROC_AutoStart+0x0/0x1c4 [bridgedriver]) (PROC_AutoStart+0x0/0x1c4 [bridgedriver]) from [] from [] (WCD_InitComplete2+0x58/0x8c [b) (WCD_InitComplete2+0x58/0x8c [bridgedriver]) r7: r7: r6:c3dc5dd4 r6:c3dc5dd4 r5:8000 r5:8000 r4:c3981600 r4:c3981600 [] [] (WCD_InitComplete2+0x0/0x8c [bridgedriver]) (WCD_InitComplete2+0x0/0x8c [bridgedriver]) from [] from [] (DSP_Init+0xd8/0xf0 [bridge) (DSP_Init+0xd8/0xf0 [bridgedriver]) r5:c3dc5c99 r5:c3dc5c99 r4:8000 r4:8000 [] [] (DSP_Init+0x0/0xf0 [bridgedriver]) (DSP_Init+0x0/0xf0 [bridgedriver]) from [] from [] (bridge_init+0x33c/0x3ec [bridgedriver]) (bridge_init+0x33c/0x3ec [bridgedriver]) r6:bf05a288 r6:bf05a288 r5:bf05ab88 r5:bf05ab88 r4:bf05ab88 r4:bf05ab88 [] [] (bridge_init+0x0/0x3ec [bridgedriver]) (bridge_init+0x0/0x3ec [bridgedriver]) from [] from [] (do_one_initcall+0x64/0x198) (do_one_initcall+0x64/0x198) r8:c002df28 r8:c002df28 r7: r7: r6:4023a000 r6:4023a000 r5:bf05a520 r5:bf05a520 r4:c03aa340 r4:c03aa340 [] [] (do_one_initcall+0x0/0x198) (do_one_initcall+0x0/0x198) from [] from [] (sys_init_module+0x98/0x188) (sys_init_module+0x98/0x188) [] [] (sys_init_module+0x0/0x188) (sys_init_module+0x0/0x188) from [] from [] (ret_fast_syscall+0x0/0x2c) (ret_fast_syscall+0x0/0x2c) r7:0080 r7:0080 r6: r6: r5:000b r5:000b r4: r4: <4>---[ end trace 7a555f9f02586741 ]--- ---[ end trace 7a555f9f02586741 ]--- <4>[ cut here ] [ cut here ] <4>WARNING: at arch/arm/plat-omap/omap-pm-srf.c:241 omap_pm_cpu_set_freq+0x20/0x44() WARNING: at arch/arm/plat-omap/omap-pm-srf.c:241 omap_pm_cpu_set_freq+0x20/0x44() Modules linked in:Modules linked in: bridgedriver(+) bridgedriver(+) [last unloaded: bridgedriver] [last unloaded: bridgedriver] [] [] (dump_stack+0x0/0x14) (dump_stack+0x0/0x14) from [] from [] (warn_on_slowpath+0x4c/0x68) (warn_on_slowpath+0x4c/0x68) [] [] (warn_on_slowpath+0x0/0x68) (warn_on_slowpath+0x0/0x68) from [] from []
RE: [PATCH 1/1] DSPBRIDGE Fix for image autoload
> -Original Message- > From: Gupta, Ramesh > Sent: Thursday, March 12, 2009 8:01 AM > To: Menon, Nishanth; linux-omap@vger.kernel.org > Cc: Kanigeri, Hari; Guzman Lugo, Fernando > Subject: RE: [PATCH 1/1] DSPBRIDGE Fix for image autoload > > I have tried this on linux-omap pm branch . This can be applied on top of > my DVFS > Patches earlier. > Your patch does not apply clean :( $ wget -O ramesh.auto.patch "http://marc.info/?l=linux-omap&m=123683598308417&q=raw"; $ vim ramesh.auto.patch (edited to remove the linux-omap trailer) $ patch -p1<./ramesh.auto.patch --dry-run patching file drivers/dsp/bridge/rmgr/drv_interface.c Hunk #1 succeeded at 400 (offset -5 lines). Hunk #2 succeeded at 408 (offset -5 lines). Hunk #3 succeeded at 450 with fuzz 1 (offset -5 lines). Hunk #4 succeeded at 470 (offset -5 lines). Hunk #5 succeeded at 655 (offset -5 lines). Could you rebase your patch against the following: git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git cd linux-omap-2.6.git git checkout -b pm --track origin/pm git fetch git://gitorious.org/lk/mainline.git tidspbridge-pm:tidspbridge-pm git checkout tidspbridge-pm git merge pm 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: [PATCH] OMAP:clock: missing list_del for clk_notifier_unregister
> -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Thursday, March 12, 2009 9:31 AM > To: Menon, Nishanth > Cc: linux-omap@vger.kernel.org; Woodruff, Richard; Nayak, Rajendra; Gupta, > Ramesh; Palande Ameya > Subject: Re: [PATCH] OMAP:clock: missing list_del for > clk_notifier_unregister > Just to clarify, this is currently against the PM branch. There's a new Yes. This is against the PM branch > version of the clock notifier patch coming out soon against l-o; will roll > this fix in. > Thanks. 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: [PATCH 1/1] DSPBRIDGE Fix for image autoload
Ramesh, > -Original Message- > From: Gupta, Ramesh > Sent: Thursday, March 12, 2009 7:32 AM > To: linux-omap@vger.kernel.org > Cc: Menon, Nishanth; Kanigeri, Hari; Guzman Lugo, Fernando > Subject: [PATCH 1/1] DSPBRIDGE Fix for image autoload > > From fbbf5c9c308c2e1e90e70c57a48798c5d05a6b1d Mon Sep 17 00:00:00 2001 > From: Ramesh Gupta > Date: Thu, 12 Mar 2009 10:48:08 +0530 > Subject: [PATCH 1/1] DSPBRIDGE Fix for image autoload. > > This fixes the issue with the image autoloading while > installing the bridgedriver with install param base_img What is your code base? Omapzoom or gitorious? Could you send us the link to the git log of the branch you are sending this for? 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: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload
> -Original Message- > From: Woodruff, Richard > Sent: Wednesday, March 11, 2009 6:40 PM > To: Menon, Nishanth; linux-omap@vger.kernel.org > Cc: ext Paul Walmsley; Nayak, Rajendra; Gupta, Ramesh > Subject: RE: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload > > > It does not make sense for clock notifier_registration to oops out.. it > has'nt > > come out of init even.. > > > > This looks like list_del missing in clock_notifier unregistration > function :(. > > I have a patch in place.. sending in a few mins > > Yes. Side issue I pointed out will come up later. If notifier doesn't > work there might be a few bugs its useable. Would this appear as the following crash (after 14-18 iterations now with my clk_notifer_unregister patch): Unable to handle kernel paging request at virtual address 80200800 pgd = c3eb8000 *pgd=[80200800] Internal error: Oops: 5 [#1] Modules linked in:Modules linked in: [last unloaded: bridgedriver] [last unloaded: bridgedriver] CPU: 0Not tainted (2.6.28-omap1-00211-gcb75442-dirty #6) PC is at vmap_page_range+0xe4/0x1c4 LR is at vmap_page_range+0x160/0x1c4 pc : []lr : []psr: 8013 Backtrace: Backtrace: [] [] (vmap_page_range+0x0/0x1c4) (vmap_page_range+0x0/0x1c4) from [] from [] (map_vm_area+0x28/0x40) (map_vm_area+0x28/0x40) [] [] (map_vm_area+0x0/0x40) (map_vm_area+0x0/0x40) from [] from [] (__vmalloc_area_node+0x104/0x130) (__vmalloc_area_node+0x104/0x130) r5:c39e1460 r5:c39e1460 r4:03a8 r4:03a8 [] [] (__vmalloc_area_node+0x0/0x130) (__vmalloc_area_node+0x0/0x130) from [] from [] (__vmalloc_node+0x90/0xa8) (__vmalloc_node+0x90/0xa8) [] [] (__vmalloc_node+0x0/0xa8) (__vmalloc_node+0x0/0xa8) from [] from [] (vmalloc+0x28/0x34) (vmalloc+0x28/0x34) r7: r7: r6:4023a000 r6:4023a000 r5:003a75f0 r5:003a75f0 r4:4023a000 r4:4023a000 [] [] (vmalloc+0x0/0x34) (vmalloc+0x0/0x34) from [] from [] (load_module+0x34/0x1468) (load_module+0x34/0x1468) [] [] (load_module+0x0/0x1468) (load_module+0x0/0x1468) from [] from [] (sys_init_module+0x54/0x188) (sys_init_module+0x54/0x188) [] [] (sys_init_module+0x0/0x188) (sys_init_module+0x0/0x188) from [] from [] (ret_fast_syscall+0x0/0x2c) (ret_fast_syscall+0x0/0x2c) r7:0080 r7:0080 r6: r6: r5:000b r5:000b r4: r4: Code: Code: 0a24 0a24 e51b1030 e51b1030 e51b303c e51b303c e0836101 e0836101 (e5952000) (e5952000) 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: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload
Richard, > -Original Message- > From: Woodruff, Richard > Sent: Wednesday, March 11, 2009 5:28 PM > To: Menon, Nishanth; linux-omap@vger.kernel.org > Cc: ext Paul Walmsley; Nayak, Rajendra; Gupta, Ramesh > Subject: RE: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload > > > > driver as explained below. Looking for any advice to fix this issue :( > > Does it need DVFS enabled to fail? Is voltage high enough (to current DM)? > There were some issues there. Yes, Rajendra's VDD change is merged in [1] pm branch. > > A side and possibly related note is the below 0x800 is way too high and > will likely result in screen or other fifo related effects. The delay > target should be around 5uS (for 26Mhz sysclk) and half of that for 13MHz > sysclk. > > Given a value of 0xC8 with ARM at 125MHz, a vdd2-opp2 -> vdd2-opp3 takes > 105uS using current code. This it self is too high for some display > fifos. 0x800 is out of the park high. > > End note is needs tuning for DVFS. > > configure_core_dpll: > ldr r4, omap3_cm_clksel1_pll > ldr r5, [r4] > ldr r6, core_m2_mask_val@ modify m2 for core dpll > and r5, r5, r6 > orr r5, r5, r3, lsl #0x1B @ r3 contains the M2 val > str r5, [r4] > mov r5, #0x800 @ wait for the clock to stabilise > cmp r3, #2 > bne wait_clk_stable > bx lr It does not make sense for clock notifier_registration to oops out.. it has'nt come out of init even.. This looks like list_del missing in clock_notifier unregistration function :(. I have a patch in place.. sending in a few mins Regards, Nishanth Menon [1] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=pm -- 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
DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload
Hi Folks, With the latest linux-omap pm + gitorious bridge changes on SDP3430, enabling BRIDGE_DVFS and SRF seems to cause an issue with clock notifier.. I am not entirely of the cause of the issue(don't have a debugger handy at the moment :( ): The condition is reproducible on exactly the third insmod of the driver as explained below. Looking for any advice to fix this issue :( Codebase: git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git git checkout -b pm --track origin/pm git fetch git://gitorious.org/lk/mainline.git tidspbridge-pm:tidspbridge-pm git checkout tidspbridge-pm git merge pm defconfig: essentially omap_3430sdp_defconfig, enable SRF and bridge+bridge_dvfs. (diff b/w defconfig and .config attached). Bootargs: console=ttyS0,115200n8 noinitrd ip=dhcp root=/dev/nfs rw nfsroot=:,nolock,wsize=1024,rsize=1024 mem=64M The error: insmod ./bridgedriver.ko phys_mempool_base=0x8700 phys_mempool_size=0x60 rmmod bridgedriver insmod ./bridgedriver.ko phys_mempool_base=0x8700 phys_mempool_size=0x60 rmmod bridgedriver insmod ./bridgedriver.ko phys_mempool_base=0x8700 phys_mempool_size=0x60 Unable to handle kernel paging request at virtual address 756e696c pgd = c3e0c000 *pgd=[756e696c] Internal error: Oops: 5 [#1] Modules linked in:Modules linked in: bridgedriver(+) bridgedriver(+) [last unloaded: bridgedriver] [last unloaded: bridgedriver] CPU: 0Not tainted (2.6.28-omap1-00211-gcb75442 #1) PC is at clk_notifier_register+0x68/0x108 LR is at kmem_cache_alloc+0x7c/0x84 pc : []lr : []psr: 0093 sp : c3e05da0 ip : c3e0b3e0 fp : c3e05dbc Backtrace: Backtrace: [] [] (clk_notifier_register+0x0/0x108) (clk_notifier_register+0x0/0x108) from [] from [] (bridge_init+0x394/0x3ec [bridgedriver]) (bridge_init+0x394/0x3ec [bridgedriver]) r7: r7: r6:bf08ab88 r6:bf08ab88 r5:1dcd6500 r5:1dcd6500 r4:0ee6b280 r4:0ee6b280 [] [] (bridge_init+0x0/0x3ec [bridgedriver]) (bridge_init+0x0/0x3ec [bridgedriver]) from [] from [] (do_one_initcall+0x64/0x198) (do_one_initcall+0x64/0x198) r8:c002df28 r8:c002df28 r7: r7: r6:4023a000 r6:4023a000 r5:bf08a520 r5:bf08a520 r4:c03aa340 r4:c03aa340 [] [] (do_one_initcall+0x0/0x198) (do_one_initcall+0x0/0x198) from [] from [] (sys_init_module+0x98/0x188) (sys_init_module+0x98/0x188) [] [] (sys_init_module+0x0/0x188) (sys_init_module+0x0/0x188) from [] from [] (ret_fast_syscall+0x0/0x2c) (ret_fast_syscall+0x0/0x2c) r7:0080 r7:0080 r6: r6: r5:000b r5:000b r4: r4: Code: Code: e5943000 e5943000 e1530006 e1530006 0a05 0a05 e2424008 e2424008 (e5942008) (e5942008) <4>---[ end trace c53b9e94a29571d4 ]--- ---[ end trace c53b9e94a29571d4 ]--- Segmentation fault Regards, Nishanth Menon sdp3430.defconfig.diff Description: sdp3430.defconfig.diff
RE: [PATCH 3/5] OV3640: Add driver
> -Original Message- > From: Tuukka.O Toivonen [mailto:tuukka.o.toivo...@nokia.com] > Sent: Tuesday, March 10, 2009 9:30 AM > To: Menon, Nishanth > Cc: Aguirre Rodriguez, Sergio Alberto; Alexey Klimov; linux- > me...@vger.kernel.org; linux-omap@vger.kernel.org; Sakari Ailus; Doyu > Hiroshi (Nokia-D/Helsinki); DongSoo(Nathaniel) Kim; MiaoStanley; Nagalla, > Hari; Hiremath, Vaibhav; Lakhani, Amish > Subject: Re: [PATCH 3/5] OV3640: Add driver > > On Monday 09 March 2009 23:29:27 ext Menon, Nishanth wrote: > > Further, we have multiple sensors following CCI[1] - why not have a > driver > > for the same, it will simplify the entire process - ov3640, mt9p012 both > > follow the spec at least.. dependency would be sensor -> cci dev->i2c > > framework. > > Sakari has written smiaregs.c pretty much exactly for this > purpose. You should check it out. Yes, smiaregs probably has a few more functionality than pure reg access APIs. Comparing CCI as defined in CCP2 spec and CSI2 spec, CCP2 spec says - register addressing could be 8 or 16, but the data size is 8 bit. In the case of CSI2, the data size could be 8, 16, 32 or 64 bytes.. we could say that CSI2's CCI is kind of a superset of CCI as defined by CCP2 spec. Might be a good idea to split the cci access out of smia_regs.c and make it a little more generic so that devices not caring for smia register set organization but using MIPI type access could also use it. Regards, Nishanth Menon Ref: [1] MIPI CSI2 revision 1.0 [2] SMIA CCP2 spec rev 1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] OV3640: Add driver
> -Original Message- > From: Tuukka.O Toivonen [mailto:tuukka.o.toivo...@nokia.com] > Sent: Tuesday, March 10, 2009 9:30 AM > To: Menon, Nishanth > Cc: Aguirre Rodriguez, Sergio Alberto; Alexey Klimov; linux- > me...@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus; Doyu > Hiroshi (Nokia-D/Helsinki); DongSoo(Nathaniel) Kim; MiaoStanley; Nagalla, > Hari; Hiremath, Vaibhav; Lakhani, Amish > Subject: Re: [PATCH 3/5] OV3640: Add driver > > On Monday 09 March 2009 23:29:27 ext Menon, Nishanth wrote: > > Further, we have multiple sensors following CCI[1] - why not have a > driver > > for the same, it will simplify the entire process - ov3640, mt9p012 both > > follow the spec at least.. dependency would be sensor -> cci dev->i2c > > framework. > > Sakari has written smiaregs.c pretty much exactly for this > purpose. You should check it out. Yes, smiaregs probably has a few more functionality than pure reg access APIs. Comparing CCI as defined in CCP2 spec and CSI2 spec, CCP2 spec says - register addressing could be 8 or 16, but the data size is 8 bit. In the case of CSI2, the data size could be 8, 16, 32 or 64 bytes.. we could say that CSI2's CCI is kind of a superset of CCI as defined by CCP2 spec. Might be a good idea to split the cci access out of smia_regs.c and make it a little more generic so that devices not caring for smia register set organization but using MIPI type access could also use it. Regards, Nishanth Menon Ref: [1] MIPI CSI2 revision 1.0 [2] SMIA CCP2 spec rev 1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] OV3640: Add driver
> -Original Message-
> From: Aguirre Rodriguez, Sergio Alberto
> Sent: Monday, March 09, 2009 10:58 PM
> To: Alexey Klimov
> Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus;
> Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel) Kim; MiaoStanley;
> Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth
> Subject: RE: [PATCH 3/5] OV3640: Add driver
>
>
> > > + /* FIXME: QXGA framerate setting forced to 15 FPS */
> > > + if (isize == QXGA) {
> > 4));
> > > + err = ov3640_write_reg(client, OV3640_ISP_YOUT_L,
> > > + (height_l -
> > 0x04));
> >
> > The same thing here.
>
> Agree, will fix..
I wonder if we cannot use an array and fill it up before pumping it out through
i2c. something like:
struct configure_array{
u16 reg;
u16 val;
}
struct configure_array reg_config[]={
{OV3640_ISP_YOUT_H, 0x0},
...
};
Then
for (i=0;i< sizeof(reg_config)/sizeof(configure_array);i++) {
err = reg_write(reg_config[i].reg, reg_config[i].val);
if (err) {
/* do something */
}
}
Further, we have multiple sensors following CCI[1] - why not have a driver for
the same, it will simplify the entire process - ov3640, mt9p012 both follow the
spec at least.. dependency would be sensor -> cci dev->i2c framework.
Regards,
Nishanth Menon
Ref:
[1] MIPI CSI2 spec rev 1.0.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] OV3640: Add driver
> -Original Message-
> From: Aguirre Rodriguez, Sergio Alberto
> Sent: Monday, March 09, 2009 10:58 PM
> To: Alexey Klimov
> Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Sakari Ailus;
> Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel) Kim; MiaoStanley;
> Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth
> Subject: RE: [PATCH 3/5] OV3640: Add driver
>
>
> > > + /* FIXME: QXGA framerate setting forced to 15 FPS */
> > > + if (isize == QXGA) {
> > 4));
> > > + err = ov3640_write_reg(client, OV3640_ISP_YOUT_L,
> > > + (height_l -
> > 0x04));
> >
> > The same thing here.
>
> Agree, will fix..
I wonder if we cannot use an array and fill it up before pumping it out through
i2c. something like:
struct configure_array{
u16 reg;
u16 val;
}
struct configure_array reg_config[]={
{OV3640_ISP_YOUT_H, 0x0},
...
};
Then
for (i=0;i< sizeof(reg_config)/sizeof(configure_array);i++) {
err = reg_write(reg_config[i].reg, reg_config[i].val);
if (err) {
/* do something */
}
}
Further, we have multiple sensors following CCI[1] - why not have a driver for
the same, it will simplify the entire process - ov3640, mt9p012 both follow the
spec at least.. dependency would be sensor -> cci dev->i2c framework.
Regards,
Nishanth Menon
Ref:
[1] MIPI CSI2 spec rev 1.0.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] DSPBRIDGE: patches.
Hi Hari, > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Kanigeri, Hari > Sent: Thursday, March 05, 2009 3:52 PM > To: Felipe Contreras > Cc: Ameya Palande; Guzman Lugo, Fernando; Hiroshi DOYU; linux- > o...@vger.kernel.org > Subject: RE: [PATCH 0/5] DSPBRIDGE: patches. > > We are in linux-omap, not omapzoom, and this is the > > tidspbridge branch in linux-omap: > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2. > 6.git;a=shortlog;h=tidspbridge > > > > I'm sure you don't want to increase the discrepancy between > > linux-omap and omapzoom, so the patches sent to l-o should > > apply on top of the l-o tidspbridge in order to be merged. > > -- I am sorry, as of now the Bridge patches will be based only on omapzoom > tree. Ok, so we have: a) omapzoom bridge b) linux omap bridge Impertinent question: what are our plans b/w these two? 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: [PATCH 0/5] DSPBRIDGE: patches.
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Felipe Contreras
> Sent: Thursday, March 05, 2009 3:42 PM
> To: Kanigeri, Hari
> Cc: Ameya Palande; Guzman Lugo, Fernando; Hiroshi DOYU; linux-
> o...@vger.kernel.org
> Subject: Re: [PATCH 0/5] DSPBRIDGE: patches.
>
> On Thu, Mar 5, 2009 at 3:18 PM, Kanigeri, Hari wrote:
> > Hi Ameya,
> >
> >> Hi Fernando,
> >>
> >> Are you using tidspbridge-pm branch from
> >> http://gitorious.org/projects/lk/repos/mainline ?
> >>
> >> Cheers,
> >> Ameya.
> >
> > -- The Bridge patches will be based on omapzoom tree.
>
> We are in linux-omap, not omapzoom, and this is the tidspbridge branch
> in linux-omap:
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-
> 2.6.git;a=shortlog;h=tidspbridge
>
> I'm sure you don't want to increase the discrepancy between linux-omap
> and omapzoom, so the patches sent to l-o should apply on top of the
> l-o tidspbridge in order to be merged.
Yeah it gets real confusing. How about following the same rules for the
OMAPZOOM kernel here too: any patch w.r.t OMAPZOOM comes:
Subj: RE: [OMAPZOOM PATCH 0/5] DSPBRIDGE: blah blah blah.
Helps to keep things in perspective..
Regards,
Nishanth Menon
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
RE: [RFC] OMAP: I2C: Use correct bit for CLOCKACTIVITY
> -Original Message- > From: Eero Nurkkala [mailto:ext-eero.nurkk...@nokia.com] > Sent: Thursday, March 05, 2009 2:33 PM > To: Menon, Nishanth > Cc: ext Paul Walmsley; linux-omap@vger.kernel.org; Woodruff, Richard > Subject: RE: [RFC] OMAP: I2C: Use correct bit for CLOCKACTIVITY > > Thank you! > > Could you please consider taking a loot at every single block > (SPI, I2C, DMA... etc). > > If I were you, I'd copy-paste the CLOCKACTIVITY features as > is it to every single HW block. So it'd be coherent. I have a > distant feeling that's what you've done, but TRM says something > else.. me? I am just a code junkie ;).. "They" wont let me write the TRM :(.. :D... Anyways, I am told internally that the right setting is the one given in table 18-44, i.e.: 9:8 CLOCKACTIVITY Clock Activity selection bits RW 0x0 0x0: Both clocks can be cut off 0x1: Only interface clock must be kept active; functional clock can be cut off 0x2: Only functional clock must be kept active; interface clock can be cut off 0x3: Both clocks must be kept active Have asked for the rest too.. But I am told that in case of these kind of issues, we should refer to the one in the register settings. 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: [RFC] OMAP: I2C: Use correct bit for CLOCKACTIVITY
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Eero Nurkkala > Sent: Thursday, March 05, 2009 10:46 AM > To: ext Paul Walmsley > Cc: linux-omap@vger.kernel.org; Woodruff, Richard > Subject: Re: [RFC] OMAP: I2C: Use correct bit for CLOCKACTIVITY > > On Thu, 2009-03-05 at 09:42 +0100, ext Paul Walmsley wrote: > > Hello Eero, > > Hmm. Looking at the 34xx Rev O TRM register tables, it looks like most > > modules use bit 9 to indicate that FCLK should be kept on and bit 8 to > > indicate that the ICLK should be kept on? DSI, DISPC, SR, DMA4 are some > > examples. > > How about McBSP? Same TRM.. I2C, Table 18-5 tells exactly the opposite > for I2C than what's said in Table 18-44: I2C_SYSC!! > Yep, that does look nuts :(.. Have pinged internally.. 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: [U-Boot] [PATCH 07/12 v2] ARM: OMAP3: Add memory and syslib common files, add NAND support
> -Original Message-
> From: Scott Wood [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 07, 2008 12:30 PM
> To: Nishanth Menon
> Cc: Dirk Behme; u-boot@lists.denx.de; Kamat, Nishant; Menon, Nishanth
> Subject: Re: [U-Boot] [PATCH 07/12 v2] ARM: OMAP3: Add memory and syslib
> common files, add NAND support
> > >>> +.eccbytes = 12,
> > >>> +.eccpos = {
> > >>> + 2, 3, 4, 5,
> > >>> + 6, 7, 8, 9,
> > >>> + 10, 11, 12, 13},
> > >>> +.oobfree = { {20, 50} }/* don't care */
> > >>
> > >>
> > >> Bytes 64-69 of a 64-byte OOB are free?
> > >> What don't we care about?
> > > +static struct nand_ecclayout hw_nand_oob_64 = {
> > >
> > > Don't know (or understand?).
> > >
> > > All: Any help?
> > I do not get it either.. ECCPOS is in offset bytes, and oobfree should
> > be {.offset=20,.length=44} /*I always hated struct initialization done
> > as above..*/, but then,
>
> Why not offset 14, length 50?
How about this part being used by ubi/jffs2 or some fs.. I cant think off-hand
if there an implication, but yep, I suspect there is no reason why not..
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc44x: RFC: Unification of virtex5 pp440 boards
Ricardo,
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ricardo Ribalda
> Delgado
> Sent: Tuesday, August 26, 2008 7:52 AM
> To: [EMAIL PROTECTED]
> Cc: u-boot@lists.denx.de; Stefan Roese; [EMAIL PROTECTED]
> Subject: Re: [U-Boot] [PATCH] ppc44x: RFC: Unification of virtex5 pp440 boards
>
> Hi Stefan
>
> First of all: Thanks for taking some time in reading the patch
>
>
> > I looked at your patch.
> > your xparameters contain space before tab
>
> Sorry :), BTW: do you know how to highlight this in vim?
Here is the vimrc I use:
set ts=8
if !exists("autocommands_loaded")
let autocommands_loaded = 1
augroup C
autocmd BufRead *.c set cindent
augroup END
endif
" Kernel janitor
let c_space_errors=1
highlight WhitespaceEOL ctermbg=red guibg=red
match WhitespaceEOL /\s\+$/
highlight Over80Col ctermbg=green guibg=blue
match Over80Col /\%>81v/
set backupcopy=auto,breakhardlink
also see if you can run checkpatch.pl script from linux kernel.. it usually
catches most of the formatting errors..
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: U-boot for Arm cortexA8
Hi Jean, > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Christophe > PLAGNIOL-VILLARD > Sent: Friday, August 22, 2008 7:42 AM > To: Robert Schwebel > Cc: U-Boot user list; Peter Pearse > Subject: Re: [U-Boot] FW: U-boot for Arm cortexA8 > > On 13:52 Fri 22 Aug , Robert Schwebel wrote: > > On Fri, Aug 22, 2008 at 09:32:52AM +0100, Peter Pearse wrote: > > > > AFAIK no code specifically for Cortex A8 has yet been posted > > > > for U-Boot. > > > > > > > > However such code is not essential to use U-Boot on a Cortex > > > > A8 based platform. > > > > > > > > Here at ARM we are successfully using the current U-Boot > > > > head, patched for our development boards, but with no Cortex > > > > A8 specific amendments to boot linux images. > > > > > > > > Other U-Boot functionality might be improved by specific > > > > porting to Cortex A8, I would be interested to see examples, > > > > Note that U-Boot-v2 has also support for the beagle board which is > > Cortex A8 as well. > And the beagle Maintainer prepare U-Boot support > If we are speaking of u-boot v2 support, there are tons of opportunities: a) Coherent ARM architecture which can scale across to all modes.. The tiny patch I had done merely handled one part of the problem - of caches.. There are possibly more opportunities such as: i) Organization of ARM code to make it cleanly pluggable and add further features. ii) Optimizations where possible -> bitops etc.. iii) Compiler optimizations and improvements of Makefile b) Beagle is not the only OMAP3 board around.. There is Zoom MDK, SDP3430, Pandora and many more -> A8 support is just the tip of the iceberg in terms of opportunities. By the way, U-boot v2 has two platforms with OMAP3 -> SDP3430 and beagle - both have A8 on them. Speaking specifically about OMAP3 with A8 and beagle support for u-boot v1, Sakoman, Dirk among others have been working on a git branch[1] which could finally move in to mainline tree in the future.. If you are specifically interested in playing/developing with beagle with CortexA8 on a OMAP3530, - just checkout beagleboard.org - if nothing, just the cost might surprise you. Regards, Nishanth Menon [1] http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=shortlog;h=refs/heads/common ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
