I've been trying to get musb drivers for Davinci DM365 working
as modules. I can get them loading and working (on 3.0-rc7)
but they don't unload properly. It seems to be some problem with
the way the platform resources are claimed and released, particularly
the way the same resources are used for two platform devices; the
iomem resource tree gets screwed up. The resource handling seems the
same for the different musb glue layers, so I don't think this is a
davinci-specific problem.

I have tried to test on 3.4 but that dies a horrible OOPS death
the moment the modules are loaded, which I haven't looked into
further. Can provide details if interested, but patches are needed to
get musb loading on DM365 at all.

I cherry-picked e9e8c85 "usb: musb: make modules behave better" and
as far as I can see the platform resource handling is the same as
in 3.4.

Here's information about what I see under 3.0-rc7. I'm hoping someone
(Felipe?) can give me some clues about what's going on with the
platform resource handling. Sorry this is not a report against 3.4 but
I haven't got that working. :/

I configure and build musb_hdrc.ko and davinci.ko. musb-davinci
device with resources is added by the board, using mach-davinci/usb.c.

On first "modprobe davinci", things load and work OK.
Then I can rmmod davinci and it unloads.
If I try to modprobe davinci again, I get

root@H:/# modprobe davinci
musb-hdrc: version 6.0, cppi-dma, otg (peripheral+host)
musb-hdrc: failed to claim resource 0
musb-davinci musb-davinci: failed to register musb device
musb-davinci: probe of musb-davinci failed with error -16

/proc/iomem is interesting: After boot, before loading any modules
there is a musb region in the list:
01c64000-01c645ff : musb-davinci

After loading the modules, an identical line appears (a child?),
but on unloading the modules, BOTH musb-davinci lines disappear.
I tweaked kernel/resource.c to also print the pointer to the
resource in question:

Clean boot:
01c64000-01c645ff : musb-davinci (c046c470)

Module(s) loaded:
01c64000-01c645ff : musb-davinci (c23e9900)
  01c64000-01c645ff : musb-davinci (c046c470)

Module unloaded: (lines are gone).

Note that the new copy of the resource created when adding the
musb-hdrc device has ended up as the PARENT of the original
allocation. That looks like a bug to me.
At unload time the copy gets removed and the original allocation
disappears (leaks memory?)

I don't understand the platform resource code very well, but I
don't see how it's supposed to make sense to assign the same
resource structs to two devices; the musb-davinci glue device and
the "real" musb-hdrc.

I will continue to try some very ugly hacks to manipulate the
iomem resource tree, but I am starting to go cross-eyed on this,
hence this plea for help.

Does musb as module work correctly with load/unload/reload for any
of the supported glue layers, does anyone know?

Happy to reciprocate with some testing/patches!

Thanks,

--
Jon Povey
jon.po...@racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 
.
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, 
MK18 1TB .

The information contained in this electronic mail transmission is intended by 
Racelogic Ltd for the use of the named individual or entity to which it is 
directed and may contain information that is confidential or privileged. If you 
have received this electronic mail transmission in error, please delete it from 
your system without copying or forwarding it, and notify the sender of the 
error by reply email so that the sender's address records can be corrected. The 
views expressed by the sender of this communication do not necessarily 
represent those of Racelogic Ltd. Please note that Racelogic reserves the right 
to monitor e-mail communications passing through its network


_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Reply via email to