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 =
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
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.
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
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
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
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
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
2010/7/8 Sean Kelvin Preston se...@pfk.co.za:
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
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
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
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):
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
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
14 matches
Mail list logo
