On 03/01/2013 03:42 PM, Ezequiel Garcia wrote:
> On Fri, Mar 1, 2013 at 6:08 PM, Ezequiel Garcia <elezegarcia@xxxxxxxxx> wrote:
>> Hi Jon,
>>
>> Yet more questions :-) See below...
>>
>> On Wed, Feb 13, 2013 at 7:07 PM, Jon Hunter <jon-hunter@xxxxxx> wrote:
>>>
>>>
>>> You don't need this extra entry if you add "simple-bus" to
>>> the gpmc node compatible string.
>>>
>>> + gpmc: gpmc@6800a000 {
>>> + compatible = "ti,omap2420-gpmc", "simple-bus";
>>> + ti,hwmods = "gpmc";
>>> + reg = <0x6800a000 0x1000>;
>>> + interrupts = <20>;
>>> +
>>
>> This "simple-bus" trick is great and very clean!
>>
>> I'm working on a new driver, similar to gpmc, called device-bus for Marvell SoC.
>> One remarkable difference is that I need to *setup* the address space
>> (sort of allocate the address region) for a child device, before I can
>> access it.
>>
>> Using simple-bus is a very clean solution. However I'm facing a strange issue:
>> the child (physmap driver) probe() is being called *before* the parent
>> (device-bus driver)
>> probe(), and so the flash device address space cannot get accessed because
>> it hasn't been setup yet.
>>
>
> Ok, now I think I understand that my problem has nothing to do with simple-bus,
> but instead related to the driver probing order.
>
> The physmap driver is just being probed before the device bus driver, and so it
> won't work.
>
> Now: is there any clean solution?
I can't say I understand why if it is a child device. I have just posted
a series this week to enable NOR support for OMAP with DT [1].
Cheers
Jon
[1] http://permalink.gmane.org/gmane.linux.ports.arm.omap/94378
--
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
