RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX
On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com --- Tested-by: Sudhakar Rajashekhara sudhakar@ti.com Tested with audio loopback on OMAP-L138, OMAP-L137 and DM365. Also tested with i2cdetect function which probes all the devices on the i2c bus. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX
Hi, On Wed, Sep 22, 2010 at 05:39:16, Ben Dooks wrote: On Tue, Sep 21, 2010 at 12:17:58PM -0700, Troy Kisky wrote: On 9/21/2010 4:24 AM, Sudhakar Rajashekhara wrote: Hi, On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com --- Reworked after comments by Troy and Sudhakar. Looking at the datasheet it seemed like setting STP without STT early might cause a stray STOP to be generated, so I moved it into the second MDR load. This passes a quick smoke test but I can't do much more testing right at the moment. Sudhakar, your comments would be welcomed. Looks good to me. I can test on couple of platforms I have and update the result by tomorrow. Thanks, Sudhakar I like it too. I hope it works for omap. Thanks as well Troy Ok, any objections to this being applied, or should I wait? I am stuck in some other work. If you can wait till I test it, that'll be good. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX
Hi, On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com --- Reworked after comments by Troy and Sudhakar. Looking at the datasheet it seemed like setting STP without STT early might cause a stray STOP to be generated, so I moved it into the second MDR load. This passes a quick smoke test but I can't do much more testing right at the moment. Sudhakar, your comments would be welcomed. Looks good to me. I can test on couple of platforms I have and update the result by tomorrow. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3] i2c: davinci: Fix race when setting up for TX
Hi, On Fri, Sep 17, 2010 at 08:32:11, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR is loaded. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Move the MDR load after DXR,IMR loads to avoid this race without locking. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 I remember I had some issues on OMAP-L138 with this fix, that's when I reverted to configuring ICMDR before writing to DXR (Please see here: https://patchwork.kernel.org/patch/75262/). I checked the BIOS I2C driver code for OMAP-L138 and there also we are configuring MDR before accessing DXR. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] nand/davinci: relax a timeout for ECC-initialization
Hi Wolfram Sang, On Fri, Sep 03, 2010 at 16:05:37, Wolfram Sang wrote: Sudhakar found out that 100us are enough. Sadly, his updated patch was overlooked and an older version still using 100ms was merged. Fix this. Reference: http://patchwork.ozlabs.org/patch/59180/ Signed-off-by: Wolfram Sang w.s...@pengutronix.de Cc: Sudhakar Rajashekhara sudhakar@ti.com Cc: Sneha Narnakaje nsnehapra...@ti.com Cc: Artem Bityutskiy artem.bityuts...@nokia.com --- Artem, if you pick up this one, too, then we have what Sudhakar sent as v3 of his original patch. Except for some minor rewording in the comment. Sudhakar, I hope it is okay if I send this patch now. I just want to have the confusion about the different versions gone. I was tied up for the past few days, so couldn't work on this patch. Thanks for taking this up. Can you modify the comment also to match my patch and re-submit this again? Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [RFC] nand/davinci: Fix comment to match the code
Hi,
On Wed, Aug 25, 2010 at 17:48:20, Wolfram Sang wrote:
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Cc: Sudhakar Rajashekhara sudhakar@ti.com
Cc: Sneha Narnakaje nsnehapra...@ti.com
Cc: Artem Bityutskiy artem.bityuts...@nokia.com
---
Found while debugging a NAND issue with a dm365.
drivers/mtd/nand/davinci_nand.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 2ac7367..53f864a 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -369,8 +369,9 @@ compare:
* after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
* begin trying to poll for the state, you may fall right out of your
* loop without any of the correction calculations having taken place.
- * The recommendation from the hardware team is to wait till ECC_STATE
- * reads less than 4, which means ECC HW has entered correction state.
+ * The recommendation from the hardware team is to initially delay as
+ * long as ECC_STATE reads less than 4. After that, ECC HW has entered
+ * correction state.
*/
do {
ecc_state = (davinci_nand_readl(info,
--
Thanks for pointing this out, but I have already corrected this and submitted
the patch. Artem Bityutskity has pushed this patch to his l2-mtd-2.6 / master
tree.
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [RFC] nand/davinci: Fix comment to match the code
On Wed, Aug 25, 2010 at 18:25:06, Artem Bityutskiy wrote:
On Wed, 2010-08-25 at 17:57 +0530, Sudhakar Rajashekhara wrote:
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -369,8 +369,9 @@ compare:
* after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
* begin trying to poll for the state, you may fall right out of your
* loop without any of the correction calculations having taken place.
- * The recommendation from the hardware team is to wait till ECC_STATE
- * reads less than 4, which means ECC HW has entered correction state.
+ * The recommendation from the hardware team is to initially delay as
+ * long as ECC_STATE reads less than 4. After that, ECC HW has entered
+ * correction state.
*/
do {
ecc_state = (davinci_nand_readl(info,
--
Thanks for pointing this out, but I have already corrected this and
submitted
the patch. Artem Bityutskity has pushed this patch to his l2-mtd-2.6 /
master
tree.
If you mean
commit 1c3275b656045aff9a75bb2c9f3251af1043ebb3
Author: Sudhakar Rajashekhara sudhakar@ti.com
Date: Tue Jul 20 15:24:01 2010 -0700
mtd: nand: davinci: correct 4-bit error correction
On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after setting the
4BITECC_ADD_CALC_START bit in the NAND Flash control register to 1 and
before waiting for the NAND Flash status register to be equal to 1, 2 or
3, we have to wait till the ECC HW goes to correction state. Without this
wait, ECC correction calculations will not be proper.
This has been tested on DA830/OMAP-L137, DA850/OMAP-L138, DM355 and DM365
EVMs.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Acked-by: Sneha Narnakaje nsnehapra...@ti.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Artem Bityutskiy artem.bityuts...@nokia.com
Signed-off-by: David Woodhouse david.woodho...@intel.com
then it is already in upstream in Linus' tree. I do not have anything else
from you.
Yes, this was the patch I was talking about. But this patch seems little
different than the one I submitted to linux-mtd list at
http://patchwork.ozlabs.org/patch/59180/. But I can submit another patch
which corrects it.
Wolfram Sang,
Do you agree that in the above link which shows the patch I have submitted,
the comment matches the code?
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] m25p80: add support for a callback to platform code on successful device probe
Hi Mike, On Wed, Aug 11, 2010 at 00:32:00, Mike Frysinger wrote: On Tue, Aug 10, 2010 at 09:07, David Brownell wrote: On Tue, Aug 10, 2010 at 12:47:05, Mike Frysinger wrote: it is necessary that you do these things from kernel space instead of standard userspace. Hard to get userspace to do this stuff if you're doing a network boot, and thus need to have the MAC address working early.. it's easy if the kernel can get the MAC address, else not possible to boot. Right? no, that isnt true at all. you can easily have a small initramfs to handle all of your random setup. if that's too much overhead, you can add a late initcall to your boards file that is run after the MTD devices are probed and let that read the required information. all of this is more than documented: http://www.denx.de/wiki/view/DULG/EthernetDoesNotWorkInLinux I looked around in the kernel and found mtd_notifier callbacks which get called upon addition of MTD device. Inside this callback, I am checking for the device in which I am interested and doing a mtd-read to get the MAC address. So this patch can be dropped. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] m25p80: add support for a callback to platform code on successful device probe
On some platforms, MTD device can hold MAC address, calibration
data, serial numbers etc.
On TI's DA850/OMAP-L138/AM18xx EVM, MAC address is stored on
the last sector of the SPI flash, which is exported as an MTD
device.
This patch adds two new members to the 'flash_platform_data'
structure, a function handler which will be called after
add_mtd_device() and an argument to be passed to this function,
for example: offset to read from.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
drivers/mtd/devices/m25p80.c | 15 +--
include/linux/spi/flash.h|2 ++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 81e49a9..b832091 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -765,6 +765,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
struct m25p *flash;
struct flash_info *info;
unsignedi;
+ int ret;
/* Platform data helps sort out which chip type we have, as
* well as how this board partitions it. If we don't have
@@ -924,13 +925,23 @@ static int __devinit m25p_probe(struct spi_device *spi)
(long long)(parts[i].size 10));
}
flash-partitioned = 1;
- return add_mtd_partitions(flash-mtd, parts, nr_parts);
+ ret = add_mtd_partitions(flash-mtd, parts, nr_parts);
+ if (!ret)
+ goto out;
+
+ return ret;
}
} else if (data data-nr_parts)
dev_warn(spi-dev, ignoring %d default partitions on %s\n,
data-nr_parts, data-name);
- return add_mtd_device(flash-mtd) == 1 ? -ENODEV : 0;
+ ret = add_mtd_device(flash-mtd);
+
+out:
+ if (data-setup !ret)
+ (data-setup)(flash-mtd, (void *)data-context);
+
+ return (ret == 1) ? -ENODEV : 0;
}
diff --git a/include/linux/spi/flash.h b/include/linux/spi/flash.h
index 3f22932..daa4875 100644
--- a/include/linux/spi/flash.h
+++ b/include/linux/spi/flash.h
@@ -24,6 +24,8 @@ struct flash_platform_data {
unsigned intnr_parts;
char*type;
+ void(*setup)(struct mtd_info *, void *context);
+ void*context;
/* we'll likely add more ... use JEDEC IDs, etc */
};
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] m25p80: add support for a callback to platform code on successful device probe
On some platforms, MTD device can hold MAC address, calibration
data, serial numbers etc.
On TI's DA850/OMAP-L138/AM18xx EVM, MAC address is stored on
the last sector of the SPI flash, which is exported as an MTD
device. Ethernet driver on this platform needs MAC address to
be passed through platform data. The callback function can be
used to read the MAC address. The callback has to be invoked
after the MTD device is setup.
This patch adds two new members to the 'flash_platform_data'
structure, a function handler which will be called after
add_mtd_device() and an argument to be passed to this function,
for example: offset to read from.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
Since v1: Updated the changelog
drivers/mtd/devices/m25p80.c | 15 +--
include/linux/spi/flash.h|2 ++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 81e49a9..b832091 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -765,6 +765,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
struct m25p *flash;
struct flash_info *info;
unsignedi;
+ int ret;
/* Platform data helps sort out which chip type we have, as
* well as how this board partitions it. If we don't have
@@ -924,13 +925,23 @@ static int __devinit m25p_probe(struct spi_device *spi)
(long long)(parts[i].size 10));
}
flash-partitioned = 1;
- return add_mtd_partitions(flash-mtd, parts, nr_parts);
+ ret = add_mtd_partitions(flash-mtd, parts, nr_parts);
+ if (!ret)
+ goto out;
+
+ return ret;
}
} else if (data data-nr_parts)
dev_warn(spi-dev, ignoring %d default partitions on %s\n,
data-nr_parts, data-name);
- return add_mtd_device(flash-mtd) == 1 ? -ENODEV : 0;
+ ret = add_mtd_device(flash-mtd);
+
+out:
+ if (data-setup !ret)
+ (data-setup)(flash-mtd, (void *)data-context);
+
+ return (ret == 1) ? -ENODEV : 0;
}
diff --git a/include/linux/spi/flash.h b/include/linux/spi/flash.h
index 3f22932..daa4875 100644
--- a/include/linux/spi/flash.h
+++ b/include/linux/spi/flash.h
@@ -24,6 +24,8 @@ struct flash_platform_data {
unsigned intnr_parts;
char*type;
+ void(*setup)(struct mtd_info *, void *context);
+ void*context;
/* we'll likely add more ... use JEDEC IDs, etc */
};
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] m25p80: add support for a callback to platform code on successful device probe
Hi, On Tue, Aug 10, 2010 at 12:47:05, Mike Frysinger wrote: On Tue, Aug 10, 2010 at 02:42, Sudhakar Rajashekhara wrote: On some platforms, MTD device can hold MAC address, calibration data, serial numbers etc. pretty standard behavior ... On TI's DA850/OMAP-L138/AM18xx EVM, MAC address is stored on the last sector of the SPI flash, which is exported as an MTD device. again, nothing unique here ... This patch adds two new members to the 'flash_platform_data' structure, a function handler which will be called after add_mtd_device() and an argument to be passed to this function, for example: offset to read from. ... and your changelog falls apart. the intro gives no basis that i can see as to why you need these hooks. please give examples of what you're actually trying to accomplish and how these hooks help you accomplish said goal and why it is necessary that you do these things from kernel space instead of standard userspace. I have submitted an updated version of this patch in which I have addressed your concerns. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] m25p80: add support for a callback to platform code on successful device probe
On Tue, Aug 10, 2010 at 18:37:47, David Brownell wrote: On Tue, Aug 10, 2010 at 12:47:05, Mike Frysinger wrote: it is necessary that you do these things from kernel space instead of standard userspace. Hard to get userspace to do this stuff if you're doing a network boot, and thus need to have the MAC address working early.. it's easy if the kernel can get the MAC address, else not possible to boot. Right? You are absolutely right. - Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2] mtd-nand: davinci: correct 4-bit error correction
Hi, On Thu, Jul 22, 2010 at 03:30:58, Andrew Morton wrote: On Thu, 15 Jul 2010 17:33:03 +0530 Sudhakar Rajashekhara sudhakar@ti.com wrote: On Thu, Jul 15, 2010 at 17:11:32, Sudhakar Rajashekhara wrote: Hi, On Thu, Jul 15, 2010 at 16:31:19, Jon Povey wrote: Sudhakar Rajashekhara wrote: On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after setting the 4BITECC_ADD_CALC_START bit in the NAND Flash control register to 1 and before waiting for the NAND Flash status register to be equal to 1, 2 or 3, we have to wait till the ECC HW goes to correction state. Without this wait, ECC correction calculations will not be proper. This has been tested on DA830/OMAP-L137, DA850/OMAP-L138, DM355 and DM365 EVMs. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Acked-by: Sneha Narnakaje nsnehapra...@ti.com Cc: David Woodhouse dw...@infradead.org Signed-off-by: Andrew Morton a...@linux-foundation.org Have these people acked and signed off this new version of the patch? No. Andrew Morton has not signed off this version. I'll remove Signed-off-by: Andrew Morton a...@linux-foundation.org Andrew Morton had signed off an earlier version of this patch and it was present in -mm tree for a long time. He has not yet commented on v2 version of this patch. But I thought I can carry forward the Sign-offs from previous version to the next version. What's the common practice? I've lost the plot on this patch and I think I'll drop my copy. Please update and resend, cc'ing everyone. I've been sitting on this thing since November last year! It fixes a bug! Where the heck are the MTD maintainers and why aren't they running around with hair on fire getting this thing finalised and merged?!?! I got an e-mail from Artem Bityutskiy(dedeki...@gmail.com) saying that he has pushed this patch to his l2-mtd-2.6/master tree. May be it will get to upstream from there. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v3] mtd-nand: davinci: correct 4-bit error correction
On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after setting the
4BITECC_ADD_CALC_START bit in the NAND Flash control register to 1 and
before waiting for the NAND Flash status register to be equal to 1, 2 or
3, we have to wait till the ECC HW goes to correction state. Without this
wait, ECC correction calculations will not be proper.
This has been tested on DA830/OMAP-L137, DA850/OMAP-L138, DM355 and DM365
EVMs.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Acked-by: Sneha Narnakaje nsnehapra...@ti.com
Cc: David Woodhouse dw...@infradead.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
Since v2, removed spilocks as that would cause jiffies not to increment.
drivers/mtd/nand/davinci_nand.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 9c9d893..574c38a 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -311,7 +311,9 @@ static int nand_davinci_correct_4bit(struct mtd_info *mtd,
unsigned short ecc10[8];
unsigned short *ecc16;
u32 syndrome[4];
+ u32 ecc_state;
unsigned num_errors, corrected;
+ unsigned long timeo;
/* All bytes 0xff? It's an erased page; ignore its ECC. */
for (i = 0; i 10; i++) {
@@ -361,6 +363,22 @@ compare:
*/
davinci_nand_writel(info, NANDFCR_OFFSET,
davinci_nand_readl(info, NANDFCR_OFFSET) | BIT(13));
+
+ /*
+* ECC_STATE field reads 0x3 (Error correction complete) immediately
+* after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
+* begin trying to poll for the state, you may fall right out of your
+* loop without any of the correction calculations having taken place.
+* The recommendation from the hardware team is to wait till ECC_STATE
+* reads = 4, which means ECC HW has entered correction state.
+*/
+ timeo = jiffies + usecs_to_jiffies(100);
+ do {
+ ecc_state = (davinci_nand_readl(info,
+ NANDFSR_OFFSET) 8) 0x0f;
+ cpu_relax();
+ } while ((ecc_state 4) time_before(jiffies, timeo));
+
for (;;) {
u32 fsr = davinci_nand_readl(info, NANDFSR_OFFSET);
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2] mtd-nand: davinci: correct 4-bit error correction
Hi, On Thu, Jul 15, 2010 at 16:31:19, Jon Povey wrote: Sudhakar Rajashekhara wrote: On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after setting the 4BITECC_ADD_CALC_START bit in the NAND Flash control register to 1 and before waiting for the NAND Flash status register to be equal to 1, 2 or 3, we have to wait till the ECC HW goes to correction state. Without this wait, ECC correction calculations will not be proper. This has been tested on DA830/OMAP-L137, DA850/OMAP-L138, DM355 and DM365 EVMs. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Acked-by: Sneha Narnakaje nsnehapra...@ti.com Cc: David Woodhouse dw...@infradead.org Signed-off-by: Andrew Morton a...@linux-foundation.org Have these people acked and signed off this new version of the patch? No. Andrew Morton has not signed off this version. I'll remove Signed-off-by: Andrew Morton a...@linux-foundation.org Since v1: a. Timeout has been changed from 100 msec to 100 usec. b. Comment above the do, while loop was not matching the code. This has been corrected. c. Initialization of 'timeo' variable has been moved down. d. It was observed that, while calculating the time in the loop, if there is a context switch between setting the 4BITECC_ADD_CALC_START bit and reading of ECC_STATE field, then the loop will not come out until the timeout happens. To prevent the context switch, spin_lock_irqsave and spin_unlock_irqrestore are used. d. means interrupts are disabled for up to 100us while waiting for ECC. Doesn't sound good if it can be avoided. I wanted to avoid context switching between setting 4BITECC_ADD_CALC_START bit: davinci_nand_writel(info, NANDFCR_OFFSET, davinci_nand_readl(info, NANDFCR_OFFSET) | BIT(13)); And reading of ECC_STATE field inside the loop: + ecc_state = (davinci_nand_readl(info, + NANDFSR_OFFSET) 8) 0x0f; Because even if there was a slight delay after setting 4BITECC_ADD_CALC_START, ECC_STATE would read 4(meaning ECC engine has completed Error correction) and I would wait in the loop for up to 100us. How about instead of spinlock, set timeo first time inside the loop? I don't think this would also solve the problem which I stated above. Adding spinlock was a blunder as that would cause jiffies not to increment. I'll be removing the spinlocks and will be resubmitting the patch. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2] mtd-nand: davinci: correct 4-bit error correction
On Thu, Jul 15, 2010 at 17:11:32, Sudhakar Rajashekhara wrote: Hi, On Thu, Jul 15, 2010 at 16:31:19, Jon Povey wrote: Sudhakar Rajashekhara wrote: On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after setting the 4BITECC_ADD_CALC_START bit in the NAND Flash control register to 1 and before waiting for the NAND Flash status register to be equal to 1, 2 or 3, we have to wait till the ECC HW goes to correction state. Without this wait, ECC correction calculations will not be proper. This has been tested on DA830/OMAP-L137, DA850/OMAP-L138, DM355 and DM365 EVMs. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Acked-by: Sneha Narnakaje nsnehapra...@ti.com Cc: David Woodhouse dw...@infradead.org Signed-off-by: Andrew Morton a...@linux-foundation.org Have these people acked and signed off this new version of the patch? No. Andrew Morton has not signed off this version. I'll remove Signed-off-by: Andrew Morton a...@linux-foundation.org Andrew Morton had signed off an earlier version of this patch and it was present in -mm tree for a long time. He has not yet commented on v2 version of this patch. But I thought I can carry forward the Sign-offs from previous version to the next version. What's the common practice? Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] mtd-nand: davinci: correct 4-bit error correction
Hi,
On Tue, Jul 13, 2010 at 23:11:26, Andrew Morton wrote:
On Tue, 13 Jul 2010 15:02:59 +0530 Sudhakar Rajashekhara
sudhakar@ti.com wrote:
Hi,
On Mon, Jul 12, 2010 at 11:58:18, Sudhakar Rajashekhara wrote:
On Sat, Jul 10, 2010 at 04:09:32, Andrew Morton wrote:
On Fri, 9 Jul 2010 10:59:49 +0530
Sudhakar Rajashekhara sudhakar@ti.com wrote:
+
+ /*
+ * ECC_STATE field reads 0x3 (Error correction complete)
immediately
+ * after setting the 4BITECC_ADD_CALC_START bit. So if you
immediately
+ * begin trying to poll for the state, you may fall right out
of your
+ * loop without any of the correction calculations having taken
place.
+ * The recommendation from the hardware team is to wait till
ECC_STATE
+ * reads less than 4, which means ECC HW has entered correction
state.
+ */
+ do {
+ ecc_state = (davinci_nand_readl(info,
+ NANDFSR_OFFSET) 8) 0x0f;
+ cpu_relax();
+ } while ((ecc_state 4) time_before(jiffies, timeo));
An up-to-100-milliseond busy wait is pretty bad. For how long do you
expect this to spin in practice?
On the hardware, I have never seen this taking 100 msec to come out of
the loop. I'll check with the hardware folks on the maximum time to wait
for, before the ECC engine is ready.
I checked this with the hardware team but no one is sure about the exact
time one should wait before the ECC engine becomes ready. But everyone is
of the opinion that 100 loop cycles should be enough. To be on the safer
side, I'll be changing the timeout to 10 milliseconds in the next version
of this patch.
Going from 100ms down to 10ms sounds a bit risky. It'd be better to
retain the 100ms and to make the kernel spend most of that time
sleeping, rather than busywaiting, IMO.
I chose 100ms timeout randomly, but today I did some calculation using
do_gettimeofday() to find out the actual time spent inside the loop. I
found that, control is coming out of loop within 5 microseconds. So I'll
go ahead and use usecs_to_jiffies(100) as timeout. Busywaiting for such
a short duration may not be a problem.
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] mtd-nand: davinci: correct 4-bit error correction
On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after setting the
4BITECC_ADD_CALC_START bit in the NAND Flash control register to 1 and
before waiting for the NAND Flash status register to be equal to 1, 2 or
3, we have to wait till the ECC HW goes to correction state. Without this
wait, ECC correction calculations will not be proper.
This has been tested on DA830/OMAP-L137, DA850/OMAP-L138, DM355 and DM365
EVMs.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Acked-by: Sneha Narnakaje nsnehapra...@ti.com
Cc: David Woodhouse dw...@infradead.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
Since v1:
a. Timeout has been changed from 100 msec to 100 usec.
b. Comment above the do, while loop was not matching the code.
This has been corrected.
c. Initialization of 'timeo' variable has been moved down.
d. It was observed that, while calculating the time in the loop,
if there is a context switch between setting the 4BITECC_ADD_CALC_START
bit and reading of ECC_STATE field, then the loop will not come out
until the timeout happens. To prevent the context switch, spin_lock_irqsave
and spin_unlock_irqrestore are used.
drivers/mtd/nand/davinci_nand.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 9c9d893..1e2657c 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -311,7 +311,11 @@ static int nand_davinci_correct_4bit(struct mtd_info *mtd,
unsigned short ecc10[8];
unsigned short *ecc16;
u32 syndrome[4];
+ u32 ecc_state;
unsigned num_errors, corrected;
+ unsigned long timeo;
+ DEFINE_SPINLOCK(ecc_spin_lock);
+ unsigned long flags;
/* All bytes 0xff? It's an erased page; ignore its ECC. */
for (i = 0; i 10; i++) {
@@ -355,12 +359,30 @@ compare:
*/
davinci_nand_readl(info, NAND_ERR_ADD1_OFFSET);
+ spin_lock_irqsave(ecc_spin_lock, flags);
/* Start address calculation, and wait for it to complete.
* We _could_ start reading more data while this is working,
* to speed up the overall page read.
*/
davinci_nand_writel(info, NANDFCR_OFFSET,
davinci_nand_readl(info, NANDFCR_OFFSET) | BIT(13));
+
+ /*
+* ECC_STATE field reads 0x3 (Error correction complete) immediately
+* after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
+* begin trying to poll for the state, you may fall right out of your
+* loop without any of the correction calculations having taken place.
+* The recommendation from the hardware team is to wait till ECC_STATE
+* reads = 4, which means ECC HW has entered correction state.
+*/
+ timeo = jiffies + usecs_to_jiffies(100);
+ do {
+ ecc_state = (davinci_nand_readl(info,
+ NANDFSR_OFFSET) 8) 0x0f;
+ cpu_relax();
+ } while ((ecc_state 4) time_before(jiffies, timeo));
+ spin_unlock_irqrestore(ecc_spin_lock, flags);
+
for (;;) {
u32 fsr = davinci_nand_readl(info, NANDFSR_OFFSET);
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] mtd-nand: davinci: correct 4-bit error correction
Hi,
On Mon, Jul 12, 2010 at 11:58:18, Sudhakar Rajashekhara wrote:
On Sat, Jul 10, 2010 at 04:09:32, Andrew Morton wrote:
On Fri, 9 Jul 2010 10:59:49 +0530
Sudhakar Rajashekhara sudhakar@ti.com wrote:
+
+ /*
+ * ECC_STATE field reads 0x3 (Error correction complete) immediately
+ * after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
+ * begin trying to poll for the state, you may fall right out of your
+ * loop without any of the correction calculations having taken place.
+ * The recommendation from the hardware team is to wait till ECC_STATE
+ * reads less than 4, which means ECC HW has entered correction state.
+ */
+ do {
+ ecc_state = (davinci_nand_readl(info,
+ NANDFSR_OFFSET) 8) 0x0f;
+ cpu_relax();
+ } while ((ecc_state 4) time_before(jiffies, timeo));
An up-to-100-milliseond busy wait is pretty bad. For how long do you
expect this to spin in practice?
On the hardware, I have never seen this taking 100 msec to come out of
the loop. I'll check with the hardware folks on the maximum time to wait
for, before the ECC engine is ready.
I checked this with the hardware team but no one is sure about the exact
time one should wait before the ECC engine becomes ready. But everyone is
of the opinion that 100 loop cycles should be enough. To be on the safer
side, I'll be changing the timeout to 10 milliseconds in the next version
of this patch.
Thanks,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] mtd-nand: davinci: correct 4-bit error correction
On Sat, Jul 10, 2010 at 04:09:32, Andrew Morton wrote:
On Fri, 9 Jul 2010 10:59:49 +0530
Sudhakar Rajashekhara sudhakar@ti.com wrote:
+
+ /*
+* ECC_STATE field reads 0x3 (Error correction complete) immediately
+* after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
+* begin trying to poll for the state, you may fall right out of your
+* loop without any of the correction calculations having taken place.
+* The recommendation from the hardware team is to wait till ECC_STATE
+* reads less than 4, which means ECC HW has entered correction state.
+*/
+ do {
+ ecc_state = (davinci_nand_readl(info,
+ NANDFSR_OFFSET) 8) 0x0f;
+ cpu_relax();
+ } while ((ecc_state 4) time_before(jiffies, timeo));
An up-to-100-milliseond busy wait is pretty bad. For how long do you
expect this to spin in practice?
On the hardware, I have never seen this taking 100 msec to come out of
the loop. I'll check with the hardware folks on the maximum time to wait
for, before the ECC engine is ready.
Thanks,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] mtd-nand: davinci: correct 4-bit error correction
On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after setting the
4BITECC_ADD_CALC_START bit in the NAND Flash control register to 1 and
before waiting for the NAND Flash status register to be equal to 1, 2 or
3, we have to wait till the ECC HW goes to correction state. Without this
wait, ECC correction calculations will not be proper.
This has been tested on DA830/OMAP-L137, DA850/OMAP-L138, DM355 and DM365
EVMs.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Acked-by: Sneha Narnakaje nsnehapra...@ti.com
Cc: David Woodhouse dw...@infradead.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
This patch applies on top of Linus's master.
This patch was present in -mm tree and was dropped because it was merged
into mainline. But now this patch is not present neither in Linus's tree
nor in linux-next. Hence resending it again.
drivers/mtd/nand/davinci_nand.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 9c9d893..2ac7367 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -311,7 +311,9 @@ static int nand_davinci_correct_4bit(struct mtd_info *mtd,
unsigned short ecc10[8];
unsigned short *ecc16;
u32 syndrome[4];
+ u32 ecc_state;
unsigned num_errors, corrected;
+ unsigned long timeo = jiffies + msecs_to_jiffies(100);
/* All bytes 0xff? It's an erased page; ignore its ECC. */
for (i = 0; i 10; i++) {
@@ -361,6 +363,21 @@ compare:
*/
davinci_nand_writel(info, NANDFCR_OFFSET,
davinci_nand_readl(info, NANDFCR_OFFSET) | BIT(13));
+
+ /*
+* ECC_STATE field reads 0x3 (Error correction complete) immediately
+* after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
+* begin trying to poll for the state, you may fall right out of your
+* loop without any of the correction calculations having taken place.
+* The recommendation from the hardware team is to wait till ECC_STATE
+* reads less than 4, which means ECC HW has entered correction state.
+*/
+ do {
+ ecc_state = (davinci_nand_readl(info,
+ NANDFSR_OFFSET) 8) 0x0f;
+ cpu_relax();
+ } while ((ecc_state 4) time_before(jiffies, timeo));
+
for (;;) {
u32 fsr = davinci_nand_readl(info, NANDFSR_OFFSET);
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [spi-devel-general] [PATCH v2 0/1] davinci: spi: replaceexisting driver
Hi Brian, On Tue, Jul 06, 2010 at 19:45:56, Brian Niebuhr wrote: On Sat, Jul 03, 2010 at 04:08:53, Brian Niebuhr wrote: I have included all of the recommended changes in this [...] Quick update. I tested this patch on DM355 and DM365 EVMs. On DM355 all the 3 modes (DMA, Polled and Interrupt) worked fine. But in interrupt mode, on DM355, if I set intr_level = 1, then kernel hangs during booting after printing spi spi0.0: DaVinci SPI driver in Interrupt mode on the console. Sudhakar - When you changed the interrupt level, did you also change the IORESOURCE_IRQ entry for SPI0? Maybe we could set the interrupt level automatically based on the IORESOURCE_IRQ provided? IORESOURCE_IRQ entry for dm365 were already present in dm365.c. On DM365 only DMA and Polled mode worked fine. In interrupt mode, whether I set intr_level to ZERO or ONE, kernel booting hangs, similar to DM355. Does the interrupt mode of the existing driver work on DM365? AFAIK, support for interrupt mode was not present in the earlier driver by Sandeep Paulraj. I don't have one of these boards, so I can't debug the issue. If you have any ideas where the problem might be I'd appreciate the help in getting this resolved. As I mentioned in my earlier e-mail, on DM365 kernel booting hangs after Printing spi spi0.0: DaVinci SPI driver in Interrupt mode on the console. Control is in spi_sync() function waiting for completion. If the change I mentioned above fixes the issue on DM355, then I am not sure whether my earlier mail was clear in this regard or not but interrupt mode works fine on DM355 if intr_level = 0. Kernel booting hangs on DM355 if intr_level = 1. I've got to imagine that it's just a configuration issue of some sort on DM365. I am also of the same opinion. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/3] ASoC: DaVinci: Added two clocking possibilities to McBSP (I2S)
Hi, On Fri, Jul 02, 2010 at 22:42:25, Raffaele Recalcati wrote: From: Raffaele Recalcati raffaele.recalc...@bticino.it Added two clocking options for dm365 McBSP peripheral when used with I2S timings, that are SND_SOC_DAIFMT_CBS_CFS (the cpu generates clock and frame sync) and SND_SOC_DAIFMT_CBS_CFM (the cpu gets clock from external pin and generates frame sync). A slave clock management can be important when the external codec needs the system clock and the bit clock synchronized (tested with uda1345). This patch has been developed against the: http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git git tree and has been tested on bmx board (similar to dm365 evm, but using uda1345 as external audio codec). Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it --- sound/soc/davinci/davinci-i2s.c | 111 +++--- sound/soc/davinci/davinci-i2s.h |5 ++ 2 files changed, 107 insertions(+), 9 deletions(-) diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c index adadcd3..a893538 100644 --- a/sound/soc/davinci/davinci-i2s.c +++ b/sound/soc/davinci/davinci-i2s.c @@ -26,6 +26,7 @@ #include mach/asp.h #include davinci-pcm.h +#include davinci-i2s.h /* @@ -68,16 +69,21 @@ #define DAVINCI_MCBSP_RCR_RDATDLY(v) ((v) 16) #define DAVINCI_MCBSP_RCR_RFIG (1 18) #define DAVINCI_MCBSP_RCR_RWDLEN2(v) ((v) 21) +#define DAVINCI_MCBSP_RCR_RFRLEN2(v) ((v) 24) +#define DAVINCI_MCBSP_RCR_RPHASE (1 31) #define DAVINCI_MCBSP_XCR_XWDLEN1(v) ((v) 5) #define DAVINCI_MCBSP_XCR_XFRLEN1(v) ((v) 8) #define DAVINCI_MCBSP_XCR_XDATDLY(v) ((v) 16) #define DAVINCI_MCBSP_XCR_XFIG (1 18) #define DAVINCI_MCBSP_XCR_XWDLEN2(v) ((v) 21) +#define DAVINCI_MCBSP_XCR_XFRLEN2(v) ((v) 24) +#define DAVINCI_MCBSP_XCR_XPHASE (1 31) #define DAVINCI_MCBSP_SRGR_FWID(v) ((v) 8) #define DAVINCI_MCBSP_SRGR_FPER(v) ((v) 16) #define DAVINCI_MCBSP_SRGR_FSGM (1 28) +#define DAVINCI_MCBSP_SRGR_CLKSM (1 29) Use BIT(x) instead of (1 x). Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 0/1] davinci: spi: replace existing driver
Hi, On Sat, Jul 03, 2010 at 04:08:53, Brian Niebuhr wrote: I have included all of the recommended changes in this version of the patch. I also combined the patches into one patch to avoid bisecting issues. This makes the diff on davinci_spi.c very large. If people who are using this driver could test this version of the driver and Ack it, I would appreciate it. ** NOTE ** This patch requires the EDMA patch at: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-March/018022.html which is queued waiting on another driver fix, for DMA mode to work correctly. Brian Niebuhr (1): davinci: spi: replace existing driver arch/arm/mach-davinci/board-dm355-evm.c | 10 + arch/arm/mach-davinci/board-dm355-leopard.c | 10 + arch/arm/mach-davinci/board-dm365-evm.c | 10 + arch/arm/mach-davinci/dm355.c | 12 +- arch/arm/mach-davinci/dm365.c | 12 +- arch/arm/mach-davinci/include/mach/spi.h| 37 +- drivers/spi/davinci_spi.c | 1328 --- 7 files changed, 648 insertions(+), 771 deletions(-) Quick update. I tested this patch on DM355 and DM365 EVMs. On DM355 all the 3 modes (DMA, Polled and Interrupt) worked fine. But in interrupt mode, on DM355, if I set intr_level = 1, then kernel hangs during booting after printing spi spi0.0: DaVinci SPI driver in Interrupt mode on the console. On DM365 only DMA and Polled mode worked fine. In interrupt mode, whether I set intr_level to ZERO or ONE, kernel booting hangs, similar to DM355. I'll update the status of testing on OMAP-L1x EVMs later. I am using the Linux kernel from [1] for testing. [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summary Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/3] ASoC: DaVinci: Added two clocking possibilities to McBSP (I2S)
Hi, On Tue, Jul 06, 2010 at 15:15:59, Liam Girdwood wrote: On Tue, 2010-07-06 at 10:39 +0200, Raffaele Recalcati wrote: From: Raffaele Recalcati raffaele.recalc...@bticino.it Added two clocking options for dm365 McBSP peripheral when used with I2S timings, that are SND_SOC_DAIFMT_CBS_CFS (the cpu generates clock and frame sync) and SND_SOC_DAIFMT_CBS_CFM (the cpu gets clock from external pin and generates frame sync). A slave clock management can be important when the external codec needs the system clock and the bit clock synchronized (tested with uda1345). This patch has been developed against the: http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git git tree and has been tested on bmx board (similar to dm365 evm, but using uda1345 as external audio codec). Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it All Acked-by: Liam Girdwood l...@slimlogic.co.uk But lets get some feedback from the DaVinci folks on this too. Acked-by: Sudhakar Rajashekhara sudhakar@ti.com Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/3] ASoC: DaVinci: Added two clocking possibilities to McBSP (I2S)
Hi,
On Fri, Jul 02, 2010 at 22:42:25, Raffaele Recalcati wrote:
From: Raffaele Recalcati raffaele.recalc...@bticino.it
Added two clocking options for dm365 McBSP peripheral when used
with I2S timings, that are SND_SOC_DAIFMT_CBS_CFS (the cpu generates
clock and frame sync) and SND_SOC_DAIFMT_CBS_CFM (the cpu gets clock
from external pin and generates frame sync).
A slave clock management can be important when the external codec needs
the system clock and the bit clock synchronized (tested with uda1345).
This patch has been developed against the:
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
git tree and has been tested on bmx board (similar to dm365 evm, but using
uda1345 as external audio codec).
Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
---
sound/soc/davinci/davinci-i2s.c | 111 +++---
sound/soc/davinci/davinci-i2s.h |5 ++
2 files changed, 107 insertions(+), 9 deletions(-)
diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
index adadcd3..a893538 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -26,6 +26,7 @@
#include mach/asp.h
#include davinci-pcm.h
+#include davinci-i2s.h
[...]
@@ -372,6 +383,19 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
return 0;
}
+static int davinci_i2s_dai_set_clkdiv(struct snd_soc_dai *cpu_dai,
+ int div_id, int div)
+{
+ struct davinci_mcbsp_dev *dev = cpu_dai-private_data;
+ int srgr;
srgr variable is not being used in this function. Consider removing it.
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 2/3] ASoC: DaVinci: Added selection of clk input pin for McBSP
Hi,
On Fri, Jul 02, 2010 at 22:42:26, Raffaele Recalcati wrote:
From: Raffaele Recalcati raffaele.recalc...@bticino.it
When McBSP peripheral gets the clock from an external pin,
there are three possible chooses, MCBSP_CLKX, MCBSP_CLKR
and MCBSP_CLKS.
evm-dm365 uses MCBSP_CLKR, instead in bmx board I have a different
hardware connection and I use MCBSP_CLKS, so I have added
this possibility.
This patch has been developed against the:
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
git tree and has been tested on bmx board (similar to dm365 evm)
Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
---
arch/arm/mach-davinci/include/mach/asp.h | 15 +++
sound/soc/davinci/davinci-i2s.c | 27 ++-
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/asp.h
b/arch/arm/mach-davinci/include/mach/asp.h
index 834725f..0847d21 100644
--- a/arch/arm/mach-davinci/include/mach/asp.h
+++ b/arch/arm/mach-davinci/include/mach/asp.h
@@ -153,6 +153,7 @@ struct davinci_mcbsp_dev {
[...]
unsigned int fmt;
int clk_div;
+ int clk_input_pin;
};
static inline void davinci_mcbsp_write_reg(struct davinci_mcbsp_dev *dev,
@@ -279,11 +280,26 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
DAVINCI_MCBSP_PCR_CLKRM;
break;
case SND_SOC_DAIFMT_CBM_CFS:
- /* McBSP CLKR pin is the input for the Sample Rate Generator.
- * McBSP FSR and FSX are driven by the Sample Rate Generator. */
- pcr = DAVINCI_MCBSP_PCR_SCLKME |
- DAVINCI_MCBSP_PCR_FSXM |
- DAVINCI_MCBSP_PCR_FSRM;
+ pcr = DAVINCI_MCBSP_PCR_FSRM | DAVINCI_MCBSP_PCR_FSXM;
+ /*
+ * Selection of the clock input pin that is the
+ * input for the Sample Rate Generator.
+ * McBSP FSR and FSX are driven by the Sample Rate
+ * Generator.
+ */
+ switch (dev-clk_input_pin) {
+ case MCBSP_CLKS:
+ pcr |= DAVINCI_MCBSP_PCR_CLKXM |
+ DAVINCI_MCBSP_PCR_CLKRM;
+ break;
+ case MCBSP_CLKR:
+ pcr |= DAVINCI_MCBSP_PCR_SCLKME;
+ break;
+ default:
+ dev_err(pdev-dev, bad clk_input_pin\n);
The above line results on compilation error as pdev is not defined in this
function.
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/3] ASoC: DaVinci: Added two clocking possibilities to McBSP (I2S)
Hi, On Sun, Jul 04, 2010 at 14:45:13, Mark Brown wrote: On Fri, Jul 02, 2010 at 07:12:25PM +0200, Raffaele Recalcati wrote: From: Raffaele Recalcati raffaele.recalc...@bticino.it Added two clocking options for dm365 McBSP peripheral when used with I2S timings, that are SND_SOC_DAIFMT_CBS_CFS (the cpu generates You've not sent any of these patches to the ALSA list or to Liam Girdwood, the other ASoC maintainer. In general you should be looking to include at least the subsystem maintainers and mailing list for the relevant code, anyone who actively works on the driver and possibly an architecture-specific list. The first two patches look OK, though I'd like to see some DaVinci people confirming they're OK. I tested this series on DM644x, DM355 and DM365 EVMs and audio is working fine with these patches. I have commented on first 2 patches of this series which needs to be fixed. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] i2c: davinci: Fix race when setting up for TX
Hi, On Tue, Jun 22, 2010 at 13:01:03, Jon Povey wrote: Move the interrupt enable after the first byte load for TX, as it was racing with the interrupt handler and corrupting dev-buf_len for messages 1 byte. Tested on DM355. Signed-off-by: Jon Povey jon.po...@racelogic.co.uk --- The race seems to have been introduced by 869e6692d527983958216f13c3c8e095791909df This fixes the problem for me, but someone from TI might want to comment on the validity of starting the transfer before enabling the RDY interrupts. Any possibility of losing interrupts? This fix can cause interrupts to be missed as there will be a race between writing to DXR and setting of interrupts. I think you can decrement dev-buf_len before writing to DXR register. This should resolve the original race condition which you had encountered. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 3/3] davinci: spi: modify platform data for updated SPIdriver
Brian, On Wed, Jun 16, 2010 at 23:07:45, Nicolas Luna wrote: Brian, I changed .io_type from SPI_IO_TYPE_DMA to SPI_IO_TYPE_INTR with .intr_level = 1. My kernel it not freezing at startup and both devices (CS1 and CS2) are still working fine. Anything else you would like to check? Nicolas On Wed, Jun 16, 2010 at 12:54 PM, Brian Niebuhr bnieb...@efjohnson.com wrote: I modified board-da850-evm.c with what you proposed and it's working very well. I didn't test the spi flash (because I do not have one on my custum hardware), but my 2 SPI CS (spidev1.1 and spidev1.2) are working. Nicolas - Would you mind taking a few minutes and testing interrupt mode for the devices on your board? I'm trying to reproduce the issue that Sudhakar was seeing, and I would appreciate additional testing if you've got the time. My mistake, I had not set intr_level to 1. When I set intr_level to 1, even interrupt mode is working fine. Are you planning to submit any new version of this patch series to the list after addressing the minor comments I had? Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 0/3] davinci: spi: replace existing SPI driver
Hi, On Tue, Jun 15, 2010 at 00:43:06, Brian Niebuhr wrote: I have compiled with the davinci_all_defconfig, but I don't have EVMs for the other davinci platforms to test with. I was testing this series on OMAP-L137, OMAP-L138 and DM365 EVMs and I found that on all these EVMS, Interrupt mode has problems. Driver works fine in DMA and POLL modes. Some problems which I had observed with the old driver are gone now. Do you have any idea what errors you're seeing in interrupt mode? I went and retested interrupt mode with several devices on my custom board and it still appeared to be working fine. It may be an interaction with code outside the driver because I'm running the identical driver code but I'm not running the latest kernel from the davinci git repository. I'm trying to figure out if I can get my DA850 EVM back into a state where I can debug this. Thanks for any hints you can give! You may be knowing that on OMAP-L138 EVM, we have M25P64 Flash on SPI. When the driver is configured in Interrupt mode, kernel booting just hangs. I noticed that the SPI probe function is not coming out of spi_bitbang_start() call. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] ASoC: DaVinci: Fix McASP hardware FIFO configuration
On DA830/OMAP-L137 and DA850/OMAP-L138 SoCs, the McASP peripheral
has FIFO support. This FIFO provides additional data buffering. It
also provides tolerance to variation in host/DMA controller response
times. More details of the FIFO operation can be found at
http://focus.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=sprufm1fileType=pdf
Existing sequence of steps for audio playback/capture are:
a. DMA configuration
b. McASP configuration (configures and enables FIFO)
c. Start DMA
d. Start McASP (enables FIFO)
During McASP configuration, while FIFO was being configured, FIFO
was being enabled in davinci_hw_common_param() function of
sound/soc/davinci/davinci-mcasp.c file. This generated a transmit
DMA event, which gets serviced when DMA is started.
https://patchwork.kernel.org/patch/84611/ patch clears the DMA
events before starting DMA, which is the right thing to do. But
this resulted in a state where DMA was waiting for an event from
McASP (after step c above), but the event which was already there,
has got cleared (because of step b above).
The fix is not to enable the FIFO during McASP configuration as
FIFO was being enabled as part of McASP start.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
Applies to latest of Linus's tree.
sound/soc/davinci/davinci-mcasp.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index 79f0f4a..d395509 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -612,7 +612,6 @@ static void davinci_hw_common_param(struct
davinci_audio_dev *dev, int stream)
NUMDMA_MASK);
mcasp_mod_bits(dev-base + DAVINCI_MCASP_WFIFOCTL,
((dev-txnumevt * tx_ser) 8), NUMEVT_MASK);
- mcasp_set_bits(dev-base + DAVINCI_MCASP_WFIFOCTL, FIFO_ENABLE);
}
if (dev-rxnumevt stream == SNDRV_PCM_STREAM_CAPTURE) {
@@ -623,7 +622,6 @@ static void davinci_hw_common_param(struct
davinci_audio_dev *dev, int stream)
NUMDMA_MASK);
mcasp_mod_bits(dev-base + DAVINCI_MCASP_RFIFOCTL,
((dev-rxnumevt * rx_ser) 8), NUMEVT_MASK);
- mcasp_set_bits(dev-base + DAVINCI_MCASP_RFIFOCTL, FIFO_ENABLE);
}
}
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 0/3] davinci: spi: replace existing SPI driver
Hi, On Mon, Jun 07, 2010 at 20:39:05, Brian Niebuhr wrote: NOTE This patch requires the EDMA patch at: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-March/018022.html which has since been reverted out of the davinci kernel. INTRODUCTION I have been working on a custom OMAP-L138 board that has multiple spi devices (seven) on one controller. These devices have a wide range of transfer parameters (speed, phase, polarity, internal and gpio chip selects). During my testing I found multiple errors in the davinci spi driver as a result of this complex setup. The primary issues were: 1. There is a race condition due to the SPIBUF read busy-waits for slow devices 2. I found some DMA transfer length errors under some conditions 3. The chip select code caused extra byte transfers (with no chip select active) due to writes to SPIDAT1 4. Several issues prevented using multiple SPI devices, especially the DMA code, as disucussed previously on the davinci list. The fixes to these problems were not simple. I ended up making fairly large changes to the driver, and those changes are contained in these patches. The full list of changes follows. CHANGE LIST 1. davinci_spi_chipelect() now performs both activation and deactivation of chip selects. This lets spi_bitbang fully control chip select activation, as intended by the SPI API. 2. Chip select activation does not cause extra writes to the SPI bus 3. Chip select activation does not use SPIDEF for control. This change will also allow for implementation of inverted (active high) chip selects in the future. 4. Added back gpio chip select capability from the old driver 5. Fixed prescale calculation for non-integer fractions of spi clock 6. Allow specification of SPI transfer parameters on a per-device (instead of per-controller) basis 7. Allow specification of polled, interrupt-based, or DMA operation on a per-device basis 8. Allow DMA with when more than one device is connected 9. Combined pio and dma txrx_bufs functions into one since they share large parts of their functionality, and to simplify item (8). 10. Use only SPIFMT0 to allow more than 4 devices TESTING I have tested the driver using a custom SPI stress test on my OMAP-L138-based board with three devices connected. I have tested configurations with all three devices polled, all three interrupt-based, all three DMA, and a mixture. I have compiled with the davinci_all_defconfig, but I don't have EVMs for the other davinci platforms to test with. I was testing this series on OMAP-L137, OMAP-L138 and DM365 EVMs and I found that on all these EVMS, Interrupt mode has problems. Driver works fine in DMA and POLL modes. Some problems which I had observed with the old driver are gone now. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 2/3] davinci: spi: add replacement SPI driver
Hi,
On Mon, Jun 07, 2010 at 20:39:07, Brian Niebuhr wrote:
Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com
---
arch/arm/mach-davinci/include/mach/spi.h | 41 +-
drivers/spi/davinci_spi.c| 936
++
drivers/spi/davinci_spi.h| 186 ++
3 files changed, 1149 insertions(+), 14 deletions(-)
create mode 100644 drivers/spi/davinci_spi.c
create mode 100644 drivers/spi/davinci_spi.h
diff --git a/arch/arm/mach-davinci/include/mach/spi.h
b/arch/arm/mach-davinci/include/mach/spi.h
index 910efbf..10c39d8 100644
--- a/arch/arm/mach-davinci/include/mach/spi.h
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -19,26 +19,39 @@
#ifndef __ARCH_ARM_DAVINCI_SPI_H
#define __ARCH_ARM_DAVINCI_SPI_H
+#define SPI_INTERN_CS0xFF
+
+/* resource flags for IORESOURCE_DMA resources */
+#define IORESOURCE_DMA_RX_CHAN 0x01
+#define IORESOURCE_DMA_TX_CHAN 0x02
+#define IORESOURCE_DMA_EVENT_Q 0x04
+
enum {
- SPI_VERSION_1, /* For DM355/DM365/DM6467 */
+ SPI_VERSION_1, /* For DM355/DM365/DM6467*/
Above line in the patch is not required.
[...]
+/*
+ * davinci_spi_probe - probe function for SPI Master Controller
+ * @pdev: platform_device structure which contains plateform specific data
+ *
+ * According to Linux Device Model this function will be invoked by Linux
+ * with plateform_device struct which contains the device specific info.
+ * This function will map the SPI controller's memory, register IRQ,
+ * Reset SPI controller and setting its registers to default value.
+ * It will invoke spi_bitbang_start to create work queue so that client
driver
+ * can register transfer method to work queue.
+ */
+static int davinci_spi_probe(struct platform_device *pdev)
+{
[...]
+
+ davinci_spi-version = pdata-version;
+
+ davinci_spi-bitbang.flags = SPI_NO_CS | SPI_LSB_FIRST | SPI_LOOP;
+ if (davinci_spi-version == SPI_VERSION_2)
+ davinci_spi-bitbang.flags |= SPI_READY;
+
+ dma_rx_chan = davinci_spi_get_dma_by_flag(pdev, IORESOURCE_DMA_RX_CHAN);
+ dma_tx_chan = davinci_spi_get_dma_by_flag(pdev, IORESOURCE_DMA_TX_CHAN);
+ dma_eventq = davinci_spi_get_dma_by_flag(pdev, IORESOURCE_DMA_EVENT_Q);
+ davinci_spi-dma_channels.dma_rx_channel = -1;
+ davinci_spi-dma_channels.dma_rx_sync_dev = dma_rx_chan;
+ davinci_spi-dma_channels.dma_tx_channel = -1;
+ davinci_spi-dma_channels.dma_tx_sync_dev = dma_tx_chan;
+ davinci_spi-dma_channels.dummy_param_slot = -1;
+ davinci_spi-dma_channels.eventq = dma_eventq;
Can the above configurations be done only in case if DMA mode?
[...]
+ ret = spi_bitbang_start(davinci_spi-bitbang);
+ if (ret != 0)
+ goto free_clk;
+
+ dev_info(pdev-dev, Controller at 0x%p \n, davinci_spi-base);
+
Some way of informing the user about the mode in which the driver is
working is desirable.
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 3/3] davinci: spi: modify platform data for updated SPI driver
Hi,
On Mon, Jun 07, 2010 at 20:39:08, Brian Niebuhr wrote:
Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com
---
arch/arm/mach-davinci/board-dm355-evm.c | 10 ++
arch/arm/mach-davinci/board-dm355-leopard.c | 10 ++
arch/arm/mach-davinci/board-dm365-evm.c | 10 ++
arch/arm/mach-davinci/dm355.c |6 --
arch/arm/mach-davinci/dm365.c |6 --
5 files changed, 30 insertions(+), 12 deletions(-)
[...]
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index a146849..0bd9f93 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -625,12 +625,6 @@ static u64 dm365_spi0_dma_mask = DMA_BIT_MASK(32);
static struct davinci_spi_platform_data dm365_spi0_pdata = {
.version= SPI_VERSION_1,
.num_chipselect = 2,
- .clk_internal = 1,
- .cs_hold= 1,
- .intr_level = 0,
- .poll_mode = 1,/* 0 - interrupt mode 1- polling mode */
- .c2tdelay = 0,
- .t2cdelay = 0,
};
static struct resource dm365_spi0_resources[] = {
This patch does not contain modifications to resource structure to 'or' the
IORESOURCE_DMA_RX_CHAN, IORESOURCE_DMA_TX_CHAN and IORESOURCE_DMA_EVENT_Q
flags with IORESOURCE_DMA. I don't think without this modification driver
will work.
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 3/6] davinci: edma: clear events in edma_start()
Hi,
On Sat, Jun 05, 2010 at 02:05:50, Brian Niebuhr wrote:
This patch causes that the sound can not work normally
on OMAP_L138.
snip
After revert it, the audio works fine.
This patch works fine on DM644x which has McBSP but breaks
audio on OMAP L138
(as you had mentioned) which has McASP. Ideally McBSP/McASP
should start after
EDMA is started. If not then this patch clears the EDMA
event which is actually
set by McBSP/McASP. As this patch is working fine on
DM644x, I think there is
some issue in the audio driver which needs to be debugged.
In the mean time, I think it makes sense to revert $SUBJECT patch in
davinci git until the audio driver is debugged.
Kevin -
What is the process or timeline for getting this patch reapplied? I am
working right now on resubmitting my patch for the Davinci SPI driver,
however that driver won't work as is without this patch. I could
probably hack something into the SPI driver to compensate, however if
all are agreed that drivers shouldn't rely on DMA events that occur
before the DMA is started, then it seems better to handle the issue in
the DMA driver as I did in the reverted patch.
I debugged this further today and I noticed that the issue of audio not
playing was observed only on DA830 and DA850 but not on DM6467 which also
has McASP. The only difference between McASP present on DM6467 and DA8XX
was hardware FIFO support. So when I disabled hardware FIFO on DA8XX devices,
even with this patch, audio started working correctly. Debugging further, I
found that, after doing FIFO configurations, FIFO was being enabled in
davinci_hw_common_param() function of sound/soc/davinci/davinci-mcasp.c file.
This was causing an extra McASP EDMA event to occur which was getting cleared
during edma_start(). This resulted in a state where EDMA was waiting for an
EDMA event from McASP, but the event which was already there, had got cleared.
Following patch fixes this issue.
===
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index 79f0f4a..d395509 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -612,7 +612,6 @@ static void davinci_hw_common_param(struct
davinci_audio_dev *dev, int stream)
NUMDMA_MASK);
mcasp_mod_bits(dev-base + DAVINCI_MCASP_WFIFOCTL,
((dev-txnumevt * tx_ser) 8), NUMEVT_MASK);
- mcasp_set_bits(dev-base + DAVINCI_MCASP_WFIFOCTL, FIFO_ENABLE);
}
if (dev-rxnumevt stream == SNDRV_PCM_STREAM_CAPTURE) {
@@ -623,7 +622,6 @@ static void davinci_hw_common_param(struct
davinci_audio_dev *dev, int stream)
NUMDMA_MASK);
mcasp_mod_bits(dev-base + DAVINCI_MCASP_RFIFOCTL,
((dev-rxnumevt * rx_ser) 8), NUMEVT_MASK);
- mcasp_set_bits(dev-base + DAVINCI_MCASP_RFIFOCTL, FIFO_ENABLE);
}
}
===
I'll be submitting this patch to the list soon.
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 2/2] Davinci-EDMA: Use default event queue numbers from platform data to initialize channels.
Hi Juha, On Thu, Jun 03, 2010 at 22:57:42, juha.kui...@elektrobit.com wrote: Without this change the edma_probe defaults all channels into EVENTQ_1. This is an issue on devices where not all EDMA controllers have multiple queues. Signed-off-by: Juha Kuikka juha.kui...@elektrobit.com diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index d33827a..24bf27c 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -1433,8 +1433,6 @@ static int __init edma_probe(struct platform_device *pdev) edma_cc[j]-num_cc = min_t(unsigned, info[j].n_cc, EDMA_MAX_CC); edma_cc[j]-default_queue = info[j].default_queue; - if (!edma_cc[j]-default_queue) - edma_cc[j]-default_queue = EVENTQ_1; On platforms which do not specify the default_queue from platform data, this patch maps them to EVENTQ_0. So this is a change from the existing behavior. You can do any of the following: a. Retain the default behavior by not removing the 2 lines above. Anyway, patch 1/2 specifies the default_queue for OMAP-L138, so we should be OK. b. Remove the 2 lines above and check the EDMA behavior on all affected platforms. c. Remove the 2 lines above and add default_queue as EVENTQ_1 for other platforms as well. dev_dbg(pdev-dev, DMA REG BASE ADDR=%p\n, edmacc_regs_base[j]); @@ -1474,7 +1472,7 @@ static int __init edma_probe(struct platform_device *pdev) * started by the codec engine will not cause audio defects. */ for (i = 0; i edma_cc[j]-num_channels; i++) - map_dmach_queue(j, i, EVENTQ_1); + map_dmach_queue(j, i, edma_cc[j]-default_queue); Please correct indenting here. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DA850 and MMCSD1 EDMA
Hi Juha, On Thu, Jun 03, 2010 at 05:48:51, Juha Kuikka wrote: Hi, Sorry about replying to my own email but I only get the digests. On Wed, May 19, 2010 at 5:38 PM, Juha Kuikka juha.kui...@gmail.com wrote: I am working with a HW that has an SDIO device on the second MMC/SD/SDIO controller (mmcsd1). I suspect the DMA channel numbers are wrong or for some reason the second EDMA controller has issues. Turns out the issue is the EDMA configuration. DA850 has two EDMA controllers. Unfortunately they are not identical, the first instance has two transfer controllers and two event queues but the second instance only has one of each. The static int __init edma_probe(struct platform_device *pdev) -function in dma.c has this code in it: edma_info[j]-default_queue = info[j].default_queue; if (!edma_info[j]-default_queue) edma_info[j]-default_queue = EVENTQ_1; /* Everything lives on transfer controller 1 until otherwise * specified. This way, long transfers on the low priority queue * started by the codec engine will not cause audio defects. */ for (i = 0; i edma_info[j]-num_channels; i++) map_dmach_queue(j, i, EVENTQ_1); And because the MMC driver allocates channels with EVENTQ_DEFAULT they get put into EVENTQ_1 which the second EDMA controller does not have and hence transfers stall. You are absolutely correct here. Your patch to fix this issue looks fine to me. Please go ahead and submit it as a patch to the same list. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 3/6] davinci: edma: clear events in edma_start()
Hi Stanley, On Tue, May 25, 2010 at 15:35:52, stanley.miao wrote: Kevin Hilman wrote: snip This patch causes that the sound can not work normally on OMAP_L138. Can you describe can not work normally? Does that mean simply does not work, or works with pops clicks etc.? Just to clarify... how did you isolate it to this patch. If you revert just this patch on current davinci git, do you have working sound as you expect again? Below is the test result: $/root aplay audiodump.wav Playing WAVE 'audiodump.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo aplay: pcm_write:1269: write error: Input/output error $/root After revert it, the audio works fine. This patch works fine on DM644x which has McBSP but breaks audio on OMAP L138 (as you had mentioned) which has McASP. Ideally McBSP/McASP should start after EDMA is started. If not then this patch clears the EDMA event which is actually set by McBSP/McASP. As this patch is working fine on DM644x, I think there is some issue in the audio driver which needs to be debugged. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DA850 and MMCSD1 EDMA
Hi Juha,
On Thu, May 20, 2010 at 06:08:41, Juha Kuikka wrote:
Hi,
I am working with a HW that has an SDIO device on the second
MMC/SD/SDIO controller (mmcsd1).
As the current Davinci-kernel does not have a platform device for the
second controller I have added my own.
It works for probing the device but fails on first CMD53. More
specifically the mmcd process freezes waiting for a response to the
command. This happens because the MMC controller does not have a
timeout for write but instead it relies on the interrupt from EDMA to
terminate writes.
If I disable the dma support in the MMC host driver the device works
without issues.
My mmcsd1 resources look like this:
static struct resource da8xx_mmcsd1_resources[] = {
{ /* registers */
.start = DA8XX_MMCSD1_BASE,
.end= DA8XX_MMCSD1_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
{ /* interrupt */
.start = IRQ_DA850_MMCSDINT0_1,
.end= IRQ_DA850_MMCSDINT0_1,
.flags = IORESOURCE_IRQ,
},
{ /* DMA RX */
.start = EDMA_CTLR_CHAN(1, 28),
.end= EDMA_CTLR_CHAN(1, 28),
.flags = IORESOURCE_DMA,
},
{ /* DMA TX */
.start = EDMA_CTLR_CHAN(1, 29),
.end= EDMA_CTLR_CHAN(1, 29),
.flags = IORESOURCE_DMA,
},
};
I suspect the DMA channel numbers are wrong or for some reason the
second EDMA controller has issues.
Looking at the OMAP-L138 datasheet table 6-13 EDMA Synchronization
events on page 98 I see that MMCSD1 does not have any events listed
but I suspected the 28 and 29 on the second controller to be the ones
to use. Maybe someone from TI could chime in on this?
The EDMA event numbers you are using are correct. Which kernel you are using
for testing this? If you are using a package from TI, then that package contains
an example for EDMA which you can execute and find out whether the second EDMA
instance is working or not.
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: da850-evm: MMC and NAND/NOR are mutually exclusive?
Hi Ben, On Thu, May 13, 2010 at 01:57:45, Ben Gardiner wrote: We are prototyping a system using the DA850 / L138 EVM from LogicPD. We noticed that in da850_evm_setup_nor_nand() of arch/arm/mach-davinci/board-da850-evm.c in both the davinci-linux and linux-omapl1 trees [1][2] there is a check for !HAS_MMC before NAND and NOR are initialized. This appears to be making use of SD/MMC cards and NAND flash mutually exclusive. We are interested in deploying a system that has both NAND flash and SD card support. As far as we can tell the restrictions due to SoC pin-mux are between SD0 and NOR but not NAND. We had a look through the EVM schematics and can't readily see any NAND vs SD0 conflicts there either. We would greatly appreciate any insight this list has into why the da850 board setup routine makes NAND and MMC support mutually exclusive. The MMC/SD card insert and write protect feature will not work properly if NAND is enabled. So we decided to make them exclusive. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2] davinci: MMC: Pass number of SG segments as platform data
Hi, On Tue, Mar 16, 2010 at 03:10:37, Andrew Morton wrote: On Fri, 12 Mar 2010 18:04:09 +0530 Sudhakar Rajashekhara sudhakar@ti.com wrote: On some platforms like DM355, the number of EDMA parameter slots available for EDMA_SLOT_ANY usage are few. In such cases, if MMC/SD uses 16 slots for each instance of MMC controller, then the number of slots available for other modules will be very few. By passing the number of EDMA slots to be used in MMC driver from platform data, EDMA slots available for other purposes can be controlled. It's unclear what the runtime effects of this change are. I assumed (without justification) that they're minor and I scheduled the patch for 2.6.35. If that was the wrong decision then blame the changelog ;) Most of the platforms will not use this platform data variable. But on DM355, as the number of EDMA resources available is limited, the number of scatter- gather segments used inside the MMC driver can be 8 (passed as platform data) instead of 16. On DM355, when the number of scatter-gather segments was reduced to 8, I saw a performance difference of about 0.25-0.4 Mbytes/sec during write. Read performance variations were negligible. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/2 v2] spi: overhaul davinci spi driver to correct multiple errors
Hi Brian, On Mon, Mar 15, 2010 at 21:20:13, Kevin Hilman wrote: Brian Niebuhr bnieb...@efjohnson.com writes: This patch is a significant overhaul of the davinci spi controller driver that corrects multiple errors: - Eliminate a race condition that exists for slow SPI devices - Fix DMA transfer length error - Fix limitations preventing multiple SPI devices on the same controller Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com The verbose description of the issues addressed from PATCH 0/2 should go here is well so it makes it into the permanent git history. I can certainly do that. That being said, I think for the sake of reviewing, you're going to need to break this up into reviewable pieces, each having a verbose description of the issues being solved. There is also a mixture of fixes, enhancements, renames etc. These should be done as separate patches. I know that it's more work to break it up like this, but that's the only way to make a large change like this reviewable by others. I guess I was hoping that this could be reviewed as if it were a new driver submission. I ended up more or less rewriting all of the functional parts of the driver (txrx_bufs(), chipselect(), IRQs and DMA callbacks), so it's very difficult to show this as a series of changes. I do understand the problem from your perspective, though. My thought was that if the TI folks were willing to look the driver over and they gave their blessing, that you would look at it as if it were a replacement driver and accept or deny it on that basis. I'm OK with the approach of considering it as a brand new driver. The changelog made me think it was a bunch of fixes/enhancements and not a re-write. It should then be made more clear in the changelog that this is essentially a re-write, and why it is not done in a series of small changes. Whichever approach, this will need to worked out between you and the origial TI authors (Sandeep, Sudahkar) who will need to review/signoff this replacement. I tried testing this patch on some DA8xx platforms I have but could not do it as the patch did not apply cleanly to Kevin's tree. You might have to rebase this patch so that it applies on Kevin's tree. Also, I would still prefer if you can breakdown this patch as per the various fixes you have done because the current SPI driver is already accepted in mainline and is working, of course with some limitations. But if you want to treat it as complete overhaul, then it is better to split the patch such that, one patch removes the existing driver and other patch adds the new driver. In this way it is easy to review the patch. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] davinci: MMC: Pass number of SG segments as platform data
Hi,
On Thu, Mar 11, 2010 at 16:30:45, Sergei Shtylyov wrote:
Hello.
Sudhakar Rajashekhara wrote:
On some platforms like DM355, the number of EDMA parameter
slots available for EDMA_SLOT_ANY usage are few. In such cases,
if MMC/SD uses 16 slots for each instance of MMC controller,
then the number of slots available for other modules will be
very few.
By passing the number of EDMA slots to be used in MMC driver
from platform data, EDMA slots available for other purposes
can be controlled.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/include/mach/mmc.h |3 +++
drivers/mmc/host/davinci_mmc.c | 22 +++---
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/mmc.h
b/arch/arm/mach-davinci/include/mach/mmc.h
index 5a85e24..384fc0e 100644
--- a/arch/arm/mach-davinci/include/mach/mmc.h
+++ b/arch/arm/mach-davinci/include/mach/mmc.h
@@ -22,6 +22,9 @@ struct davinci_mmc_config {
/* Version of the MMC/SD controller */
u8 version;
+
+ /* Number of sg segments */
+ u32 nr_sg;
Why waste 4 bytres if the maximum number is 16?
I'll modify it to u8 and re-submit the patch.
Thanks,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] davinci: MMC: Pass number of SG segments as platform data
Kevin, On Fri, Mar 12, 2010 at 05:09:24, Kevin Hilman wrote: Sudhakar Rajashekhara sudhakar@ti.com writes: On some platforms like DM355, the number of EDMA parameter slots available for EDMA_SLOT_ANY usage are few. In such cases, if MMC/SD uses 16 slots for each instance of MMC controller, then the number of slots available for other modules will be very few. By passing the number of EDMA slots to be used in MMC driver from platform data, EDMA slots available for other purposes can be controlled. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com --- arch/arm/mach-davinci/include/mach/mmc.h |3 +++ drivers/mmc/host/davinci_mmc.c | 22 +++--- 2 files changed, 18 insertions(+), 7 deletions(-) [...] @@ -1202,6 +1206,10 @@ static int __init davinci_mmcsd_probe(struct platform_device *pdev) init_mmcsd_host(host); + host-nr_sg = pdata-nr_sg - 1; If a board doesn't setup pdata-nr_sg it will be zero, leaving host-nr_sg = -1. + if (host-nr_sg MAX_NR_SG || host-nr_sg == 0) + host-nr_sg = MAX_NR_SG; Since host-nr_sg is unsigned, you get lucky and fix it up here, but for readability, this not too clean and should be more thorough. Wrapping the above in 'if (pdata-nr_sg)' is a more standard way of handling optional platform_data paramaters. I'll modify the patch as per your suggestion and resubmit it. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] davinci: MMC: Pass number of SG segments as platform data
On some platforms like DM355, the number of EDMA parameter
slots available for EDMA_SLOT_ANY usage are few. In such cases,
if MMC/SD uses 16 slots for each instance of MMC controller,
then the number of slots available for other modules will be
very few.
By passing the number of EDMA slots to be used in MMC driver
from platform data, EDMA slots available for other purposes
can be controlled.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
Following are the modifications from the previous version:
1. Changed the type of nr_sg variable to u8 from u32.
2. 'if (pdata-nr_sg)' check was introduced before initializing
host-nr_sg.
arch/arm/mach-davinci/include/mach/mmc.h |3 +++
drivers/mmc/host/davinci_mmc.c | 24 +---
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/mmc.h
b/arch/arm/mach-davinci/include/mach/mmc.h
index 5a85e24..d4f1e96 100644
--- a/arch/arm/mach-davinci/include/mach/mmc.h
+++ b/arch/arm/mach-davinci/include/mach/mmc.h
@@ -22,6 +22,9 @@ struct davinci_mmc_config {
/* Version of the MMC/SD controller */
u8 version;
+
+ /* Number of sg segments */
+ u8 nr_sg;
};
void davinci_setup_mmc(int module, struct davinci_mmc_config *config);
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 3bd0ba2..547d29c 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -137,15 +137,15 @@
/*
* One scatterlist dma segment is at most MAX_CCNT rw_threshold units,
- * and we handle up to NR_SG segments. MMC_BLOCK_BOUNCE kicks in only
+ * and we handle up to MAX_NR_SG segments. MMC_BLOCK_BOUNCE kicks in only
* for drivers with max_hw_segs == 1, making the segments bigger (64KB)
- * than the page or two that's otherwise typical. NR_SG == 16 gives at
- * least the same throughput boost, using EDMA transfer linkage instead
- * of spending CPU time copying pages.
+ * than the page or two that's otherwise typical. nr_sg (passed from
+ * platform data) == 16 gives at least the same throughput boost, using
+ * EDMA transfer linkage instead of spending CPU time copying pages.
*/
#define MAX_CCNT ((1 16) - 1)
-#define NR_SG 16
+#define MAX_NR_SG 16
static unsigned rw_threshold = 32;
module_param(rw_threshold, uint, S_IRUGO);
@@ -192,7 +192,7 @@ struct mmc_davinci_host {
struct edmacc_param tx_template;
struct edmacc_param rx_template;
unsignedn_link;
- u32 links[NR_SG - 1];
+ u32 links[MAX_NR_SG - 1];
/* For PIO we walk scatterlists one segment at a time. */
unsigned intsg_len;
@@ -202,6 +202,8 @@ struct mmc_davinci_host {
u8 version;
/* for ns in one cycle calculation */
unsigned ns_in_one_cycle;
+ /* Number of sg segments */
+ u8 nr_sg;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
@@ -568,6 +570,7 @@ davinci_release_dma_channels(struct mmc_davinci_host *host)
static int __init davinci_acquire_dma_channels(struct mmc_davinci_host *host)
{
+ u32 link_size;
int r, i;
/* Acquire master DMA write channel */
@@ -593,7 +596,8 @@ static int __init davinci_acquire_dma_channels(struct
mmc_davinci_host *host)
/* Allocate parameter RAM slots, which will later be bound to a
* channel as needed to handle a scatterlist.
*/
- for (i = 0; i ARRAY_SIZE(host-links); i++) {
+ link_size = min_t(unsigned, host-nr_sg, ARRAY_SIZE(host-links));
+ for (i = 0; i link_size; i++) {
r = edma_alloc_slot(EDMA_CTLR(host-txdma), EDMA_SLOT_ANY);
if (r 0) {
dev_dbg(mmc_dev(host-mmc), dma PaRAM alloc -- %d\n,
@@ -1202,6 +1206,12 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
init_mmcsd_host(host);
+ if (pdata-nr_sg)
+ host-nr_sg = pdata-nr_sg - 1;
+
+ if (host-nr_sg MAX_NR_SG || !host-nr_sg)
+ host-nr_sg = MAX_NR_SG;
+
host-use_dma = use_dma;
host-irq = irq;
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] davinci: MMC: Pass number of SG segments as platform data
On some platforms like DM355, the number of EDMA parameter
slots available for EDMA_SLOT_ANY usage are few. In such cases,
if MMC/SD uses 16 slots for each instance of MMC controller,
then the number of slots available for other modules will be
very few.
By passing the number of EDMA slots to be used in MMC driver
from platform data, EDMA slots available for other purposes
can be controlled.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/include/mach/mmc.h |3 +++
drivers/mmc/host/davinci_mmc.c | 22 +++---
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/mmc.h
b/arch/arm/mach-davinci/include/mach/mmc.h
index 5a85e24..384fc0e 100644
--- a/arch/arm/mach-davinci/include/mach/mmc.h
+++ b/arch/arm/mach-davinci/include/mach/mmc.h
@@ -22,6 +22,9 @@ struct davinci_mmc_config {
/* Version of the MMC/SD controller */
u8 version;
+
+ /* Number of sg segments */
+ u32 nr_sg;
};
void davinci_setup_mmc(int module, struct davinci_mmc_config *config);
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 3bd0ba2..19c050c 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -137,15 +137,15 @@
/*
* One scatterlist dma segment is at most MAX_CCNT rw_threshold units,
- * and we handle up to NR_SG segments. MMC_BLOCK_BOUNCE kicks in only
+ * and we handle up to MAX_NR_SG segments. MMC_BLOCK_BOUNCE kicks in only
* for drivers with max_hw_segs == 1, making the segments bigger (64KB)
- * than the page or two that's otherwise typical. NR_SG == 16 gives at
- * least the same throughput boost, using EDMA transfer linkage instead
- * of spending CPU time copying pages.
+ * than the page or two that's otherwise typical. nr_sg (passed from
+ * platform data) == 16 gives at least the same throughput boost, using
+ * EDMA transfer linkage instead of spending CPU time copying pages.
*/
#define MAX_CCNT ((1 16) - 1)
-#define NR_SG 16
+#define MAX_NR_SG 16
static unsigned rw_threshold = 32;
module_param(rw_threshold, uint, S_IRUGO);
@@ -192,7 +192,7 @@ struct mmc_davinci_host {
struct edmacc_param tx_template;
struct edmacc_param rx_template;
unsignedn_link;
- u32 links[NR_SG - 1];
+ u32 links[MAX_NR_SG - 1];
/* For PIO we walk scatterlists one segment at a time. */
unsigned intsg_len;
@@ -202,6 +202,8 @@ struct mmc_davinci_host {
u8 version;
/* for ns in one cycle calculation */
unsigned ns_in_one_cycle;
+ /* Number of sg segments */
+ u32 nr_sg;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
@@ -568,6 +570,7 @@ davinci_release_dma_channels(struct mmc_davinci_host *host)
static int __init davinci_acquire_dma_channels(struct mmc_davinci_host *host)
{
+ u32 link_size;
int r, i;
/* Acquire master DMA write channel */
@@ -593,7 +596,8 @@ static int __init davinci_acquire_dma_channels(struct
mmc_davinci_host *host)
/* Allocate parameter RAM slots, which will later be bound to a
* channel as needed to handle a scatterlist.
*/
- for (i = 0; i ARRAY_SIZE(host-links); i++) {
+ link_size = min_t(unsigned, host-nr_sg, ARRAY_SIZE(host-links));
+ for (i = 0; i link_size; i++) {
r = edma_alloc_slot(EDMA_CTLR(host-txdma), EDMA_SLOT_ANY);
if (r 0) {
dev_dbg(mmc_dev(host-mmc), dma PaRAM alloc -- %d\n,
@@ -1202,6 +1206,10 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
init_mmcsd_host(host);
+ host-nr_sg = pdata-nr_sg - 1;
+ if (host-nr_sg MAX_NR_SG || host-nr_sg == 0)
+ host-nr_sg = MAX_NR_SG;
+
host-use_dma = use_dma;
host-irq = irq;
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/6] i2c: davinci: Fix smbus Oops with AIC33 usage
Kevin,
On Wed, Jan 27, 2010 at 20:20:08, Kevin Hilman wrote:
Sudhakar Rajashekhara sudhakar@ti.com writes:
Hi,
On Wed, Jan 27, 2010 at 05:11:28, Kevin Hilman wrote:
From: Dirk Behme dirk.be...@googlemail.com
This fixes Oops at kernel startup while scanning for TLV320AIC23IDx
addresses.
Signed-off-by: Alexander Vasiliev alexvasil...@gmail.com
Signed-off-by: Brad Griffis bgrif...@ti.com
Signed-off-by: Dirk Behme dirk.be...@gmail.com
Acked-by: Kevin Hilman khil...@mvista.com
---
drivers/i2c/busses/i2c-davinci.c | 29 +
1 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c
b/drivers/i2c/busses/i2c-davinci.c
index c89687a..444a9f2 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
[...]
@@ -290,6 +293,16 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
davinci_i2c_write_reg(dev, DAVINCI_I2C_IMR_REG, w);
dev-terminate = 0;
+
+ /* First byte should be set here, not after interrupt,
+ * because transmit-data-ready interrupt can come before
+ * NACK-interrupt during sending of previous message and
+ * ICDXR may have wrong data */
+ if ((!(msg-flags I2C_M_RD)) dev-buf_len) {
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_DXR_REG, *dev-buf++);
+ dev-buf_len--;
+ }
+
I found an issue on DA850 while using this patch.
ok, I'll drop this one for 2.6.34 until we figure this out.
I think the above code should come after the
below lines because an I2C transaction is being carried out before
configuring the I2C mode
register (which has bits to configure Master, Start condition etc), which
causes undefined
behavior.
hmm, are you seeing this behavior on davinci git too? This is the same
patch that has been in davinci git for some time?
The following patch fixes the issue I reported. I have tested it extensively on
DA850/OMAP-L138.
You can roll-in these changes into the current patch.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
drivers/i2c/busses/i2c-davinci.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 35f9daa..8526bce 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -308,6 +308,9 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
dev-terminate = 0;
+ /* write the data into mode register */
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+
/* First byte should be set here, not after interrupt,
* because transmit-data-ready interrupt can come before
* NACK-interrupt during sending of previous message and
@@ -317,9 +320,6 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
dev-buf_len--;
}
- /* write the data into mode register */
- davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
-
r = wait_for_completion_interruptible_timeout(dev-cmd_complete,
dev-adapter.timeout);
if (r == 0) {
--
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/6] i2c: davinci: Fix smbus Oops with AIC33 usage
Hi,
On Wed, Jan 27, 2010 at 05:11:28, Kevin Hilman wrote:
From: Dirk Behme dirk.be...@googlemail.com
This fixes Oops at kernel startup while scanning for TLV320AIC23IDx
addresses.
Signed-off-by: Alexander Vasiliev alexvasil...@gmail.com
Signed-off-by: Brad Griffis bgrif...@ti.com
Signed-off-by: Dirk Behme dirk.be...@gmail.com
Acked-by: Kevin Hilman khil...@mvista.com
---
drivers/i2c/busses/i2c-davinci.c | 29 +
1 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c
b/drivers/i2c/busses/i2c-davinci.c
index c89687a..444a9f2 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
[...]
@@ -290,6 +293,16 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
davinci_i2c_write_reg(dev, DAVINCI_I2C_IMR_REG, w);
dev-terminate = 0;
+
+ /* First byte should be set here, not after interrupt,
+ * because transmit-data-ready interrupt can come before
+ * NACK-interrupt during sending of previous message and
+ * ICDXR may have wrong data */
+ if ((!(msg-flags I2C_M_RD)) dev-buf_len) {
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_DXR_REG, *dev-buf++);
+ dev-buf_len--;
+ }
+
I found an issue on DA850 while using this patch. I think the above code should
come after the
below lines because an I2C transaction is being carried out before configuring
the I2C mode
register (which has bits to configure Master, Start condition etc), which
causes undefined
behavior.
/* write the data into mode register */
davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/6] i2c: davinci: Fix smbus Oops with AIC33 usage
On Wed, Jan 27, 2010 at 20:20:08, Kevin Hilman wrote:
Sudhakar Rajashekhara sudhakar@ti.com writes:
Hi,
On Wed, Jan 27, 2010 at 05:11:28, Kevin Hilman wrote:
From: Dirk Behme dirk.be...@googlemail.com
This fixes Oops at kernel startup while scanning for TLV320AIC23IDx
addresses.
Signed-off-by: Alexander Vasiliev alexvasil...@gmail.com
Signed-off-by: Brad Griffis bgrif...@ti.com
Signed-off-by: Dirk Behme dirk.be...@gmail.com
Acked-by: Kevin Hilman khil...@mvista.com
---
drivers/i2c/busses/i2c-davinci.c | 29 +
1 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c
b/drivers/i2c/busses/i2c-davinci.c
index c89687a..444a9f2 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
[...]
@@ -290,6 +293,16 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
davinci_i2c_write_reg(dev, DAVINCI_I2C_IMR_REG, w);
dev-terminate = 0;
+
+ /* First byte should be set here, not after interrupt,
+ * because transmit-data-ready interrupt can come before
+ * NACK-interrupt during sending of previous message and
+ * ICDXR may have wrong data */
+ if ((!(msg-flags I2C_M_RD)) dev-buf_len) {
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_DXR_REG, *dev-buf++);
+ dev-buf_len--;
+ }
+
I found an issue on DA850 while using this patch.
ok, I'll drop this one for 2.6.34 until we figure this out.
I think the above code should come after the
below lines because an I2C transaction is being carried out before
configuring the I2C mode
register (which has bits to configure Master, Start condition etc), which
causes undefined
behavior.
hmm, are you seeing this behavior on davinci git too? This is the same
patch that has been in davinci git for some time?
Yes, I am seeing this issue on davinci git.
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2 0/9] davinci: EDMA updates
This patch set corrects some issues with the existing EDMA driver and also adds support for EDMA resource (channel/slots) sharing between two processors (say ARM and DSP). The patch set has been tested on DM646x, OMAP-L137 and OMAP-L138 EVM boards. First 6 patches of this set are same as the previous patches. The last 3 patches are different. Sudhakar Rajashekhara (9): davinci: Correct return value of edma_alloc_channel api davinci: Keep count of channel controllers on a platform davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case davinci: build list of unused EDMA events dynamically davinci: support for EDMA resource sharing davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 davinci: da830/omapl137: Specify reserved channels/slots davinci: da850/omapl138: Specify reserved channels/slots davinci: dm646x: Specify reserved EDMA channel/slots for DM646x arch/arm/mach-davinci/devices-da8xx.c | 191 +++-- arch/arm/mach-davinci/dm355.c |8 -- arch/arm/mach-davinci/dm644x.c| 10 -- arch/arm/mach-davinci/dm646x.c| 33 - arch/arm/mach-davinci/dma.c | 101 +--- arch/arm/mach-davinci/include/mach/edma.h |4 +- 6 files changed, 291 insertions(+), 56 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 3/9] davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case
Though edma_alloc_channel api was looping through the available
channel controllers in EDMA_CHANNEL_ANY case, it was never
returning the channel for 2nd channel controller, if 1st
channel controller had no free channels. This issue has
been fixed with this patch.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/dma.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 97a49f9..89a3dcc 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -595,7 +595,7 @@ int edma_alloc_channel(int channel,
void *data,
enum dma_event_q eventq_no)
{
- unsigned i, done, ctlr = 0;
+ unsigned i, done = 0, ctlr = 0;
if (channel = 0) {
ctlr = EDMA_CTLR(channel);
@@ -611,7 +611,7 @@ int edma_alloc_channel(int channel,
edma_info[i]-num_channels,
channel);
if (channel == edma_info[i]-num_channels)
- return -ENOMEM;
+ break;
if (!test_and_set_bit(channel,
edma_info[i]-edma_inuse)) {
done = 1;
@@ -623,6 +623,8 @@ int edma_alloc_channel(int channel,
if (done)
break;
}
+ if (!done)
+ return -ENOMEM;
} else if (channel = edma_info[ctlr]-num_channels) {
return -EINVAL;
} else if (test_and_set_bit(channel, edma_info[ctlr]-edma_inuse)) {
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/9] davinci: Correct return value of edma_alloc_channel api
Currently, edma_alloc_channel api is returning the channel number without prepending the controller on which the channel was allocated. So, if a channel is allocated on 2nd controller, calls subsequent to edma_alloc_channel would never know that channel was allocated on the 2nd controller, and continue to operate on 1st controller, resulting in edma failure. This patch fixes this issue. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com --- arch/arm/mach-davinci/dma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index 648fbb7..5a71f4d 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -642,7 +642,7 @@ int edma_alloc_channel(int channel, map_dmach_queue(ctlr, channel, eventq_no); - return channel; + return EDMA_CTLR_CHAN(ctlr, channel); } EXPORT_SYMBOL(edma_alloc_channel); -- 1.5.6 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 2/9] davinci: Keep count of channel controllers on a platform
Some architectures have only one channel controller, but the
edma_alloc_channel api loops twice to findout the free channel
available in EDMA_CHANNEL_ANY case. A new variable has been
introduced to keep count of number of channel controllers being
used on a particular architecture.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/dma.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 5a71f4d..97a49f9 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -243,6 +243,7 @@ struct edma {
};
static struct edma *edma_info[EDMA_MAX_CC];
+static int arch_num_cc;
/* dummy param set used to (re)initialize parameter RAM slots */
static const struct edmacc_param dummy_paramset = {
@@ -602,7 +603,7 @@ int edma_alloc_channel(int channel,
}
if (channel 0) {
- for (i = 0; i EDMA_MAX_CC; i++) {
+ for (i = 0; i arch_num_cc; i++) {
channel = 0;
for (;;) {
channel = find_next_bit(edma_info[i]-
@@ -1467,6 +1468,7 @@ static int __init edma_probe(struct platform_device *pdev)
edma_write_array2(j, EDMA_DRAE, i, 1, 0x0);
edma_write_array(j, EDMA_QRAE, i, 0x0);
}
+ arch_num_cc++;
}
if (tc_errs_handled) {
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2 8/9] davinci: da850/omapl138: Specify reserved channels/slots
Pass reserved EDMA channel/slots as platform data for da850/omap-l138.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/devices-da8xx.c | 39 +
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index e32579f..7739391 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -134,6 +134,41 @@ static const s16 da830_dma_rsv_slots[][2] = {
{-1, -1}
};
+/*
+ * The following EDMA channels/slots are not being used by drivers (for
+ * example: Timer, GPIO, UART events etc) on da850/omap-l138, hence they
+ * are being reserved for codecs on the DSP side.
+ */
+static const s16 da850_dma0_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 8, 6},
+ {24, 4},
+ {30, 2},
+ {-1, -1}
+};
+
+static const s16 da850_dma0_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 8, 6},
+ {24, 4},
+ {30, 50},
+ {-1, -1}
+};
+
+static const s16 da850_dma1_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 0, 28},
+ {30, 2},
+ {-1, -1}
+};
+
+static const s16 da850_dma1_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 0, 28},
+ {30, 90},
+ {-1, -1}
+};
+
static struct edma_soc_info da830_edma_info[] = {
{
.n_channel = 32,
@@ -155,6 +190,8 @@ static struct edma_soc_info da850_edma_info[] = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
+ .rsv_chans = da850_dma0_rsv_chans,
+ .rsv_slots = da850_dma0_rsv_slots,
.queue_tc_mapping = da8xx_queue_tc_mapping,
.queue_priority_mapping = da8xx_queue_priority_mapping,
},
@@ -164,6 +201,8 @@ static struct edma_soc_info da850_edma_info[] = {
.n_slot = 128,
.n_tc = 1,
.n_cc = 1,
+ .rsv_chans = da850_dma1_rsv_chans,
+ .rsv_slots = da850_dma1_rsv_slots,
.queue_tc_mapping = da850_queue_tc_mapping,
.queue_priority_mapping = da850_queue_priority_mapping,
},
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 5/9] davinci: support for EDMA resource sharing
Current EDMA driver is not taking care of EDMA channels/slots
which are allocated from other processor, say DSP. If a
channel/slot is allocated from DSP, the existing EDMA driver
can still allocate the same resource on ARM.
This patch enables the user to pass the channel/slots reserved
for DSP as platform data. EDMA driver scans this list during
probe and prepares a bitmap of channel/slots which can be used
on ARM side.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Cc: David Brownell davi...@pacbell.net
---
arch/arm/mach-davinci/dma.c | 36 -
arch/arm/mach-davinci/include/mach/edma.h |2 +
2 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 15dd886..d3e1702 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -206,6 +206,18 @@ static inline void edma_parm_or(unsigned ctlr, int offset,
int param_no,
edma_or(ctlr, EDMA_PARM + offset + (param_no 5), or);
}
+static inline void set_bits(int offset, int len, unsigned long *p)
+{
+ for (; len 0; len--)
+ set_bit(offset + (len - 1), p);
+}
+
+static inline void clear_bits(int offset, int len, unsigned long *p)
+{
+ for (; len 0; len--)
+ clear_bit(offset + (len - 1), p);
+}
+
/*/
/* actual number of DMA channels and slots on this silicon */
@@ -1379,8 +1391,10 @@ static int __init edma_probe(struct platform_device
*pdev)
struct edma_soc_info*info = pdev-dev.platform_data;
const s8(*queue_priority_mapping)[2];
const s8(*queue_tc_mapping)[2];
- int i, j, found = 0;
+ int i, j, off, ln, found = 0;
int status = -1;
+ const s16 (*rsv_chans)[2];
+ const s16 (*rsv_slots)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
struct resource *r[EDMA_MAX_CC] = {NULL};
@@ -1447,6 +1461,26 @@ static int __init edma_probe(struct platform_device
*pdev)
memset(edma_info[j]-edma_unused, 0xff,
sizeof(edma_info[j]-edma_unused));
+ /* Clear the reserved channels in unused list */
+ rsv_chans = info[j].rsv_chans;
+ if (rsv_chans) {
+ for (i = 0; rsv_chans[i][0] != -1; i++) {
+ off = rsv_chans[i][0];
+ ln = rsv_chans[i][1];
+ clear_bits(off, ln, edma_info[j]-edma_unused);
+ }
+ }
+
+ /* Set the reserved channels/slots in inuse list */
+ rsv_slots = info[j].rsv_slots;
+ if (rsv_slots) {
+ for (i = 0; rsv_slots[i][0] != -1; i++) {
+ off = rsv_slots[i][0];
+ ln = rsv_slots[i][1];
+ set_bits(off, ln, edma_info[j]-edma_inuse);
+ }
+ }
+
sprintf(irq_name, edma%d, j);
irq[j] = platform_get_irq_byname(pdev, irq_name);
edma_info[j]-irq_res_start = irq[j];
diff --git a/arch/arm/mach-davinci/include/mach/edma.h
b/arch/arm/mach-davinci/include/mach/edma.h
index ced3092..55e217e 100644
--- a/arch/arm/mach-davinci/include/mach/edma.h
+++ b/arch/arm/mach-davinci/include/mach/edma.h
@@ -280,6 +280,8 @@ struct edma_soc_info {
unsignedn_cc;
enum dma_event_qdefault_queue;
+ const s16 (*rsv_chans)[2];
+ const s16 (*rsv_slots)[2];
const s8(*queue_tc_mapping)[2];
const s8(*queue_priority_mapping)[2];
};
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 6/9] davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138
Currently da850/omap-l138 supports only one channel controller
instance of EDMA though EDMA driver as such supports multiple
channel controller instances. This patch adds platform data
for the 2nd EDMA channel controller. As, the platform data
differ between da830/omap-l137 and da850/omap-l138, existing
code has been re-shuffled to accommodate this.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/devices-da8xx.c | 121 +++--
1 files changed, 114 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index ab12a8f..0a96791 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -24,8 +24,10 @@
#include clock.h
#define DA8XX_TPCC_BASE0x01c0
+#define DA850_TPCC1_BASE 0x01e3
#define DA8XX_TPTC0_BASE 0x01c08000
#define DA8XX_TPTC1_BASE 0x01c08400
+#define DA850_TPTC2_BASE 0x01e38000
#define DA8XX_WDOG_BASE0x01c21000 /*
DA8XX_TIMER64P1_BASE */
#define DA8XX_I2C0_BASE0x01c22000
#define DA8XX_RTC_BASE 0x01C23000
@@ -97,7 +99,31 @@ static const s8 da8xx_queue_priority_mapping[][2] = {
{-1, -1}
};
-static struct edma_soc_info da8xx_edma_info[] = {
+static const s8 da850_queue_tc_mapping[][2] = {
+ /* {event queue no, TC no} */
+ {0, 0},
+ {-1, -1}
+};
+
+static const s8 da850_queue_priority_mapping[][2] = {
+ /* {event queue no, Priority} */
+ {0, 3},
+ {-1, -1}
+};
+
+static struct edma_soc_info da830_edma_info[] = {
+ {
+ .n_channel = 32,
+ .n_region = 4,
+ .n_slot = 128,
+ .n_tc = 2,
+ .n_cc = 1,
+ .queue_tc_mapping = da8xx_queue_tc_mapping,
+ .queue_priority_mapping = da8xx_queue_priority_mapping,
+ },
+};
+
+static struct edma_soc_info da850_edma_info[] = {
{
.n_channel = 32,
.n_region = 4,
@@ -107,9 +133,49 @@ static struct edma_soc_info da8xx_edma_info[] = {
.queue_tc_mapping = da8xx_queue_tc_mapping,
.queue_priority_mapping = da8xx_queue_priority_mapping,
},
+ {
+ .n_channel = 32,
+ .n_region = 4,
+ .n_slot = 128,
+ .n_tc = 1,
+ .n_cc = 1,
+ .queue_tc_mapping = da850_queue_tc_mapping,
+ .queue_priority_mapping = da850_queue_priority_mapping,
+ },
+};
+
+static struct resource da830_edma_resources[] = {
+ {
+ .name = edma_cc0,
+ .start = DA8XX_TPCC_BASE,
+ .end= DA8XX_TPCC_BASE + SZ_32K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = edma_tc0,
+ .start = DA8XX_TPTC0_BASE,
+ .end= DA8XX_TPTC0_BASE + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = edma_tc1,
+ .start = DA8XX_TPTC1_BASE,
+ .end= DA8XX_TPTC1_BASE + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = edma0,
+ .start = IRQ_DA8XX_CCINT0,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = edma0_err,
+ .start = IRQ_DA8XX_CCERRINT,
+ .flags = IORESOURCE_IRQ,
+ },
};
-static struct resource da8xx_edma_resources[] = {
+static struct resource da850_edma_resources[] = {
{
.name = edma_cc0,
.start = DA8XX_TPCC_BASE,
@@ -129,6 +195,18 @@ static struct resource da8xx_edma_resources[] = {
.flags = IORESOURCE_MEM,
},
{
+ .name = edma_cc1,
+ .start = DA850_TPCC1_BASE,
+ .end= DA850_TPCC1_BASE + SZ_32K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = edma_tc2,
+ .start = DA850_TPTC2_BASE,
+ .end= DA850_TPTC2_BASE + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
.name = edma0,
.start = IRQ_DA8XX_CCINT0,
.flags = IORESOURCE_IRQ,
@@ -138,21 +216,50 @@ static struct resource da8xx_edma_resources[] = {
.start = IRQ_DA8XX_CCERRINT,
.flags = IORESOURCE_IRQ,
},
+ {
+ .name = edma1,
+ .start = IRQ_DA850_CCINT1,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name
[PATCH 4/9] davinci: build list of unused EDMA events dynamically
Currently, the edma_noevent list is passed from platform data.
But on some architectures, there will be many EDMA channels
which will not be used at all. This patch scans all the
platform devices and then builds a list of events which are
not being used. The unused event list will be used to allocate
EDMA channels in case of EDMA_CHANNEL_ANY usage instead of the
edma_noevent being used earlier for this purpose.
This patch is based on David Brownells's suggestion at
http://article.gmane.org/gmane.linux.davinci/15176.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/devices-da8xx.c |6 ---
arch/arm/mach-davinci/dm355.c |8
arch/arm/mach-davinci/dm644x.c| 10 -
arch/arm/mach-davinci/dm646x.c|9 -
arch/arm/mach-davinci/dma.c | 55 ++--
arch/arm/mach-davinci/include/mach/edma.h |2 -
6 files changed, 43 insertions(+), 47 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 0c759ad..ab12a8f 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -83,11 +83,6 @@ struct platform_device da8xx_serial_device = {
},
};
-static const s8 da8xx_dma_chan_no_event[] = {
- 20, 21,
- -1
-};
-
static const s8 da8xx_queue_tc_mapping[][2] = {
/* {event queue no, TC no} */
{0, 0},
@@ -109,7 +104,6 @@ static struct edma_soc_info da8xx_edma_info[] = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
- .noevent= da8xx_dma_chan_no_event,
.queue_tc_mapping = da8xx_queue_tc_mapping,
.queue_priority_mapping = da8xx_queue_priority_mapping,
},
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 2244e8c..9b2c40e 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -564,13 +564,6 @@ static u8 dm355_default_priorities[DAVINCI_N_AINTC_IRQ] = {
/*--*/
-static const s8 dma_chan_dm355_no_event[] = {
- 12, 13, 24, 56, 57,
- 58, 59, 60, 61, 62,
- 63,
- -1
-};
-
static const s8
queue_tc_mapping[][2] = {
/* {event queue no, TC no} */
@@ -594,7 +587,6 @@ static struct edma_soc_info dm355_edma_info[] = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
- .noevent= dma_chan_dm355_no_event,
.queue_tc_mapping = queue_tc_mapping,
.queue_priority_mapping = queue_priority_mapping,
},
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index e65e29e..61856f8 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -479,15 +479,6 @@ static u8 dm644x_default_priorities[DAVINCI_N_AINTC_IRQ] =
{
/*--*/
-static const s8 dma_chan_dm644x_no_event[] = {
-0, 1, 12, 13, 14,
- 15, 25, 30, 31, 45,
- 46, 47, 55, 56, 57,
- 58, 59, 60, 61, 62,
- 63,
- -1
-};
-
static const s8
queue_tc_mapping[][2] = {
/* {event queue no, TC no} */
@@ -511,7 +502,6 @@ static struct edma_soc_info dm644x_edma_info[] = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
- .noevent= dma_chan_dm644x_no_event,
.queue_tc_mapping = queue_tc_mapping,
.queue_priority_mapping = queue_priority_mapping,
},
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 6f80616..de306ca 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -511,14 +511,6 @@ static u8 dm646x_default_priorities[DAVINCI_N_AINTC_IRQ] =
{
/*--*/
-static const s8 dma_chan_dm646x_no_event[] = {
-0, 1, 2, 3, 13,
- 14, 15, 24, 25, 26,
- 27, 30, 31, 54, 55,
- 56,
- -1
-};
-
/* Four Transfer Controllers on DM646x */
static const s8
dm646x_queue_tc_mapping[][2] = {
@@ -547,7 +539,6 @@ static struct edma_soc_info dm646x_edma_info[] = {
.n_slot = 512,
.n_tc = 4,
.n_cc = 1,
- .noevent= dma_chan_dm646x_no_event,
.queue_tc_mapping = dm646x_queue_tc_mapping,
.queue_priority_mapping = dm646x_queue_priority_mapping,
},
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 89a3dcc
[PATCH v2 7/9] davinci: da830/omapl137: Specify reserved channels/slots
Pass reserved EDMA channel/slots as platform data for da830/omap-l137.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/devices-da8xx.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 0a96791..e32579f 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -111,6 +111,29 @@ static const s8 da850_queue_priority_mapping[][2] = {
{-1, -1}
};
+/*
+ * The following EDMA channels/slots are not being used by drivers (for
+ * example: Timer, GPIO, UART events etc) on da830/omap-l137, hence they
+ * are being reserved for codecs on the DSP side.
+ */
+static const s16 da830_dma_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 8, 2},
+ {12, 2},
+ {24, 4},
+ {30, 2},
+ {-1, -1}
+};
+
+static const s16 da830_dma_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 8, 2},
+ {12, 2},
+ {24, 4},
+ {30, 26},
+ {-1, -1}
+};
+
static struct edma_soc_info da830_edma_info[] = {
{
.n_channel = 32,
@@ -118,6 +141,8 @@ static struct edma_soc_info da830_edma_info[] = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
+ .rsv_chans = da830_dma_rsv_chans,
+ .rsv_slots = da830_dma_rsv_slots,
.queue_tc_mapping = da8xx_queue_tc_mapping,
.queue_priority_mapping = da8xx_queue_priority_mapping,
},
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2 9/9] davinci: dm646x: Specify reserved EDMA channel/slots for DM646x
Pass reserved EDMA channel/slots as platform data for dm646x.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/dm646x.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index de306ca..99224ec 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -511,6 +511,32 @@ static u8 dm646x_default_priorities[DAVINCI_N_AINTC_IRQ] =
{
/*--*/
+/*
+ * The following EDMA channels/slots are not being used by drivers (for
+ * example: Timer, GPIO, UART events etc) on dm646x, hence they are being
+ * reserved for codecs on the DSP side.
+ */
+static const s16 dm646x_dma_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 0, 4},
+ {13, 3},
+ {24, 4},
+ {30, 2},
+ {54, 3},
+ {-1, -1}
+};
+
+static const s16 dm646x_dma_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 0, 4},
+ {13, 3},
+ {24, 4},
+ {30, 2},
+ {54, 3},
+ {128, 384},
+ {-1, -1}
+};
+
/* Four Transfer Controllers on DM646x */
static const s8
dm646x_queue_tc_mapping[][2] = {
@@ -539,6 +565,8 @@ static struct edma_soc_info dm646x_edma_info[] = {
.n_slot = 512,
.n_tc = 4,
.n_cc = 1,
+ .rsv_chans = dm646x_dma_rsv_chans,
+ .rsv_slots = dm646x_dma_rsv_slots,
.queue_tc_mapping = dm646x_queue_tc_mapping,
.queue_priority_mapping = dm646x_queue_priority_mapping,
},
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] mtd-nand: davinci: Correct 4-bit error correction
On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after
setting the 4BITECC_ADD_CALC_START bit in the NAND Flash
control register to 1 and before waiting for the NAND Flash
status register to be equal to 1, 2 or 3, we have to wait
till the ECC HW goes to correction state. Without this wait,
ECC correction calculations will not be proper.
This has been tested on DA830/OMAP-L137, DA850/OMAP-L138,
DM355 and DM365 EVMs.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Acked-by: Sneha Narnakaje nsnehapra...@ti.com
---
From the previous version, timeout has been added to come out
of the infinite loop.
drivers/mtd/nand/davinci_nand.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index f13f5b9..89f0a0f 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -310,7 +310,9 @@ static int nand_davinci_correct_4bit(struct mtd_info *mtd,
unsigned short ecc10[8];
unsigned short *ecc16;
u32 syndrome[4];
+ u32 ecc_state;
unsigned num_errors, corrected;
+ unsigned long timeo = jiffies + msecs_to_jiffies(100);
/* All bytes 0xff? It's an erased page; ignore its ECC. */
for (i = 0; i 10; i++) {
@@ -360,6 +362,21 @@ compare:
*/
davinci_nand_writel(info, NANDFCR_OFFSET,
davinci_nand_readl(info, NANDFCR_OFFSET) | BIT(13));
+
+ /*
+* ECC_STATE field reads 0x3 (Error correction complete) immediately
+* after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
+* begin trying to poll for the state, you may fall right out of your
+* loop without any of the correction calculations having taken place.
+* The recommendation from the hardware team is to wait till ECC_STATE
+* reads less than 4, which means ECC HW has entered correction state.
+*/
+ do {
+ ecc_state = (davinci_nand_readl(info,
+ NANDFSR_OFFSET) 8) 0x0f;
+ cpu_relax();
+ } while ((ecc_state 4) time_before(jiffies, timeo));
+
for (;;) {
u32 fsr = davinci_nand_readl(info, NANDFSR_OFFSET);
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] mtd-nand: davinci: Correct 4-bit error correction
On Tue, Nov 03, 2009 at 16:01:10, Sudhakar Rajashekhara wrote:
On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after
setting the 4BITECC_ADD_CALC_START bit in the NAND Flash
control register to 1 and before waiting for the NAND Flash
status register to be equal to 1, 2 or 3, we have to wait
till the ECC HW goes to correction state. Without this wait,
ECC correction calculations will not be proper.
This has been tested on DA830/OMAP-L137, DA850/OMAP-L138,
DM355 and DM365 EVMs.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Acked-by: Sneha Narnakaje nsnehapra...@ti.com
---
drivers/mtd/nand/davinci_nand.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index fe3eba8..8a32999 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
[...]
+
+ /*
+ * ECC_STATE field reads 0x3 (Error correction complete) immediately
+ * after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
+ * begin trying to poll for the state, you may fall right out of your
+ * loop without any of the correction calculations having taken place.
+ * The recommendation from the hardware team is to wait till ECC_STATE
+ * reads less than 4, which means ECC HW has entered correction state.
+ */
+ do {
+ ecc_state = (davinci_nand_readl(info,
+ NANDFSR_OFFSET) 8) 0x0f;
+ cpu_relax();
+ } while (ecc_state 4);
+
Kevin,
David Woodhouse has suggested to add timeout in the above loop. I'll be
re-submitting
this patch soon.
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 2/9] davinci: Keep count of channel controllers on a platform
Some architectures have only one channel controller, but the
edma_alloc_channel api loops twice to findout the free channel
available in EDMA_CHANNEL_ANY case. A new variable has been
introduced to keep count of number of channel controllers being
used on a particular architecture.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/dma.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 5a71f4d..97a49f9 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -243,6 +243,7 @@ struct edma {
};
static struct edma *edma_info[EDMA_MAX_CC];
+static int arch_num_cc;
/* dummy param set used to (re)initialize parameter RAM slots */
static const struct edmacc_param dummy_paramset = {
@@ -602,7 +603,7 @@ int edma_alloc_channel(int channel,
}
if (channel 0) {
- for (i = 0; i EDMA_MAX_CC; i++) {
+ for (i = 0; i arch_num_cc; i++) {
channel = 0;
for (;;) {
channel = find_next_bit(edma_info[i]-
@@ -1467,6 +1468,7 @@ static int __init edma_probe(struct platform_device *pdev)
edma_write_array2(j, EDMA_DRAE, i, 1, 0x0);
edma_write_array(j, EDMA_QRAE, i, 0x0);
}
+ arch_num_cc++;
}
if (tc_errs_handled) {
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/9] davinci: Correct return value of edma_alloc_channel api
Currently, edma_alloc_channel api is returning the channel number without prepending the controller on which the channel was allocated. So, if a channel is allocated on 2nd controller, calls subsequent to edma_alloc_channel would never know that channel was allocated on the 2nd controller, and continue to operate on 1st controller, resulting in edma failure. This patch fixes this issue. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com --- arch/arm/mach-davinci/dma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index 648fbb7..5a71f4d 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -642,7 +642,7 @@ int edma_alloc_channel(int channel, map_dmach_queue(ctlr, channel, eventq_no); - return channel; + return EDMA_CTLR_CHAN(ctlr, channel); } EXPORT_SYMBOL(edma_alloc_channel); -- 1.5.6 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 0/9] davinci: EDMA updates
This patch set corrects some issues with the existing EDMA driver and also adds support for EDMA resource (channel/slots) sharing between two processors (say ARM and DSP). The patch set has been tested on DM646x, OMAP-L137 and OMAP-L138 EVM boards. Sudhakar Rajashekhara (9): davinci: Correct return value of edma_alloc_channel api davinci: Keep count of channel controllers on a platform davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case davinci: build list of unused EDMA events dynamically davinci: support for EDMA resource sharing davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 davinci: da830/omapl137: Specify reserved channels/slots davinci: da850/omapl138: Specify reserved channels/slots davinci: dm646x: Specify reserved EDMA channel/slots for DM646x arch/arm/mach-davinci/devices-da8xx.c | 181 ++-- arch/arm/mach-davinci/dm355.c |8 -- arch/arm/mach-davinci/dm644x.c| 10 -- arch/arm/mach-davinci/dm646x.c| 28 - arch/arm/mach-davinci/dma.c | 101 ++--- arch/arm/mach-davinci/include/mach/edma.h |4 +- 6 files changed, 276 insertions(+), 56 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 7/9] davinci: da830/omapl137: Specify reserved channels/slots
Pass reserved EDMA channel/slots as platform data for da830/omap-l137.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/devices-da8xx.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index f6c6453..0f34c91 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -110,6 +110,24 @@ static const s8 da850_queue_priority_mapping[][2] = {
{-1, -1}
};
+static const s16 da830_dma_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 8, 2},
+ {12, 2},
+ {24, 4},
+ {30, 2},
+ {-1, -1}
+};
+
+static const s16 da830_dma_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 8, 2},
+ {12, 2},
+ {24, 4},
+ {30, 26},
+ {-1, -1}
+};
+
static struct edma_soc_info da830_edma_info[] = {
{
.n_channel = 32,
@@ -117,6 +135,8 @@ static struct edma_soc_info da830_edma_info[] = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
+ .rsv_chans = da830_dma_rsv_chans,
+ .rsv_slots = da830_dma_rsv_slots,
.queue_tc_mapping = da8xx_queue_tc_mapping,
.queue_priority_mapping = da8xx_queue_priority_mapping,
},
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 3/9] davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case
Though edma_alloc_channel api was looping through the available
channel controllers in EDMA_CHANNEL_ANY case, it was never
returning the channel for 2nd channel controller, if 1st
channel controller had no free channels. This issue has
been fixed with this patch.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/dma.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 97a49f9..89a3dcc 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -595,7 +595,7 @@ int edma_alloc_channel(int channel,
void *data,
enum dma_event_q eventq_no)
{
- unsigned i, done, ctlr = 0;
+ unsigned i, done = 0, ctlr = 0;
if (channel = 0) {
ctlr = EDMA_CTLR(channel);
@@ -611,7 +611,7 @@ int edma_alloc_channel(int channel,
edma_info[i]-num_channels,
channel);
if (channel == edma_info[i]-num_channels)
- return -ENOMEM;
+ break;
if (!test_and_set_bit(channel,
edma_info[i]-edma_inuse)) {
done = 1;
@@ -623,6 +623,8 @@ int edma_alloc_channel(int channel,
if (done)
break;
}
+ if (!done)
+ return -ENOMEM;
} else if (channel = edma_info[ctlr]-num_channels) {
return -EINVAL;
} else if (test_and_set_bit(channel, edma_info[ctlr]-edma_inuse)) {
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 4/9] davinci: build list of unused EDMA events dynamically
Currently, the edma_noevent list is passed from platform data.
But on some architectures, there will be many EDMA channels
which will not be used at all. This patch scans all the
platform devices and then builds a list of events which are
not being used. The unused event list will be used to allocate
EDMA channels in case of EDMA_CHANNEL_ANY usage instead of the
edma_noevent being used earlier for this purpose.
This patch is based on David Brownells's suggestion at
http://article.gmane.org/gmane.linux.davinci/15176.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Cc: David Brownell davi...@pacbell.net
---
arch/arm/mach-davinci/devices-da8xx.c |6 ---
arch/arm/mach-davinci/dm355.c |8
arch/arm/mach-davinci/dm644x.c| 10 -
arch/arm/mach-davinci/dm646x.c|9 -
arch/arm/mach-davinci/dma.c | 55 ++--
arch/arm/mach-davinci/include/mach/edma.h |2 -
6 files changed, 43 insertions(+), 47 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index dd2d32c..6860067 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -82,11 +82,6 @@ struct platform_device da8xx_serial_device = {
},
};
-static const s8 da8xx_dma_chan_no_event[] = {
- 20, 21,
- -1
-};
-
static const s8 da8xx_queue_tc_mapping[][2] = {
/* {event queue no, TC no} */
{0, 0},
@@ -108,7 +103,6 @@ static struct edma_soc_info da8xx_edma_info[] = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
- .noevent= da8xx_dma_chan_no_event,
.queue_tc_mapping = da8xx_queue_tc_mapping,
.queue_priority_mapping = da8xx_queue_priority_mapping,
},
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index dedf4d4..b1185f8 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -564,13 +564,6 @@ static u8 dm355_default_priorities[DAVINCI_N_AINTC_IRQ] = {
/*--*/
-static const s8 dma_chan_dm355_no_event[] = {
- 12, 13, 24, 56, 57,
- 58, 59, 60, 61, 62,
- 63,
- -1
-};
-
static const s8
queue_tc_mapping[][2] = {
/* {event queue no, TC no} */
@@ -594,7 +587,6 @@ static struct edma_soc_info dm355_edma_info[] = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
- .noevent= dma_chan_dm355_no_event,
.queue_tc_mapping = queue_tc_mapping,
.queue_priority_mapping = queue_priority_mapping,
},
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 2cd0081..fc060e7 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -479,15 +479,6 @@ static u8 dm644x_default_priorities[DAVINCI_N_AINTC_IRQ] =
{
/*--*/
-static const s8 dma_chan_dm644x_no_event[] = {
-0, 1, 12, 13, 14,
- 15, 25, 30, 31, 45,
- 46, 47, 55, 56, 57,
- 58, 59, 60, 61, 62,
- 63,
- -1
-};
-
static const s8
queue_tc_mapping[][2] = {
/* {event queue no, TC no} */
@@ -511,7 +502,6 @@ static struct edma_soc_info dm644x_edma_info[] = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
- .noevent= dma_chan_dm644x_no_event,
.queue_tc_mapping = queue_tc_mapping,
.queue_priority_mapping = queue_priority_mapping,
},
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 829a44b..eb2e518 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -513,14 +513,6 @@ static u8 dm646x_default_priorities[DAVINCI_N_AINTC_IRQ] =
{
/*--*/
-static const s8 dma_chan_dm646x_no_event[] = {
-0, 1, 2, 3, 13,
- 14, 15, 24, 25, 26,
- 27, 30, 31, 54, 55,
- 56,
- -1
-};
-
/* Four Transfer Controllers on DM646x */
static const s8
dm646x_queue_tc_mapping[][2] = {
@@ -549,7 +541,6 @@ static struct edma_soc_info dm646x_edma_info[] = {
.n_slot = 512,
.n_tc = 4,
.n_cc = 1,
- .noevent= dma_chan_dm646x_no_event,
.queue_tc_mapping = dm646x_queue_tc_mapping,
.queue_priority_mapping = dm646x_queue_priority_mapping,
},
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm
[PATCH 6/9] davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138
Currently da850/omap-l138 supports only one channel controller
instance of EDMA though EDMA driver as such supports multiple
channel controller instances. This patch adds platform data
for the 2nd EDMA channel controller. As, the platform data
differ between da830/omap-l137 and da850/omap-l138, existing
code has been re-shuffled to accommodate this.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/devices-da8xx.c | 121 +++--
1 files changed, 114 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 6860067..f6c6453 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -24,8 +24,10 @@
#include clock.h
#define DA8XX_TPCC_BASE0x01c0
+#define DA850_TPCC1_BASE 0x01e3
#define DA8XX_TPTC0_BASE 0x01c08000
#define DA8XX_TPTC1_BASE 0x01c08400
+#define DA850_TPTC2_BASE 0x01e38000
#define DA8XX_WDOG_BASE0x01c21000 /*
DA8XX_TIMER64P1_BASE */
#define DA8XX_I2C0_BASE0x01c22000
#define DA8XX_RTC_BASE 0x01C23000
@@ -96,7 +98,31 @@ static const s8 da8xx_queue_priority_mapping[][2] = {
{-1, -1}
};
-static struct edma_soc_info da8xx_edma_info[] = {
+static const s8 da850_queue_tc_mapping[][2] = {
+ /* {event queue no, TC no} */
+ {0, 0},
+ {-1, -1}
+};
+
+static const s8 da850_queue_priority_mapping[][2] = {
+ /* {event queue no, Priority} */
+ {0, 3},
+ {-1, -1}
+};
+
+static struct edma_soc_info da830_edma_info[] = {
+ {
+ .n_channel = 32,
+ .n_region = 4,
+ .n_slot = 128,
+ .n_tc = 2,
+ .n_cc = 1,
+ .queue_tc_mapping = da8xx_queue_tc_mapping,
+ .queue_priority_mapping = da8xx_queue_priority_mapping,
+ },
+};
+
+static struct edma_soc_info da850_edma_info[] = {
{
.n_channel = 32,
.n_region = 4,
@@ -106,9 +132,49 @@ static struct edma_soc_info da8xx_edma_info[] = {
.queue_tc_mapping = da8xx_queue_tc_mapping,
.queue_priority_mapping = da8xx_queue_priority_mapping,
},
+ {
+ .n_channel = 32,
+ .n_region = 4,
+ .n_slot = 128,
+ .n_tc = 1,
+ .n_cc = 1,
+ .queue_tc_mapping = da850_queue_tc_mapping,
+ .queue_priority_mapping = da850_queue_priority_mapping,
+ },
+};
+
+static struct resource da830_edma_resources[] = {
+ {
+ .name = edma_cc0,
+ .start = DA8XX_TPCC_BASE,
+ .end= DA8XX_TPCC_BASE + SZ_32K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = edma_tc0,
+ .start = DA8XX_TPTC0_BASE,
+ .end= DA8XX_TPTC0_BASE + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = edma_tc1,
+ .start = DA8XX_TPTC1_BASE,
+ .end= DA8XX_TPTC1_BASE + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = edma0,
+ .start = IRQ_DA8XX_CCINT0,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = edma0_err,
+ .start = IRQ_DA8XX_CCERRINT,
+ .flags = IORESOURCE_IRQ,
+ },
};
-static struct resource da8xx_edma_resources[] = {
+static struct resource da850_edma_resources[] = {
{
.name = edma_cc0,
.start = DA8XX_TPCC_BASE,
@@ -128,6 +194,18 @@ static struct resource da8xx_edma_resources[] = {
.flags = IORESOURCE_MEM,
},
{
+ .name = edma_cc1,
+ .start = DA850_TPCC1_BASE,
+ .end= DA850_TPCC1_BASE + SZ_32K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = edma_tc2,
+ .start = DA850_TPTC2_BASE,
+ .end= DA850_TPTC2_BASE + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
.name = edma0,
.start = IRQ_DA8XX_CCINT0,
.flags = IORESOURCE_IRQ,
@@ -137,21 +215,50 @@ static struct resource da8xx_edma_resources[] = {
.start = IRQ_DA8XX_CCERRINT,
.flags = IORESOURCE_IRQ,
},
+ {
+ .name = edma1,
+ .start = IRQ_DA850_CCINT1,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name
[PATCH 5/9] davinci: support for EDMA resource sharing
Current EDMA driver is not taking care of EDMA channels/slots
which are allocated from other processor, say DSP. If a
channel/slot is allocated from DSP, the existing EDMA driver
can still allocate the same resource on ARM.
This patch enables the user to pass the channel/slots reserved
for DSP as platform data. EDMA driver scans this list during
probe and prepares a bitmap of channel/slots which can be used
on ARM side.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/dma.c | 36 -
arch/arm/mach-davinci/include/mach/edma.h |2 +
2 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 15dd886..d3e1702 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -206,6 +206,18 @@ static inline void edma_parm_or(unsigned ctlr, int offset,
int param_no,
edma_or(ctlr, EDMA_PARM + offset + (param_no 5), or);
}
+static inline void set_bits(int offset, int len, unsigned long *p)
+{
+ for (; len 0; len--)
+ set_bit(offset + (len - 1), p);
+}
+
+static inline void clear_bits(int offset, int len, unsigned long *p)
+{
+ for (; len 0; len--)
+ clear_bit(offset + (len - 1), p);
+}
+
/*/
/* actual number of DMA channels and slots on this silicon */
@@ -1379,8 +1391,10 @@ static int __init edma_probe(struct platform_device
*pdev)
struct edma_soc_info*info = pdev-dev.platform_data;
const s8(*queue_priority_mapping)[2];
const s8(*queue_tc_mapping)[2];
- int i, j, found = 0;
+ int i, j, off, ln, found = 0;
int status = -1;
+ const s16 (*rsv_chans)[2];
+ const s16 (*rsv_slots)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
struct resource *r[EDMA_MAX_CC] = {NULL};
@@ -1447,6 +1461,26 @@ static int __init edma_probe(struct platform_device
*pdev)
memset(edma_info[j]-edma_unused, 0xff,
sizeof(edma_info[j]-edma_unused));
+ /* Clear the reserved channels in unused list */
+ rsv_chans = info[j].rsv_chans;
+ if (rsv_chans) {
+ for (i = 0; rsv_chans[i][0] != -1; i++) {
+ off = rsv_chans[i][0];
+ ln = rsv_chans[i][1];
+ clear_bits(off, ln, edma_info[j]-edma_unused);
+ }
+ }
+
+ /* Set the reserved channels/slots in inuse list */
+ rsv_slots = info[j].rsv_slots;
+ if (rsv_slots) {
+ for (i = 0; rsv_slots[i][0] != -1; i++) {
+ off = rsv_slots[i][0];
+ ln = rsv_slots[i][1];
+ set_bits(off, ln, edma_info[j]-edma_inuse);
+ }
+ }
+
sprintf(irq_name, edma%d, j);
irq[j] = platform_get_irq_byname(pdev, irq_name);
edma_info[j]-irq_res_start = irq[j];
diff --git a/arch/arm/mach-davinci/include/mach/edma.h
b/arch/arm/mach-davinci/include/mach/edma.h
index ced3092..55e217e 100644
--- a/arch/arm/mach-davinci/include/mach/edma.h
+++ b/arch/arm/mach-davinci/include/mach/edma.h
@@ -280,6 +280,8 @@ struct edma_soc_info {
unsignedn_cc;
enum dma_event_qdefault_queue;
+ const s16 (*rsv_chans)[2];
+ const s16 (*rsv_slots)[2];
const s8(*queue_tc_mapping)[2];
const s8(*queue_priority_mapping)[2];
};
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 8/9] davinci: da850/omapl138: Specify reserved channels/slots
Pass reserved EDMA channel/slots as platform data for da850/omap-l138.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/devices-da8xx.c | 34 +
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 0f34c91..3a5e86c 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -128,6 +128,36 @@ static const s16 da830_dma_rsv_slots[][2] = {
{-1, -1}
};
+static const s16 da850_dma0_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 8, 6},
+ {24, 4},
+ {30, 2},
+ {-1, -1}
+};
+
+static const s16 da850_dma0_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 8, 6},
+ {24, 4},
+ {30, 50},
+ {-1, -1}
+};
+
+static const s16 da850_dma1_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 0, 28},
+ {30, 2},
+ {-1, -1}
+};
+
+static const s16 da850_dma1_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 0, 28},
+ {30, 90},
+ {-1, -1}
+};
+
static struct edma_soc_info da830_edma_info[] = {
{
.n_channel = 32,
@@ -149,6 +179,8 @@ static struct edma_soc_info da850_edma_info[] = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
+ .rsv_chans = da850_dma0_rsv_chans,
+ .rsv_slots = da850_dma0_rsv_slots,
.queue_tc_mapping = da8xx_queue_tc_mapping,
.queue_priority_mapping = da8xx_queue_priority_mapping,
},
@@ -158,6 +190,8 @@ static struct edma_soc_info da850_edma_info[] = {
.n_slot = 128,
.n_tc = 1,
.n_cc = 1,
+ .rsv_chans = da850_dma1_rsv_chans,
+ .rsv_slots = da850_dma1_rsv_slots,
.queue_tc_mapping = da850_queue_tc_mapping,
.queue_priority_mapping = da850_queue_priority_mapping,
},
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 9/9] davinci: dm646x: Specify reserved EDMA channel/slots for DM646x
Pass reserved EDMA channel/slots as platform data for dm646x.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/dm646x.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index eb2e518..481d150 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -513,6 +513,27 @@ static u8 dm646x_default_priorities[DAVINCI_N_AINTC_IRQ] =
{
/*--*/
+static const s16 dm646x_dma_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 0, 4},
+ {13, 3},
+ {24, 4},
+ {30, 2},
+ {54, 3},
+ {-1, -1}
+};
+
+static const s16 dm646x_dma_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 0, 4},
+ {13, 3},
+ {24, 4},
+ {30, 2},
+ {54, 3},
+ {128, 384},
+ {-1, -1}
+};
+
/* Four Transfer Controllers on DM646x */
static const s8
dm646x_queue_tc_mapping[][2] = {
@@ -541,6 +562,8 @@ static struct edma_soc_info dm646x_edma_info[] = {
.n_slot = 512,
.n_tc = 4,
.n_cc = 1,
+ .rsv_chans = dm646x_dma_rsv_chans,
+ .rsv_slots = dm646x_dma_rsv_slots,
.queue_tc_mapping = dm646x_queue_tc_mapping,
.queue_priority_mapping = dm646x_queue_priority_mapping,
},
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] davinci: fb: Fix frame buffer driver issues
Following issues have been addressed on DA8XX/OMAP-L1XX: a. Screen misalignment during booting when frame buffer console is enabled. b. Driver was configured always in PSEUDOCOLOR mode. This patch dynamically configures the driver either in PSEUDOCOLOUR or TRUECOLOR mode depending on bpp. c. The RED and BLUE offsets were interchanged resulting in wrong bootup logo colour. This patch has been tested on DA830/OMAP-L137 and DA850/OMAP-L138 EVMs. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com --- drivers/video/da8xx-fb.c | 11 +++ 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c index d065894..95f4e73 100644 --- a/drivers/video/da8xx-fb.c +++ b/drivers/video/da8xx-fb.c @@ -554,11 +554,11 @@ static int fb_check_var(struct fb_var_screeninfo *var, var-transp.length = 0; break; case 16:/* RGB 565 */ - var-red.offset = 0; + var-red.offset = 11; var-red.length = 5; var-green.offset = 5; var-green.length = 6; - var-blue.offset = 11; + var-blue.offset = 0; var-blue.length = 5; var-transp.offset = 0; var-transp.length = 0; @@ -591,7 +591,7 @@ static int __devexit fb_remove(struct platform_device *dev) unregister_framebuffer(info); fb_dealloc_cmap(info-cmap); dma_free_coherent(NULL, par-databuf_sz + PAGE_SIZE, - info-screen_base, + info-screen_base - PAGE_SIZE, info-fix.smem_start); free_irq(par-irq, par); clk_disable(par-lcdc_clk); @@ -749,6 +749,7 @@ static int __init fb_probe(struct platform_device *device) (PAGE_SIZE - par-palette_sz); /* the rest of the frame buffer is pixel data */ + da8xx_fb_info-screen_base = par-v_palette_base + par-palette_sz; da8xx_fb_fix.smem_start = par-p_palette_base + par-palette_sz; da8xx_fb_fix.smem_len = par-databuf_sz - par-palette_sz; da8xx_fb_fix.line_length = (lcdc_info-width * lcd_cfg-bpp) / 8; @@ -787,6 +788,8 @@ static int __init fb_probe(struct platform_device *device) da8xx_fb_info-var = da8xx_fb_var; da8xx_fb_info-fbops = da8xx_fb_ops; da8xx_fb_info-pseudo_palette = par-pseudo_palette; + da8xx_fb_info-fix.visual = (da8xx_fb_info-var.bits_per_pixel = 8) ? + FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR; ret = fb_alloc_cmap(da8xx_fb_info-cmap, PALETTE_SIZE, 0); if (ret) @@ -825,7 +828,7 @@ err_free_irq: err_release_fb_mem: dma_free_coherent(NULL, par-databuf_sz + PAGE_SIZE, - da8xx_fb_info-screen_base, + da8xx_fb_info-screen_base - PAGE_SIZE, da8xx_fb_info-fix.smem_start); err_release_fb: -- 1.5.6 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] davinci: da850/omap-l138: Modify NOR partition info
On DA850/OMAP-L138, NOR flash partition was starting from offset
ZERO erasing the UBL and u-boot when the complete NOR is erased.
This patch moves the start of the partition to 512K, after the
bootloaders and u-boot env variables.
This patch also creates a new partition on NOR Flash to store
Linux kernel image.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/board-da850-evm.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 62b98bf..65bc6b0 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -46,8 +46,20 @@
static struct mtd_partition da850_evm_norflash_partition[] = {
{
- .name = NOR filesystem,
+ .name = bootloaders + env,
.offset = 0,
+ .size = SZ_512K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ {
+ .name = kernel,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_2M,
+ .mask_flags = 0,
+ },
+ {
+ .name = filesystem,
+ .offset = MTDPART_OFS_APPEND,
.size = MTDPART_SIZ_FULL,
.mask_flags = 0,
},
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] davinci: da850/omap-l138: Enable 4-bit ecc
This patch initializes the platform data to enable 4-bit
ecc support on DA850/OMAP-L138.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/board-da850-evm.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 65bc6b0..fe10dc1 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -131,6 +131,7 @@ static struct davinci_nand_pdata da850_evm_nandflash_data =
{
.parts = da850_evm_nandflash_partition,
.nr_parts = ARRAY_SIZE(da850_evm_nandflash_partition),
.ecc_mode = NAND_ECC_HW,
+ .ecc_bits = 4,
.options= NAND_USE_FLASH_BBT,
};
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] mtd-nand: davinci: Correct 4-bit error correction
On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after
setting the 4BITECC_ADD_CALC_START bit in the NAND Flash
control register to 1 and before waiting for the NAND Flash
status register to be equal to 1, 2 or 3, we have to wait
till the ECC HW goes to correction state. Without this wait,
ECC correction calculations will not be proper.
This has been tested on DA830/OMAP-L137, DA850/OMAP-L138,
DM355 and DM365 EVMs.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Acked-by: Sneha Narnakaje nsnehapra...@ti.com
---
drivers/mtd/nand/davinci_nand.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index fe3eba8..8a32999 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -310,6 +310,7 @@ static int nand_davinci_correct_4bit(struct mtd_info *mtd,
unsigned short ecc10[8];
unsigned short *ecc16;
u32 syndrome[4];
+ u32 ecc_state;
unsigned num_errors, corrected;
/* All bytes 0xff? It's an erased page; ignore its ECC. */
@@ -360,6 +361,21 @@ compare:
*/
davinci_nand_writel(info, NANDFCR_OFFSET,
davinci_nand_readl(info, NANDFCR_OFFSET) | BIT(13));
+
+ /*
+* ECC_STATE field reads 0x3 (Error correction complete) immediately
+* after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
+* begin trying to poll for the state, you may fall right out of your
+* loop without any of the correction calculations having taken place.
+* The recommendation from the hardware team is to wait till ECC_STATE
+* reads less than 4, which means ECC HW has entered correction state.
+*/
+ do {
+ ecc_state = (davinci_nand_readl(info,
+ NANDFSR_OFFSET) 8) 0x0f;
+ cpu_relax();
+ } while (ecc_state 4);
+
for (;;) {
u32 fsr = davinci_nand_readl(info, NANDFSR_OFFSET);
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/2] davinci: DA850/OMAP-L138: eliminate static function declaration
On Tue, Nov 03, 2009 at 00:57:01, Kevin Hilman wrote: Sudhakar Rajashekhara sudhakar@ti.com writes: Eliminate the static function declaration by rearranging data in da850/omap-l138 board file. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Sudhakar, Can you redo this series on top of Sekhar's 5-patch series that starts with davinci: DA830/OMAP-L137 EVM: use runtime detection for UI card. The two series are moving/changing the same code. Sure. I noticed one more warning during compilation. I'll fix that as well in my next version. Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2 1/2] davinci: DA850/OMAP-L138: eliminate static function declaration
Eliminate the static function declaration by rearranging
data in da850/omap-l138 board file.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
This series applies on top of Sekhar's 5-patch series that starts with
davinci: DA830/OMAP-L137 EVM: use runtime detection for UI card.
arch/arm/mach-davinci/board-da850-evm.c | 103 +++
1 files changed, 51 insertions(+), 52 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index d0e3178..19eb047 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -145,8 +145,58 @@ static struct platform_device da850_evm_nandflash_device =
{
.resource = da850_evm_nandflash_resource,
};
+static struct platform_device *da850_evm_devices[] __initdata = {
+ da850_evm_nandflash_device,
+ da850_evm_norflash_device,
+};
+
+#define DA8XX_AEMIF_CE2CFG_OFFSET 0x10
+#define DA8XX_AEMIF_ASIZE_16BIT0x1
+
+static void __init da850_evm_init_nor(void)
+{
+ void __iomem *aemif_addr;
+
+ aemif_addr = ioremap(DA8XX_AEMIF_CTL_BASE, SZ_32K);
+
+ /* Configure data bus width of CS2 to 16 bit */
+ writel(readl(aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET) |
+ DA8XX_AEMIF_ASIZE_16BIT,
+ aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET);
+
+ iounmap(aemif_addr);
+}
+
static u32 ui_card_detected;
-static void da850_evm_setup_nor_nand(void);
+
+#if defined(CONFIG_MMC_DAVINCI) || \
+defined(CONFIG_MMC_DAVINCI_MODULE)
+#define HAS_MMC 1
+#else
+#define HAS_MMC 0
+#endif
+
+static void da850_evm_setup_nor_nand(void)
+{
+ int ret = 0;
+
+ if (ui_card_detected !HAS_MMC) {
+ ret = da8xx_pinmux_setup(da850_nand_pins);
+ if (ret)
+ pr_warning(da850_evm_init: nand mux setup failed:
+ %d\n, ret);
+
+ ret = da8xx_pinmux_setup(da850_nor_pins);
+ if (ret)
+ pr_warning(da850_evm_init: nor mux setup failed: %d\n,
+ ret);
+
+ da850_evm_init_nor();
+
+ platform_add_devices(da850_evm_devices,
+ ARRAY_SIZE(da850_evm_devices));
+ }
+}
#ifdef CONFIG_DA850_UI_RMII
static inline void da850_evm_setup_emac_rmii(int rmii_sel)
@@ -249,11 +299,6 @@ static struct davinci_uart_config da850_evm_uart_config
__initdata = {
.enabled_uarts = 0x7,
};
-static struct platform_device *da850_evm_devices[] __initdata = {
- da850_evm_nandflash_device,
- da850_evm_norflash_device,
-};
-
/* davinci da850 evm audio machine driver */
static u8 da850_iis_serializer_direction[] = {
INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE,
@@ -324,23 +369,6 @@ static int da850_lcd_hw_init(void)
return 0;
}
-#define DA8XX_AEMIF_CE2CFG_OFFSET 0x10
-#define DA8XX_AEMIF_ASIZE_16BIT0x1
-
-static void __init da850_evm_init_nor(void)
-{
- void __iomem *aemif_addr;
-
- aemif_addr = ioremap(DA8XX_AEMIF_CTL_BASE, SZ_32K);
-
- /* Configure data bus width of CS2 to 16 bit */
- writel(readl(aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET) |
- DA8XX_AEMIF_ASIZE_16BIT,
- aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET);
-
- iounmap(aemif_addr);
-}
-
/* TPS65070 voltage regulator support */
/* 3.3V */
@@ -488,35 +516,6 @@ static int __init pmic_tps65070_init(void)
ARRAY_SIZE(da850evm_tps65070_info));
}
-#if defined(CONFIG_MMC_DAVINCI) || \
-defined(CONFIG_MMC_DAVINCI_MODULE)
-#define HAS_MMC 1
-#else
-#define HAS_MMC 0
-#endif
-
-static void da850_evm_setup_nor_nand(void)
-{
- int ret = 0;
-
- if (ui_card_detected !HAS_MMC) {
- ret = da8xx_pinmux_setup(da850_nand_pins);
- if (ret)
- pr_warning(da850_evm_init: nand mux setup failed:
- %d\n, ret);
-
- ret = da8xx_pinmux_setup(da850_nor_pins);
- if (ret)
- pr_warning(da850_evm_init: nor mux setup failed: %d\n,
- ret);
-
- da850_evm_init_nor();
-
- platform_add_devices(da850_evm_devices,
- ARRAY_SIZE(da850_evm_devices));
- }
-}
-
static const short da850_evm_lcdc_pins[] = {
DA850_GPIO2_8, DA850_GPIO2_15,
-1
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2 2/2] davinci: DA8XX/OMAP-L1XX: fix compiler warning
When kernel is built with CONFIG_DEBUG_SECTION_MISMATCH=y
option, using da8xx_omapl_defconfig, some warnings are
observed:
WARNING: vmlinux.o(.text+0xc2a4): Section mismatch in reference
from the function da850_evm_setup_nor_nand() to the variable
.init.data:da850_nand_pins
The function da850_evm_setup_nor_nand() references
the variable __initdata da850_nand_pins.
This is often because da850_evm_setup_nor_nand lacks a __initdata
annotation or the annotation of da850_nand_pins is wrong.
This patch fixes such warnings.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/board-da830-evm.c |6 +++---
arch/arm/mach-davinci/board-da850-evm.c |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index 4fb0447..4759c21 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -404,8 +404,8 @@ static struct at24_platform_data da830_evm_i2c_eeprom_info
= {
.context= (void *)0x7f00,
};
-static int da830_evm_ui_expander_setup(struct i2c_client *client, int gpio,
- unsigned ngpio, void *context)
+static int __init da830_evm_ui_expander_setup(struct i2c_client *client,
+ int gpio, unsigned ngpio, void *context)
{
gpio_request(gpio + 6, MUX_MODE);
@@ -426,7 +426,7 @@ static int da830_evm_ui_expander_teardown(struct i2c_client
*client, int gpio,
return 0;
}
-static struct pcf857x_platform_data da830_evm_ui_expander_info = {
+static struct pcf857x_platform_data __initdata da830_evm_ui_expander_info = {
.gpio_base = DAVINCI_N_GPIO,
.setup = da830_evm_ui_expander_setup,
.teardown = da830_evm_ui_expander_teardown,
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 19eb047..529e472 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -176,7 +176,7 @@ static u32 ui_card_detected;
#define HAS_MMC 0
#endif
-static void da850_evm_setup_nor_nand(void)
+static __init void da850_evm_setup_nor_nand(void)
{
int ret = 0;
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/2] davinci: DA850/OMAP-L138: eliminate static function declaration
Eliminate the static function declaration by rearranging
data in da850/omap-l138 board file.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/board-da850-evm.c | 103 +++
1 files changed, 51 insertions(+), 52 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 23e2024..e04f775 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -145,8 +145,58 @@ static struct platform_device da850_evm_nandflash_device =
{
.resource = da850_evm_nandflash_resource,
};
+static struct platform_device *da850_evm_devices[] __initdata = {
+ da850_evm_nandflash_device,
+ da850_evm_norflash_device,
+};
+
+#define DA8XX_AEMIF_CE2CFG_OFFSET 0x10
+#define DA8XX_AEMIF_ASIZE_16BIT0x1
+
+static void __init da850_evm_init_nor(void)
+{
+ void __iomem *aemif_addr;
+
+ aemif_addr = ioremap(DA8XX_AEMIF_CTL_BASE, SZ_32K);
+
+ /* Configure data bus width of CS2 to 16 bit */
+ writel(readl(aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET) |
+ DA8XX_AEMIF_ASIZE_16BIT,
+ aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET);
+
+ iounmap(aemif_addr);
+}
+
static u32 ui_card_detected;
-static void da850_evm_setup_nor_nand(void);
+
+#if defined(CONFIG_MMC_DAVINCI) || \
+defined(CONFIG_MMC_DAVINCI_MODULE)
+#define HAS_MMC 1
+#else
+#define HAS_MMC 0
+#endif
+
+static void da850_evm_setup_nor_nand(void)
+{
+ int ret = 0;
+
+ if (ui_card_detected !HAS_MMC) {
+ ret = da8xx_pinmux_setup(da850_nand_pins);
+ if (ret)
+ pr_warning(da850_evm_init: nand mux setup failed:
+ %d\n, ret);
+
+ ret = da8xx_pinmux_setup(da850_nor_pins);
+ if (ret)
+ pr_warning(da850_evm_init: nor mux setup failed: %d\n,
+ ret);
+
+ da850_evm_init_nor();
+
+ platform_add_devices(da850_evm_devices,
+ ARRAY_SIZE(da850_evm_devices));
+ }
+}
static int da850_evm_ui_expander_setup(struct i2c_client *client, unsigned
gpio,
unsigned ngpio, void *c)
@@ -240,11 +290,6 @@ static struct davinci_uart_config da850_evm_uart_config
__initdata = {
.enabled_uarts = 0x7,
};
-static struct platform_device *da850_evm_devices[] __initdata = {
- da850_evm_nandflash_device,
- da850_evm_norflash_device,
-};
-
/* davinci da850 evm audio machine driver */
static u8 da850_iis_serializer_direction[] = {
INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE,
@@ -315,23 +360,6 @@ static int da850_lcd_hw_init(void)
return 0;
}
-#define DA8XX_AEMIF_CE2CFG_OFFSET 0x10
-#define DA8XX_AEMIF_ASIZE_16BIT0x1
-
-static void __init da850_evm_init_nor(void)
-{
- void __iomem *aemif_addr;
-
- aemif_addr = ioremap(DA8XX_AEMIF_CTL_BASE, SZ_32K);
-
- /* Configure data bus width of CS2 to 16 bit */
- writel(readl(aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET) |
- DA8XX_AEMIF_ASIZE_16BIT,
- aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET);
-
- iounmap(aemif_addr);
-}
-
/* TPS65070 voltage regulator support */
/* 3.3V */
@@ -479,35 +507,6 @@ static int __init pmic_tps65070_init(void)
ARRAY_SIZE(da850evm_tps65070_info));
}
-#if defined(CONFIG_MMC_DAVINCI) || \
-defined(CONFIG_MMC_DAVINCI_MODULE)
-#define HAS_MMC 1
-#else
-#define HAS_MMC 0
-#endif
-
-static void da850_evm_setup_nor_nand(void)
-{
- int ret = 0;
-
- if (ui_card_detected !HAS_MMC) {
- ret = da8xx_pinmux_setup(da850_nand_pins);
- if (ret)
- pr_warning(da850_evm_init: nand mux setup failed:
- %d\n, ret);
-
- ret = da8xx_pinmux_setup(da850_nor_pins);
- if (ret)
- pr_warning(da850_evm_init: nor mux setup failed: %d\n,
- ret);
-
- da850_evm_init_nor();
-
- platform_add_devices(da850_evm_devices,
- ARRAY_SIZE(da850_evm_devices));
- }
-}
-
static const short da850_evm_lcdc_pins[] = {
DA850_GPIO2_8, DA850_GPIO2_15,
-1
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 2/2] davinci: DA850/OMAP-L138: fix compiler warning
When kernel is built with CONFIG_DEBUG_SECTION_MISMATCH=y
option, using da8xx_omapl_defconfig, following warning is
observed:
WARNING: vmlinux.o(.text+0xc2a4): Section mismatch in reference
from the function da850_evm_setup_nor_nand() to the variable
.init.data:da850_nand_pins
The function da850_evm_setup_nor_nand() references
the variable __initdata da850_nand_pins.
This is often because da850_evm_setup_nor_nand lacks a __initdata
annotation or the annotation of da850_nand_pins is wrong.
This patch fixes this warning.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/board-da850-evm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index e04f775..6ddea9b 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -176,7 +176,7 @@ static u32 ui_card_detected;
#define HAS_MMC 0
#endif
-static void da850_evm_setup_nor_nand(void)
+static __init void da850_evm_setup_nor_nand(void)
{
int ret = 0;
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] DaVinci: MMC: Modify data types of EDMA related variables
From: Sudhakar Rajashekhara sudhakar@ti.com
Currently DaVinci EDMA driver supports multiple EDMA channel
controller instances. edma_alloc_channel() api returns a 32
bit value which has the channel controller number in MSB and
the EDMA channel number in LSB. The variables which store the
value returned by edma_alloc_channel() have to be 32 bit wide
now.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Acked-by: Vipin Bhandari vipin.bhand...@ti.com
---
This patch applies on top of the following patch submitted by
Vipin Bhandari vipin.bhand...@ti.com,
http://patchwork.kernel.org/patch/50914/.
drivers/mmc/host/davinci_mmc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index fe8f613..6c76f64 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -178,7 +178,7 @@ struct mmc_davinci_host {
u32 buffer_bytes_left;
u32 bytes_left;
- u8 rxdma, txdma;
+ u32 rxdma, txdma;
bool use_dma;
bool do_dma;
@@ -190,7 +190,7 @@ struct mmc_davinci_host {
struct edmacc_param tx_template;
struct edmacc_param rx_template;
unsignedn_link;
- u8 links[NR_SG - 1];
+ u32 links[NR_SG - 1];
/* For PIO we walk scatterlists one segment at a time. */
unsigned intsg_len;
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/2] nand: Add bad block table overrides to Davinci NAND driver
On Tue, Sep 29, 2009 at 00:19:05, Kevin Hilman wrote: Mark A. Greer mgr...@mvista.com writes: On Tue, Sep 22, 2009 at 06:10:41PM +0530, Sudhakar Rajashekhara wrote: On Sat, Sep 19, 2009 at 02:40:04, Mark A. Greer wrote: From: Mark A. Greer mgr...@mvista.com The existing NAND infrastructure allows the default main and mirror bad block tables to be overridden in nand_default_bbt(). However, the davinci_nand driver does not support this. So, add fields to the davinci driver's platform data so platform code can pass in their own bbt's and make the driver honor those overrides. Signed-off-by: Mark A. Greer mgr...@mvista.com --- This is required by the da830 evm (see following patch) which requires different 'offs' and 'veroffs' values than the default. This seemed like the solution that fit best with the existing infratructure. If anyone has a better solution, please speak up. Mark, Are you trying to align with the OOB layout being followed in U-Boot? Yes. That and to match what both TI and MV have been supporting for quite a while. U-Boot for da830/omap-l137 is not in mainline yet. I am planning to start working on that shortly. We can re-visit this when da830/omap-l137 support is present in u-boot. Hmm, okay... So what about all the platforms that are already out there? Even if it changes, I'd recommend the driver patch [1/2] still go in so that the functionality is there if/when its ever needed (and its a really simple patch). I can alway redo the platform patch [2/2]. I'll apply 1/1 today. Sudhakar, for 2/2, what's the reason to wait for u-boot support to go upstream. Is the u-boot support going to change? If most folks are using recent u-boot anyways, it seems that this should get merged as well. Kevin, Existing u-boot for da8xx was based on u-boot for DM355/DM365 but u-boot for DM355/DM365 has changed in mainline so I expect that u-boot for da8xx is also going to change. Also, there may be some users which are using the old u-boot for DM355/DM365 and this kind of patch is required for those platforms as well. Of course it can be a different patch. - Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/2] nand: Add bad block table overrides to Davinci NAND driver
On Wed, Sep 30, 2009 at 05:26:32, Kevin Hilman wrote: Mark A. Greer mgr...@mvista.com writes: On Tue, Sep 29, 2009 at 02:18:42PM +0530, Sudhakar Rajashekhara wrote: On Tue, Sep 29, 2009 at 00:19:05, Kevin Hilman wrote: Mark A. Greer mgr...@mvista.com writes: On Tue, Sep 22, 2009 at 06:10:41PM +0530, Sudhakar Rajashekhara wrote: On Sat, Sep 19, 2009 at 02:40:04, Mark A. Greer wrote: Are you trying to align with the OOB layout being followed in U-Boot? Yes. That and to match what both TI and MV have been supporting for quite a while. U-Boot for da830/omap-l137 is not in mainline yet. I am planning to start working on that shortly. We can re-visit this when da830/omap-l137 support is present in u-boot. Hmm, okay... So what about all the platforms that are already out there? Even if it changes, I'd recommend the driver patch [1/2] still go in so that the functionality is there if/when its ever needed (and its a really simple patch). I can alway redo the platform patch [2/2]. I'll apply 1/1 today. Sudhakar, for 2/2, what's the reason to wait for u-boot support to go upstream. Is the u-boot support going to change? If most folks are using recent u-boot anyways, it seems that this should get merged as well. Kevin, Existing u-boot for da8xx was based on u-boot for DM355/DM365 but u-boot for DM355/DM365 has changed in mainline so I expect that u-boot for da8xx is also going to change. Also, there may be some users which are using the old u-boot for DM355/DM365 and this kind of patch is required for those platforms as well. Of course it can be a different patch. What if we applied the patch so systems with the current u-boot work and then worry about how to disable it when the new u-boot is ready (e.g., CONFIG_ option or ...). This is fine with me. Sudhakar, any objections? No objections from my side for this approach. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/2] nand: Add bad block table overrides to Davinci NAND driver
On Sat, Sep 19, 2009 at 02:40:04, Mark A. Greer wrote: From: Mark A. Greer mgr...@mvista.com The existing NAND infrastructure allows the default main and mirror bad block tables to be overridden in nand_default_bbt(). However, the davinci_nand driver does not support this. So, add fields to the davinci driver's platform data so platform code can pass in their own bbt's and make the driver honor those overrides. Signed-off-by: Mark A. Greer mgr...@mvista.com --- This is required by the da830 evm (see following patch) which requires different 'offs' and 'veroffs' values than the default. This seemed like the solution that fit best with the existing infratructure. If anyone has a better solution, please speak up. Mark, Are you trying to align with the OOB layout being followed in U-Boot? U-Boot for da830/omap-l137 is not in mainline yet. I am planning to start working on that shortly. We can re-visit this when da830/omap-l137 support is present in u-boot. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] DM355: Update NAND driver platform data
Sneha,
Today I tested these 4-bit ECC patches on DA850/OMAP-L138 and here
are my observations:
I booted the kernel and wrote a JFFS2 file system image to a NAND
partition. I rebooted the board (1st time after writing the file
system image)and modified the bootargs to pick up the file system
from the NAND partition. While booting the kernel prints warning
messages like:
Empty flash at 0xfffc ends at 0x0001
Empty flash at 0x0002fffc ends at 0x0003
Empty flash at 0x0004fffc ends at 0x0005
Empty flash at 0x0006fffc ends at 0x0007
Empty flash at 0x0008fffc ends at 0x0009
Empty flash at 0x000afffc ends at 0x000b
Empty flash at 0x000cfffc ends at 0x000d
The board boots properly after these messages.
After the board boots, if I just restart the EVM without even logging
In (2nd time onwards, after the file system image is written), I see
the following messages from the kernel while booting:
Empty flash at 0x0008fffc ends at 0x0009
Empty flash at 0x000afffc ends at 0x000b
Empty flash at 0x000cfffc ends at 0x000d
mtd-read(0x1fc20 bytes from 0x3a03e0) returned ECC error
mtd-read(0x10dbc bytes from 0x3af244) returned ECC error
mtd-read(0x448 bytes from 0x3afbb8) returned ECC error
mtd-read(0x7bc bytes from 0x3af844) returned ECC error
mtd-read(0x790 bytes from 0x3af870) returned ECC error
The board boots up properly after the messages and the file system
seems to be intact in-spite of ECC errors.
I tried the above tests on DM355 EVM, and there also I observed the
same behavior. One thing which I noticed is, without the 4-bit ECC
patches I am not seeing ECC error messages but the Empty flash
messages do appear. Do you have any idea what's going wrong here?
Regards, Sudhakar
On Thu, Sep 17, 2009 at 08:29:48, nsnehapra...@ti.com wrote:
From: Sneha Narnakaje nsnehapra...@ti.com
This patch updates the NAND driver platform data to use 4-bit ECC and the
ECC_HW/ECC_HW_OOB_FIRST modes.
Signed-off-by: Sneha Narnakaje nsnehapra...@ti.com
---
arch/arm/mach-davinci/board-dm355-evm.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index 9f25fd8..d12c9e9 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -84,8 +84,9 @@ static struct davinci_nand_pdata davinci_nand_data = {
.mask_chipsel = BIT(14),
.parts = davinci_nand_partitions,
.nr_parts = ARRAY_SIZE(davinci_nand_partitions),
- .ecc_mode = NAND_ECC_HW_SYNDROME,
+ .ecc_mode = NAND_ECC_HW,
.options= NAND_USE_FLASH_BBT,
+ .ecc_bits = 4,
};
static struct resource davinci_nand_resources[] = {
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] davinci: fb: Disable end-of-frame interrupt
Currently end-of-frame interrupt is being used while disabling
LCD controller to wait or the frame being diaplyed to complete.
But when the LCD is disabled by clearing the LCD Raster Control
enable bit in the LCD Raster Control Register, the LCD allows
the current frame to complete before it is disabled.
Hence disable end-of-frame interrupt and remove waitqueue related
code which was used to handle this interrupt.
Because of above modifications, modify the lcd_disable_raster()
and lcd_reset() functions to return void instead of int.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
This patch applies to mmotm tree available at
http://git.zen-sources.org/?p=mmotm.git;a=summary.
drivers/video/da8xx-fb.c | 36
1 files changed, 8 insertions(+), 28 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 04de744..42e1005 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -107,7 +107,6 @@ static inline void lcdc_write(unsigned int val, unsigned
int addr)
}
struct da8xx_fb_par {
- wait_queue_head_t da8xx_wq;
resource_size_t p_palette_base;
unsigned char *v_palette_base;
struct clk *lcdc_clk;
@@ -193,21 +192,13 @@ static struct da8xx_panel known_lcd_panels[] = {
};
/* Disable the Raster Engine of the LCD Controller */
-static int lcd_disable_raster(struct da8xx_fb_par *par)
+static void lcd_disable_raster(struct da8xx_fb_par *par)
{
- int ret = 0;
u32 reg;
reg = lcdc_read(LCD_RASTER_CTRL_REG);
- if (reg LCD_RASTER_ENABLE) {
+ if (reg LCD_RASTER_ENABLE)
lcdc_write(reg ~LCD_RASTER_ENABLE, LCD_RASTER_CTRL_REG);
- ret = wait_event_interruptible_timeout(par-da8xx_wq,
- !lcdc_read(LCD_STAT_REG)
- LCD_END_OF_FRAME0, WSI_TIMEOUT);
- if (ret == 0)
- ret = -ETIMEDOUT;
- }
- return ret;
}
static void lcd_blit(int load_mode, struct da8xx_fb_par *par)
@@ -255,7 +246,7 @@ static int lcd_cfg_dma(int burst_size)
default:
return -EINVAL;
}
- lcdc_write(reg | LCD_END_OF_FRAME_INT_ENA, LCD_DMA_CTRL_REG);
+ lcdc_write(reg, LCD_DMA_CTRL_REG);
return 0;
}
@@ -450,19 +441,15 @@ static int fb_setcolreg(unsigned regno, unsigned red,
unsigned green,
return 0;
}
-static int lcd_reset(struct da8xx_fb_par *par)
+static void lcd_reset(struct da8xx_fb_par *par)
{
- int ret = 0;
-
/* Disable the Raster if previously Enabled */
if (lcdc_read(LCD_RASTER_CTRL_REG) LCD_RASTER_ENABLE)
- ret = lcd_disable_raster(par);
+ lcd_disable_raster(par);
/* DMA has to be disabled */
lcdc_write(0, LCD_DMA_CTRL_REG);
lcdc_write(0, LCD_RASTER_CTRL_REG);
-
- return ret;
}
static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config
*cfg,
@@ -471,9 +458,7 @@ static int lcd_init(struct da8xx_fb_par *par, const struct
lcd_ctrl_config *cfg,
u32 bpp;
int ret = 0;
- ret = lcd_reset(par);
- if (ret != 0)
- return ret;
+ lcd_reset(par);
/* Configure the LCD clock divisor. */
lcdc_write(LCD_CLK_DIVISOR(panel-pxl_clk) |
@@ -529,7 +514,6 @@ static int lcd_init(struct da8xx_fb_par *par, const struct
lcd_ctrl_config *cfg,
static irqreturn_t lcdc_irq_handler(int irq, void *arg)
{
u32 stat = lcdc_read(LCD_STAT_REG);
- struct da8xx_fb_par *par = arg;
u32 reg;
if ((stat LCD_SYNC_LOST) (stat LCD_FIFO_UNDERFLOW)) {
@@ -540,7 +524,6 @@ static irqreturn_t lcdc_irq_handler(int irq, void *arg)
} else
lcdc_write(stat, LCD_STAT_REG);
- wake_up_interruptible(par-da8xx_wq);
return IRQ_HANDLED;
}
@@ -595,13 +578,12 @@ static int fb_check_var(struct fb_var_screeninfo *var,
static int __devexit fb_remove(struct platform_device *dev)
{
struct fb_info *info = dev_get_drvdata(dev-dev);
- int ret = 0;
if (info) {
struct da8xx_fb_par *par = info-par;
if (lcdc_read(LCD_RASTER_CTRL_REG) LCD_RASTER_ENABLE)
- ret = lcd_disable_raster(par);
+ lcd_disable_raster(par);
lcdc_write(0, LCD_RASTER_CTRL_REG);
/* disable DMA */
@@ -620,7 +602,7 @@ static int __devexit fb_remove(struct platform_device *dev)
release_mem_region(lcdc_regs-start, resource_size(lcdc_regs));
}
- return ret;
+ return 0;
}
static int fb_ioctl(struct fb_info *info, unsigned int cmd,
@@ -774,8 +756,6 @@ static int __init fb_probe(struct platform_device *device)
par-lcdc_clk = fb_clk;
- init_waitqueue_head(par-da8xx_wq);
-
par-irq = platform_get_irq(device, 0
[PATCH v2] davinci: Correct the GPIO number for LCD panel power
On the latest DA850/OMAP-L138 EVM (Beta) the GPIO pin
number of LCD panel power has changed. This patch takes
care of this change. Software will support only Beta
versions of DA850/OMAP-L138 EVM.
In the process, add the missing entry for data pin 0
in da850_lcdcntl_pins structure.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/board-da850-evm.c |5 +
arch/arm/mach-davinci/da850.c| 13 ++---
arch/arm/mach-davinci/include/mach/mux.h |2 +-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index fbc7aae..d9fda71 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -32,6 +32,7 @@
#include mach/cp_intc.h
#include mach/da8xx.h
#include mach/nand.h
+#include mach/mux.h
#define DA850_EVM_PHY_MASK 0x1
#define DA850_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
@@ -372,6 +373,10 @@ static __init void da850_evm_init(void)
pr_warning(da850_evm_init: lcdcntl mux setup failed: %d\n,
ret);
+ /* Handle board specific muxing for LCD here */
+ davinci_cfg_reg(DA850_GPIO2_8);
+ davinci_cfg_reg(DA850_GPIO2_15);
+
ret = da850_lcd_hw_init();
if (ret)
pr_warning(da850_evm_init: lcd initialization failed: %d\n,
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 575e9cc..a62863c 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -513,8 +513,8 @@ static const struct mux_config da850_pins[] = {
MUX_CFG(DA850, EMA_WAIT_1, 6, 24, 15, 1, false)
MUX_CFG(DA850, NEMA_CS_2, 7, 0, 15, 1, false)
/* GPIO function */
+ MUX_CFG(DA850, GPIO2_8, 5, 28, 15, 8, false)
MUX_CFG(DA850, GPIO2_15,5, 0, 15, 8, false)
- MUX_CFG(DA850, GPIO8_10,18, 28, 15, 8, false)
MUX_CFG(DA850, GPIO4_0, 10, 28, 15, 8, false)
MUX_CFG(DA850, GPIO4_1, 10, 24, 15, 8, false)
#endif
@@ -562,12 +562,11 @@ const short da850_mcasp_pins[] __initdata = {
};
const short da850_lcdcntl_pins[] __initdata = {
- DA850_LCD_D_1, DA850_LCD_D_2, DA850_LCD_D_3, DA850_LCD_D_4,
- DA850_LCD_D_5, DA850_LCD_D_6, DA850_LCD_D_7, DA850_LCD_D_8,
- DA850_LCD_D_9, DA850_LCD_D_10, DA850_LCD_D_11, DA850_LCD_D_12,
- DA850_LCD_D_13, DA850_LCD_D_14, DA850_LCD_D_15, DA850_LCD_PCLK,
- DA850_LCD_HSYNC, DA850_LCD_VSYNC, DA850_NLCD_AC_ENB_CS, DA850_GPIO2_15,
- DA850_GPIO8_10,
+ DA850_LCD_D_0, DA850_LCD_D_1, DA850_LCD_D_2, DA850_LCD_D_3,
+ DA850_LCD_D_4, DA850_LCD_D_5, DA850_LCD_D_6, DA850_LCD_D_7,
+ DA850_LCD_D_8, DA850_LCD_D_9, DA850_LCD_D_10, DA850_LCD_D_11,
+ DA850_LCD_D_12, DA850_LCD_D_13, DA850_LCD_D_14, DA850_LCD_D_15,
+ DA850_LCD_PCLK, DA850_LCD_HSYNC, DA850_LCD_VSYNC, DA850_NLCD_AC_ENB_CS,
-1
};
diff --git a/arch/arm/mach-davinci/include/mach/mux.h
b/arch/arm/mach-davinci/include/mach/mux.h
index 7732832..fc8eb16 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -872,8 +872,8 @@ enum davinci_da850_index {
DA850_NEMA_CS_2,
/* GPIO function */
+ DA850_GPIO2_8,
DA850_GPIO2_15,
- DA850_GPIO8_10,
DA850_GPIO4_0,
DA850_GPIO4_1,
};
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2] davinci: Correct the GPIO number for LCD panel power
On Tue, Sep 15, 2009 at 23:45:48, Sudhakar Rajashekhara wrote: On the latest DA850/OMAP-L138 EVM (Beta) the GPIO pin number of LCD panel power has changed. This patch takes care of this change. Software will support only Beta versions of DA850/OMAP-L138 EVM. In the process, add the missing entry for data pin 0 in da850_lcdcntl_pins structure. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com --- Please ignore this patch. I'll submit the correct patch as PATCH v3. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v3] davinci: Correct the GPIO number for LCD panel power
On the latest DA850/OMAP-L138 EVM (Beta) the GPIO pin
number of LCD panel power has changed. This patch takes
care of this change. Software will support only Beta
versions of DA850/OMAP-L138 EVM.
In the process, add the missing entry for data pin 0
in da850_lcdcntl_pins structure.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/board-da850-evm.c |7 ++-
arch/arm/mach-davinci/da850.c| 13 ++---
arch/arm/mach-davinci/include/mach/mux.h |2 +-
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index fbc7aae..a36dea3 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -32,12 +32,13 @@
#include mach/cp_intc.h
#include mach/da8xx.h
#include mach/nand.h
+#include mach/mux.h
#define DA850_EVM_PHY_MASK 0x1
#define DA850_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
+#define DA850_LCD_PWR_PIN GPIO_TO_PIN(2, 8)
#define DA850_LCD_BL_PIN GPIO_TO_PIN(2, 15)
-#define DA850_LCD_PWR_PIN GPIO_TO_PIN(8, 10)
#define DA850_MMCSD_CD_PIN GPIO_TO_PIN(4, 0)
#define DA850_MMCSD_WP_PIN GPIO_TO_PIN(4, 1)
@@ -372,6 +373,10 @@ static __init void da850_evm_init(void)
pr_warning(da850_evm_init: lcdcntl mux setup failed: %d\n,
ret);
+ /* Handle board specific muxing for LCD here */
+ davinci_cfg_reg(DA850_GPIO2_8);
+ davinci_cfg_reg(DA850_GPIO2_15);
+
ret = da850_lcd_hw_init();
if (ret)
pr_warning(da850_evm_init: lcd initialization failed: %d\n,
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 575e9cc..a62863c 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -513,8 +513,8 @@ static const struct mux_config da850_pins[] = {
MUX_CFG(DA850, EMA_WAIT_1, 6, 24, 15, 1, false)
MUX_CFG(DA850, NEMA_CS_2, 7, 0, 15, 1, false)
/* GPIO function */
+ MUX_CFG(DA850, GPIO2_8, 5, 28, 15, 8, false)
MUX_CFG(DA850, GPIO2_15,5, 0, 15, 8, false)
- MUX_CFG(DA850, GPIO8_10,18, 28, 15, 8, false)
MUX_CFG(DA850, GPIO4_0, 10, 28, 15, 8, false)
MUX_CFG(DA850, GPIO4_1, 10, 24, 15, 8, false)
#endif
@@ -562,12 +562,11 @@ const short da850_mcasp_pins[] __initdata = {
};
const short da850_lcdcntl_pins[] __initdata = {
- DA850_LCD_D_1, DA850_LCD_D_2, DA850_LCD_D_3, DA850_LCD_D_4,
- DA850_LCD_D_5, DA850_LCD_D_6, DA850_LCD_D_7, DA850_LCD_D_8,
- DA850_LCD_D_9, DA850_LCD_D_10, DA850_LCD_D_11, DA850_LCD_D_12,
- DA850_LCD_D_13, DA850_LCD_D_14, DA850_LCD_D_15, DA850_LCD_PCLK,
- DA850_LCD_HSYNC, DA850_LCD_VSYNC, DA850_NLCD_AC_ENB_CS, DA850_GPIO2_15,
- DA850_GPIO8_10,
+ DA850_LCD_D_0, DA850_LCD_D_1, DA850_LCD_D_2, DA850_LCD_D_3,
+ DA850_LCD_D_4, DA850_LCD_D_5, DA850_LCD_D_6, DA850_LCD_D_7,
+ DA850_LCD_D_8, DA850_LCD_D_9, DA850_LCD_D_10, DA850_LCD_D_11,
+ DA850_LCD_D_12, DA850_LCD_D_13, DA850_LCD_D_14, DA850_LCD_D_15,
+ DA850_LCD_PCLK, DA850_LCD_HSYNC, DA850_LCD_VSYNC, DA850_NLCD_AC_ENB_CS,
-1
};
diff --git a/arch/arm/mach-davinci/include/mach/mux.h
b/arch/arm/mach-davinci/include/mach/mux.h
index 7732832..fc8eb16 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -872,8 +872,8 @@ enum davinci_da850_index {
DA850_NEMA_CS_2,
/* GPIO function */
+ DA850_GPIO2_8,
DA850_GPIO2_15,
- DA850_GPIO8_10,
DA850_GPIO4_0,
DA850_GPIO4_1,
};
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v4] davinci: Correct the GPIO number for LCD panel power
On the latest DA850/OMAP-L138 EVM (Beta) the GPIO pin
number of LCD panel power has changed. This patch takes
care of this change. Software will support only Beta
versions of DA850/OMAP-L138 EVM.
In the process, add the missing entry for data pin 0
and remove the GPIO specific pins from da850_lcdcntl_pins
structure. EVM specific muxing for LCD is being done in the
board file now.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
Since the previous version:
1. Added an entry for the EVM specific LCD pins.
2. Configuring the pins using da8xx_pinmux_setup() instead
of calling davinci_cfg_reg() directly.
arch/arm/mach-davinci/board-da850-evm.c | 14 +-
arch/arm/mach-davinci/da850.c| 13 ++---
arch/arm/mach-davinci/include/mach/mux.h |2 +-
3 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index fbc7aae..7f511b7 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -32,12 +32,13 @@
#include mach/cp_intc.h
#include mach/da8xx.h
#include mach/nand.h
+#include mach/mux.h
#define DA850_EVM_PHY_MASK 0x1
#define DA850_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
+#define DA850_LCD_PWR_PIN GPIO_TO_PIN(2, 8)
#define DA850_LCD_BL_PIN GPIO_TO_PIN(2, 15)
-#define DA850_LCD_PWR_PIN GPIO_TO_PIN(8, 10)
#define DA850_MMCSD_CD_PIN GPIO_TO_PIN(4, 0)
#define DA850_MMCSD_WP_PIN GPIO_TO_PIN(4, 1)
@@ -264,6 +265,11 @@ static void __init da850_evm_init_nor(void)
#define HAS_MMC 0
#endif
+static const short da850_evm_lcdc_pins[] = {
+ DA850_GPIO2_8, DA850_GPIO2_15,
+ -1
+};
+
static __init void da850_evm_init(void)
{
struct davinci_soc_info *soc_info = davinci_soc_info;
@@ -372,6 +378,12 @@ static __init void da850_evm_init(void)
pr_warning(da850_evm_init: lcdcntl mux setup failed: %d\n,
ret);
+ /* Handle board specific muxing for LCD here */
+ ret = da8xx_pinmux_setup(da850_evm_lcdc_pins);
+ if (ret)
+ pr_warning(da850_evm_init: evm specific lcd mux setup
+ failed: %d\n, ret);
+
ret = da850_lcd_hw_init();
if (ret)
pr_warning(da850_evm_init: lcd initialization failed: %d\n,
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 575e9cc..a62863c 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -513,8 +513,8 @@ static const struct mux_config da850_pins[] = {
MUX_CFG(DA850, EMA_WAIT_1, 6, 24, 15, 1, false)
MUX_CFG(DA850, NEMA_CS_2, 7, 0, 15, 1, false)
/* GPIO function */
+ MUX_CFG(DA850, GPIO2_8, 5, 28, 15, 8, false)
MUX_CFG(DA850, GPIO2_15,5, 0, 15, 8, false)
- MUX_CFG(DA850, GPIO8_10,18, 28, 15, 8, false)
MUX_CFG(DA850, GPIO4_0, 10, 28, 15, 8, false)
MUX_CFG(DA850, GPIO4_1, 10, 24, 15, 8, false)
#endif
@@ -562,12 +562,11 @@ const short da850_mcasp_pins[] __initdata = {
};
const short da850_lcdcntl_pins[] __initdata = {
- DA850_LCD_D_1, DA850_LCD_D_2, DA850_LCD_D_3, DA850_LCD_D_4,
- DA850_LCD_D_5, DA850_LCD_D_6, DA850_LCD_D_7, DA850_LCD_D_8,
- DA850_LCD_D_9, DA850_LCD_D_10, DA850_LCD_D_11, DA850_LCD_D_12,
- DA850_LCD_D_13, DA850_LCD_D_14, DA850_LCD_D_15, DA850_LCD_PCLK,
- DA850_LCD_HSYNC, DA850_LCD_VSYNC, DA850_NLCD_AC_ENB_CS, DA850_GPIO2_15,
- DA850_GPIO8_10,
+ DA850_LCD_D_0, DA850_LCD_D_1, DA850_LCD_D_2, DA850_LCD_D_3,
+ DA850_LCD_D_4, DA850_LCD_D_5, DA850_LCD_D_6, DA850_LCD_D_7,
+ DA850_LCD_D_8, DA850_LCD_D_9, DA850_LCD_D_10, DA850_LCD_D_11,
+ DA850_LCD_D_12, DA850_LCD_D_13, DA850_LCD_D_14, DA850_LCD_D_15,
+ DA850_LCD_PCLK, DA850_LCD_HSYNC, DA850_LCD_VSYNC, DA850_NLCD_AC_ENB_CS,
-1
};
diff --git a/arch/arm/mach-davinci/include/mach/mux.h
b/arch/arm/mach-davinci/include/mach/mux.h
index 7732832..fc8eb16 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -872,8 +872,8 @@ enum davinci_da850_index {
DA850_NEMA_CS_2,
/* GPIO function */
+ DA850_GPIO2_8,
DA850_GPIO2_15,
- DA850_GPIO8_10,
DA850_GPIO4_0,
DA850_GPIO4_1,
};
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] parport: Add character LCD driver for da850/omap-l138
On Fri, Sep 04, 2009 at 03:50:42, Andrew Morton wrote: On Wed, 2 Sep 2009 19:23:27 +0530 Sudhakar Rajashekhara sudhakar@ti.com wrote: On Tue, Sep 01, 2009 at 18:53:30, Pavel Machek wrote: Hi! On TI DA850/OMAP-L138 EVM, HD44780 (24x2) LCD panel is being used, interfaced through the SoC specific LCD interface[1]. Driver from drivers/staging/panel/panel.c works for this LCD panel but that driver expects the LCD panel to be interfaced through a parallel port. This patch implements a dummy parallel port driver which interfaces to the panel driver in staging area through the LCD interface available on SoC. This is a nasty hack, right? Just fixup panel.c to work with your interface, too? Pavel Agree, that this is a hack. I have submitted a patch which modifies panel.c to support this kind of interface. Currently the problem with panel.c is that, it is tightly coupled with parallel port interface. Panel driver needs to be completely re-written to de-couple parallel port related stuff. If I have to do this, then I need to start from ground zero as I do not have a setup on which HD44780 panel has been interfaced using parallel port. But I can certainly help here by testing such a modification to the panel driver by testing on the hardware what I have. In the meantime, can I re-submit this patch by moving the dummy parallel port driver to reside in staging area? Later it can be moved/deleted depending on the modifications to the panel driver. If we're going to pull tricks like that then panel.c will never get itself moved from outside staging/ :( Really, I don't think we should be hacking things into drivers/parport/ code to accommodate design shortcomings in a staging/ driver. Once done, these things have a tendency to never be undone. Is anyone working on cleaning up the panel driver under staging to remove dependency on parallel port? If yes, please reply to this mail, so that we can coordinate. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] davinci: Correct the GPIO number for LCD panel power
On the latest DA850/OMAP-L138 EVM (Beta) the GPIO pin
number of LCD panel power has changed. This patch takes
care of this change. Software will support only Beta
versions of DA850/OMAP-L138 EVM.
In the process, add the missing entry for data pin 0
in da850_lcdcntl_pins structure.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/da850.c| 14 +++---
arch/arm/mach-davinci/include/mach/mux.h |2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 192d719..9fbac35 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -506,8 +506,8 @@ static const struct mux_config da850_pins[] = {
MUX_CFG(DA850, EMA_WAIT_1, 6, 24, 15, 1, false)
MUX_CFG(DA850, NEMA_CS_2, 7, 0, 15, 1, false)
/* GPIO function */
+ MUX_CFG(DA850, GPIO2_8, 5, 28, 15, 8, false)
MUX_CFG(DA850, GPIO2_15,5, 0, 15, 8, false)
- MUX_CFG(DA850, GPIO8_10,18, 28, 15, 8, false)
MUX_CFG(DA850, GPIO4_0, 10, 28, 15, 8, false)
MUX_CFG(DA850, GPIO4_1, 10, 24, 15, 8, false)
#endif
@@ -555,12 +555,12 @@ const short da850_mcasp_pins[] __initdata = {
};
const short da850_lcdcntl_pins[] __initdata = {
- DA850_LCD_D_1, DA850_LCD_D_2, DA850_LCD_D_3, DA850_LCD_D_4,
- DA850_LCD_D_5, DA850_LCD_D_6, DA850_LCD_D_7, DA850_LCD_D_8,
- DA850_LCD_D_9, DA850_LCD_D_10, DA850_LCD_D_11, DA850_LCD_D_12,
- DA850_LCD_D_13, DA850_LCD_D_14, DA850_LCD_D_15, DA850_LCD_PCLK,
- DA850_LCD_HSYNC, DA850_LCD_VSYNC, DA850_NLCD_AC_ENB_CS, DA850_GPIO2_15,
- DA850_GPIO8_10,
+ DA850_LCD_D_0, DA850_LCD_D_1, DA850_LCD_D_2, DA850_LCD_D_3,
+ DA850_LCD_D_4, DA850_LCD_D_5, DA850_LCD_D_6, DA850_LCD_D_7,
+ DA850_LCD_D_8, DA850_LCD_D_9, DA850_LCD_D_10, DA850_LCD_D_11,
+ DA850_LCD_D_12, DA850_LCD_D_13, DA850_LCD_D_14, DA850_LCD_D_15,
+ DA850_LCD_PCLK, DA850_LCD_HSYNC, DA850_LCD_VSYNC, DA850_NLCD_AC_ENB_CS,
+ DA850_GPIO2_8, DA850_GPIO2_15,
-1
};
diff --git a/arch/arm/mach-davinci/include/mach/mux.h
b/arch/arm/mach-davinci/include/mach/mux.h
index 7732832..fc8eb16 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -872,8 +872,8 @@ enum davinci_da850_index {
DA850_NEMA_CS_2,
/* GPIO function */
+ DA850_GPIO2_8,
DA850_GPIO2_15,
- DA850_GPIO8_10,
DA850_GPIO4_0,
DA850_GPIO4_1,
};
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] parport: Add character LCD driver for da850/omap-l138
On Tue, Sep 01, 2009 at 18:53:30, Pavel Machek wrote: Hi! On TI DA850/OMAP-L138 EVM, HD44780 (24x2) LCD panel is being used, interfaced through the SoC specific LCD interface[1]. Driver from drivers/staging/panel/panel.c works for this LCD panel but that driver expects the LCD panel to be interfaced through a parallel port. This patch implements a dummy parallel port driver which interfaces to the panel driver in staging area through the LCD interface available on SoC. This is a nasty hack, right? Just fixup panel.c to work with your interface, too? Pavel Agree, that this is a hack. I have submitted a patch which modifies panel.c to support this kind of interface. Currently the problem with panel.c is that, it is tightly coupled with parallel port interface. Panel driver needs to be completely re-written to de-couple parallel port related stuff. If I have to do this, then I need to start from ground zero as I do not have a setup on which HD44780 panel has been interfaced using parallel port. But I can certainly help here by testing such a modification to the panel driver by testing on the hardware what I have. In the meantime, can I re-submit this patch by moving the dummy parallel port driver to reside in staging area? Later it can be moved/deleted depending on the modifications to the panel driver. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] parport: Add character LCD driver for da850/omap-l138
On TI DA850/OMAP-L138 EVM, HD44780 (24x2) LCD panel is
being used, interfaced through the SoC specific LCD
interface[1].
Driver from drivers/staging/panel/panel.c works for this
LCD panel but that driver expects the LCD panel to be
interfaced through a parallel port.
This patch implements a dummy parallel port driver which
interfaces to the panel driver in staging area through the
LCD interface available on SoC.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
drivers/parport/Kconfig |8 +
drivers/parport/Makefile |3 +-
drivers/parport/parport_da8xx.c | 324 +
include/linux/parport_da8xx.h | 28 +++
4 files changed, 362 insertions(+), 1 deletions(-)
create mode 100644 drivers/parport/parport_da8xx.c
create mode 100644 include/linux/parport_da8xx.h
diff --git a/drivers/parport/Kconfig b/drivers/parport/Kconfig
index 855f389..5709b88 100644
--- a/drivers/parport/Kconfig
+++ b/drivers/parport/Kconfig
@@ -154,6 +154,14 @@ config PARPORT_1284
transfer modes. Also say Y if you want device ID information to
appear in /proc/sys/dev/parport/*/autoprobe*. It is safe to say N.
+config PARPORT_DA8XX
+ tristate DA8XX Dummy Parallel Port
+ depends on ARCH_DAVINCI_DA8XX !(FB_DA8XX = y) !(FB_DA8XX = m)
+ select PARPORT_NOT_PC
+ help
+ Say Y here if you need support for the DA8XX/OMAP-L1XX character
+ LCD which is using the staging panel driver.
+
config PARPORT_NOT_PC
bool
diff --git a/drivers/parport/Makefile b/drivers/parport/Makefile
index 696b8d4..ad7dfd0 100644
--- a/drivers/parport/Makefile
+++ b/drivers/parport/Makefile
@@ -18,4 +18,5 @@ obj-$(CONFIG_PARPORT_ATARI) += parport_atari.o
obj-$(CONFIG_PARPORT_SUNBPP) += parport_sunbpp.o
obj-$(CONFIG_PARPORT_GSC) += parport_gsc.o
obj-$(CONFIG_PARPORT_AX88796) += parport_ax88796.o
-obj-$(CONFIG_PARPORT_IP32) += parport_ip32.o
\ No newline at end of file
+obj-$(CONFIG_PARPORT_IP32) += parport_ip32.o
+obj-$(CONFIG_PARPORT_DA8XX)+= parport_da8xx.o
diff --git a/drivers/parport/parport_da8xx.c b/drivers/parport/parport_da8xx.c
new file mode 100644
index 000..117123f
--- /dev/null
+++ b/drivers/parport/parport_da8xx.c
@@ -0,0 +1,324 @@
+/* linux/drivers/parport/parport_da8xx.c
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed .as is. WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/parport.h
+#include linux/parport_da8xx.h
+#include linux/interrupt.h
+#include linux/errno.h
+#include linux/delay.h
+#include linux/clk.h
+#include linux/platform_device.h
+#include linux/io.h
+
+#include asm/irq.h
+
+/* LCDC register offsets */
+#define LCDC_LCD_CTRL 0x04
+#define LCDC_LIDD_CTRL 0x0c
+#define LCDC_LIDD_CS0_CONF 0x10
+#define LCDC_LIDD_CS0_ADDR 0x14
+#define LCDC_LIDD_CS0_DATA 0x18
+#define LCDC_LIDD_CS1_CONF 0x1c
+#define LCDC_LIDD_CS1_ADDR 0x20
+#define LCDC_LIDD_CS1_DATA 0x24
+
+#define LCD_CTRL_RASTER_MODE BIT(0)
+#define LIDD_CONF_W_SU BIT(27)
+#define LIDD_CONF_W_STROBE (4 21)
+#define LIDD_CONF_W_HOLD BIT(17)
+#define LIDD_CONF_R_SU BIT(12)
+#define LIDD_CONF_R_STROBE (4 6)
+#define LIDD_CONF_R_HOLD BIT(2)
+#define LIDD_CTRL_MODE_SEL_MASK0x7
+#define LIDD_CTRL_MODE_HITACHI 0x4
+
+struct da8xx_drvdata {
+ struct parport *parport;
+
+ struct device *dev;
+ struct resource *io;
+ struct clk *clk;
+
+ unsigned char irq_enabled;
+ unsigned char version;
+
+ void __iomem*base;
+ void __iomem*spp_data;
+ void __iomem*spp_cpr;
+};
+
+static inline struct da8xx_drvdata *pp_to_drv(struct parport *p)
+{
+ return p-private_data;
+}
+
+static void
+parport_da8xx_init_state(struct pardevice *d, struct parport_state *s)
+{
+ struct da8xx_drvdata *dd = pp_to_drv(d-port);
+
+ memset(s, 0, sizeof(struct parport_state));
+
+ dev_dbg(dd-dev, init_state: %p: state=%p\n, d, s);
+}
+
+static void
+parport_da8xx_save_state(struct parport *p, struct parport_state *s)
+{
+ /* do nothing */
+}
+
+static void
+parport_da8xx_restore_state(struct parport *p, struct parport_state *s)
+{
+ /* do nothing
[PATCH] staging/panel/panel.c: Add support for TI CLCD interface
On TI DA850/OMAP-L138 EVM, HD44780 (24x2) LCD panel is being
used[1], but it is interfaced through the SoC specific LCD
interface and not through parallel port. A parallel port
driver has been developed which interfaces to the panel driver
through the SoC specific LCD interface.
Basically, both the serial and parallel interfaces supported
by the panel driver do not suit the specific interface SoC is
supporting so, a new interface type has been introduced.
Ideally the panel driver should be de-coupled from parallel
and serial port related items but this patch is something
that can be merged in the meantime.
[1]Specification of the character LCD interface on TI DA850/OMAP-L138:
http://www.ti.com/litv/pdf/sprufm0a.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
drivers/staging/panel/panel.c | 50 +++-
1 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/panel/panel.c b/drivers/staging/panel/panel.c
index c2747bc..dd7d3fd 100644
--- a/drivers/staging/panel/panel.c
+++ b/drivers/staging/panel/panel.c
@@ -243,6 +243,7 @@ static unsigned char
lcd_bits[LCD_PORTS][LCD_BITS][BIT_STATES];
*/
#define LCD_PROTO_PARALLEL 0
#define LCD_PROTO_SERIAL1
+#define LCD_PROTO_TI_DA8XX_LCD 2
/*
* LCD character sets
@@ -440,7 +441,8 @@ MODULE_PARM_DESC(lcd_type,
static int lcd_proto = -1;
module_param(lcd_proto, int, );
-MODULE_PARM_DESC(lcd_proto, LCD communication: 0=parallel (//), 1=serial);
+MODULE_PARM_DESC(lcd_proto, LCD communication: 0=parallel (//), 1=serial,
+ 2=TI LCD Interface);
static int lcd_charset = -1;
module_param(lcd_charset, int, );
@@ -797,6 +799,26 @@ static void lcd_write_data_p8(int data)
spin_unlock(pprt_lock);
}
+/* send a command to the TI LCD panel */
+static void lcd_write_cmd_tilcd(int cmd)
+{
+ spin_lock(pprt_lock);
+ /* present the data to the control port */
+ w_ctr(pprt, cmd);
+ udelay(60);
+ spin_unlock(pprt_lock);
+}
+
+/* send data to the TI LCD panel */
+static void lcd_write_data_tilcd(int data)
+{
+ spin_lock(pprt_lock);
+ /* present the data to the data port */
+ w_dtr(pprt, data);
+ udelay(60);
+ spin_unlock(pprt_lock);
+}
+
static void lcd_gotoxy(void)
{
lcd_write_cmd(0x80 /* set DDRAM address */
@@ -870,6 +892,26 @@ static void lcd_clear_fast_p8(void)
lcd_gotoxy();
}
+/* fills the display with spaces and resets X/Y */
+static void lcd_clear_fast_tilcd(void)
+{
+ int pos;
+ lcd_addr_x = lcd_addr_y = 0;
+ lcd_gotoxy();
+
+ spin_lock(pprt_lock);
+ for (pos = 0; pos lcd_height * lcd_hwidth; pos++) {
+ /* present the data to the data port */
+ w_dtr(pprt, ' ');
+ udelay(60);
+ }
+
+ spin_unlock(pprt_lock);
+
+ lcd_addr_x = lcd_addr_y = 0;
+ lcd_gotoxy();
+}
+
/* clears the display and resets X/Y */
static void lcd_clear_display(void)
{
@@ -1396,7 +1438,7 @@ void lcd_init(void)
if (lcd_da_pin == PIN_NOT_SET)
lcd_da_pin = DEFAULT_LCD_PIN_SDA;
- } else {/* PARALLEL */
+ } else if (lcd_proto == LCD_PROTO_PARALLEL) { /* PARALLEL */
lcd_write_cmd = lcd_write_cmd_p8;
lcd_write_data = lcd_write_data_p8;
lcd_clear_fast = lcd_clear_fast_p8;
@@ -1407,6 +1449,10 @@ void lcd_init(void)
lcd_rs_pin = DEFAULT_LCD_PIN_RS;
if (lcd_rw_pin == PIN_NOT_SET)
lcd_rw_pin = DEFAULT_LCD_PIN_RW;
+ } else {
+ lcd_write_cmd = lcd_write_cmd_tilcd;
+ lcd_write_data = lcd_write_data_tilcd;
+ lcd_clear_fast = lcd_clear_fast_tilcd;
}
if (lcd_bl_pin == PIN_NOT_SET)
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] TI DaVinci EMAC: delay DaVinci EMAC initialization
On TI's DA850/OMAP-L138 EVM, MAC address is stored in SPI
flash which is accessed using MTD interface.
This patch delays the initialization of DaVinci EMAC driver
by changing module_init to late_initcall. This helps SPI and
MTD drivers to get initialized before EMAC thereby enabling
EMAC driver to read the MAC address while booting and use it.
Tested with NFS on DM644x, DM6467, DA830/OMAP-L137 and
DA850/OMAP-L138 EVMs.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Reviewed-by: Chaithrika U S chaithr...@ti.com
---
drivers/net/davinci_emac.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 12fd446..5e6652b 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -2817,7 +2817,7 @@ static int __init davinci_emac_init(void)
{
return platform_driver_register(davinci_emac_driver);
}
-module_init(davinci_emac_init);
+late_initcall(davinci_emac_init);
/**
* davinci_emac_exit: EMAC driver module exit
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] [MTD] driver/Makefile: Initialize mtd and spi before net
On TI's da850/omap-l138 EVM, MAC address is stored in SPI flash. This patch changes the initialization sequence of the drivers by moving mtd and spi ahead of net in drivers/Makefile thereby enabling da850/omap-l138 ethernet driver to read the MAC address while booting. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com --- drivers/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/Makefile b/drivers/Makefile index bc4205d..2a1d41f 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -42,6 +42,8 @@ obj-y += macintosh/ obj-$(CONFIG_IDE) += ide/ obj-$(CONFIG_SCSI) += scsi/ obj-$(CONFIG_ATA) += ata/ +obj-$(CONFIG_MTD) += mtd/ +obj-$(CONFIG_SPI) += spi/ obj-y += net/ obj-$(CONFIG_ATM) += atm/ obj-$(CONFIG_FUSION) += message/ @@ -50,8 +52,6 @@ obj-y += ieee1394/ obj-$(CONFIG_UIO) += uio/ obj-y += cdrom/ obj-y += auxdisplay/ -obj-$(CONFIG_MTD) += mtd/ -obj-$(CONFIG_SPI) += spi/ obj-$(CONFIG_PCCARD) += pcmcia/ obj-$(CONFIG_DIO) += dio/ obj-$(CONFIG_SBUS) += sbus/ -- 1.5.6 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] [MTD] mtdpart: memory accessor interface for MTD layer
This patch implements memory accessor interface in the MTD
layer which enables the kernel to access flash data.
This patch adds two new members to the mtd_partition structure,
a function handler which will be called during setup of the
partition and an argument to be passed to this setup function.
Example:
+static struct mtd_partition spi_flash_partitions[] = {
+ [0] = {
+ .name = U-Boot,
+ .offset = 0,
+ .size = SZ_256K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [1] = {
+ .name = U-Boot Environment,
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = SZ_64K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [2] = {
+ .name = Linux,
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = SZ_7M,
+ .mask_flags = 0,
+ },
+ [3] = {
+ .name = MAC Address,
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = SZ_64K,
+ .mask_flags = 0,
+ .setup = davinci_get_mac_addr,
+ .context= (void *)0,
+ },
+};
The davinci_get_mac_addr function reads the MAC address from
offset ZERO of last MTD partition.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
drivers/mtd/mtdpart.c | 40
include/linux/mtd/partitions.h |3 +++
2 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 349fcbe..8f14653 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -26,6 +26,7 @@ static LIST_HEAD(mtd_partitions);
struct mtd_part {
struct mtd_info mtd;
struct mtd_info *master;
+ struct memory_accessor macc;
uint64_t offset;
struct list_head list;
};
@@ -327,6 +328,39 @@ int del_mtd_partitions(struct mtd_info *master)
}
EXPORT_SYMBOL(del_mtd_partitions);
+/*
+ * This lets other kernel code access the flash data. For example, it
+ * might hold a board's Ethernet address, or board-specific calibration
+ * data generated on the manufacturing floor.
+ */
+static ssize_t mtd_macc_read(struct memory_accessor *macc, char *buf,
+ off_t offset, size_t count)
+{
+ struct mtd_part *part = container_of(macc, struct mtd_part, macc);
+ ssize_t ret = -EIO;
+ size_t retlen;
+
+ if (part_read((struct mtd_info *)part, offset, count,
+ retlen, buf) == 0)
+ ret = retlen;
+
+ return ret;
+}
+
+static ssize_t mtd_macc_write(struct memory_accessor *macc, const char *buf,
+ off_t offset, size_t count)
+{
+ struct mtd_part *part = container_of(macc, struct mtd_part, macc);
+ ssize_t ret = -EIO;
+ size_t retlen;
+
+ if (part_write((struct mtd_info *)part, offset, count,
+ retlen, buf) == 0)
+ ret = retlen;
+
+ return ret;
+}
+
static struct mtd_part *add_one_partition(struct mtd_info *master,
const struct mtd_partition *part, int partno,
uint64_t cur_offset)
@@ -364,6 +398,9 @@ static struct mtd_part *add_one_partition(struct mtd_info
*master,
slave-mtd.read = part_read;
slave-mtd.write = part_write;
+ slave-macc.read = mtd_macc_read;
+ slave-macc.write = mtd_macc_write;
+
if (master-panic_write)
slave-mtd.panic_write = part_panic_write;
@@ -428,6 +465,9 @@ static struct mtd_part *add_one_partition(struct mtd_info
*master,
printk(KERN_NOTICE 0x%012llx-0x%012llx : \%s\\n, (unsigned long
long)slave-offset,
(unsigned long long)(slave-offset + slave-mtd.size),
slave-mtd.name);
+ if (part-setup)
+ part-setup(slave-macc, (void *)part-context);
+
/* let's do some sanity checks */
if (slave-offset = master-size) {
/* let's register it anyway to preserve ordering */
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index af6dcb9..cc76779 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -10,6 +10,7 @@
#define MTD_PARTITIONS_H
#include linux/types.h
+#include linux/memory.h
/*
@@ -40,6 +41,8 @@ struct mtd_partition {
uint64_t offset;/* offset within the master MTD space */
uint32_t mask_flags;/* master MTD flags to mask out for
this partition */
struct nand_ecclayout *ecclayout; /* out of band layout for this
partition (NAND only)*/
+ void (*setup)(struct memory_accessor *, void *context);
+ void *context;
};
#define MTDPART_OFS_NXTBLK (-2)
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http
RE: [PATCH] [MTD] m25p80: memory accessor interface for SPI MTD driver
On Tue, Aug 04, 2009 at 06:54:01, David Brownell wrote: On Monday 03 August 2009, Sudhakar Rajashekhara wrote: On TI's da850/omap-l138 EVM, MAC address is stored in SPI flash. This patch implements memory accessor interface for SPI MTD driver which enables the kernel to access flash data. If that's going to be possible, shouldn't it work for any MTD device? And the lack of protection bothers me a bit more here than with EEPROMs and NVRAM, since it seems kind of easy to clobber UBI (or JFFS2 etc) data. Maybe there should be a way to make jus a specific partition available this way? I have submitted the modified version of this patch which implements the accessor interface in mtdpart.c file so that it works for any mtd drivers (NAND, NOR, SPI). Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
