On Friday 17 February 2012 03:03 PM, Rajendra Nayak wrote:
Sorry, I did'nt repond back because I wanted to get this resolved
completely before I did.
(3) did not probe the inserted mmc device because the driver was
doing a platform_driver_probe() and not a platform_driver_register().
Once I fixed that and removed the __init from probe, I then hit a
failure with gpio_to_irq() call in the mmc driver probe.
This was beacuse the twl gpio driver does not register irqs as said by
this error at driver load...
>>>> [ 16.217864] twl4030_gpio twl4030_gpio: can't dispatch IRQs from
modules
... apparently because there is no way to unregister a irq once the
module is unloaded.
That makes sdmmc pretty much unusable if twl gpio is built as a module.
Tony: I think there's a bug here - if the gpio-twl4030 module is
inserted,
removed and re-inserted, I think we'll end up creating the devices for
MMC
twice with the same name, resulting in sysfs complaining very loudly.
I still went ahead and tried (4) becasue I knew I would hit the above
issue. However I end up with a rmmod complaining 'resource temporarily
unavailable' because I see there are 3 gpio_requests, which I found
were from the .setup callback in the board file (I am using beagle).
The beagle board file does not seem to however register a .teardown
hook provided by twl4030 gpio platform_data structure to do a gpio_free.
So I am now trying to get the teardown function clean stuff up including
unregister the mmc device, which should also fix the problem with
multiple mmc device register that you reported with insmod/rmmod/insmod
sequence.
hmm, rmmod does not even seem to trigger the drivers .remove if there
are outstanding requests on the module, so a pdata->teardown called
from within the .remove does not help to get the gpio_requests done
from the board file cleaned.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
