On 13/09/13 13:17, Archit Taneja wrote:
> On Friday 13 September 2013 03:32 PM, Tomi Valkeinen wrote:
>> On 13/09/13 12:51, Archit Taneja wrote:
>>
>>> The calls in omap_generic_init() check the machine type via
>>> of_machine_is_compatible(), even if it's a multiplatform image, the dtb
>>> should be only of one platform. So it wouldn't be called at all.
>>
>> Hmm. BeagleBone is "ti,am33xx". The "Generic AM33XX (Flattened Device
>> Tree)" machine definition uses omap_generic_init(). So if I'm not
>> missing something here, omap_generic_init() is called for BeagleBone.
>
> I was talking about the calls within omap_generic_init() :
>
> omap_generic_init(void)
> {
> ...
> if (of_machine_is_compatible("ti,omap4-panda")) {
> omap4_panda_display_init_of();
> legacy_init_ehci_clk("auxclk3_ck");
>
> }
> }
>
> omap4_panda_display_init_of() would be called only if a panda board dtb
> was used. Are you talking about these display calls, or something else?
Ah, right. I was looking at the DSS DT branch. There we have
omapdss_init_of() call from omap_generic_init(). So that is a problem,
but not in the mainline.
You're right, the current mainline doesn't call the DSS init function on
am33xx. But it does create omapfb and omapdrm devices, as you noted.
Well, those devices don't do any actual harm, but I agree that they
shouldn't be there. It's probably best to move the device creation into
display.c, as you did. Just include omapfb also, and maybe remove the
DMM creation as a first patch.
Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
