RE: Driver probe functionality
Hi Jean-Philippe
Thanks for the response.
> For platform bus, you can match by id or by name :
> for example in the board code you have :
>
> static struct platform_device davinci_nand_device = {
>> lines removed >>
>
> And in the driver code :
>
> static struct platform_driver nand_davinci_driver = {
>> linesremoved >>
>
> the device and driver name must match if you want the
> platform_match function to work.
I have found this code and the observed behaviour I have is that it is doing
a match by name for the TI DM365 EVM board I am using. If I have the old
NAND chip (MT29F16G08FAA) plugged in then I can see platform_match going
through the list and it finds the davinci_nand driver. If I plug my new
NAND chip (MT29F8G08ABABA) in then I can see the same platform_match
occurring but this time it does not find the driver so no match occurs.
I know this particular chip is supported on this EVM as I have managed to
get it working correctly with uBoot but it obviously initialises and defines
things differently to the kernel. So what I do not understand or know is
what decides which drivers should be loaded? Something must be doing a
check based on the fact that I have enabled the driver in the board config
but it is not available for the platform_match to succeed.
When I looked at the execution of the code I can see the following functions
being called: platform_driver_probe, platform_driver_register,
platform_match (repeated looking through list of driver names),
platform_driver_unregister. It does not appear that the actual matching for
NAND IDs is occurring as that section of the driver code does not appear to
be executed so I think I am missing something that is executed earlier to
detect the hardware.
I would appreciate any pointers.
Regards
Sean
--
Sean Preston
Email: se...@pfk.co.za
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Driver probe functionality
On Thu, 2010-07-08 at 11:25 +0200, Sean Kelvin Preston wrote:
> Hi Jean-Philippe
>
> Thanks for the response.
>
> > For platform bus, you can match by id or by name :
> > for example in the board code you have :
> >
> > static struct platform_device davinci_nand_device = {
> >> lines removed >>
> >
> > And in the driver code :
> >
> > static struct platform_driver nand_davinci_driver = {
> >> linesremoved >>
> >
> > the device and driver name must match if you want the
> > platform_match function to work.
>
> I have found this code and the observed behaviour I have is that it is doing
> a match by name for the TI DM365 EVM board I am using. If I have the old
> NAND chip (MT29F16G08FAA) plugged in then I can see platform_match going
> through the list and it finds the davinci_nand driver. If I plug my new
> NAND chip (MT29F8G08ABABA) in then I can see the same platform_match
> occurring but this time it does not find the driver so no match occurs.
>
> I know this particular chip is supported on this EVM as I have managed to
> get it working correctly with uBoot but it obviously initialises and defines
> things differently to the kernel. So what I do not understand or know is
> what decides which drivers should be loaded? Something must be doing a
> check based on the fact that I have enabled the driver in the board config
> but it is not available for the platform_match to succeed.
>
You are right, the platform_match() does not succeed based on a simple
string comparison. platform_match() defined in platform.c drivers/base,
does a string comparison of the driver and device name variable. If
there is a name mismatch platform_match() bails out and the probe fails.
Try setting the ".name" variable in your platform driver and device to
be the same.
Regards,
Philby
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Driver probe functionality
Hi Philby > You are right, the platform_match() does not succeed based on a simple > string comparison. platform_match() defined in platform.c drivers/base, > does a string comparison of the driver and device name variable. If there is a > name mismatch platform_match() bails out and the probe fails. > > Try setting the ".name" variable in your platform driver and device to be the > same. The names are the same as I have not changed that code at all. As I was just testing the new NAND I did not change the drivers except to add an additional ID to the drivers/mtd/nand/nand_ids.c file. Otherwise I just replaced the actual chip on the EVM board. This is why I was wondering if there was something else going on when the platform_probe is done or maybe before that which is failing because I need to change or add something elsewhere to identify the new chip. Thanks for the info. Regards Sean -- Sean Preston Email: se...@pfk.co.za ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Driver probe functionality
On Thu, 2010-07-08 at 12:37 +0200, Sean Kelvin Preston wrote: > Hi Philby > > > You are right, the platform_match() does not succeed based on a simple > > string comparison. platform_match() defined in platform.c drivers/base, > > does a string comparison of the driver and device name variable. If there > is a > > name mismatch platform_match() bails out and the probe fails. > > > > Try setting the ".name" variable in your platform driver and device to be > the > > same. > > The names are the same as I have not changed that code at all. As I was > just testing the new NAND I did not change the drivers except to add an > additional ID to the drivers/mtd/nand/nand_ids.c file. Otherwise I just > replaced the actual chip on the EVM board. This is why I was wondering if > there was something else going on when the platform_probe is done or maybe > before that which is failing because I need to change or add something > elsewhere to identify the new chip. > Okay, then how about here, where a check is first done to see if there is a match between the device and driver id if (drv->bus->match && !drv->bus->match(dev, drv)) Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Driver probe functionality
Hi > > The names are the same as I have not changed that code at all. As I > > was just testing the new NAND I did not change the drivers except to > > add an additional ID to the drivers/mtd/nand/nand_ids.c file. > > Otherwise I just replaced the actual chip on the EVM board. This is > > why I was wondering if there was something else going on when the > > platform_probe is done or maybe before that which is failing because I > > need to change or add something elsewhere to identify the new chip. > > > > Okay, then how about here, where a check is first done to see if there is a > match between the device and driver id > > if (drv->bus->match && !drv->bus->match(dev, drv)) Sorry I am struggling to find this line of code. I am using version 2.6.32-rc2 of the kernel. Where would I look to find this entry? Regards Sean -- Sean Preston Email: se...@pfk.co.za ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Driver probe functionality
On Thu, 2010-07-08 at 13:28 +0200, Sean Kelvin Preston wrote: > Hi > > > > The names are the same as I have not changed that code at all. As I > > > was just testing the new NAND I did not change the drivers except to > > > add an additional ID to the drivers/mtd/nand/nand_ids.c file. > > > Otherwise I just replaced the actual chip on the EVM board. This is > > > why I was wondering if there was something else going on when the > > > platform_probe is done or maybe before that which is failing because I > > > need to change or add something elsewhere to identify the new chip. > > > > > > > Okay, then how about here, where a check is first done to see if there is > a > > match between the device and driver id > > > > if (drv->bus->match && !drv->bus->match(dev, drv)) > > Sorry I am struggling to find this line of code. I am using version > 2.6.32-rc2 of the kernel. Where would I look to find this entry? > Sorry about that, I was looking at an older kernel version :-) In the function driver_match_device() Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Driver probe functionality
Hi > Sorry about that, I was looking at an older kernel version :-) In the function > driver_match_device() Thanks for the suggestions and help so far but as I am new to this and I am really not understanding what the problem is. From what I have understood is that the platform_probe and platform_register functions are not loading the driver. I have not changed anything about the driver except to add the actual chip id to the nand_ids.c file but by looking at the original NAND boot sequence I have observed that this is only used later once the davinci_nand driver is loaded. So when the kernel boots and it needs to determine what hardware is there. How is it doing this? How does it know that a particular driver should be loaded? In my board configuration file for the TO DM365 EVM board it has an option to enable the davinci_nand and this is definitely being compiled in as the kernel work with the old NAND but not the new one. Except for me physically changing the NAND chip nothing else has changed so surely the driver should load anyway? Sorry for all the newbie questions but I am new and digging around worked for getting the NAND working with uBoot but is not for getting it to work with the Linux Kernel. Regards Sean -- Sean Preston Email: se...@pfk.co.za ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Driver probe functionality
On Thu, 2010-07-08 at 14:20 +0200, Sean Kelvin Preston wrote: > Hi > > > Sorry about that, I was looking at an older kernel version :-) In the > function > > driver_match_device() > > Thanks for the suggestions and help so far but as I am new to this and I am > really not understanding what the problem is. From what I have understood > is that the platform_probe and platform_register functions are not loading > the driver. You need to identify exactly where the code fails. Like previously mentioned I could think of two such places, can't think of any other. > I have not changed anything about the driver except to add the > actual chip id to the nand_ids.c file but by looking at the original NAND > boot sequence I have observed that this is only used later once the > davinci_nand driver is loaded. > > So when the kernel boots and it needs to determine what hardware is there. > How is it doing this? How does it know that a particular driver should be > loaded? After a match is found using the id and name variable, the function driver_probe_device() calls really_probe(dev, drv). This is the function that actually calls your driver specific probe function. But you can verify all this by putting printk's in your code. Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Driver probe functionality
2010/7/8 Sean Kelvin Preston : > Hi > >> I guess it is not a platform_match problem then, but a driver_probe > problem. >> >> Did you try using it as a module ? > > No I have not tried it as a module. The TI DM365 EVM board does not have > any modules built by default from what I can see so will need to see how to > get it working with the build environment to test. The old NAND works > perfectly with this kernel. > > When the driver_probe is run how does it determine if a piece of hardware > exists or which driver a piece of hardware should be using. At this stage > nothing has been changed from a hardware point of view except the physical > NAND chip. As best as I can tell the interfacing is working correctly > because I can get the chip working with uBoot. The board code registers the device, if it is not compiled out by config options Then the nand driver init function register the driver. Since nothing changed, I assume the platform bus code matches the driver and the device. Then the driver code probe function is called. Then you have to dig in nand_scan_idents, which in turns calls nand_get_flash_type (in drivers/mtd/nand_base.c) Happy printk debugging ! Jean-Philippe François ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DM355 Auto Focus
Hi All,
I am working on a DM355 processor based Development board and the kernel
version is 2.6.10.
I need auto focus value that is sharpness of the image.
I found an example application for autofocus in DM355 EVM package and
the output of the
sample example is as follows
2974: Green Sum (Paxel 0 Data)
122 : FV Sum for IIR filter 0 (Paxel 0 Data)
1496: FV Sum for IIR filter 1 (Paxel 0 Data)
0 : Zero (Paxel 0 Data)
1022: Red/Blue Sum (Paxel 0 Data)
62 : FV Sum for IIR filter 0 (Paxel 0 Data)
831 : FV Sum for IIR filter 1 (Paxel 0 Data)
0 : Zero (Paxel 0 Data)
1122: Red/Blue Sum (Paxel 0 Data)
115 : FV Sum for IIR filter 0 (Paxel 0 Data)
881 : FV Sum for IIR filter 1 (Paxel 0 Data)
0 : Zero (Paxel 0 Data)
I could not understand this output format. Please can anyone clarify my
doubts. I need a single focus value.
How does I know that the object is focused properly using the H3A engine
in DM355 ?
Can I give a static frame data (instead of the frame captured from
sensor) to this Auto Focus engine ?
My configuration:
int iir0[12] = { 64, 0, 0, 21, 22, 21, 0, 0, -16, 32, -16 };
int iir1[12] = { 64, 0, 0, 21, 22, 21, 0, -29, -16,32, -16 };
/* Enable Alaw */
config.alaw_enable = H3A_AF_DISABLE;
/*Set Horizontal Median filter*/
config.hmf_config.enable = H3A_AF_DISABLE;
config.hmf_config.threshold = 100;
/* Set paxel Parmateres */
config.iir_config.hz_start_pos = 2;
config.paxel_config.height = 8;
config.paxel_config.width = 8;
config.paxel_config.line_incr = 4;
config.paxel_config.vt_start = 4;
config.paxel_config.hz_start = 4;
config.paxel_config.hz_cnt = 1;
config.paxel_config.vt_cnt = 1;
/* Set Accumulator mode */
//config.mode = ACCUMULATOR_SUMMED;
config.mode = ACCUMULATOR_PEAK;
/* Set IIR Filter Parameters */
for (index = 0; index < 11; index++) {
config.iir_config.coeff_set0[index] = iir0[index];
config.iir_config.coeff_set1[index] = iir1[index];
}
/* Set RGBPOSITION */
config.rgb_pos = RG_GB_BAYER;
Thanks
Dinesh
___
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 0/1] davinci: spi: replace existing driver
Fixed in this version: - Got rid of the incorrect IORESOURCE flags. DMA resources are now selected by index. - Added a third SPI controller version to differentiate the version on DM355 with no Tx interrupt and the version on DM365 and DM6467 with a Tx interrupt. This should fix the interrupt-mode issues on DM365. ** 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 |8 +- arch/arm/mach-davinci/dm365.c |6 - arch/arm/mach-davinci/include/mach/spi.h| 35 +- drivers/spi/davinci_spi.c | 1329 --- 7 files changed, 640 insertions(+), 768 deletions(-) ___ 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 1/1] davinci: spi: replace existing driver
On Thu, Jul 8, 2010 at 1:23 PM, Brian Niebuhr wrote: > 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: Nack. Sorry for being abrupt, but the patch still is full of unrelated whitespace changes (tabs converted to spaces) which makes the patch very difficult to review. This needs to be fixed. Let me know if you need help with how to do this. g. ___ 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 0/1] davinci: spi: replace existing driver
Fixed in this version: -Fixed whitespace mangling ** 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 |8 +- arch/arm/mach-davinci/dm365.c |6 - arch/arm/mach-davinci/include/mach/spi.h| 35 +- drivers/spi/davinci_spi.c | 1112 --- 7 files changed, 528 insertions(+), 663 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 v4 1/1] davinci: spi: replace existing driver
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.
Signed-off-by: Brian Niebuhr
---
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 |8 +-
arch/arm/mach-davinci/dm365.c |6 -
arch/arm/mach-davinci/include/mach/spi.h| 35 +-
drivers/spi/davinci_spi.c | 1112 ---
7 files changed, 528 insertions(+), 663 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index a319101..ad8779b 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
/* NOTE: this is geared for the standard config, with a socketed
* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
@@ -300,10 +301,19 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = false,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = true,
+};
+
static struct spi_board_info dm355_evm_spi_info[] __initconst = {
{
.modalias = "at25",
.platform_data = &at25640a,
+ .controller_data = &at25640a_spi_cfg,
.max_speed_hz = 10 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c
b/arch/arm/mach-davinci/board-dm355-leopard.c
index f1d8132..b2d8d48 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
/* NOTE: this is geared for the standard config, with a socketed
* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
@@ -222,10 +223,19 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = false,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = true,
+};
+
static struct spi_board_info dm355_leopard_spi_info[] __initconst = {
{
.modalias = "at25",
.platform_data = &at25640a,
+ .controller_data = &at25640a_spi_cfg,
.max_speed_hz = 10 * 1000 * 1000, /* a
Re: Rif: Re: [PATCH 3/3] ASoC: DaVinci: More accurate calculation for clock divider for McBSP (I2S)
2010/7/7 Mark Brown > On Tue, Jul 06, 2010 at 11:35:28AM -0700, Troy Kisky wrote: > > > Indeed, your algorithm may produce more accurate results for the specific > rate > > that you tested for. However, that seems more luck than anything. How do > you > > know that a frame size of 33 will always give more accurate results than > a frame > > size of 32? If your going to loop, you need to calculate the error and > minimize that > > and not just stop when framesize finally reaches your minimum size of 33. > > Yes, this is pretty much the algorithm I was trying to suggest earlier. > Iterate up until you hit either an exact match or decide that the frame > size is getting too big. > Mark and Troy, yes, it is wrong to say that a faster clock is automatically better approximated. But we did measurements and it was better. Sorry, no data available. The setup was difficult due to very thin wires solded to the I2S bus. Now we don't have the setup. At the moment is for me impossible to enhance the algorithm. I'm sorry. During september or october I'll work again on it and it is possible I could do some improvements. I hope anyway that the three patches are accepted. I don't know exactly how this procedure works, can you explain to me? I should see the patches in the mainline kernel, or in a special linux-next or other? Thanks, Raffaele ___ 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
Acked-by: Sneha Narnakaje
Cc: David Woodhouse
Signed-off-by: Andrew Morton
---
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
