[patch 2.6.26-omap-git] beagle LED fixes
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Update and fix Beagle LED declarations: gpios for USR0 and USR1
were swapped, and their names don't match docs or silksreen.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-omap3beagle.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/arch/arm/mach-omap2/board-omap3beagle.c 2008-08-04 22:08:16.0
-0700
+++ b/arch/arm/mach-omap2/board-omap3beagle.c 2008-08-04 22:08:36.0
-0700
@@ -75,14 +76,14 @@ static struct omap_lcd_config omap3_beag
struct gpio_led gpio_leds[] = {
{
- .name = "beagleboard::led0",
+ .name = "beagleboard::usr0",
.default_trigger= "none",
- .gpio = 149,
+ .gpio = 150,
},
{
- .name = "beagleboard::led1",
+ .name = "beagleboard::usr1",
.default_trigger= "none",
- .gpio = 150,
+ .gpio = 149,
},
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3 CPUidle patches - fixes
> -Original Message-
> From: Tony Lindgren [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 04, 2008 8:03 PM
> To: Rajendra Nayak
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH] OMAP3 CPUidle patches - fixes
>
> * Rajendra Nayak <[EMAIL PROTECTED]> [080703 14:55]:
> > This patch fixes few of the comments posted on the patch
> set till now.
> >
> > One major fix is the moving of uart clock enable/disable
> out of the context save path as pointed out by Jouni.
> > This would leave the UART clcoks disabled in case a CORE
> OFF was attempted and not achieved.
>
> What kernel or patch series this is against? If it's for some
> patch series that's not applied yet to linux-omap tree, let's
> merge the fix to the original patch.
I sent another patch set later to the list (dated 18/07/2008)
"[PATCH 00/11] OMAP3 CPUidle patches - ver 2"
which is the final patch set for CPUidle which can be merged.
This patch and all the previous patches on CPUidle can be ignored.
>
> Tony
>
> > Signed-off-by: Rajendra Nayak <[EMAIL PROTECTED]>
> > ---
> > arch/arm/mach-omap2/cpuidle34xx.c | 56
> ++
> > 1 files changed, 22 insertions(+), 34 deletions(-)
> >
> > Index: linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c
> > ===
> > --- linux-omap-2.6.orig/arch/arm/mach-omap2/cpuidle34xx.c
> 2008-07-03 10:50:04.0 +0530
> > +++ linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c
> 2008-07-03 13:11:13.435048828 +0530
> > @@ -405,9 +405,7 @@ void omap3_save_core_ctx(void)
> > /* Save the system control module context, padconf
> already save above*/
> > omap_save_control_ctx();
> > omap_save_uart_ctx(0);
> > - omap_serial_enable_clocks(0, 0);
> > omap_save_uart_ctx(1);
> > - omap_serial_enable_clocks(0, 1);
> > }
> >
> > void omap3_restore_core_ctx(void)
> > @@ -418,9 +416,7 @@ void omap3_restore_core_ctx(void)
> > omap_restore_gpmc_ctx();
> > /* Restore the interrupt controller context */
> > omap_restore_intc_ctx();
> > - omap_serial_enable_clocks(1, 0);
> > omap_restore_uart_ctx(0);
> > - omap_serial_enable_clocks(1, 1);
> > omap_restore_uart_ctx(1);
> > padconf_saved = 0;
> > }
> > @@ -472,28 +468,27 @@ static int omap3_enter_idle(struct cpuid
> >
> > /* Program MPU to target state */
> > if (cx->mpu_state < PWRDM_POWER_ON) {
> > - if (neon_pwrst == PWRDM_POWER_ON) {
> > - if (cx->mpu_state == PWRDM_POWER_RET)
> > - pwrdm_set_next_pwrst(neon_pd,
> PWRDM_POWER_RET);
> > - else if (cx->mpu_state == PWRDM_POWER_OFF)
> > - pwrdm_set_next_pwrst(neon_pd,
> PWRDM_POWER_OFF);
> > - }
> > + pwrdm_set_next_pwrst(neon_pd, cx->mpu_state);
> > pwrdm_set_next_pwrst(mpu_pd, cx->mpu_state);
> > }
> >
> > /* Program CORE and PER to target state */
> > if (cx->core_state < PWRDM_POWER_ON) {
> > - if (per_pwrst == PWRDM_POWER_ON) {
> > - omap2_gpio_prepare_for_retention();
> > - if (clocks_off_while_idle) {
> > - omap3_save_per_ctx();
> > - per_gpio_clk_disable();
> > - omap_save_uart_ctx(2);
> > - omap_serial_enable_clocks(0, 2);
> > - }
> > + omap2_gpio_prepare_for_retention();
> > + if (clocks_off_while_idle) {
> > + omap3_save_per_ctx();
> > + per_gpio_clk_disable();
> > + omap_save_uart_ctx(2);
> > + omap_serial_enable_clocks(0, 2);
> > }
> > if (cx->core_state == PWRDM_POWER_OFF)
> > omap3_save_core_ctx();
> > + /* Disable UART1/UART2 clocks here. Done using
> direct register
> > + * writes as using clock f/w calls results in a
> hang in prcm_
> > + * interrupt_handler trying to clear WKST for CORE
> > + */
> > + cm_clear_mod_reg_bits(0x6000, CORE_MOD, CM_ICLKEN1);
> > + cm_clear_mod_reg_bits(0x6000, CORE_MOD, CM_FCLKEN1);
> > pwrdm_set_next_pwrst(core_pd, cx->core_state);
> > }
> >
> > @@ -507,14 +502,9 @@ static int omap3_enter_idle(struct cpuid
> >
> > *(scratchpad_restore_addr) = 0x0;
> >
> > - /* Program MPU/NEON to ON */
> > - if (cx->mpu_state < PWRDM_POWER_ON) {
> > - if (neon_pwrst == PWRDM_POWER_ON)
> > - pwrdm_set_next_pwrst(neon_pd, PWRDM_POWER_ON);
> > - pwrdm_set_next_pwrst(mpu_pd, PWRDM_POWER_ON);
> > - }
> > -
> > if (cx->core_state < PWRDM_POWER_ON) {
> > + cm_set_mod_reg_bits(0x6000, CORE_MOD, CM_ICLKEN1);
> > + cm_set_mod_reg_bits(0x6000, CORE_MOD, CM_FCLKEN1);
> > if ((cx->core_state == PWRDM_POWER_OFF)
> >
[PATCH] MUSB: Fix bug - don't mess up count number and CSR0 register value
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/usb/musb/musb_gadget_ep0.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget_ep0.c
b/drivers/usb/musb/musb_gadget_ep0.c
index 2d2574c..e7b56df 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
+++ b/drivers/usb/musb/musb_gadget_ep0.c
@@ -452,7 +452,7 @@ static void ep0_rxstate(struct musb *musb)
{
void __iomem*regs = musb->control_ep->regs;
struct usb_request *req;
- u16 tmp;
+ u16 count, csr;
req = next_ep0_request(musb);
@@ -464,34 +464,34 @@ static void ep0_rxstate(struct musb *musb)
unsignedlen = req->length - req->actual;
/* read the buffer */
- tmp = musb_readb(regs, MUSB_COUNT0);
- if (tmp > len) {
+ count = musb_readb(regs, MUSB_COUNT0);
+ if (count > len) {
req->status = -EOVERFLOW;
- tmp = len;
+ count = len;
}
- musb_read_fifo(&musb->endpoints[0], tmp, buf);
- req->actual += tmp;
- tmp = MUSB_CSR0_P_SVDRXPKTRDY;
- if (tmp < 64 || req->actual == req->length) {
+ musb_read_fifo(&musb->endpoints[0], count, buf);
+ req->actual += count;
+ csr = MUSB_CSR0_P_SVDRXPKTRDY;
+ if (count < 64 || req->actual == req->length) {
musb->ep0_state = MUSB_EP0_STAGE_STATUSIN;
- tmp |= MUSB_CSR0_P_DATAEND;
+ csr |= MUSB_CSR0_P_DATAEND;
} else
req = NULL;
} else
- tmp = MUSB_CSR0_P_SVDRXPKTRDY | MUSB_CSR0_P_SENDSTALL;
+ csr = MUSB_CSR0_P_SVDRXPKTRDY | MUSB_CSR0_P_SENDSTALL;
/* Completion handler may choose to stall, e.g. because the
* message just received holds invalid data.
*/
if (req) {
- musb->ackpend = tmp;
+ musb->ackpend = csr;
musb_g_ep0_giveback(musb, req);
if (!musb->ackpend)
return;
musb->ackpend = 0;
}
- musb_writew(regs, MUSB_CSR0, tmp);
+ musb_writew(regs, MUSB_CSR0, csr);
}
/*
--
1.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MUSB: Workaround for simultaneous TX and RX usage
On Mon, Aug 4, 2008 at 9:18 PM, Gadiyar, Anand <[EMAIL PROTECTED]> wrote:
> MUSB RTL v1.4 has a hardware issue which results in a DMA controller
> hang when TX and RX DMA channels are simultaneously enabled. This
> affects at least OMAP2430 and OMAP34XX.
>
> Since RX transfers are in Mode 0 and anyway result in one DMA interrupt
> per packet, we can use System DMA to unload the RX fifos. MUSB DMA can
> be used for all TX channels as before.
>
Hi Gadiyar,
We also found some similar issue on Blackfin with the MUSB+musbhsdma.
Some time DMA mode 1 interrupt lost and system hang.
But if we use the PIO mode and rewrite the
musb_read_fifo/musb_write_fifo to use DMA polling method,
the issue is gone.
Any idea about this?
-Bryan
> Tested with full-duplex TX and RX transfers using g_ether. Runs for 24
> hours without a hang. Without this patch, the hang occurs within minutes.
>
> Signed-off-by: Anand Gadiyar <[EMAIL PROTECTED]>
> ---
> This issue was first reported by Jon Hunter on [1]
>
> [1] http://marc.info/?l=linux-omap&m=119634480534453&w=2
>
> drivers/usb/musb/Kconfig |8 +
> drivers/usb/musb/musbhsdma.c | 174
> +++
> 2 files changed, 153 insertions(+), 29 deletions(-)
>
> Index: testing/drivers/usb/musb/musbhsdma.c
> ===
> --- testing.orig/drivers/usb/musb/musbhsdma.c
> +++ testing/drivers/usb/musb/musbhsdma.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include "musb_core.h"
> +#include
>
> #if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3430)
> #include "omap2430.h"
> @@ -64,6 +65,9 @@
>
> #define MUSB_HSDMA_CHANNELS8
>
> +#define MUSB_FIFO_ADDRESS(epnum) \
> + ((unsigned long) (OMAP_HSOTG_BASE + MUSB_FIFO_OFFSET(epnum)))
> +
> struct musb_dma_controller;
>
> struct musb_dma_channel {
> @@ -75,6 +79,10 @@ struct musb_dma_channel {
>u8 bIndex;
>u8 epnum;
>u8 transmit;
> +
> +#ifdef CONFIG_MUSB_USE_SYSTEM_DMA_RX
> + int sysdma_channel;
> +#endif
> };
>
> struct musb_dma_controller {
> @@ -93,6 +101,10 @@ static int dma_controller_start(struct d
>return 0;
> }
>
> +#ifdef CONFIG_MUSB_USE_SYSTEM_DMA_RX
> +static void musb_sysdma_completion(int lch, u16 ch_status, void *data);
> +#endif
> +
> static void dma_channel_release(struct dma_channel *pChannel);
>
> static int dma_controller_stop(struct dma_controller *c)
> @@ -144,6 +156,30 @@ static struct dma_channel *dma_channel_a
>/* Tx => mode 1; Rx => mode 0 */
>pChannel->desired_mode = transmit;
>pChannel->actual_len = 0;
> + pImplChannel->sysdma_channel = -1;
> +
> +#ifdef CONFIG_MUSB_USE_SYSTEM_DMA_RX
> + if (!transmit) {
> + int ret;
> + ret = omap_request_dma(OMAP24XX_DMA_NO_DEVICE,
> + "MUSB SysDMA", musb_sysdma_completion,
> + (void *) pImplChannel,
> + &(pImplChannel->sysdma_channel));
> +/* FIXME: Decide on the correct private data to use */
> +
> + if (ret) {
> + printk(KERN_ERR "request_dma failed:"
> + " %d\n", ret);
> + controller->bmUsedChannels &=
> + ~(1 << bBit);
> + pChannel->status =
> +
> MUSB_DMA_STATUS_UNKNOWN;
> + pImplChannel->sysdma_channel = -1;
> + pChannel = NULL;
> + }
> + }
> +#endif
> +
>break;
>}
>}
> @@ -163,6 +199,14 @@ static void dma_channel_release(struct d
>~(1 << pImplChannel->bIndex);
>
>pChannel->status = MUSB_DMA_STATUS_UNKNOWN;
> +
> +#ifdef CONFIG_MUSB_USE_SYSTEM_DMA_RX
> + if (pImplChannel->sysdma_channel != -1) {
> + omap_stop_dma(pImplChannel->sysdma_channel);
> + omap_free_dma(pImplChannel->sysdma_channel);
> + pImplChannel->sysdma_channel = -1;
> + }
> +#endif
> }
>
> static void configure_channel(struct dma_channel *pChannel,
> @@ -179,43 +223,108 @@ static void configure_channel(struct dma
>DBG(4, "%p, pkt_sz %d, addr 0x%x, len %d, mode %d\n",
>pChannel, packet_sz, dma_addr, len, mode);
>
> - if (mode) {
> - csr |= 1 << MUSB_HSDMA_MODE1_SHIFT;
> - BUG_ON(len < packet_sz);
> +#ifdef
RE: [PATCH] Add option for DSP bridge debugging.
Hi Felipe, The bridge debug option looks good. Thank you, Best regards, Hari > -Original Message- > From: [EMAIL PROTECTED] [mailto:linux-omap- > [EMAIL PROTECTED] On Behalf Of Felipe Contreras > Sent: Monday, August 04, 2008 8:48 AM > To: linux-omap@vger.kernel.org > Cc: Felipe Contreras > Subject: [PATCH] Add option for DSP bridge debugging. > > --- > drivers/dsp/dspbridge/Kconfig |3 +++ > drivers/dsp/dspbridge/mpu_driver/src/Kbuild |2 +- > 2 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/drivers/dsp/dspbridge/Kconfig b/drivers/dsp/dspbridge/Kconfig > index 5d5622d..580c148 100644 > --- a/drivers/dsp/dspbridge/Kconfig > +++ b/drivers/dsp/dspbridge/Kconfig > @@ -29,4 +29,7 @@ config BRIDGE_PM > DSP Bridge employs power management techniques to save dynamic and > static power consumption of the IVA sub system. > > +config BRIDGE_DEBUG > + bool "DSP Bridge Debug Support" > + > endif > diff --git a/drivers/dsp/dspbridge/mpu_driver/src/Kbuild > b/drivers/dsp/dspbridge/mpu_driver/src/Kbuild > index b6ad62a..62ca643 100644 > --- a/drivers/dsp/dspbridge/mpu_driver/src/Kbuild > +++ b/drivers/dsp/dspbridge/mpu_driver/src/Kbuild > @@ -33,7 +33,7 @@ ccflags-y = -DDISABLE_BRIDGE_PM > endif > > # Debug > -ifeq ($(CONFIG_DEBUG_KERNEL),y) > +ifeq ($(CONFIG_BRIDGE_DEBUG),y) > ccflags-y += -DGT_TRACE -DDEBUG > endif > > -- > 1.5.6.2.1.g1a51b > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM MMU: add strongly-ordered memory type
Add the MT_MEMORY_STRONGLY_ORDERED memory type for ARM strongly ordered
memory.
This is used on OMAP3 for on-board SRAM. On OMAP, SRAM is used for code
that changes the SDRAM controller's clock, temporarily blocking access to
SDRAM. During this period, as code executes from SRAM, the ARM cache
controller can attempt to write dirty cache lines back to SDRAM to make
room for SRAM cache lines, causing the MPU subsystem to hang. To avoid
this, we mark SRAM as strongly- ordered memory.
Problem noted by Richard Woodruff <[EMAIL PROTECTED]>. Fix derived
from the TI CDP codebase.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mm/mmu.c |5 +
include/asm-arm/mach/map.h | 13 +++--
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 2d6d682..5b56539 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -239,6 +239,11 @@ static struct mem_type mem_types[] = {
.prot_sect = PMD_TYPE_SECT,
.domain= DOMAIN_KERNEL,
},
+ [MT_MEMORY_STRONGLY_ORDERED] = {
+ .prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE |
+ PMD_SECT_UNCACHED,
+ .domain= DOMAIN_KERNEL,
+ },
};
const struct mem_type *get_mem_type(unsigned int type)
diff --git a/include/asm-arm/mach/map.h b/include/asm-arm/mach/map.h
index 7ef3c83..8cb46b7 100644
--- a/include/asm-arm/mach/map.h
+++ b/include/asm-arm/mach/map.h
@@ -19,12 +19,13 @@ struct map_desc {
};
/* types 0-3 are defined in asm/io.h */
-#define MT_CACHECLEAN 4
-#define MT_MINICLEAN 5
-#define MT_LOW_VECTORS 6
-#define MT_HIGH_VECTORS7
-#define MT_MEMORY 8
-#define MT_ROM 9
+#define MT_CACHECLEAN 4
+#define MT_MINICLEAN 5
+#define MT_LOW_VECTORS 6
+#define MT_HIGH_VECTORS7
+#define MT_MEMORY 8
+#define MT_ROM 9
+#define MT_MEMORY_STRONGLY_ORDERED 10
#define MT_NONSHARED_DEVICEMT_DEVICE_NONSHARED
#define MT_IXP2000_DEVICE MT_DEVICE_IXP2000
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
> Hmmm. So bit [7] of the system control register is ignored entirely, > and if you write a 1 to it, nothing at all happens and the system > boots as usual? (To test, add a line "OBJS += big-endian.o" to the > top of arch/arm/boot/compressed/Makefile.) > > Does it also mean that the ARMv6 based OMAPs have the SETEND > instruction behave as NOPs? Last time I explicitly tried was back on OMAP1. I then dug into doc's it was said that the bit was hardwired at the integration point. I don't recall signal name. Now, Peeking into OMAP2 (armv6) MPU integration docs I see that BIGENDINIT is pulled low. This forces the behavior as I indicated. OMAP3 (armv7) does something similar at cpu-to-bus bridge. Doing a quick desktop search in documents I see the armv6 behavior is defined as part of BIGENDINIT in ARM TRMs. I'll guess SETEND instruction follows what ever that dictates. I don't know as I've never tried. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Mon, Aug 04, 2008 at 04:45:19PM -0500, Woodruff, Richard wrote: > > > The most visible BE-ARM seems to be Intel's IXP network processors. > > > > The IXPs are one of the few cases where the vendors _ships an all-BE > > software development environment by default_ -- but that doesn't mean > > that BE doesn't work on ARM CPUs where the vendor ships a LE software > > development environment by default (BE has certainly worked on all > > ARM CPUs I've ever tried it on). > > I wonder how many shipping systems use LE. A grep of current ARM Linux > Kconfig's only shows 3 IXP systems setting CONFIG_CPU_BIG_ENDIAN. Perhaps you > are correct about ability but few seem to use it. Seems like a trivia > question for ARM Ltd. > > At any rate all OMAPs have been hardwired. Hmmm. So bit [7] of the system control register is ignored entirely, and if you write a 1 to it, nothing at all happens and the system boots as usual? (To test, add a line "OBJS += big-endian.o" to the top of arch/arm/boot/compressed/Makefile.) Does it also mean that the ARMv6 based OMAPs have the SETEND instruction behave as NOPs? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
> > The most visible BE-ARM seems to be Intel's IXP network processors. > > The IXPs are one of the few cases where the vendors _ships an all-BE > software development environment by default_ -- but that doesn't mean > that BE doesn't work on ARM CPUs where the vendor ships a LE software > development environment by default (BE has certainly worked on all > ARM CPUs I've ever tried it on). I wonder how many shipping systems use LE. A grep of current ARM Linux Kconfig's only shows 3 IXP systems setting CONFIG_CPU_BIG_ENDIAN. Perhaps you are correct about ability but few seem to use it. Seems like a trivia question for ARM Ltd. At any rate all OMAPs have been hardwired. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Mon, Aug 04, 2008 at 02:37:34PM -0700, David Brownell wrote: > > I've never seen CPU endianity being hardwired in any ARM system ever > > -- but maybe OMAP is different. > > I'll let TI answer that one, since I'm not going to look at docs for > all the ARM's I've ever used. > > My observation stands *REGARDLESS* of whether endianness was fixed in > hardware, bootloader, or kernel ... and in any case, with very few > exceptions (not including OMAP), Linux uses ARMs in LE mode: > > ~/kernel/linux-2.6/arch/arm/configs$ grep ENDIAN * | egrep -v '#' |egrep -v > OHCI > ixp2000_defconfig:CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y > ixp2000_defconfig:CONFIG_CPU_BIG_ENDIAN=y > ixp23xx_defconfig:CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y > ixp23xx_defconfig:CONFIG_CPU_BIG_ENDIAN=y > ixp4xx_defconfig:CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y > ixp4xx_defconfig:CONFIG_CPU_BIG_ENDIAN=y > ~/kernel/linux-2.6/arch/arm/configs$ ls | wc -l > 105 > ~/kernel/linux-2.6/arch/arm/configs$ That's just because not many people ask for BE or use BE -- not because the LE'ness would be hardwired in hardware as you asserted earlier. > To repeat: there's no point in having the words byteswapped when > writing, then again when reading, like this driver does. All that > does is ensure slow I/O paths. Were you disagreeing with that main > point? Or just quibbling about where any unusual big-endianness > might come from? I was responding to your statement that ARM CPU endianity is hardwired when ARM cores are turned into silicon. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Mon, Aug 04, 2008 at 04:23:35PM -0500, Woodruff, Richard wrote: > The most visible BE-ARM seems to be Intel's IXP network processors. The IXPs are one of the few cases where the vendors _ships an all-BE software development environment by default_ -- but that doesn't mean that BE doesn't work on ARM CPUs where the vendor ships a LE software development environment by default (BE has certainly worked on all ARM CPUs I've ever tried it on). -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Monday 04 August 2008, Lennert Buytenhek wrote: > > I've never seen CPU endianity being hardwired in any ARM system ever > -- but maybe OMAP is different. I'll let TI answer that one, since I'm not going to look at docs for all the ARM's I've ever used. My observation stands *REGARDLESS* of whether endianness was fixed in hardware, bootloader, or kernel ... and in any case, with very few exceptions (not including OMAP), Linux uses ARMs in LE mode: ~/kernel/linux-2.6/arch/arm/configs$ grep ENDIAN * | egrep -v '#' |egrep -v OHCI ixp2000_defconfig:CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y ixp2000_defconfig:CONFIG_CPU_BIG_ENDIAN=y ixp23xx_defconfig:CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y ixp23xx_defconfig:CONFIG_CPU_BIG_ENDIAN=y ixp4xx_defconfig:CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y ixp4xx_defconfig:CONFIG_CPU_BIG_ENDIAN=y ~/kernel/linux-2.6/arch/arm/configs$ ls | wc -l 105 ~/kernel/linux-2.6/arch/arm/configs$ To repeat: there's no point in having the words byteswapped when writing, then again when reading, like this driver does. All that does is ensure slow I/O paths. Were you disagreeing with that main point? Or just quibbling about where any unusual big-endianness might come from? - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
> On Monday 04 August 2008, Lennert Buytenhek wrote: > > On Mon, Aug 04, 2008 at 01:02:46PM -0700, David Brownell wrote: > > > > > > Looks like this driver does not exist outside linux-omap tree, > > > > care to send the whole driver to MTD list? > > > > > > Unless someone created a big-endian OMAP, > > > > Don't they use standard ARM ARM cores, which can all be used in both > > LE and BE modes? > > And when those cores turn into silicon, the choice is usually > hard-wired. Regardless, all OMAP cores I've worked with are > set up for LE mode ... and then there's still the point that > byteswapping to/from the NAND chip seems to add no value. Yes all OMAP-ARM's have been LE. I've only used a couple ARMs in the past where it was run time configurable. Most hardware hard wire it as Dave asserts. As trivia you might find a BE-DSP in the OMAP1 SOC and LE-ARM. So, internal bridge chips usually allow hardware swapping. OMAP3-DSP is LE. The most visible BE-ARM seems to be Intel's IXP network processors. Matching network byte order apparently saves some cycles. Earlier BE ones I recall were trying to pick up Mot-68K-BE sockets which had BE friendly peripherals. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/2] TWL4030: convert old-style function documentation to current kerneldoc
Several functions use old-style function documentation; convert those to
use the current kerneldoc style.
Thanks to Felipe Balbi <[EMAIL PROTECTED]> for catching an error.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
drivers/i2c/chips/twl4030-core.c | 54 ++
1 files changed, 26 insertions(+), 28 deletions(-)
diff --git a/drivers/i2c/chips/twl4030-core.c b/drivers/i2c/chips/twl4030-core.c
index 54e392b..88447f1 100644
--- a/drivers/i2c/chips/twl4030-core.c
+++ b/drivers/i2c/chips/twl4030-core.c
@@ -389,17 +389,18 @@ static struct irq_chip twl4030_irq_chip = {
};
/* Global Functions */
-/*
- * @brief twl4030_i2c_write - Writes a n bit register in TWL4030
+
+/**
+ * twl4030_i2c_write - Writes a n bit register in TWL4030
+ * @mod_no: module number
+ * @value: an array of num_bytes+1 containing data to write
+ * @reg: register address (just offset will do)
+ * @num_bytes: number of bytes to transfer
*
- * @param mod_no - module number
- * @param *value - an array of num_bytes+1 containing data to write
- * IMPORTANT - Allocate value num_bytes+1 and valid data starts at
- * Offset 1.
- * @param reg - register address (just offset will do)
- * @param num_bytes - number of bytes to transfer
+ * IMPORTANT: for 'value' parameter: Allocate value num_bytes+1 and
+ * valid data starts at Offset 1.
*
- * @return result of operation - 0 is success
+ * Returns the result of operation - 0 is success
*/
int twl4030_i2c_write(u8 mod_no, u8 *value, u8 reg, u8 num_bytes)
{
@@ -443,14 +444,13 @@ int twl4030_i2c_write(u8 mod_no, u8 *value, u8 reg, u8
num_bytes)
EXPORT_SYMBOL(twl4030_i2c_write);
/**
- * @brief twl4030_i2c_read - Reads a n bit register in TWL4030
+ * twl4030_i2c_read - Reads a n bit register in TWL4030
+ * @mod_no: module number
+ * @value: an array of num_bytes containing data to be read
+ * @reg: register address (just offset will do)
+ * @num_bytes: number of bytes to transfer
*
- * @param mod_no - module number
- * @param *value - an array of num_bytes containing data to be read
- * @param reg - register address (just offset will do)
- * @param num_bytes - number of bytes to transfer
- *
- * @return result of operation - num_bytes is success else failure.
+ * Returns result of operation - num_bytes is success else failure.
*/
int twl4030_i2c_read(u8 mod_no, u8 *value, u8 reg, u8 num_bytes)
{
@@ -497,13 +497,12 @@ int twl4030_i2c_read(u8 mod_no, u8 *value, u8 reg, u8
num_bytes)
EXPORT_SYMBOL(twl4030_i2c_read);
/**
- * @brief twl4030_i2c_write_u8 - Writes a 8 bit register in TWL4030
- *
- * @param mod_no - module number
- * @param value - the value to be written 8 bit
- * @param reg - register address (just offset will do)
+ * twl4030_i2c_write_u8 - Writes a 8 bit register in TWL4030
+ * @mod_no: module number
+ * @value: the value to be written 8 bit
+ * @reg: register address (just offset will do)
*
- * @return result of operation - 0 is success
+ * Returns result of operation - 0 is success
*/
int twl4030_i2c_write_u8(u8 mod_no, u8 value, u8 reg)
{
@@ -517,13 +516,12 @@ int twl4030_i2c_write_u8(u8 mod_no, u8 value, u8 reg)
EXPORT_SYMBOL(twl4030_i2c_write_u8);
/**
- * @brief twl4030_i2c_read_u8 - Reads a 8 bit register from TWL4030
- *
- * @param mod_no - module number
- * @param *value - the value read 8 bit
- * @param reg - register address (just offset will do)
+ * twl4030_i2c_read_u8 - Reads a 8 bit register from TWL4030
+ * @mod_no: module number
+ * @value: the value read 8 bit
+ * @reg: register address (just offset will do)
*
- * @return result of operation - 0 is success
+ * Returns result of operation - 0 is success
*/
int twl4030_i2c_read_u8(u8 mod_no, u8 *value, u8 reg)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/2] TWL4030: mark init functions __init, fix kerneldoc
This second revision incorporates a documentation fix from Felipe Balbi <[EMAIL PROTECTED]>. --- Mark most of the functions in twl4030-core.c as __init. Fix the old-style kerneldoc in several functions. Frees up an extra 4kB page after kernel init on 3430SDP. Not sure why there is such a large kernel image size difference; no new code or data has been added. Boot-tested on 3430SDP ES2. - Paul --- size: textdata bss dec hex filename 3391251 157104 107136 3655491 37c743 vmlinux.3430sdp.orig 3394259 157104 107136 3658499 37d303 vmlinux.3430sdp drivers/i2c/chips/twl4030-core.c | 71 +++--- 1 files changed, 35 insertions(+), 36 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/2] TWL4030: mark init-only functions as __init
Mark many functions in twl4030-core.c as __init.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
drivers/i2c/chips/twl4030-core.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/chips/twl4030-core.c b/drivers/i2c/chips/twl4030-core.c
index 47d547d..54e392b 100644
--- a/drivers/i2c/chips/twl4030-core.c
+++ b/drivers/i2c/chips/twl4030-core.c
@@ -681,7 +681,8 @@ static void do_twl4030_irq(unsigned int irq, irq_desc_t
*desc)
}
/* attach a client to the adapter */
-static int twl4030_detect_client(struct i2c_adapter *adapter, unsigned char
sid)
+static int __init twl4030_detect_client(struct i2c_adapter *adapter,
+ unsigned char sid)
{
int err = 0;
struct twl4030_client *twl;
@@ -730,7 +731,7 @@ static int twl4030_detect_client(struct i2c_adapter
*adapter, unsigned char sid)
}
/* adapter callback */
-static int twl4030_attach_adapter(struct i2c_adapter *adapter)
+static int __init twl4030_attach_adapter(struct i2c_adapter *adapter)
{
int i;
int ret = 0;
@@ -783,7 +784,7 @@ static int twl4030_detach_client(struct i2c_client *client)
return 0;
}
-static struct task_struct *start_twl4030_irq_thread(int irq)
+static struct task_struct * __init start_twl4030_irq_thread(int irq)
{
struct task_struct *thread;
@@ -801,7 +802,7 @@ static struct task_struct *start_twl4030_irq_thread(int irq)
* These three functions should be part of Voltage frame work
* added here to complete the functionality for now.
*/
-static int protect_pm_master(void)
+static int __init protect_pm_master(void)
{
int e = 0;
@@ -810,7 +811,7 @@ static int protect_pm_master(void)
return e;
}
-static int unprotect_pm_master(void)
+static int __init unprotect_pm_master(void)
{
int e = 0;
@@ -821,7 +822,7 @@ static int unprotect_pm_master(void)
return e;
}
-static int power_companion_init(void)
+static int __init power_companion_init(void)
{
struct clk *osc;
u32 rate;
@@ -866,7 +867,7 @@ static int power_companion_init(void)
* don't know whether the COR bit is set in _SIH_CTRL. Returns
* the status from the I2C read operation.
*/
-static int twl4030_i2c_clear_isr(u8 mod_no, u8 reg)
+static int __init twl4030_i2c_clear_isr(u8 mod_no, u8 reg)
{
int res;
u8 tmp;
@@ -878,7 +879,7 @@ static int twl4030_i2c_clear_isr(u8 mod_no, u8 reg)
return twl4030_i2c_write_u8(mod_no, 0xff, reg);
}
-static void twl_init_irq(void)
+static void __init twl_init_irq(void)
{
int i, j;
int res = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] TWL4030: convert old-style function documentation to current kerneldoc
On Mon, 4 Aug 2008, Tony Lindgren wrote: > Are you planning to repost this patch? I can't seem to find any other > version.. Reposting now. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Mon, Aug 04, 2008 at 01:26:38PM -0700, David Brownell wrote: > > > > Looks like this driver does not exist outside linux-omap tree, > > > > care to send the whole driver to MTD list? > > > > > > Unless someone created a big-endian OMAP, > > > > Don't they use standard ARM ARM cores, which can all be used in both > > LE and BE modes? > > And when those cores turn into silicon, the choice is usually > hard-wired. I've never seen CPU endianity being hardwired in any ARM system ever -- but maybe OMAP is different. (Out of all the ARM subarchs supported in the kernel right now, I've had ep93xx'es, iop13xx'es, iop32x'es, iop33x'es, ixp2000s, ixp23xx'es, ixp4xx'es, kirkwoods, mv78xx0's, and orion5x'es all running in BE mode at some point.) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Mon, Aug 04, 2008 at 01:02:46PM -0700, David Brownell wrote: > > Looks like this driver does not exist outside linux-omap tree, > > care to send the whole driver to MTD list? > > Unless someone created a big-endian OMAP, Don't they use standard ARM ARM cores, which can all be used in both LE and BE modes? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Monday 04 August 2008, Lennert Buytenhek wrote: > On Mon, Aug 04, 2008 at 01:02:46PM -0700, David Brownell wrote: > > > > Looks like this driver does not exist outside linux-omap tree, > > > care to send the whole driver to MTD list? > > > > Unless someone created a big-endian OMAP, > > Don't they use standard ARM ARM cores, which can all be used in both > LE and BE modes? And when those cores turn into silicon, the choice is usually hard-wired. Regardless, all OMAP cores I've worked with are set up for LE mode ... and then there's still the point that byteswapping to/from the NAND chip seems to add no value. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Monday 04 August 2008, Tony Lindgren wrote: > Looks like this driver does not exist outside linux-omap tree, > care to send the whole driver to MTD list? Unless someone created a big-endian OMAP, the cpu_to_le16() calls in the read/write buffer calls can be removed ... and then the read buffer code can use __raw_readsw(...) to get what's been a significant speedup on some other ARMs. (The atmel_nand.c code should be usable as-is.) If there are big-endian OMAPs, it's still unclear why that would be needed (maybe the hardware ECC code would need to become byteorder-aware?) ... little point in byteswapping on the i/o paths, except maybe to slow things down. It'd make sense to merge the driver version which handles both OMAP2 and OMAP3, too. With beagleboard.org pushing out those puppies, the omap3 support matters more. :) - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[UPDATE][PATCH 00/07][GIT 3/4+] Dspbridge cleanup patches
Hi, The following set of patches, are used to fix some of the warnings and errors reported from various code check tools, like checkpatch and sparse. They also remove some code that is now obsolete and try to make bridge code more understandable and clean, these patches are placed under: http://omapzoom.org/gf/project/omapbridge/frs/?action=FrsReleaseView&release_id=115 The patch order is: BRD001-ARM-OMAP-checkpatch-cleanup.patch BRD002-ARM-OMAP-compilation-fixes.patch BRD003-ARM-OMAP-remove-unused-headers.patch BRD004-ARM-OMAP-remove-unused-code.patch BRD005-ARM-OMAP-remove-dynload-flags.patch BRD006-ARM-OMAP-remove-commented-out-code.patch BRD007-ARM-OMAP-renamingC55Procs.patch Many thanks for your time. Best Regards, omar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 07/07][GIT 3/4+] Renaming CFG_GetC55Procs
> > Renaming CFG_GetC55Procs function for a more proper name > (CFG_GetDSPProcs) and removed redundant initialization statements. > > Why does this function need to exist in the first place? The only place > this is ever going to be used print a trace message on how many > dsp's there are... Just eliminate the CFG_GetC55Procs please. > > > --- Looks like legacy Bridge code from 2430. Yes, we can get rid of this function. Best regards, Hari -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3 v2] OMAP3 Beagle: add nand support
Acked-by: Koen Kooi <[EMAIL PROTECTED] dot org>
Op 4 aug 2008, om 17:58 heeft Dirk Behme het volgende geschreven:
From: Steve Sakoman <[EMAIL PROTECTED]>, Dirk Behme <[EMAIL PROTECTED]
>
Add nand support to omap3beagle
Signed-off-by: Steve Sakoman <[EMAIL PROTECTED]>
Signed-off-by: Dirk Behme <[EMAIL PROTECTED]>
Index: linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
===
--- linux-beagle.orig/arch/arm/mach-omap2/board-omap3beagle.c
+++ linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
@@ -20,11 +20,15 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
#include
#include
+#include
#include
#include
@@ -32,6 +36,64 @@
#include
#include
#include
+#include
+#include
+
+#define GPMC_CS0_BASE 0x60
+#define GPMC_CS_SIZE 0x30
+
+static struct mtd_partition omap3beagle_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = "X-Loader",
+ .offset = 0,
+ .size = 4*(64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = "U-Boot",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 15*(64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = "U-Boot Env",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x26 */
+ .size = 1*(64 * 2048),
+ },
+ {
+ .name = "Kernel",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 32*(64 * 2048),
+ },
+ {
+ .name = "File System",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct omap_nand_platform_data omap3beagle_nand_data = {
+ .parts = omap3beagle_nand_partitions,
+ .nr_parts = ARRAY_SIZE(omap3beagle_nand_partitions),
+ .dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .nand_setup = NULL,
+ .dev_ready = NULL,
+};
+
+static struct resource omap3beagle_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device omap3beagle_nand_device = {
+ .name = "omap2-nand",
+ .id = -1,
+ .dev= {
+ .platform_data = &omap3beagle_nand_data,
+ },
+ .num_resources = 1,
+ .resource = &omap3beagle_nand_resource,
+};
static struct omap_uart_config omap3_beagle_uart_config __initdata = {
.enabled_uarts = ((1 << 0) | (1 << 1) | (1 << 2)),
@@ -113,6 +175,44 @@ static struct platform_device *omap3_bea
&leds_gpio,
};
+void __init omap3beagle_flash_init(void)
+{
+ u8 cs = 0;
+ u8 nandcs = GPMC_CS_NUM + 1;
+
+ u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
+
+ /* find out the chip-select on which NAND exists */
+ while (cs < GPMC_CS_NUM) {
+ u32 ret = 0;
+ ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+ if ((ret & 0xC00) == 0x800) {
+ printk(KERN_INFO "Found NAND on CS%d\n", cs);
+ if (nandcs > GPMC_CS_NUM)
+ nandcs = cs;
+ }
+ cs++;
+ }
+
+ if (nandcs > GPMC_CS_NUM) {
+ printk(KERN_INFO "NAND: Unable to find configuration "
+"in GPMC\n ");
+ return;
+ }
+
+ if (nandcs < GPMC_CS_NUM) {
+ omap3beagle_nand_data.cs = nandcs;
+ omap3beagle_nand_data.gpmc_cs_baseaddr = (void *)
+ (gpmc_base_add + GPMC_CS0_BASE + nandcs * GPMC_CS_SIZE);
+ omap3beagle_nand_data.gpmc_baseaddr = (void *) (gpmc_base_add);
+
+ printk(KERN_INFO "Registering NAND on CS%d\n", nandcs);
+ if (platform_device_register(&omap3beagle_nand_device) < 0)
+ printk(KERN_ERR "Unable to register NAND device\n");
+ }
+}
+
static void __init omap3_beagle_init(void)
{
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
@@ -122,6 +222,7 @@ static void __init omap3_beagle_init(voi
hsmmc_init();
usb_musb_init();
usb_ehci_init();
+ omap3beagle_flash_init();
}
arch_initcall(omap3_beagle_i2c_init);
PGP.sig
Description: This is a digitally signed message part
Re: [PATCH 3/3 v2] OMAP3 Beagle: Enable nand and jffs2 support in defconfig
Acked-by: Koen Kooi <[EMAIL PROTECTED] dot org> Op 4 aug 2008, om 17:58 heeft Dirk Behme het volgende geschreven: From: Steve Sakoman <[EMAIL PROTECTED]>, Dirk Behme <[EMAIL PROTECTED] > Enable nand and jffs2 in defconfig Signed-off-by: Steve Sakoman <[EMAIL PROTECTED]> Signed-off-by: Dirk Behme <[EMAIL PROTECTED]> Index: linux-beagle/arch/arm/configs/omap3_beagle_defconfig === --- linux-beagle.orig/arch/arm/configs/omap3_beagle_defconfig +++ linux-beagle/arch/arm/configs/omap3_beagle_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.26-rc3-omap1 -# Tue May 27 22:23:14 2008 +# Linux kernel version: 2.6.26-rc8-omap1 +# Fri Jul 4 10:19:23 2008 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -170,9 +170,9 @@ CONFIG_ARCH_OMAP3=y # # OMAP Feature Selections # -CONFIG_OMAP_DEBUG_SRAM_PATCH=y # CONFIG_OMAP_DEBUG_POWERDOMAIN is not set # CONFIG_OMAP_DEBUG_CLOCKDOMAIN is not set +# CONFIG_OMAP_SMARTREFLEX is not set # CONFIG_OMAP_RESET_CLOCKS is not set CONFIG_OMAP_BOOT_TAG=y CONFIG_OMAP_BOOT_REASON=y @@ -415,7 +415,83 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set -# CONFIG_MTD is not set +CONFIG_MTD=y +# CONFIG_MTD_DEBUG is not set +# CONFIG_MTD_CONCAT is not set +CONFIG_MTD_PARTITIONS=y +# CONFIG_MTD_REDBOOT_PARTS is not set +# CONFIG_MTD_CMDLINE_PARTS is not set +# CONFIG_MTD_AFS_PARTS is not set +# CONFIG_MTD_AR7_PARTS is not set + +# +# User Modules And Translation Layers +# +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLKDEVS=y +CONFIG_MTD_BLOCK=y +# CONFIG_FTL is not set +# CONFIG_NFTL is not set +# CONFIG_INFTL is not set +# CONFIG_RFD_FTL is not set +# CONFIG_SSFDC is not set +# CONFIG_MTD_OOPS is not set + +# +# RAM/ROM/Flash chip drivers +# +# CONFIG_MTD_CFI is not set +# CONFIG_MTD_JEDECPROBE is not set +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +# CONFIG_MTD_CFI_I4 is not set +# CONFIG_MTD_CFI_I8 is not set +# CONFIG_MTD_RAM is not set +# CONFIG_MTD_ROM is not set +# CONFIG_MTD_ABSENT is not set + +# +# Mapping drivers for chip access +# +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +# CONFIG_MTD_PLATRAM is not set + +# +# Self-contained MTD device drivers +# +# CONFIG_MTD_SLRAM is not set +# CONFIG_MTD_PHRAM is not set +# CONFIG_MTD_MTDRAM is not set +# CONFIG_MTD_BLOCK2MTD is not set + +# +# Disk-On-Chip Device Drivers +# +# CONFIG_MTD_DOC2000 is not set +# CONFIG_MTD_DOC2001 is not set +# CONFIG_MTD_DOC2001PLUS is not set +CONFIG_MTD_NAND=y +# CONFIG_MTD_NAND_VERIFY_WRITE is not set +# CONFIG_MTD_NAND_ECC_SMC is not set +# CONFIG_MTD_NAND_MUSEUM_IDS is not set +CONFIG_MTD_NAND_OMAP2=y +CONFIG_MTD_NAND_IDS=y +# CONFIG_MTD_NAND_DISKONCHIP is not set +# CONFIG_MTD_NAND_NANDSIM is not set +# CONFIG_MTD_NAND_PLATFORM is not set +# CONFIG_MTD_ALAUDA is not set +# CONFIG_MTD_ONENAND is not set + +# +# UBI - Unsorted block images +# +# CONFIG_MTD_UBI is not set # CONFIG_PARPORT is not set CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_COW_COMMON is not set @@ -791,6 +867,7 @@ CONFIG_USB_MUSB_LOGLEVEL=0 # # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set +# CONFIG_USB_WDM is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' @@ -837,6 +914,7 @@ CONFIG_USB_MON=y # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set +# CONFIG_USB_ISIGHTFW is not set CONFIG_USB_GADGET=y # CONFIG_USB_GADGET_DEBUG is not set # CONFIG_USB_GADGET_DEBUG_FILES is not set @@ -873,6 +951,7 @@ CONFIG_MMC=y CONFIG_MMC_BLOCK=y CONFIG_MMC_BLOCK_BOUNCE=y # CONFIG_SDIO_UART is not set +# CONFIG_MMC_TEST is not set # # MMC/SD Host Controller Drivers @@ -909,6 +988,7 @@ CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_DRV_M41T80 is not set CONFIG_RTC_DRV_TWL4030=y # CONFIG_RTC_DRV_S35390A is not set +# CONFIG_RTC_DRV_FM3130 is not set # # SPI RTC drivers @@ -1001,6 +1081,17 @@ CONFIG_TMPFS=y # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set +CONFIG_JFFS2_FS=y +CONFIG_JFFS2_FS_DEBUG=0 +CONFIG_JFFS2_FS_WRITEBUFFER=y +# CONFIG_JFFS2_FS_WBUF_VERIFY is not set +# CONFIG_JFFS2_SUMMARY is not set +# CONFIG_JFFS2_FS_XATTR is not set +# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set +CONFIG_JFFS2_ZLIB=y +# CONFIG_JFFS2_LZO is not set +CONFIG_JFFS2_RTIME=y +# CONFIG_JFFS2_RUBIN is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set @@ -1235,6 +1326,8 @@ CONFIG_CRC_CCITT=y CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=y +CONFIG_ZLIB_INFLATE=y +CONFIG_ZLIB_DEFLATE=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y PGP.sig Description: This is a digitally signed message part
Re: [PATCH 1/3 v2] mtd omap2 nand driver: extend to work with omap3 boards
Acked-by: Koen Kooi
Op 4 aug 2008, om 17:58 heeft Dirk Behme het volgende geschreven:
From: Teerth Reddy <[EMAIL PROTECTED]>, Steve Sakoman
<[EMAIL PROTECTED]>, Dirk Behme <[EMAIL PROTECTED]>
Extend omap2 mtd nand driver to work with ARCH_OMAP3 boards
Signed-off-by: Steve Sakoman <[EMAIL PROTECTED]>
Signed-off-by: Dirk Behme <[EMAIL PROTECTED]>
Index: linux-beagle/drivers/mtd/nand/Kconfig
===
--- linux-beagle.orig/drivers/mtd/nand/Kconfig
+++ linux-beagle/drivers/mtd/nand/Kconfig
@@ -70,10 +70,10 @@ config MTD_NAND_AMS_DELTA
Support for NAND flash on Amstrad E3 (Delta).
config MTD_NAND_OMAP2
- tristate "NAND Flash device on OMAP 2420H4/2430SDP boards"
- depends on (ARM && ARCH_OMAP2 && MTD_NAND)
+ tristate "NAND Flash device on OMAP2 and OMAP3"
+ depends on ARM && MTD_NAND && (ARCH_OMAP2 || ARCH_OMAP3)
help
- Support for NAND flash on Texas Instruments 2430SDP/
2420H4 platforms.
+ Support for NAND flash on Texas Instruments OMAP2 and
OMAP3 platforms.
config MTD_NAND_OMAP
tristate "NAND Flash device on OMAP H3/H2/P2 boards"
Index: linux-beagle/drivers/mtd/nand/omap2.c
===
--- linux-beagle.orig/drivers/mtd/nand/omap2.c
+++ linux-beagle/drivers/mtd/nand/omap2.c
@@ -111,15 +111,6 @@
static const char *part_probes[] = { "cmdlinepart", NULL };
#endif
-static int hw_ecc = 1;
-
-/* new oob placement block for use with hardware ecc generation */
-static struct nand_ecclayout omap_hw_eccoob = {
- .eccbytes = 12,
- .eccpos = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13},
- .oobfree = {{16, 32}, {33, 63} },
-};
-
struct omap_nand_info {
struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
@@ -133,6 +124,13 @@ struct omap_nand_info {
void __iomem*gpmc_cs_baseaddr;
void __iomem*gpmc_baseaddr;
};
+
+/*
+ * omap_nand_wp - This function enable or disable the Write Protect
feature on
+ * NAND device
+ * @mtd: MTD device structure
+ * @mode: WP ON/OFF
+ */
static void omap_nand_wp(struct mtd_info *mtd, int mode)
{
struct omap_nand_info *info = container_of(mtd,
@@ -189,11 +187,11 @@ static void omap_hwcontrol(struct mtd_in
}
/*
-* omap_read_buf - read data from NAND controller into buffer
-* @mtd: MTD device structure
-* @buf: buffer to store date
-* @len: number of bytes to read
-*/
+ * omap_read_buf - read data from NAND controller into buffer
+ * @mtd: MTD device structure
+ * @buf: buffer to store date
+ * @len: number of bytes to read
+ */
static void omap_read_buf(struct mtd_info *mtd, u_char *buf, int len)
{
struct omap_nand_info *info = container_of(mtd,
@@ -207,11 +205,11 @@ static void omap_read_buf(struct mtd_inf
}
/*
-* omap_write_buf - write buffer to NAND controller
-* @mtd: MTD device structure
-* @buf: data buffer
-* @len: number of bytes to write
-*/
+ * omap_write_buf - write buffer to NAND controller
+ * @mtd: MTD device structure
+ * @buf: data buffer
+ * @len: number of bytes to write
+ */
static void omap_write_buf(struct mtd_info *mtd, const u_char * buf,
int len)
{
struct omap_nand_info *info = container_of(mtd,
@@ -250,10 +248,16 @@ static int omap_verify_buf(struct mtd_in
return 0;
}
+#ifdef CONFIG_MTD_NAND_OMAP_HWECC
+/*
+ * omap_hwecc_init-Initialize the Hardware ECC for NAND flash in
GPMC controller
+ * @mtd: MTD device structure
+ */
static void omap_hwecc_init(struct mtd_info *mtd)
{
struct omap_nand_info *info = container_of(mtd, struct
omap_nand_info,
mtd);
+ register struct nand_chip *chip = mtd->priv;
unsigned long val = 0x0;
/* Read from ECC Control Register */
@@ -264,16 +268,15 @@ static void omap_hwecc_init(struct mtd_i
/* Read from ECC Size Config Register */
val = __raw_readl(info->gpmc_baseaddr + GPMC_ECC_SIZE_CONFIG);
- /* ECCSIZE1=512 | ECCSIZE0=8bytes | Select eccResultsize[0123] */
- val = ((0x00FF<<22) | (0x0003<<12) | (0x000F));
+ /* ECCSIZE1=512 | Select eccResultsize[0-3] */
+ val = chip->ecc.size >> 1) - 1) << 22) | (0x000F));
__raw_writel(val, info->gpmc_baseaddr + GPMC_ECC_SIZE_CONFIG);
-
-
}
/*
- * This function will generate true ECC value, which can be used
+ * gen_true_ecc - This function will generate true ECC value, which
can be used
* when correcting data read from NAND flash memory core
+ * @ecc_buf: buffer to store ecc code
*/
static void gen_true_ecc(u8 *ecc_buf)
{
@@ -289,8 +292,12 @@ static void gen_true_ecc(u8 *ecc_buf)
}
/*
- * This function compares two ECC's and indicates if there is an
error.
- * If the error can be corrected it will be corrected to the buffer
+ * omap_compare_ecc - This function compares two ECC's and
indicates
Re: USB driver issue
On Sat, Aug 02, 2008 at 01:51:59AM -0700, ext Emanoil Kotsev wrote: > > > Kernel developers should fix bugs in minor kernel > > versions as they are > > > meant for this purpous and do major changes only in > > major version. A > > > bunch of bugfixes I see (not only usb related) are > > just not in place > > > in minor kernel versions. That's my opinion at > > first place. > > > > Minor (2.6.x.y) releases happen with only bugfixes every > > few weeks. > > Perhaps you should use them. But realize that they are > > only supported > > for about 3-4 months, then you are expected to move to the > > next major > > release. > > This is the issue 3-4 months are enough for ATI or NVidia to bring a new > driver > Either change the policy or find a solution! The policy is 'we do not support proprietary drivers' (both in X.Org and in the kernel). The solution is for vendors not to produce proprietary drivers. Intel, AMD/ATI, and others have already got the message and already work with us to provide high-quality open source drivers. If this bothers you, please tell NVIDIA that you're a customer who's purchased their product, and that you wish to have acceptable (i.e., open source) Linux kernel + X.Org support. That's the only way it will ever get fixed, full stop. (Well, either that or through Nouveau.) > > Given the rate of change in the Linux kernel (faster than > > any other > > software project known to man), how do you really expect us > > to do that? > > It's pretty impossible. > > The question is - what are you doing this for? What's your goal I think the primary motivation for most people could be summed up by the title of Linus Torvalds's autobiography: 'Just for Fun'. As soon as it's no longer fun (hint: attempting to force people to do things they don't think are good ideas usually drains some amount of the fun), people will begin to walk away. > I'm going to give up linux soon if it goes this way I've never met you before, so you'll have to understand if myself and most others on this list aren't dropping everything to ensure you don't carry out this threat. > > No, we expect that you would use hardware that works with, > > and > > contributes toward the advancement of Linux. Not hardware > > that requires > > closed source modules. > > I spent a lot of time reading about hardware and linu support when IO bought > my dell notebook, that's why I choose one with intel video vard inside ... > and what happened - I don't have 3D when using dual screen - GREAT! Upgrade to Xorg 7.3 or above. Anything with xorg-server 1.3.0 or above and xf86-video-intel 2.x.x supports dual screen with 3D just fine, via XRandR 1.2. As an added bonus, you get to drop the static configuration in xorg.conf, and you can have hotplug monitor support, on-the-fly reconfiguration, etc. See http://www.intellinuxgraphics.org for more details. The Radeon driver also supports this in 6.8.x and above. > > Again, if you are stuck with such hardware, there is > > _nothing_ that I or > > any other kernel developer can do about it. It is > > physically > > impossible. > > The problem is, that ATI, NVidia and a lot of other hardware producers are > willing to support linux, but can not afford it to bring up drivers for the > latest stable kernel in the terms you consider it as stable - and this was my > original point. AMD/ATI already support it in this model, except for fglrx, which is not actually for home consumers and game players at all, but for people like Pixar with huge renderfarms, or heavy CAD users. Hence the extreme focus on absolute GL spec compliance, et al. NVIDIA have chosen not to support that model. Their loss. > Then fix the hfs modem for my dell notebook (oh ... it is closed driver by > connexant - but they are willing to help me and oh, they suggest I use > the 2.6.24 kernel) That's not much help then, is it? What happens when NVIDIA have a bug that forces you to downgrade to 2.6.22, which hfs doesn't support in that version? Incidentally, Ubuntu are now having to ship four NVIDIA drivers, because they keep deprecating support, and the old drivers don't always keep up with new kernel versions (even stable ones: they receive literally zero updates once your card is deemed too old). I assume this is the kind of 'help' and 'support' you keep talking about. > > We change because the world changes. In order to survive, > > we also need > > to change. > > > > If we stop, we die. > > This is true, but out of scope - see above. There is no sence to install a > new kernel that does not support my hardware and also is outaged when I have > the drivers for this kernel version. No-one can do anything about third-party drivers. If the driver for your NVIDIA chipset, which is written and shipped by NVIDIA, does not support the newest kernel version, then complain to NVIDIA, not the people working on the kernel. As everyone in this discussion has repeatedly said, there's nothing anyone
[PATCH 00/07][GIT 3/4+] Bridge cleanup patches
I removed the attached patches as this mail got rejected by size limit. Also patches 1 and 6 got rejected: BRD001-ARM-OMAP-checkpatch-cleanup.patch (183 KB) BRD006-ARM-OMAP-remove-commented-out-code.patch (197 KB) These patches are just for cleanup but your feedback would be of great help, so I'll be splitting these to fit the size limit, hope this is ok. Regards, omar -Original Message- From: Ramirez Luna, Omar Sent: Monday, August 04, 2008 9:54 AM To: 'linux-omap@vger.kernel.org' Subject: [PATCH 00/07][GIT 3/4+] Bridge cleanup patches Hi, The following set of patches, are used to fix some of the warnings and errors reported from various code check tools, like checkpatch and sparse. They also remove some code that is now obsolete and try to make bridge code more understandable and clean. The patch order is: BRD001-ARM-OMAP-checkpatch-cleanup.patch BRD002-ARM-OMAP-compilation-fixes.patch BRD003-ARM-OMAP-remove-unused-headers.patch BRD004-ARM-OMAP-remove-unused-code.patch BRD005-ARM-OMAP-remove-dynload-flags.patch BRD006-ARM-OMAP-remove-commented-out-code.patch BRD007-ARM-OMAP-renamingC55Procs.patch Regards, omar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3 v2] OMAP3 Beagle: add nand support
From: Steve Sakoman <[EMAIL PROTECTED]>, Dirk Behme <[EMAIL PROTECTED]>
Add nand support to omap3beagle
Signed-off-by: Steve Sakoman <[EMAIL PROTECTED]>
Signed-off-by: Dirk Behme <[EMAIL PROTECTED]>
Index: linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
===
--- linux-beagle.orig/arch/arm/mach-omap2/board-omap3beagle.c
+++ linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
@@ -20,11 +20,15 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
#include
#include
+#include
#include
#include
@@ -32,6 +36,64 @@
#include
#include
#include
+#include
+#include
+
+#define GPMC_CS0_BASE 0x60
+#define GPMC_CS_SIZE 0x30
+
+static struct mtd_partition omap3beagle_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = "X-Loader",
+ .offset = 0,
+ .size = 4*(64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = "U-Boot",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 15*(64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = "U-Boot Env",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x26 */
+ .size = 1*(64 * 2048),
+ },
+ {
+ .name = "Kernel",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 32*(64 * 2048),
+ },
+ {
+ .name = "File System",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct omap_nand_platform_data omap3beagle_nand_data = {
+ .parts = omap3beagle_nand_partitions,
+ .nr_parts = ARRAY_SIZE(omap3beagle_nand_partitions),
+ .dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .nand_setup = NULL,
+ .dev_ready = NULL,
+};
+
+static struct resource omap3beagle_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device omap3beagle_nand_device = {
+ .name = "omap2-nand",
+ .id = -1,
+ .dev= {
+ .platform_data = &omap3beagle_nand_data,
+ },
+ .num_resources = 1,
+ .resource = &omap3beagle_nand_resource,
+};
static struct omap_uart_config omap3_beagle_uart_config __initdata = {
.enabled_uarts = ((1 << 0) | (1 << 1) | (1 << 2)),
@@ -113,6 +175,44 @@ static struct platform_device *omap3_bea
&leds_gpio,
};
+void __init omap3beagle_flash_init(void)
+{
+ u8 cs = 0;
+ u8 nandcs = GPMC_CS_NUM + 1;
+
+ u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
+
+ /* find out the chip-select on which NAND exists */
+ while (cs < GPMC_CS_NUM) {
+ u32 ret = 0;
+ ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+ if ((ret & 0xC00) == 0x800) {
+ printk(KERN_INFO "Found NAND on CS%d\n", cs);
+ if (nandcs > GPMC_CS_NUM)
+ nandcs = cs;
+ }
+ cs++;
+ }
+
+ if (nandcs > GPMC_CS_NUM) {
+ printk(KERN_INFO "NAND: Unable to find configuration "
+"in GPMC\n ");
+ return;
+ }
+
+ if (nandcs < GPMC_CS_NUM) {
+ omap3beagle_nand_data.cs = nandcs;
+ omap3beagle_nand_data.gpmc_cs_baseaddr = (void *)
+ (gpmc_base_add + GPMC_CS0_BASE + nandcs * GPMC_CS_SIZE);
+ omap3beagle_nand_data.gpmc_baseaddr = (void *) (gpmc_base_add);
+
+ printk(KERN_INFO "Registering NAND on CS%d\n", nandcs);
+ if (platform_device_register(&omap3beagle_nand_device) < 0)
+ printk(KERN_ERR "Unable to register NAND device\n");
+ }
+}
+
static void __init omap3_beagle_init(void)
{
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
@@ -122,6 +222,7 @@ static void __init omap3_beagle_init(voi
hsmmc_init();
usb_musb_init();
usb_ehci_init();
+ omap3beagle_flash_init();
}
arch_initcall(omap3_beagle_i2c_init);
[PATCH 3/3 v2] OMAP3 Beagle: Enable nand and jffs2 support in defconfig
From: Steve Sakoman <[EMAIL PROTECTED]>, Dirk Behme <[EMAIL PROTECTED]> Enable nand and jffs2 in defconfig Signed-off-by: Steve Sakoman <[EMAIL PROTECTED]> Signed-off-by: Dirk Behme <[EMAIL PROTECTED]> Index: linux-beagle/arch/arm/configs/omap3_beagle_defconfig === --- linux-beagle.orig/arch/arm/configs/omap3_beagle_defconfig +++ linux-beagle/arch/arm/configs/omap3_beagle_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.26-rc3-omap1 -# Tue May 27 22:23:14 2008 +# Linux kernel version: 2.6.26-rc8-omap1 +# Fri Jul 4 10:19:23 2008 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -170,9 +170,9 @@ CONFIG_ARCH_OMAP3=y # # OMAP Feature Selections # -CONFIG_OMAP_DEBUG_SRAM_PATCH=y # CONFIG_OMAP_DEBUG_POWERDOMAIN is not set # CONFIG_OMAP_DEBUG_CLOCKDOMAIN is not set +# CONFIG_OMAP_SMARTREFLEX is not set # CONFIG_OMAP_RESET_CLOCKS is not set CONFIG_OMAP_BOOT_TAG=y CONFIG_OMAP_BOOT_REASON=y @@ -415,7 +415,83 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set -# CONFIG_MTD is not set +CONFIG_MTD=y +# CONFIG_MTD_DEBUG is not set +# CONFIG_MTD_CONCAT is not set +CONFIG_MTD_PARTITIONS=y +# CONFIG_MTD_REDBOOT_PARTS is not set +# CONFIG_MTD_CMDLINE_PARTS is not set +# CONFIG_MTD_AFS_PARTS is not set +# CONFIG_MTD_AR7_PARTS is not set + +# +# User Modules And Translation Layers +# +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLKDEVS=y +CONFIG_MTD_BLOCK=y +# CONFIG_FTL is not set +# CONFIG_NFTL is not set +# CONFIG_INFTL is not set +# CONFIG_RFD_FTL is not set +# CONFIG_SSFDC is not set +# CONFIG_MTD_OOPS is not set + +# +# RAM/ROM/Flash chip drivers +# +# CONFIG_MTD_CFI is not set +# CONFIG_MTD_JEDECPROBE is not set +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +# CONFIG_MTD_CFI_I4 is not set +# CONFIG_MTD_CFI_I8 is not set +# CONFIG_MTD_RAM is not set +# CONFIG_MTD_ROM is not set +# CONFIG_MTD_ABSENT is not set + +# +# Mapping drivers for chip access +# +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +# CONFIG_MTD_PLATRAM is not set + +# +# Self-contained MTD device drivers +# +# CONFIG_MTD_SLRAM is not set +# CONFIG_MTD_PHRAM is not set +# CONFIG_MTD_MTDRAM is not set +# CONFIG_MTD_BLOCK2MTD is not set + +# +# Disk-On-Chip Device Drivers +# +# CONFIG_MTD_DOC2000 is not set +# CONFIG_MTD_DOC2001 is not set +# CONFIG_MTD_DOC2001PLUS is not set +CONFIG_MTD_NAND=y +# CONFIG_MTD_NAND_VERIFY_WRITE is not set +# CONFIG_MTD_NAND_ECC_SMC is not set +# CONFIG_MTD_NAND_MUSEUM_IDS is not set +CONFIG_MTD_NAND_OMAP2=y +CONFIG_MTD_NAND_IDS=y +# CONFIG_MTD_NAND_DISKONCHIP is not set +# CONFIG_MTD_NAND_NANDSIM is not set +# CONFIG_MTD_NAND_PLATFORM is not set +# CONFIG_MTD_ALAUDA is not set +# CONFIG_MTD_ONENAND is not set + +# +# UBI - Unsorted block images +# +# CONFIG_MTD_UBI is not set # CONFIG_PARPORT is not set CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_COW_COMMON is not set @@ -791,6 +867,7 @@ CONFIG_USB_MUSB_LOGLEVEL=0 # # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set +# CONFIG_USB_WDM is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' @@ -837,6 +914,7 @@ CONFIG_USB_MON=y # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set +# CONFIG_USB_ISIGHTFW is not set CONFIG_USB_GADGET=y # CONFIG_USB_GADGET_DEBUG is not set # CONFIG_USB_GADGET_DEBUG_FILES is not set @@ -873,6 +951,7 @@ CONFIG_MMC=y CONFIG_MMC_BLOCK=y CONFIG_MMC_BLOCK_BOUNCE=y # CONFIG_SDIO_UART is not set +# CONFIG_MMC_TEST is not set # # MMC/SD Host Controller Drivers @@ -909,6 +988,7 @@ CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_DRV_M41T80 is not set CONFIG_RTC_DRV_TWL4030=y # CONFIG_RTC_DRV_S35390A is not set +# CONFIG_RTC_DRV_FM3130 is not set # # SPI RTC drivers @@ -1001,6 +1081,17 @@ CONFIG_TMPFS=y # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set +CONFIG_JFFS2_FS=y +CONFIG_JFFS2_FS_DEBUG=0 +CONFIG_JFFS2_FS_WRITEBUFFER=y +# CONFIG_JFFS2_FS_WBUF_VERIFY is not set +# CONFIG_JFFS2_SUMMARY is not set +# CONFIG_JFFS2_FS_XATTR is not set +# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set +CONFIG_JFFS2_ZLIB=y +# CONFIG_JFFS2_LZO is not set +CONFIG_JFFS2_RTIME=y +# CONFIG_JFFS2_RUBIN is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set @@ -1235,6 +1326,8 @@ CONFIG_CRC_CCITT=y CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=y +CONFIG_ZLIB_INFLATE=y +CONFIG_ZLIB_DEFLATE=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y
[PATCH 0/3 v2] OMAP3 Beagle: Enable nand support
This series of patches adds NAND support to the BeagleBoard. The first patch in the series builds on work by Teerth Reddy <[EMAIL PROTECTED]> and Steve Sakoman <[EMAIL PROTECTED]> to extend the omap2 nand driver to work with both omap2 and omap3 architectures (as well as adding/clarifying comments). The second patch adds the beagle nand support, and the final patch enables the nand driver and jffs2 support in the beagle defconfig. The patch set was reviewed by Khasim Syed Mohammed <[EMAIL PROTECTED]> prior to this submission. It was tested on Rev A and B BeagleBoards. This v2 replaces http://marc.info/?l=linux-omap&m=121230229625544&w=2 Changes in v2: - Apply cleanly to recent git (defconfig, drivers/mtd/nand/omap2.c) - Beagle has only NAND. This results in small config. Move configuration to board-omap3beagle.c and don't create a new file board-omap3beagle-flash.c for it. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3 v2] mtd omap2 nand driver: extend to work with omap3 boards
From: Teerth Reddy <[EMAIL PROTECTED]>, Steve Sakoman <[EMAIL PROTECTED]>,
Dirk Behme <[EMAIL PROTECTED]>
Extend omap2 mtd nand driver to work with ARCH_OMAP3 boards
Signed-off-by: Steve Sakoman <[EMAIL PROTECTED]>
Signed-off-by: Dirk Behme <[EMAIL PROTECTED]>
Index: linux-beagle/drivers/mtd/nand/Kconfig
===
--- linux-beagle.orig/drivers/mtd/nand/Kconfig
+++ linux-beagle/drivers/mtd/nand/Kconfig
@@ -70,10 +70,10 @@ config MTD_NAND_AMS_DELTA
Support for NAND flash on Amstrad E3 (Delta).
config MTD_NAND_OMAP2
- tristate "NAND Flash device on OMAP 2420H4/2430SDP boards"
- depends on (ARM && ARCH_OMAP2 && MTD_NAND)
+ tristate "NAND Flash device on OMAP2 and OMAP3"
+ depends on ARM && MTD_NAND && (ARCH_OMAP2 || ARCH_OMAP3)
help
- Support for NAND flash on Texas Instruments 2430SDP/2420H4 platforms.
+ Support for NAND flash on Texas Instruments OMAP2 and OMAP3
platforms.
config MTD_NAND_OMAP
tristate "NAND Flash device on OMAP H3/H2/P2 boards"
Index: linux-beagle/drivers/mtd/nand/omap2.c
===
--- linux-beagle.orig/drivers/mtd/nand/omap2.c
+++ linux-beagle/drivers/mtd/nand/omap2.c
@@ -111,15 +111,6 @@
static const char *part_probes[] = { "cmdlinepart", NULL };
#endif
-static int hw_ecc = 1;
-
-/* new oob placement block for use with hardware ecc generation */
-static struct nand_ecclayout omap_hw_eccoob = {
- .eccbytes = 12,
- .eccpos = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13},
- .oobfree = {{16, 32}, {33, 63} },
-};
-
struct omap_nand_info {
struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
@@ -133,6 +124,13 @@ struct omap_nand_info {
void __iomem*gpmc_cs_baseaddr;
void __iomem*gpmc_baseaddr;
};
+
+/*
+ * omap_nand_wp - This function enable or disable the Write Protect feature on
+ * NAND device
+ * @mtd: MTD device structure
+ * @mode: WP ON/OFF
+ */
static void omap_nand_wp(struct mtd_info *mtd, int mode)
{
struct omap_nand_info *info = container_of(mtd,
@@ -189,11 +187,11 @@ static void omap_hwcontrol(struct mtd_in
}
/*
-* omap_read_buf - read data from NAND controller into buffer
-* @mtd: MTD device structure
-* @buf: buffer to store date
-* @len: number of bytes to read
-*/
+ * omap_read_buf - read data from NAND controller into buffer
+ * @mtd: MTD device structure
+ * @buf: buffer to store date
+ * @len: number of bytes to read
+ */
static void omap_read_buf(struct mtd_info *mtd, u_char *buf, int len)
{
struct omap_nand_info *info = container_of(mtd,
@@ -207,11 +205,11 @@ static void omap_read_buf(struct mtd_inf
}
/*
-* omap_write_buf - write buffer to NAND controller
-* @mtd: MTD device structure
-* @buf: data buffer
-* @len: number of bytes to write
-*/
+ * omap_write_buf - write buffer to NAND controller
+ * @mtd: MTD device structure
+ * @buf: data buffer
+ * @len: number of bytes to write
+ */
static void omap_write_buf(struct mtd_info *mtd, const u_char * buf, int len)
{
struct omap_nand_info *info = container_of(mtd,
@@ -250,10 +248,16 @@ static int omap_verify_buf(struct mtd_in
return 0;
}
+#ifdef CONFIG_MTD_NAND_OMAP_HWECC
+/*
+ * omap_hwecc_init-Initialize the Hardware ECC for NAND flash in GPMC
controller
+ * @mtd: MTD device structure
+ */
static void omap_hwecc_init(struct mtd_info *mtd)
{
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
+ register struct nand_chip *chip = mtd->priv;
unsigned long val = 0x0;
/* Read from ECC Control Register */
@@ -264,16 +268,15 @@ static void omap_hwecc_init(struct mtd_i
/* Read from ECC Size Config Register */
val = __raw_readl(info->gpmc_baseaddr + GPMC_ECC_SIZE_CONFIG);
- /* ECCSIZE1=512 | ECCSIZE0=8bytes | Select eccResultsize[0123] */
- val = ((0x00FF<<22) | (0x0003<<12) | (0x000F));
+ /* ECCSIZE1=512 | Select eccResultsize[0-3] */
+ val = chip->ecc.size >> 1) - 1) << 22) | (0x000F));
__raw_writel(val, info->gpmc_baseaddr + GPMC_ECC_SIZE_CONFIG);
-
-
}
/*
- * This function will generate true ECC value, which can be used
+ * gen_true_ecc - This function will generate true ECC value, which can be used
* when correcting data read from NAND flash memory core
+ * @ecc_buf: buffer to store ecc code
*/
static void gen_true_ecc(u8 *ecc_buf)
{
@@ -289,8 +292,12 @@ static void gen_true_ecc(u8 *ecc_buf)
}
/*
- * This function compares two ECC's and indicates if there is an error.
- * If the error can be corrected it will be corrected to the buffer
+ * omap_compare_ecc - This function compares two ECC's and indicates if there
+ * is an error. If the error can be corrected it will be cor
Re: [PATCH 07/07][GIT 3/4+] Renaming CFG_GetC55Procs
On Mon, Aug 04, 2008 at 09:56:31AM -0500, Ramirez Luna, Omar wrote:
> Renaming CFG_GetC55Procs function for a more proper name (CFG_GetDSPProcs)
> and removed redundant initialization statements.
Why does this function need to exist in the first place? The only place
this is ever going to be used print a trace message on how many
dsp's there are... Just eliminate the CFG_GetC55Procs please.
> ---
> Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/cfg.h
> ===
> --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/cfg.h 2008-07-29
> 23:52:55.0 -0500
> +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/cfg.h 2008-07-29
> 23:56:40.0 -0500
> @@ -337,6 +337,6 @@
> */
> extern DSP_STATUS CFG_SetObject(IN u32 dwValue, IN u32 dwType);
>
> - extern DSP_STATUS CFG_GetC55Procs(OUT u32 *numProcs);
> + extern DSP_STATUS CFG_GetDSPProcs(OUT u32 *numProcs);
>
> #endif /* CFG_ */
> Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/src/rmgr/dspdrv.c
> ===
> --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/src/rmgr/dspdrv.c
> 2008-07-29 23:56:26.0 -0500
> +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/src/rmgr/dspdrv.c
> 2008-07-29 23:56:40.0 -0500
> @@ -156,7 +156,7 @@
> goto func_cont;
> } /* End DRV_Create */
> GT_0trace(curTrace, GT_5CLASS, "DSP_Init:DRV Created \r\n");
> - status = CFG_GetC55Procs(&numProcs);
> + status = CFG_GetDSPProcs(&numProcs);
> GT_1trace(curTrace, GT_5CLASS, "DSP_Init:C55 procs configured = %d\n",
> numProcs);
> if (DSP_SUCCEEDED(status) & numProcs) {
> Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/src/services/cfg.c
> ===
> --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/src/services/cfg.c
> 2008-07-29 23:52:26.0 -0500
> +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/src/services/cfg.c
> 2008-07-29 23:56:40.0 -0500
> @@ -485,16 +485,15 @@
> }
>
> /*
> - * ===CFG_GetC55Procs
> + * ===CFG_GetDSPProcs
> * Purpose:
> * Get the number of configured C55 processors
> */
>
> -DSP_STATUS CFG_GetC55Procs(OUT u32 *numProcs)
> +DSP_STATUS CFG_GetDSPProcs(OUT u32 *numProcs)
> {
> DSP_STATUS status = DSP_SOK;
>
> - *numProcs = 0;
> *numProcs = 1;
> return status;
> }
> ---
>
> Regards,
>
> omar
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
"rm -rf" only sounds scary if you don't have backups
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] OMAP3 Beagle: add nand support
Can this patch go in as well today?
regards,
Koen
Op 11 jun 2008, om 20:19 heeft Steve Sakoman het volgende geschreven:
Add nand support to omap3beagle
Signed-off-by: Steve Sakoman <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/Makefile |3
arch/arm/mach-omap2/board-omap3beagle-flash.c | 119
++
arch/arm/mach-omap2/board-omap3beagle.c |1
include/asm-arm/arch-omap/board-omap3beagle.h |2
4 files changed, 124 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/
Makefile
index 13d0043..d582b8f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -44,7 +44,8 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
board-omap3evm-flash.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o \
usb-musb.o usb-ehci.o \
- hsmmc.o
+ hsmmc.o \
+ board-omap3beagle-flash.o
obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o \
hsmmc.o \
usb-musb.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle-flash.c b/arch/
arm/mach-omap2/board-omap3beagle-flash.c
new file mode 100644
index 000..5346df0
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3beagle-flash.c
@@ -0,0 +1,119 @@
+/*
+ * board-omap3beagle-flash.c
+ *
+ * Copyright (c) 2008 Texas Instruments
+ *
+ * Modified from board-omap3evm-flash.c
+ *
+ * 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
+
+#define GPMC_CS0_BASE 0x60
+#define GPMC_CS_SIZE 0x30
+
+static struct mtd_partition omap3beagle_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = "X-Loader",
+ .offset = 0,
+ .size = 4*(64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = "U-Boot",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 15*(64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = "U-Boot Env",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x26 */
+ .size = 1*(64 * 2048),
+ },
+ {
+ .name = "Kernel",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 32*(64 * 2048),
+ },
+ {
+ .name = "File System",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct omap_nand_platform_data omap3beagle_nand_data = {
+ .parts = omap3beagle_nand_partitions,
+ .nr_parts = ARRAY_SIZE(omap3beagle_nand_partitions),
+ .dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .nand_setup = NULL,
+ .dev_ready = NULL,
+};
+
+static struct resource omap3beagle_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device omap3beagle_nand_device = {
+ .name = "omap2-nand",
+ .id = -1,
+ .dev= {
+ .platform_data = &omap3beagle_nand_data,
+ },
+ .num_resources = 1,
+ .resource = &omap3beagle_nand_resource,
+};
+
+
+void __init omap3beagle_flash_init(void)
+{
+ u8 cs = 0;
+ u8 nandcs = GPMC_CS_NUM + 1;
+
+ u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
+
+ /* find out the chip-select on which NAND exists */
+ while (cs < GPMC_CS_NUM) {
+ u32 ret = 0;
+ ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+ if ((ret & 0xC00) == 0x800) {
+ printk(KERN_INFO "Found NAND on CS%d\n", cs);
+ if (nandcs > GPMC_CS_NUM)
+ nandcs = cs;
+ }
+ cs++;
+ }
+
+ if (nandcs > GPMC_CS_NUM) {
+ printk(KERN_INFO "NAND: Unable to find configuration "
+"in GPMC\n ");
+ return;
+ }
+
+ if (nandcs < GPMC_CS_NUM) {
+ omap3beagle_nand_data.cs = nandcs;
+ omap3beagle_nand_data.gpmc_cs_baseaddr = (void *)
+
RE: [PATCH] MUSB: Workaround for simultaneous TX and RX usage
> On Mon, Aug 04, 2008 at 06:48:22PM +0530, ext Gadiyar, Anand wrote: > > MUSB RTL v1.4 has a hardware issue which results in a DMA controller > > hang when TX and RX DMA channels are simultaneously enabled. This > > affects at least OMAP2430 and OMAP34XX. > > > > Since RX transfers are in Mode 0 and anyway result in one DMA interrupt > > per packet, we can use System DMA to unload the RX fifos. MUSB DMA can > > be used for all TX channels as before. > > > > Tested with full-duplex TX and RX transfers using g_ether. Runs for 24 > > hours without a hang. Without this patch, the hang occurs within minutes. > > This patch is not applying against linux-omap musb neither musb on > greg's queue. Could you please refresh it ? It's better to use the > version on greg's queue, if it fails for linux-omap I can prepare a > clean patch to avoid conflicts later. > > -- > balbi > Okay! I had prepared this Friday evening and it seemed to apply for me. I'll check again and re-send. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/07][GIT 3/4+] Removing bridge compilation flags
Remove the compilation flags to make Dynamic loader optimizations default in the code. Modified Kbuild so these flags are not defined anymore. --- Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/dbtype.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/dbtype.h 2008-07-30 00:46:15.0 -0500 +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/dbtype.h2008-07-30 00:46:32.0 -0500 @@ -101,10 +101,6 @@ #define CDECL -#define WINAPI - -#define STDCALL - #define DLLIMPORT #define DLLEXPORT Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/dynamic_loader.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/dynamic_loader.h 2008-07-30 00:46:15.0 -0500 +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/dynamic_loader.h 2008-07-30 00:46:32.0 -0500 @@ -19,11 +19,7 @@ #ifndef _DYNAMIC_LOADER_H_ #define _DYNAMIC_LOADER_H_ #include -#ifndef __KERNEL__ -#include -#else #include -#endif /* * Dynamic Loader @@ -100,7 +96,7 @@ /* the returned module handle*/ DLOAD_mhandle *mhandle ); -#ifdef OPT_ELIMINATE_EXTRA_DLOAD + /* * Procedure Dynamic_Open_Module * @@ -137,7 +133,6 @@ /* the returned module handle */ DLOAD_mhandle *mhandle ); -#endif /* * Procedure Dynamic_Unload_Module @@ -341,29 +336,15 @@ LDR_ADDR load_addr; /* load address of the section */ LDR_ADDR size; /* size of the section in addressable units */ #ifndef _BIG_ENDIAN -#ifdef __KERNEL__ u16 page; /* memory page or view */ u16 type; /* one of the section types below */ #else - uint16_t page; /* memory page or view */ - uint16_t type; /* one of the section types below */ -#endif -#else -#ifdef __KERNEL__ u16 type; /* one of the section types below */ u16 page; /* memory page or view */ -#else - uint16_t type; /* one of the section types below */ - uint16_t page; /* memory page or view */ -#endif #endif /* a context field for use by Dynamic_Loader_Allocate; * ignored but maintained by the dynamic loader */ -#ifdef __KERNEL__ u32 context; -#else - uintptr_t context; -#endif } ; /* use this macro to extract type of section from LDR_SECTION_INFO.type field */ Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/host_os.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/host_os.h 2008-07-30 00:46:15.0 -0500 +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/host_os.h 2008-07-30 00:46:32.0 -0500 @@ -27,8 +27,6 @@ #ifndef _HOST_OS_H_ #define _HOST_OS_H_ -#ifdef __KERNEL__ - #include #include #include @@ -55,9 +53,9 @@ #include #include #include +#include /* #include */ - #if defined(OMAP_2430) || defined(OMAP_3430) #include #ifdef OMAP_3430 @@ -76,28 +74,10 @@ #define SEEK_CUR1 /* Seek from current position. */ #define SEEK_END2 /* Seek from end of file. */ - /* TODO -- Remove, once BP defines them */ #ifdef OMAP_3430 #define INT_MAIL_MPU_IRQ26 #define INT_DSP_MMU_IRQ28 #endif - -#else - -#include -#include -#include -#include -#include - -#include -#include -#include -#include -#endif - -#include - #endif Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/mem.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/mem.h 2008-07-30 00:46:15.0 -0500 +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/mem.h 2008-07-30 00:46:32.0 -0500 @@ -89,11 +89,7 @@ * The returned pointer, if not NULL, points to a valid memory block of * the size requested. */ -#ifdef __KERNEL__ extern void *MEM_Alloc(IN u32 cBytes, IN enum MEM_POOLATTRS type); -#else -#define MEM_Alloc(size, type) malloc(size) -#endif /* * MEM_AllocObject @@ -203,11 +199,7 @@ * Ensures: * pMemBuf is no longer a valid pointer to memory. */ -#ifdef __KERNEL__ extern void MEM_Free(IN void *pMemBuf); -#else -#define MEM_Free(ptr) free(ptr) -#endif /* * MEM_FreePhysMem Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/src/Kbuild === --- omapkernel.orig/drivers/dsp/ds
[PATCH 07/07][GIT 3/4+] Renaming CFG_GetC55Procs
Renaming CFG_GetC55Procs function for a more proper name (CFG_GetDSPProcs) and
removed redundant initialization statements.
---
Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/cfg.h
===
--- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/cfg.h 2008-07-29
23:52:55.0 -0500
+++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/cfg.h 2008-07-29
23:56:40.0 -0500
@@ -337,6 +337,6 @@
*/
extern DSP_STATUS CFG_SetObject(IN u32 dwValue, IN u32 dwType);
- extern DSP_STATUS CFG_GetC55Procs(OUT u32 *numProcs);
+ extern DSP_STATUS CFG_GetDSPProcs(OUT u32 *numProcs);
#endif /* CFG_ */
Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/src/rmgr/dspdrv.c
===
--- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/src/rmgr/dspdrv.c
2008-07-29 23:56:26.0 -0500
+++ omapkernel/drivers/dsp/dspbridge/mpu_driver/src/rmgr/dspdrv.c
2008-07-29 23:56:40.0 -0500
@@ -156,7 +156,7 @@
goto func_cont;
} /* End DRV_Create */
GT_0trace(curTrace, GT_5CLASS, "DSP_Init:DRV Created \r\n");
- status = CFG_GetC55Procs(&numProcs);
+ status = CFG_GetDSPProcs(&numProcs);
GT_1trace(curTrace, GT_5CLASS, "DSP_Init:C55 procs configured = %d\n",
numProcs);
if (DSP_SUCCEEDED(status) & numProcs) {
Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/src/services/cfg.c
===
--- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/src/services/cfg.c
2008-07-29 23:52:26.0 -0500
+++ omapkernel/drivers/dsp/dspbridge/mpu_driver/src/services/cfg.c
2008-07-29 23:56:40.0 -0500
@@ -485,16 +485,15 @@
}
/*
- * ===CFG_GetC55Procs
+ * ===CFG_GetDSPProcs
* Purpose:
* Get the number of configured C55 processors
*/
-DSP_STATUS CFG_GetC55Procs(OUT u32 *numProcs)
+DSP_STATUS CFG_GetDSPProcs(OUT u32 *numProcs)
{
DSP_STATUS status = DSP_SOK;
- *numProcs = 0;
*numProcs = 1;
return status;
}
---
Regards,
omar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/07][GIT 3/4+] Removed bridge unused files
Deleted unused headers, updating include references to avoid compilation errors. Deleted c files and moving their functions to a more proper location. Updating Kbuild file with these changes. --- Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/cfg.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/cfg.h 2008-07-29 23:44:28.0 -0500 +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/cfg.h 2008-07-29 23:52:55.0 -0500 @@ -65,7 +65,6 @@ #ifndef CFG_ #define CFG_ -#include #include #include Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/clk.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/clk.h 2008-07-29 23:52:26.0 -0500 +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/clk.h 2008-07-29 23:52:55.0 -0500 @@ -26,8 +26,6 @@ #ifndef _CLK_H #define _CLK_H -#include - /* Generic TIMER object: */ /*typedef struct TIMER_OBJECT *TIMER_HOBJECT;*/ struct TIMER_OBJECT; Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/cmm.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/cmm.h 2008-07-29 23:52:26.0 -0500 +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/cmm.h 2008-07-29 23:52:55.0 -0500 @@ -68,7 +68,6 @@ #define CMM_ #include -#include #include Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/csl.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/csl.h 2008-07-29 23:44:28.0 -0500 +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/csl.h 2008-07-29 23:52:55.0 -0500 @@ -56,10 +56,8 @@ #ifndef CSL_ #define CSL_ -#include #include - /* * CSL_Atoi * Purpose: Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/dbapi.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/dbapi.h 2008-07-29 23:44:28.0 -0500 +++ /dev/null 1970-01-01 00:00:00.0 + @@ -1,48 +0,0 @@ -/* - * dspbridge/mpu_driver/inc/dbapi.h - * - * DSP-BIOS Bridge driver support functions for TI OMAP processors. - * - * Copyright (C) 2008 Texas Instruments, Inc. - * - * This package is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR - * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED - * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. - */ - -/* - * dbapi.h - * Description: - * Top level header file for GPP side DSP/BIOS Bridge APIs. - * - *! Revision History: - *! - *! 22-Nov-2002 gp Cleaned up comments, formatting. - *! 13-Feb-2001 kc: Name changed from ddspapi.h to dbapi.h. - *! 27-Jun-2000 rr: Name changed to ddspapi.h. Broken into various h files. - *! 12-May-2000 gp: Removed PROC_UNKNOWN state. Moved OEM DSPProcessor_ fxns - *! to ddspoem.h. Changed DDSP_MSG to be fixed length; - *! Changed DDSPStream_Issue/Reclaim to take u32 dwArg. - *! 11-May-2000 gp: Reformatted; converted tabs to spaces; changed NODEHANDLE - *! to HNODE; changed GUID to UUID; added "Detail" sections - *! documenting differences from DDSP API spec. (ver. 0.6); - *! enhanced comments. - *! 19-Apr-2000 ww: Updated based on code review. - *! 12-Apr-2000 ww: Created based on DSP/BIOS Bridge API specification, Ver 0.6. - */ - -#ifndef DBAPI_ -#define DBAPI_ - -#include /* DSP/BIOS Bridge global definitions and constants */ -#include/* DSP/BIOS Bridge status and error codes */ -#include /* DSP/BIOS Bridge Manager APIs */ -#include /* DSP/BIOS Bridge Processor APIs */ -#include/* DSP/BIOS Bridge Node APIs*/ -#include /* DSP/BIOS Bridge Stream APIs */ - -#endif /* DBAPI_ */ Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/dbg.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/dbg.h 2008-07-29 23:44:28.0 -0500 +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/dbg.h 2008-07-29 23:52:55.0 -0500 @@ -40,7 +40,6 @@ #ifndef DBG_ #define DBG_ -#include #include /* Levels of trace debug messages: */ Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/ddmatypes.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/ddmatypes.h 20
[PATCH 04/07][GIT 3/4+] Removed bridge obsolete code
This patch removes the code that is not used by any component of bridge driver. --- Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/brddefs.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/brddefs.h 2008-07-29 23:44:27.0 -0500 +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/brddefs.h 2008-07-29 23:53:12.0 -0500 @@ -46,12 +46,6 @@ #define BRD_RETENTION 0x8 /* Retention mode */ #define BRD_DSP_HIBERNATION 0x9 /* DSP initiated hibernation */ -/* platform access options */ -#define BRD_ACCMODIFY0x1 /* modify the board's state */ -#define BRD_ACCSTATUS0x2 /* monitor changes in board status */ -#define BRD_ACCEXCLUSIVE 0x80 /* exclusive ownership of board */ -#define BRD_ACCMASK(~0x83) - typedef u32 BRD_STATUS; /* BRD Object */ Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/dev.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/dev.h 2008-07-29 23:52:26.0 -0500 +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/dev.h 2008-07-29 23:53:12.0 -0500 @@ -791,27 +791,6 @@ struct MSG_MGR *hMgr); /* - * DEV_SetLockOwner - * Purpose: - * Sets the lock owner to a particular board interface. - * Parameters: - * hDevObject: Handle to device object created with - * DEV_CreateDevice(). - * hBrdObject: Board interface which owns exclusive modify access to - * the board. - * Returns: - * DSP_SOK:Success. - * DSP_EHANDLE:hDevObject was invalid. - * Requires: - * DEV Initialized. - * Ensures: - * DSP_SOK: Device lock is set. Only this registered board interface - * can alter the device state. - */ - extern DSP_STATUS CDECL DEV_SetLockOwner(struct DEV_OBJECT *hDevObject, -struct BRD_OBJECT *hBrdObject); - -/* * DEV_StartDevice * Purpose: * Initializes the new device with the WinBRIDGE environment. This @@ -829,23 +808,4 @@ */ extern DSP_STATUS CDECL DEV_StartDevice(struct CFG_DEVNODE *hDevNode); -/* - * DEV_StartIVADevice - * Purpose: - * Initializes the new device with the WinBRIDGE environment. This - * involves querying CM for allocated resources, querying the registry - * for necessary IVA resources, and using - * this information to create a WinBRIDGE device object. - * Parameters: - * hDevNode: Device node as it is known to OS. - * Returns: - * DSP_SOK:If success; - * Otherwise. - * Requires: - * DEV initialized. - * Ensures: - */ - extern DSP_STATUS CDECL DEV_StartIVADevice(struct CFG_DEVNODE* - hDevNode); - #endif /* DEV_ */ Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/wcdioctl.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/wcdioctl.h 2008-07-29 23:52:26.0 -0500 +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/wcdioctl.h 2008-07-29 23:53:12.0 -0500 @@ -515,21 +515,4 @@ #define CMD_CMM_GETINFO_OFFSET (CMD_CMM_BASE_OFFSET + 3) #define CMD_CMM_END_OFFSET CMD_CMM_GETINFO_OFFSET -/* MEMRY module offsets */ -#define CMD_MEM_BASE_OFFSET (CMD_CMM_END_OFFSET + 1) -#define CMD_MEM_ALLOC_OFFSET (CMD_MEM_BASE_OFFSET + 0) -#define CMD_MEM_CALLOC_OFFSET (CMD_MEM_BASE_OFFSET + 1) -#define CMD_MEM_FREE_OFFSET (CMD_MEM_BASE_OFFSET + 2) -#define CMD_MEM_PAGELOCK_OFFSET (CMD_MEM_BASE_OFFSET + 3) -#define CMD_MEM_PAGEUNLOCK_OFFSET (CMD_MEM_BASE_OFFSET + 4) -#define CMD_MEM_END_OFFSET CMD_MEM_PAGEUNLOCK_OFFSET - -/* UTIL module */ -#define CMD_UTIL_BASE_OFFSET (CMD_MEM_END_OFFSET + 1) -#define CMD_UTIL_TESTDLL_OFFSET (CMD_UTIL_BASE_OFFSET + 0) -#define CMD_UTIL_END_OFFSET CMD_UTIL_TESTDLL_OFFSET - -/* !!! place all command modules before CMD_BASE_END_OFFSET */ -#define CMD_BASE_END_OFFSET CMD_UTIL_END_OFFSET - #endif /* WCDIOCTL_ */ Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/wmdioctl.h === --- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/inc/wmdioctl.h 2008-07-29 23:52:26.0 -0500 +++ omapkernel/drivers/dsp/dspbridge/mpu_driver/inc/wmdioctl.h 2008-07-29 23:53:12.0 -0500 @@ -47,7 +47,6 @@ /* Any IOCTLS at or above this value are reserved for standard WMD interfaces.*/ #define WMDIOCTL_RESERVEDBASE 0x8000 -#define WMDIOCTL_BIOSSCOPEBASE (WMDIOCTL_RESERVEDBASE + 0x100) #define WMDIOCTL_CHNLREAD (WMD
[PATCH 02/07][GIT 3/4+] Fixing driver compilation warnings
Code cleanup minor changes to fix some compilation warnings.
- Indent style changes
- Fixed undefined LEAD3 compilation flag
- Fixed ISO C90 forbids mixed declarations and code
- Fixed unused variables
---
Index: omapkernel/drivers/dsp/dspbridge/mpu_driver/src/dynload/cload.c
===
--- omapkernel.orig/drivers/dsp/dspbridge/mpu_driver/src/dynload/cload.c
2008-07-29 23:52:26.0 -0500
+++ omapkernel/drivers/dsp/dspbridge/mpu_driver/src/dynload/cload.c
2008-07-29 23:52:46.0 -0500
@@ -41,12 +41,6 @@
#if BITS_PER_AU > BITS_PER_BYTE
static char *unpack_name(struct dload_state *dlthis, u32 soffset);
#endif
-#if LEAD3
-static boolean chk_revision_mix(struct dload_state *dlthis, const char *sname);
-static boolean chk_memmodel_mix(struct dload_state *dlthis,
- const struct doff_syment_t *sym, const struct dynload_symbol
- *defSym, const char *sname);
-#endif
static const char CINITNAME[] = { ".cinit" };
static const char LOADER_DLLVIEW_ROOT[] = { "?DLModules?" };
@@ -832,13 +826,6 @@
}
val += delta;
}
-#if LEAD3
- if (is_data_scn_num(sp->secnn)) {
- /* adjust for 16-bit data addresses */
- delta >>= 1;
- val >>= 1;
- }
-#endif
goto loop_itr;
}
/* This symbol is an absolute symbol */
@@ -847,28 +834,9 @@
struct dynload_symbol *symp;
symp = dlthis->mysym->Find_Matching_Symbol
(dlthis->mysym, sname);
- if (!symp) {
-#if LEAD3
- /* This absolute symbol is not already
-* defined. Check for revision clash
-* before proceeding. */
- if (chk_revision_mix(dlthis, sname)) {
- /* If revision IDs are mixed,
-* return */
- return;
- }
-#endif
+ if (!symp)
goto loop_itr;
- }
/* This absolute symbol is already defined. */
-#if LEAD3
- /* Check for memory model mixing */
- if (chk_memmodel_mix(dlthis, input_sym,
- symp, sname)) {
- /* If memory models are mixed, return */
- return;
- }
-#endif
if (symp->value == input_sym->dn_value) {
/* If symbol values are equal, continue
* but don't add to the global symbol
@@ -1165,15 +1133,9 @@
s32 nip;
LDR_ADDR image_offset = 0;
/* set relocation info for this section */
- if (curr_sect < dlthis->allocated_secn_count) {
+ if (curr_sect < dlthis->allocated_secn_count)
dlthis->delta_runaddr = sptr->ds_paddr;
-#if LEAD3
- if (is_data_scn(lptr)) {
- /* word-addressed data */
- dlthis->delta_runaddr >>= 1;
- }
-#endif
- } else {
+ else {
lptr = DOFFSEC_IS_LDRSEC(sptr);
dlthis->delta_runaddr = 0;
}
@@ -1658,18 +1620,8 @@
dbsec = dbmod->sects;
for (curr_sect = dlthis->allocated_secn_count;
curr_sect > 0; curr_sect -= 1) {
-#if LEAD3
-#define LEAD3_DATA_FLAG (3UL << 30)
- if (is_data_scn(asecs)) {
- dbsec->sect_load_adr = asecs->load_addr >> 1;
- dbsec->sect_run_adr = (asecs->run_addr >> 1) |
- LEAD3_DATA_FLAG;
- } else
-#endif
- {
- dbsec->sect_load_adr = asecs->load_addr;
- dbsec->sect_run_adr = asecs->run_addr;
- }
+ dbsec->sect_load_adr = asecs->load_addr;
+ dbsec->sect_run_adr = asecs->run_addr;
db
Re: [i2c] N800 problems with MMC, LM8323 on current linux-omap git head
* Felipe Balbi <[EMAIL PROTECTED]> [080723 13:13]: > > > On Wed, 23 Jul 2008 12:38:49 +0300, Riku Voipio <[EMAIL PROTECTED]> wrote: > > Indeed - compared to my previous version, this one makes the boardfile > > even smaller: > > > >textdata bss dec hex filename > >23621552 43918 f4e > > old/arch/arm/mach-omap2/board-n800.o > >23541456 43814 ee6 > > new/arch/arm/mach-omap2/board-n800.o > > Cool :-) Pushing to linux-omap tree. Tony > Acked-by: Felipe Balbi <[EMAIL PROTECTED]> > > -- > Best Regards, > > Felipe Balbi > http://blog.felipebalbi.com > [EMAIL PROTECTED] > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] twl4030-madc: Fix arbitrarily initialized function pointer
* Viktor Rosendahl <[EMAIL PROTECTED]> [080703 18:37]:
>
> >
> > > + req.func_cb = NULL;
> >
> > maybe below is a better patch:
> >
> > diff --git a/drivers/i2c/chips/twl4030-madc.c
> > b/drivers/i2c/chips/twl4030-madc.c
> > index 72b126b..6d8915e 100644
> > --- a/drivers/i2c/chips/twl4030-madc.c
> > +++ b/drivers/i2c/chips/twl4030-madc.c
> > @@ -360,7 +360,7 @@ static int twl4030_madc_ioctl(struct inode *inode,
> > struct file *filp,
> >
> > switch (cmd) {
> > case TWL4030_MADC_IOCX_ADC_RAW_READ: {
> > - struct twl4030_madc_request req;
> > + static struct twl4030_madc_request req;
> > if (par.channel >= TWL4030_MADC_MAX_CHANNELS)
> > return -EINVAL;
>
> I don't like this idea because:
>
> - It's fragile. This struct, which is not a const, gets initialized only
> once but we are still passing a pointer to it, expecting that a fairly
> complex function will not modify it. This assertion is probably true
> today but makes it easier for somebody to create a bug in the future.
>
> - You introduce another shared datum and it is only protected by the BKL
> in fs/ioctl.c:vfs_ioctl().
>
> - I didn't see any argument why this variable should be static. Making
> local variables static just to get cheap zero initialization is a weird
> thing to do IMO.
Pushing the original patch.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 CPUidle patches - fixes
* Rajendra Nayak <[EMAIL PROTECTED]> [080703 14:55]:
> This patch fixes few of the comments posted on the patch set till now.
>
> One major fix is the moving of uart clock enable/disable out of the context
> save path as pointed out by Jouni.
> This would leave the UART clcoks disabled in case a CORE OFF was attempted
> and not achieved.
What kernel or patch series this is against? If it's for some patch
series that's not applied yet to linux-omap tree, let's merge the fix
to the original patch.
Tony
> Signed-off-by: Rajendra Nayak <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 56
> ++
> 1 files changed, 22 insertions(+), 34 deletions(-)
>
> Index: linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c
> ===
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/cpuidle34xx.c 2008-07-03
> 10:50:04.0 +0530
> +++ linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c 2008-07-03
> 13:11:13.435048828 +0530
> @@ -405,9 +405,7 @@ void omap3_save_core_ctx(void)
> /* Save the system control module context, padconf already save above*/
> omap_save_control_ctx();
> omap_save_uart_ctx(0);
> - omap_serial_enable_clocks(0, 0);
> omap_save_uart_ctx(1);
> - omap_serial_enable_clocks(0, 1);
> }
>
> void omap3_restore_core_ctx(void)
> @@ -418,9 +416,7 @@ void omap3_restore_core_ctx(void)
> omap_restore_gpmc_ctx();
> /* Restore the interrupt controller context */
> omap_restore_intc_ctx();
> - omap_serial_enable_clocks(1, 0);
> omap_restore_uart_ctx(0);
> - omap_serial_enable_clocks(1, 1);
> omap_restore_uart_ctx(1);
> padconf_saved = 0;
> }
> @@ -472,28 +468,27 @@ static int omap3_enter_idle(struct cpuid
>
> /* Program MPU to target state */
> if (cx->mpu_state < PWRDM_POWER_ON) {
> - if (neon_pwrst == PWRDM_POWER_ON) {
> - if (cx->mpu_state == PWRDM_POWER_RET)
> - pwrdm_set_next_pwrst(neon_pd, PWRDM_POWER_RET);
> - else if (cx->mpu_state == PWRDM_POWER_OFF)
> - pwrdm_set_next_pwrst(neon_pd, PWRDM_POWER_OFF);
> - }
> + pwrdm_set_next_pwrst(neon_pd, cx->mpu_state);
> pwrdm_set_next_pwrst(mpu_pd, cx->mpu_state);
> }
>
> /* Program CORE and PER to target state */
> if (cx->core_state < PWRDM_POWER_ON) {
> - if (per_pwrst == PWRDM_POWER_ON) {
> - omap2_gpio_prepare_for_retention();
> - if (clocks_off_while_idle) {
> - omap3_save_per_ctx();
> - per_gpio_clk_disable();
> - omap_save_uart_ctx(2);
> - omap_serial_enable_clocks(0, 2);
> - }
> + omap2_gpio_prepare_for_retention();
> + if (clocks_off_while_idle) {
> + omap3_save_per_ctx();
> + per_gpio_clk_disable();
> + omap_save_uart_ctx(2);
> + omap_serial_enable_clocks(0, 2);
> }
> if (cx->core_state == PWRDM_POWER_OFF)
> omap3_save_core_ctx();
> + /* Disable UART1/UART2 clocks here. Done using direct register
> + * writes as using clock f/w calls results in a hang in prcm_
> + * interrupt_handler trying to clear WKST for CORE
> + */
> + cm_clear_mod_reg_bits(0x6000, CORE_MOD, CM_ICLKEN1);
> + cm_clear_mod_reg_bits(0x6000, CORE_MOD, CM_FCLKEN1);
> pwrdm_set_next_pwrst(core_pd, cx->core_state);
> }
>
> @@ -507,14 +502,9 @@ static int omap3_enter_idle(struct cpuid
>
> *(scratchpad_restore_addr) = 0x0;
>
> - /* Program MPU/NEON to ON */
> - if (cx->mpu_state < PWRDM_POWER_ON) {
> - if (neon_pwrst == PWRDM_POWER_ON)
> - pwrdm_set_next_pwrst(neon_pd, PWRDM_POWER_ON);
> - pwrdm_set_next_pwrst(mpu_pd, PWRDM_POWER_ON);
> - }
> -
> if (cx->core_state < PWRDM_POWER_ON) {
> + cm_set_mod_reg_bits(0x6000, CORE_MOD, CM_ICLKEN1);
> + cm_set_mod_reg_bits(0x6000, CORE_MOD, CM_FCLKEN1);
> if ((cx->core_state == PWRDM_POWER_OFF)
> && (pwrdm_read_prev_pwrst(core_pd) == PWRDM_POWER_OFF)) {
> omap3_restore_core_ctx();
> @@ -522,15 +512,13 @@ static int omap3_enter_idle(struct cpuid
> omap3_restore_sram_ctx();
> }
> pwrdm_set_next_pwrst(core_pd, PWRDM_POWER_ON);
> - if (per_pwrst == PWRDM_POWER_ON) {
> - if (clocks_off_while_idle) {
> - omap_serial_enable_clocks(1, 2);
> - omap_restore_uart_ctx(2);
> -
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
* Kamat, Nishant <[EMAIL PROTECTED]> [080703 14:55]: > Hi, > > > > Kyungmin Park on July 02, 2008 4:57 AM, wrote: > > > > Hi, > > > > It's should be sent to MTD list. and we also fix the NOR similar ways. > > It's already posted but not committed. > > > Posting the patch on MTD list. Please merge. Looks like this driver does not exist outside linux-omap tree, care to send the whole driver to MTD list? Pushing this fix to linux-omap tree meanwhile. Tony > ---< Cut here >--- > > From: Nishant Kamat <[EMAIL PROTECTED]> > > This patch fixes the omap2 nand driver code that allows > reading of partition data from board info. > > The parse_mtd_partitions() function no longer returns a > negative error in case cmdline is not passed. > See commit: b0d06afb607 > > Signed-off-by: Nishant Kamat <[EMAIL PROTECTED]> > --- > drivers/mtd/nand/omap2.c |2 +- > 1 files changed, 1 insertion(+), 1 deletion(-) > > Index: linux-omap-ti.ldp/drivers/mtd/nand/omap2.c > === > --- linux-omap-ti.ldp.orig/drivers/mtd/nand/omap2.c 2008-06-30 > 22:01:50.0 +0530 > +++ linux-omap-ti.ldp/drivers/mtd/nand/omap2.c 2008-06-30 22:03:34.446471469 > +0530 > @@ -699,7 +699,7 @@ > err = parse_mtd_partitions(&info->mtd, part_probes, &info->parts, 0); > if (err > 0) > add_mtd_partitions(&info->mtd, info->parts, err); > - else if (err < 0 && pdata->parts) > + else if (pdata->parts) > add_mtd_partitions(&info->mtd, pdata->parts, pdata->nr_parts); > else > #endif -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] TWL4030: convert old-style function documentation to current kerneldoc
* Paul Walmsley <[EMAIL PROTECTED]> [080722 07:19]: > On Fri, 18 Jul 2008, Felipe Balbi wrote: > > > On Thu, 17 Jul 2008 20:15:51 -0600, Paul Walmsley <[EMAIL PROTECTED]> wrote: > > > > + * Results the result of operation - 0 is success > > > I suppose you mean Returns here. > > thanks Felipe, fixed. Are you planning to repost this patch? I can't seem to find any other version.. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] TWL4030 bugfixes and cleanups: version 2
* Paul Walmsley <[EMAIL PROTECTED]> [080723 08:11]: > [ This is the second version of these patches - they now check the > SIH_CTRL.COR bit to determine whether to read or write to clear ] > > At boot, twl_init_irq() tries to mask off all TWL4030 secondary > interrupts and clear them, since no secondary interrupt handlers are > registered yet (that happens later in the boot). > > However, this code is flawed. MADC, BCI, keypad, and GPIO ISRs are > either not cleared or are incompletely cleared. Some BCI register > addresses are nonsensical. And some code attempts to clear ISRs > before masking IMRs, which is race-prone (an interrupt could occur > after the ISR clear, but before the mask). > > These problems can cause large numbers of boot messages similar to > this: > > TWL4030 module irq 368 is disabled but can't be masked! > > and I2C transmit overflows, both observed during boot on the > BeagleBoard here. The actual IRQ number sometimes varied depending on > which interrupt was unacknowledged. > > This series fixes these issues and does some code cleanup, saving 272 > bytes. > > Thanks to Philip Balister <[EMAIL PROTECTED]>, Koen Kooi > <[EMAIL PROTECTED]>, Måns Rullgård <[EMAIL PROTECTED]>, Steve > Sakoman <[EMAIL PROTECTED]> and others on #beagle for help tracing > these problems. > > Thanks also to Peter De Schrijver <[EMAIL PROTECTED]> for > help with this second version, allowing several unnecessary I2C > transactions to be elided from twl_init_irq(). > > Tested on BeagleBoard rev B4 (3530ES2.2). Pushing this series today. Tony > > > - Paul > > --- > > size: >textdata bss dec hex filename > 3076157 142840 104248 3323245 32b56d vmlinux.beagle.orig > 3075885 142840 104248 3322973 32b45d vmlinux.beagle > > diffstat: > > drivers/i2c/chips/twl4030-core.c | 383 > ++-- > drivers/i2c/chips/twl4030-gpio.c | 48 - > drivers/i2c/chips/twl4030-pwrirq.c | 15 + > include/linux/i2c/twl4030-gpio.h | 76 +++ > include/linux/i2c/twl4030-pwrirq.h | 37 +++ > 5 files changed, 359 insertions(+), 200 deletions(-) > create mode 100644 include/linux/i2c/twl4030-gpio.h > create mode 100644 include/linux/i2c/twl4030-pwrirq.h > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MUSB: Workaround for simultaneous TX and RX usage
On Mon, Aug 04, 2008 at 06:48:22PM +0530, ext Gadiyar, Anand wrote: > MUSB RTL v1.4 has a hardware issue which results in a DMA controller > hang when TX and RX DMA channels are simultaneously enabled. This > affects at least OMAP2430 and OMAP34XX. > > Since RX transfers are in Mode 0 and anyway result in one DMA interrupt > per packet, we can use System DMA to unload the RX fifos. MUSB DMA can > be used for all TX channels as before. > > Tested with full-duplex TX and RX transfers using g_ether. Runs for 24 > hours without a hang. Without this patch, the hang occurs within minutes. This patch is not applying against linux-omap musb neither musb on greg's queue. Could you please refresh it ? It's better to use the version on greg's queue, if it fails for linux-omap I can prepare a clean patch to avoid conflicts later. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] i2c-omap: reduce bloat
* Paul Walmsley <[EMAIL PROTECTED]> [080718 04:48]: > Don't compile the OMAP15xx I2C ISR for non-OMAP15xx builds. Also, mark > init-only functions in i2c-omap as __init. > > Boot-tested on OMAP3430SDP ES2. Pushing these today. Tony > > Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]> > > --- > > size: > 3391587 157104 107136 3655827 37c893 vmlinux.3430sdp.orig > 3390339 157104 107136 3654579 37c3b3 vmlinux.3430sdp > > > drivers/i2c/busses/i2c-omap.c | 14 ++ > 1 files changed, 10 insertions(+), 4 deletions(-) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: OneNAND for OMAP3
Hi,
Will push today as this will make the driver more usable. Also few
comments below if you feel like improving things in the long run.
* Adrian Hunter <[EMAIL PROTECTED]> [080801 11:10]:
> Update OneNAND support for OMAP3.
>
> Signed-off-by: Adrian Hunter <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/board-n800-flash.c | 240
> arch/arm/mach-omap2/gpmc.c |5 +
> drivers/mtd/onenand/omap2.c| 186 +++--
> include/asm-arm/arch-omap/gpmc.h |4 +
> include/asm-arm/arch-omap/onenand.h|3 +
> include/linux/mtd/onenand_regs.h |2 +
> 6 files changed, 367 insertions(+), 73 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-n800-flash.c
> b/arch/arm/mach-omap2/board-n800-flash.c
> index f7403b9..cd98be5 100644
> --- a/arch/arm/mach-omap2/board-n800-flash.c
> +++ b/arch/arm/mach-omap2/board-n800-flash.c
> @@ -19,13 +19,17 @@
> #include
> #include
>
> -static struct mtd_partition n800_partitions[8];
> +struct mtd_partition n800_partitions[ONENAND_MAX_PARTITIONS];
>
> static int n800_onenand_setup(void __iomem *, int freq);
>
> static struct omap_onenand_platform_data n800_onenand_data = {
> .cs = 0,
> +#ifdef CONFIG_ARCH_OMAP3430
> + .gpio_irq = 65,
> +#else
> .gpio_irq = 26,
> +#endif
> .parts = n800_partitions,
> .nr_parts = 0, /* filled later */
> .onenand_setup = n800_onenand_setup,
The gpio number is board specific, so that information should come
in platform_data from board-*.c files.
> @@ -39,6 +43,55 @@ static struct platform_device n800_onenand_device = {
> },
> };
>
> +static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
> +{
> + struct gpmc_timings t;
> +
> + const int t_cer = 15;
> + const int t_avdp = 12;
> + const int t_aavdh = 7;
> + const int t_ce = 76;
> + const int t_aa = 76;
> + const int t_oe = 20;
> + const int t_cez = 20; /* max of t_cez, t_oez */
> + const int t_ds = 30;
> + const int t_wpl = 40;
> + const int t_wph = 30;
> +
> + memset(&t, 0, sizeof(t));
> + t.sync_clk = 0;
> + t.cs_on = 0;
> + t.adv_on = 0;
> +
> + /* Read */
> + t.adv_rd_off = gpmc_round_ns_to_ticks(max_t(int, t_avdp, t_cer));
> + t.oe_on = t.adv_rd_off + gpmc_round_ns_to_ticks(t_aavdh);
> + t.access = t.adv_on + gpmc_round_ns_to_ticks(t_aa);
> + t.access = max_t(int, t.access, t.cs_on + gpmc_round_ns_to_ticks(t_ce));
> + t.access = max_t(int, t.access, t.oe_on + gpmc_round_ns_to_ticks(t_oe));
> + t.oe_off = t.access + gpmc_round_ns_to_ticks(1);
> + t.cs_rd_off = t.oe_off;
> + t.rd_cycle = t.cs_rd_off + gpmc_round_ns_to_ticks(t_cez);
> +
> + /* Write */
> + t.adv_wr_off = t.adv_rd_off;
> + t.we_on = t.oe_on;
> +#ifdef CONFIG_ARCH_OMAP3430
> + t.wr_data_mux_bus = t.we_on;
> + t.wr_access = t.we_on + gpmc_round_ns_to_ticks(t_ds);
> +#endif
> + t.we_off = t.we_on + gpmc_round_ns_to_ticks(t_wpl);
> + t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(t_wph);
> + t.wr_cycle = t.cs_wr_off + gpmc_round_ns_to_ticks(t_cez);
> +
> + /* Configure GPMC for asynchronous read */
> + gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
> + GPMC_CONFIG1_DEVICESIZE_16 |
> + GPMC_CONFIG1_MUXADDDATA);
> +
> + return gpmc_cs_set_timings(cs, &t);
> +}
> +
> static unsigned short omap2_onenand_readw(void __iomem *addr)
> {
> return readw(addr);
How about using cpu_is_omap34xx() instead of the ifdefs where possible
through the code? It should be possible to compile in support for 24xx
and 34xx to the same kernel soonish.
Tony
> @@ -49,54 +102,124 @@ static void omap2_onenand_writew(unsigned short value,
> void __iomem *addr)
> writew(value, addr);
> }
>
> +static void set_onenand_cfg(void __iomem *onenand_base, int latency,
> + int sync_write, int hf)
> +{
> + u32 reg;
> +
> + reg = omap2_onenand_readw(onenand_base + ONENAND_REG_SYS_CFG1);
> + reg &= ~((0x7 << ONENAND_SYS_CFG1_BRL_SHIFT) | (0x7 << 9));
> + reg |= (latency << ONENAND_SYS_CFG1_BRL_SHIFT) |
> + ONENAND_SYS_CFG1_SYNC_READ |
> + ONENAND_SYS_CFG1_BL_16;
> + if (sync_write)
> + reg |= ONENAND_SYS_CFG1_SYNC_WRITE;
> + else
> + reg &= ~ONENAND_SYS_CFG1_SYNC_WRITE;
> + if (hf)
> + reg |= ONENAND_SYS_CFG1_HF;
> + else
> + reg &= ~ONENAND_SYS_CFG1_HF;
> + omap2_onenand_writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
> +}
> +
> static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
> int freq)
> {
> struct gpmc_timings t;
> - int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_avdp, t_wpl, t_wea;
> + const int t_cer = 15;
> + const int t_avdp = 12;
> + const int t_cez = 20; /* max of t_cez, t_oez */
> +#ifdef CONFIG_A
Re: [PATCH] i2c-omap: close suspected race between omap_i2c_idle() and omap_i2c_isr()
* Paul Walmsley <[EMAIL PROTECTED]> [080715 22:04]:
>
> omap_i2c_idle() sets an internal flag, "dev->idle", instructing its
> ISR to decline interrupts. It sets this flag before it actually masks
> the interrupts on the I2C controller. This is problematic, since an
> I2C interrupt could arrive after dev->idle is set, but before the
> interrupt source is masked. When this happens, Linux disables the I2C
> controller's IRQ, causing all future transactions on the bus to fail.
>
> Symptoms, happening on about 7% of boots:
>
>irq 56: nobody cared (try booting with the "irqpoll" option)
>
>Disabling IRQ #56
>i2c_omap i2c_omap.1: controller timed out
>
> In omap_i2c_idle(), this patch sets dev->idle only after the interrupt
> mask write to the I2C controller has left the ARM write buffer.
> That's probably the major offender. For additional prophylaxis, in
> omap_i2c_unidle(), the patch clears the dev->idle flag before
> interrupts are enabled, rather than afterwards.
>
> The patch has survived twenty-two reboots on the 3430SDP here without
> wedging I2C1. Not absolutely dispositive, but promising!
Great, pushing today.
Tony
>
>
> Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
> ---
>
> drivers/i2c/busses/i2c-omap.c | 10 --
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 55779f5..ed7e9ad 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -209,22 +209,28 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
> if (dev->iclk != NULL)
> clk_enable(dev->iclk);
> clk_enable(dev->fclk);
> + dev->idle = 0;
> if (dev->iestate)
> omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
> - dev->idle = 0;
> }
>
> static void omap_i2c_idle(struct omap_i2c_dev *dev)
> {
> u16 iv;
>
> - dev->idle = 1;
> dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
> omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
> if (dev->rev1)
> iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG);
> else
> omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
> + /*
> + * The wmb() is to ensure that the I2C interrupt mask write
> + * reaches the I2C controller before the dev->idle store
> + * occurs.
> + */
> + wmb();
> + dev->idle = 1;
> clk_disable(dev->fclk);
> if (dev->iclk != NULL)
> clk_disable(dev->iclk);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add option for DSP bridge debugging.
--- drivers/dsp/dspbridge/Kconfig |3 +++ drivers/dsp/dspbridge/mpu_driver/src/Kbuild |2 +- 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/dsp/dspbridge/Kconfig b/drivers/dsp/dspbridge/Kconfig index 5d5622d..580c148 100644 --- a/drivers/dsp/dspbridge/Kconfig +++ b/drivers/dsp/dspbridge/Kconfig @@ -29,4 +29,7 @@ config BRIDGE_PM DSP Bridge employs power management techniques to save dynamic and static power consumption of the IVA sub system. +config BRIDGE_DEBUG + bool "DSP Bridge Debug Support" + endif diff --git a/drivers/dsp/dspbridge/mpu_driver/src/Kbuild b/drivers/dsp/dspbridge/mpu_driver/src/Kbuild index b6ad62a..62ca643 100644 --- a/drivers/dsp/dspbridge/mpu_driver/src/Kbuild +++ b/drivers/dsp/dspbridge/mpu_driver/src/Kbuild @@ -33,7 +33,7 @@ ccflags-y = -DDISABLE_BRIDGE_PM endif # Debug -ifeq ($(CONFIG_DEBUG_KERNEL),y) +ifeq ($(CONFIG_BRIDGE_DEBUG),y) ccflags-y += -DGT_TRACE -DDEBUG endif -- 1.5.6.2.1.g1a51b -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] MUSB: Workaround for simultaneous TX and RX usage
MUSB RTL v1.4 has a hardware issue which results in a DMA controller
hang when TX and RX DMA channels are simultaneously enabled. This
affects at least OMAP2430 and OMAP34XX.
Since RX transfers are in Mode 0 and anyway result in one DMA interrupt
per packet, we can use System DMA to unload the RX fifos. MUSB DMA can
be used for all TX channels as before.
Tested with full-duplex TX and RX transfers using g_ether. Runs for 24
hours without a hang. Without this patch, the hang occurs within minutes.
Signed-off-by: Anand Gadiyar <[EMAIL PROTECTED]>
---
This issue was first reported by Jon Hunter on [1]
[1] http://marc.info/?l=linux-omap&m=119634480534453&w=2
drivers/usb/musb/Kconfig |8 +
drivers/usb/musb/musbhsdma.c | 174 +++
2 files changed, 153 insertions(+), 29 deletions(-)
Index: testing/drivers/usb/musb/musbhsdma.c
===
--- testing.orig/drivers/usb/musb/musbhsdma.c
+++ testing/drivers/usb/musb/musbhsdma.c
@@ -34,6 +34,7 @@
#include
#include
#include "musb_core.h"
+#include
#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3430)
#include "omap2430.h"
@@ -64,6 +65,9 @@
#define MUSB_HSDMA_CHANNELS8
+#define MUSB_FIFO_ADDRESS(epnum) \
+ ((unsigned long) (OMAP_HSOTG_BASE + MUSB_FIFO_OFFSET(epnum)))
+
struct musb_dma_controller;
struct musb_dma_channel {
@@ -75,6 +79,10 @@ struct musb_dma_channel {
u8 bIndex;
u8 epnum;
u8 transmit;
+
+#ifdef CONFIG_MUSB_USE_SYSTEM_DMA_RX
+ int sysdma_channel;
+#endif
};
struct musb_dma_controller {
@@ -93,6 +101,10 @@ static int dma_controller_start(struct d
return 0;
}
+#ifdef CONFIG_MUSB_USE_SYSTEM_DMA_RX
+static void musb_sysdma_completion(int lch, u16 ch_status, void *data);
+#endif
+
static void dma_channel_release(struct dma_channel *pChannel);
static int dma_controller_stop(struct dma_controller *c)
@@ -144,6 +156,30 @@ static struct dma_channel *dma_channel_a
/* Tx => mode 1; Rx => mode 0 */
pChannel->desired_mode = transmit;
pChannel->actual_len = 0;
+ pImplChannel->sysdma_channel = -1;
+
+#ifdef CONFIG_MUSB_USE_SYSTEM_DMA_RX
+ if (!transmit) {
+ int ret;
+ ret = omap_request_dma(OMAP24XX_DMA_NO_DEVICE,
+ "MUSB SysDMA", musb_sysdma_completion,
+ (void *) pImplChannel,
+ &(pImplChannel->sysdma_channel));
+/* FIXME: Decide on the correct private data to use */
+
+ if (ret) {
+ printk(KERN_ERR "request_dma failed:"
+ " %d\n", ret);
+ controller->bmUsedChannels &=
+ ~(1 << bBit);
+ pChannel->status =
+ MUSB_DMA_STATUS_UNKNOWN;
+ pImplChannel->sysdma_channel = -1;
+ pChannel = NULL;
+ }
+ }
+#endif
+
break;
}
}
@@ -163,6 +199,14 @@ static void dma_channel_release(struct d
~(1 << pImplChannel->bIndex);
pChannel->status = MUSB_DMA_STATUS_UNKNOWN;
+
+#ifdef CONFIG_MUSB_USE_SYSTEM_DMA_RX
+ if (pImplChannel->sysdma_channel != -1) {
+ omap_stop_dma(pImplChannel->sysdma_channel);
+ omap_free_dma(pImplChannel->sysdma_channel);
+ pImplChannel->sysdma_channel = -1;
+ }
+#endif
}
static void configure_channel(struct dma_channel *pChannel,
@@ -179,43 +223,108 @@ static void configure_channel(struct dma
DBG(4, "%p, pkt_sz %d, addr 0x%x, len %d, mode %d\n",
pChannel, packet_sz, dma_addr, len, mode);
- if (mode) {
- csr |= 1 << MUSB_HSDMA_MODE1_SHIFT;
- BUG_ON(len < packet_sz);
+#ifdef CONFIG_MUSB_USE_SYSTEM_DMA_RX
+ if (pImplChannel->sysdma_channel != -1) {
+ /* System DMA */
+ /* RX: set src = FIFO */
+
+ omap_set_dma_transfer_params(pImplChannel->sysdma_channel,
+ OMAP_DMA_DATA_TYPE_S8,
+ len, 1, /* One frame */
+ OMAP_DMA_SYNC_ELEMENT,
+ OMAP24XX_DMA_NO_DEVICE,
+ 0); /* Src Sync */
+
+ omap_set_dma_src_params(pImplCh
Re: musb fix
* Felipe Balbi <[EMAIL PROTECTED]> [080804 15:23]:
> Hi Tony,
>
> Please before merging with mailine apply the attached patch so musb
> driver won't break compilation.
>
> We now have a standard WARN() macro so to avoid conflicts we change
> musb's WARN() to WARNING.
OK, will push today.
The current plan is that I'll apply all the fixes floaging on l-o list
today and tomorrow and tag v2.6.26-omap1, then will merge with mainline
tree on Wednesday.
Tony
>
> --
> balbi
> From: David Brownell <[EMAIL PROTECTED]>
>
> Latest musb_hdrc code wouldn't:
> * build ... because there's now a standard WARN() macro
> * build without false printf format warnings ... "%zd" is for ssize_t,
> while "%zu" is for size_t
>
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
> Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c
> index e6770d6..e03aa99 100644
> --- a/drivers/usb/musb/cppi_dma.c
> +++ b/drivers/usb/musb/cppi_dma.c
> @@ -862,10 +862,10 @@ cppi_next_rx_segment(struct musb *musb, struct
> cppi_channel *rx, int onepacket)
>
> /* we always expect at least one reusable BD! */
> if (!tail) {
> - WARN("rx dma%d -- no BDs? need %d\n", rx->index, n_bds);
> + WARNING("rx dma%d -- no BDs? need %d\n", rx->index, n_bds);
> return;
> } else if (i < n_bds)
> - WARN("rx dma%d -- only %d of %d BDs\n", rx->index, i, n_bds);
> + WARNING("rx dma%d -- only %d of %d BDs\n", rx->index, i, n_bds);
>
> tail->next = NULL;
> tail->hw_next = 0;
> @@ -963,13 +963,13 @@ static int cppi_channel_program(struct dma_channel *ch,
> case MUSB_DMA_STATUS_BUS_ABORT:
> case MUSB_DMA_STATUS_CORE_ABORT:
> /* fault irq handler should have handled cleanup */
> - WARN("%cX DMA%d not cleaned up after abort!\n",
> + WARNING("%cX DMA%d not cleaned up after abort!\n",
> cppi_ch->transmit ? 'T' : 'R',
> cppi_ch->index);
> /* WARN_ON(1); */
> break;
> case MUSB_DMA_STATUS_BUSY:
> - WARN("program active channel? %cX DMA%d\n",
> + WARNING("program active channel? %cX DMA%d\n",
> cppi_ch->transmit ? 'T' : 'R',
> cppi_ch->index);
> /* WARN_ON(1); */
> diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
> index acd2aa8..75baf18 100644
> --- a/drivers/usb/musb/davinci.c
> +++ b/drivers/usb/musb/davinci.c
> @@ -120,7 +120,7 @@ void musb_platform_disable(struct musb *musb)
> musb_writel(musb->ctrl_base, DAVINCI_USB_EOI_REG, 0);
>
> if (is_dma_capable() && !dma_off)
> - WARN("dma still active\n");
> + WARNING("dma still active\n");
> }
>
>
> @@ -329,7 +329,7 @@ static irqreturn_t davinci_interrupt(int irq, void *__hci)
> musb->int_usb &= ~MUSB_INTR_VBUSERROR;
> musb->xceiv.state = OTG_STATE_A_WAIT_VFALL;
> mod_timer(&otg_workaround, jiffies + POLL_SECONDS * HZ);
> - WARN("VBUS error workaround (delay coming)\n");
> + WARNING("VBUS error workaround (delay coming)\n");
> } else if (is_host_enabled(musb) && drvvbus) {
> musb->is_active = 1;
> MUSB_HST_MODE(musb);
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 75c3013..1404a10 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -443,7 +443,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
> int_usb,
> MUSB_DEV_MODE(musb);
> break;
> default:
> - WARN("bogus %s RESUME (%s)\n",
> + WARNING("bogus %s RESUME (%s)\n",
> "host",
> otg_state_string(musb));
> }
> @@ -477,7 +477,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
> int_usb,
> break;
> #endif
> default:
> - WARN("bogus %s RESUME (%s)\n",
> + WARNING("bogus %s RESUME (%s)\n",
> "peripheral",
> otg_state_string(musb));
> }
> @@ -799,7 +799,7 @@ static irqreturn_t musb_stage2_irq(struct musb *musb, u8
> int_usb,
> break;
> #endif /* GADGET */
> default:
> - WARN("unhandled DISCONNECT transition (%s)\n",
> + WARNING("unhandled DISCONNECT transition (%s)\n",
> otg_state_string(musb));
>
musb fix
Hi Tony,
Please before merging with mailine apply the attached patch so musb
driver won't break compilation.
We now have a standard WARN() macro so to avoid conflicts we change
musb's WARN() to WARNING.
--
balbi
From: David Brownell <[EMAIL PROTECTED]>
Latest musb_hdrc code wouldn't:
* build ... because there's now a standard WARN() macro
* build without false printf format warnings ... "%zd" is for ssize_t,
while "%zu" is for size_t
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c
index e6770d6..e03aa99 100644
--- a/drivers/usb/musb/cppi_dma.c
+++ b/drivers/usb/musb/cppi_dma.c
@@ -862,10 +862,10 @@ cppi_next_rx_segment(struct musb *musb, struct
cppi_channel *rx, int onepacket)
/* we always expect at least one reusable BD! */
if (!tail) {
- WARN("rx dma%d -- no BDs? need %d\n", rx->index, n_bds);
+ WARNING("rx dma%d -- no BDs? need %d\n", rx->index, n_bds);
return;
} else if (i < n_bds)
- WARN("rx dma%d -- only %d of %d BDs\n", rx->index, i, n_bds);
+ WARNING("rx dma%d -- only %d of %d BDs\n", rx->index, i, n_bds);
tail->next = NULL;
tail->hw_next = 0;
@@ -963,13 +963,13 @@ static int cppi_channel_program(struct dma_channel *ch,
case MUSB_DMA_STATUS_BUS_ABORT:
case MUSB_DMA_STATUS_CORE_ABORT:
/* fault irq handler should have handled cleanup */
- WARN("%cX DMA%d not cleaned up after abort!\n",
+ WARNING("%cX DMA%d not cleaned up after abort!\n",
cppi_ch->transmit ? 'T' : 'R',
cppi_ch->index);
/* WARN_ON(1); */
break;
case MUSB_DMA_STATUS_BUSY:
- WARN("program active channel? %cX DMA%d\n",
+ WARNING("program active channel? %cX DMA%d\n",
cppi_ch->transmit ? 'T' : 'R',
cppi_ch->index);
/* WARN_ON(1); */
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index acd2aa8..75baf18 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -120,7 +120,7 @@ void musb_platform_disable(struct musb *musb)
musb_writel(musb->ctrl_base, DAVINCI_USB_EOI_REG, 0);
if (is_dma_capable() && !dma_off)
- WARN("dma still active\n");
+ WARNING("dma still active\n");
}
@@ -329,7 +329,7 @@ static irqreturn_t davinci_interrupt(int irq, void *__hci)
musb->int_usb &= ~MUSB_INTR_VBUSERROR;
musb->xceiv.state = OTG_STATE_A_WAIT_VFALL;
mod_timer(&otg_workaround, jiffies + POLL_SECONDS * HZ);
- WARN("VBUS error workaround (delay coming)\n");
+ WARNING("VBUS error workaround (delay coming)\n");
} else if (is_host_enabled(musb) && drvvbus) {
musb->is_active = 1;
MUSB_HST_MODE(musb);
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 75c3013..1404a10 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -443,7 +443,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
MUSB_DEV_MODE(musb);
break;
default:
- WARN("bogus %s RESUME (%s)\n",
+ WARNING("bogus %s RESUME (%s)\n",
"host",
otg_state_string(musb));
}
@@ -477,7 +477,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
break;
#endif
default:
- WARN("bogus %s RESUME (%s)\n",
+ WARNING("bogus %s RESUME (%s)\n",
"peripheral",
otg_state_string(musb));
}
@@ -799,7 +799,7 @@ static irqreturn_t musb_stage2_irq(struct musb *musb, u8
int_usb,
break;
#endif /* GADGET */
default:
- WARN("unhandled DISCONNECT transition (%s)\n",
+ WARNING("unhandled DISCONNECT transition (%s)\n",
otg_state_string(musb));
break;
}
diff --git a/drivers/usb/musb/musb_debug.h b/drivers/usb/musb/musb_debug.h
index 0743972..3bdb311 100644
--- a/drivers/usb/musb/musb_debug.h
+++ b/drivers/usb/musb/musb_debug.h
@@ -38,7 +38,7 @@
#define yprintk(facility, format, args...) \
do { printk(facility "%s %d: " format , \
__func__
[PATCH] usb: musb: fix hanging when rmmod gadget driver
If we try to modprobe a second gadget driver before
rmmoding the first one, the reference for the first
gadget driver would get NULLed avoiding usb to change
gadget drivers later.
Cc: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Cc: David Brownell <[EMAIL PROTECTED]>
Cc: Tony Lindgren <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/usb/musb/musb_gadget.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index b3773f1..d6a802c 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1710,17 +1710,15 @@ int usb_gadget_register_driver(struct usb_gadget_driver
*driver)
spin_unlock_irqrestore(&musb->lock, flags);
- if (retval == 0)
+ if (retval == 0) {
retval = driver->bind(&musb->g);
- if (retval != 0) {
- DBG(3, "bind to driver %s failed --> %d\n",
- driver->driver.name, retval);
- musb->gadget_driver = NULL;
- musb->g.dev.driver = NULL;
- }
+ if (retval != 0) {
+ DBG(3, "bind to driver %s failed --> %d\n",
+ driver->driver.name, retval);
+ musb->gadget_driver = NULL;
+ musb->g.dev.driver = NULL;
+ }
- /* start peripheral and/or OTG engines */
- if (retval == 0) {
spin_lock_irqsave(&musb->lock, flags);
/* REVISIT always use otg_set_peripheral(), handling
--
1.6.0.rc1.11.g1ce47
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP3 clock: fix 96MHz clocks, usbhost_120m_fclk enable
* Paul Walmsley <[EMAIL PROTECTED]> [080717 05:15]: > This series fixes a few bugs in the OMAP3 clock tree. The most noticeable > difference is that the "Clock usbhost_48m_fck didn't enable in 10 tries" > no longer appears during boot. Pushing these two today. Tony > > > --- > >textdata bss dec hex filename > 3391587 157104 107136 3655827 37c893 vmlinux.3430sdp.orig > 3391683 157104 107136 3655923 37c8f3 vmlinux.3430sdp.new > > arch/arm/mach-omap2/clock.c | 63 > ++--- > arch/arm/mach-omap2/clock34xx.h | 60 --- > arch/arm/mach-omap2/cm-regbits-34xx.h | 10 - > 3 files changed, 80 insertions(+), 53 deletions(-) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PROTECT_KEY register is in the PM_MASTER module not in the PM_RECEIVER module
* Peter 'p2' De Schrijver <[EMAIL PROTECTED]> [080716 19:53]: > This patch fixes a write to the wrong address in the triton2 chip. Pushing today. Tony > Signed-off-by: Peter 'p2' De Schrijver <[EMAIL PROTECTED]> > --- > drivers/i2c/chips/twl4030-usb.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/i2c/chips/twl4030-usb.c b/drivers/i2c/chips/twl4030-usb.c > index ab335ca..20858b5 100644 > --- a/drivers/i2c/chips/twl4030-usb.c > +++ b/drivers/i2c/chips/twl4030-usb.c > @@ -586,7 +586,7 @@ static void twl4030_usb_ldo_init(struct twl4030_usb *twl) > twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V8_TYPE); > > /* disable access to power configuration registers */ > - twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, PROTECT_KEY); > + twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, PROTECT_KEY); > } > > static irqreturn_t twl4030_usb_irq(int irq, void *_twl) > -- > 1.5.3.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: OneNAND for OMAP3
Paul Walmsley wrote:
Hello Adrian,
On Fri, 1 Aug 2008, Adrian Hunter wrote:
Update OneNAND support for OMAP3.
a few quick comments.
Thanks for looking at the code.
+ reg =
omap2_onenand_readw(onenand_base+ONENAND_REG_VERSION_ID);
Just a minor nit - please use spaces around binary & ternary operators per
CodingStyle.
+ (sync_write?GPMC_CONFIG1_WRITEMULTIPLE_SUPP:0) |
+ (sync_write?GPMC_CONFIG1_WRITETYPE_SYNC:0) |
as above.
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index ba83900..378ee17 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -223,6 +227,155 @@ static inline int omap2_onenand_bufferram_offset(struct
mtd_info *mtd, int area)
return 0;
}
+#if defined(CONFIG_ARCH_OMAP3)
+
+static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
+ unsigned char *buffer, int offset,
+ size_t count)
+{
+ struct omap2_onenand *info = container_of(mtd, struct omap2_onenand,
mtd);
+ struct onenand_chip *this = mtd->priv;
+ dma_addr_t dma_src, dma_dst;
+ int bram_offset;
+ unsigned long timeout;
+ void *buf = (void *)buffer;
+ size_t xtra;
+ volatile unsigned *done;
The way this volatile is used doesn't look right...
Well, it is correct.
+ INIT_COMPLETION(info->dma_done);
+ omap_start_dma(info->dma_channel);
+
+ timeout = jiffies + msecs_to_jiffies(20);
+ done = &info->dma_done.done;
So the volatile here appears to apply to the address of 'done', but this
address does not change, correct? Only the value of 'done' itself
changes.
No, the volatile applies to the "unsigned" not the "*".
+ while (time_before(jiffies, timeout))
+ if (*done)
+ break;
Can this be replaced with wait_for_completion_timeout() or something
similar?
No. Performance testing showed that a context switch here is too expensive.
It is better to spin.
+ dma_unmap_single(&info->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
+
+ if (!*done) {
+ dev_err(&info->pdev->dev, "timeout waiting for DMA\n");
+ goto out_copy;
+ }
...
+static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
+const unsigned char *buffer, int
offset,
+size_t count)
+{
+ struct omap2_onenand *info = container_of(mtd, struct omap2_onenand,
mtd);
+ struct onenand_chip *this = mtd->priv;
+ dma_addr_t dma_src, dma_dst;
+ int bram_offset;
+ unsigned long timeout;
+ void *buf = (void *)buffer;
+ volatile unsigned *done;
Same comments in this function per volatile.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
