Hi Panto, On 10/31/2012 07:09 PM, Tony Lindgren wrote: > * Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx> [121031 11:05]: >> Hi Tony, >> >> On Oct 31, 2012, at 7:52 PM, Tony Lindgren wrote: >> >>> * Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx> [121031 10:26]: >>>> It is painless to move the adapter DT devices to arch/arm/mach-omap2 >>>> >>>> However I got bit by the __init at omap_build_device family functions. >>>> If you don't remove it, crashes every time you instantiate a device >>>> at runtime, or you load the cape driver as a module. >>> >>> Hmm I think you misunderstood me. You only need to create the >>> platform_device under arch/arm/mach-omap2. The device creation >>> happens only at __init, so omap_build_device can stay as __init. >>> The driver itself should be under drivers. >>> >>> But is this bus on non-device-tree omaps? If not, just make it >>> device tree only. >>> >> >> I'm afraid that's not the case. The whole notion of capebus is that >> instantiation of the devices doesn't just happen early at the boot >> sequence. >> >> It is perfectly valid for a cape to be instantiated via loading >> a module, or by making an override by writing a sysfs file. >> >> When having the __init there, the function has been long removed >> and you get a crash by calling into the weeds. >> >> So the sequence is: >> >> <early boot> Register the adapter driver. > > OK this is always there for the hardware, and done during > the __init and this one should have an omap_device.. > >> <user> insmod bone-geiger-cape >> <cape-is-matched> call omap_build_device >> >> Please look into the capebus patches for the details. > > ..but it seems that the devices connected to capebus should > not have anything to do with omap_device and hwmod? Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? Regards, Benoit -- 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