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 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 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
Re: Driver probe functionality
2010/7/7 Sean Kelvin Preston se...@pfk.co.za:
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 platform_match function never finds it in the
list of drivers loaded. How does a driver determine whether it should be
loaded? I have seen the probe function defined in the
drivers/base/platform.c as well as the drivers/mtd/nand/davinci_nand.c but
am not sure of the process and how these are being used.
Sorry I am new to kernel development so I am sure I have not asked this
question the best way so if there is anything else I can provide to help
answer my question then please let me know.
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 = {
.name = davinci_nand,
.id = 0,
.num_resources = ARRAY_SIZE(davinci_nand_resources),
.resource = davinci_nand_resources,
.dev= {
.platform_data = davinci_nand_data,
},
};
And in the driver code :
static struct platform_driver nand_davinci_driver = {
.remove = __exit_p(nand_davinci_remove),
.driver = {
.name = davinci_nand,
},
};
the device and driver name must match if you want the
platform_match function to work.
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
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
