Re: Driver probe functionality

2010-07-08 Thread jean-philippe francois
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 n

RE: Driver probe functionality

2010-07-08 Thread Philby John
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 p

RE: Driver probe functionality

2010-07-08 Thread Sean Kelvin Preston
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 platfor

RE: Driver probe functionality

2010-07-08 Thread Philby John
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. > > > Other

RE: Driver probe functionality

2010-07-08 Thread Sean Kelvin Preston
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

RE: Driver probe functionality

2010-07-08 Thread Philby John
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

RE: Driver probe functionality

2010-07-08 Thread Sean Kelvin Preston
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 fai

RE: Driver probe functionality

2010-07-08 Thread Philby John
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...

RE: Driver probe functionality

2010-07-08 Thread Sean Kelvin Preston
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_davinc

Re: Driver probe functionality

2010-07-07 Thread jean-philippe francois
2010/7/7 Sean Kelvin Preston : > Hi > > I am trying to understand how the driver probe and loading works from a > kernel level.  I am working on changing the NAND chip used on the DM365 EVM > and have managed to determine that the davinci_nand driver is not loading > for the new chip because the pl