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
[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
[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
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)
warning traceback here
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
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 asm/arch/board.h
#include asm/arch/gpmc.h
-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_ARCH_OMAP3430
+ const int t_ds = 30;
+#endif
+ const int t_wpl = 40;
+ const int t_wph =
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 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] 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 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);
- per_gpio_clk_enable();
- omap3_restore_per_ctx();
- }
-
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
[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;
dbsec += 1;
asecs += 1;
[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 stdarg.h -#ifndef __KERNEL__ -#include stdint.h -#else #include linux/types.h -#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 linux/autoconf.h #include asm/system.h #include asm/atomic.h @@ -55,9 +53,9 @@ #include linux/vmalloc.h #include linux/ioport.h #include linux/platform_device.h +#include dbtype.h /* #include asm/arch/bus.h */ - #if defined(OMAP_2430) || defined(OMAP_3430) #include asm/arch/clock.h #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 stdio.h -#include stdlib.h -#include fcntl.h -#include unistd.h -#include semaphore.h - -#include sys/types.h -#include sys/stat.h -#include sys/ioctl.h -#include sys/mman.h -#endif - -#include dbtype.h - #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);
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 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-omapm=121230229625544w=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 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 linux/clk.h
#include linux/io.h
#include linux/leds.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
#include asm/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
+#include asm/mach/flash.h
#include asm/arch/gpio.h
#include asm/arch/board.h
@@ -32,6 +36,64 @@
#include asm/arch/usb-ehci.h
#include asm/arch/hsmmc.h
#include asm/arch/common.h
+#include asm/arch/gpmc.h
+#include asm/arch/nand.h
+
+#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 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
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 can do about third-party drivers. Incidentally, a senior NVIDIA manager said a while ago that
Re: [PATCH 1/3 v2] mtd omap2 nand driver: extend to work with omap3 boards
Acked-by: Koen Kooi koen at openembedded dot org
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 = ((0x00FF22) | (0x000312) | (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
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 linux/clk.h
#include linux/io.h
#include linux/leds.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
#include asm/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
+#include asm/mach/flash.h
#include asm/arch/gpio.h
#include asm/arch/board.h
@@ -32,6 +36,64 @@
#include asm/arch/usb-ehci.h
#include asm/arch/hsmmc.h
#include asm/arch/common.h
+#include asm/arch/gpmc.h
+#include asm/arch/nand.h
+
+#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
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
[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=FrsReleaseViewrelease_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] 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
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 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 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 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
[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 module_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
[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
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 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
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 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
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] 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
