Re: [RFC/PATCH 2/7] OMAP3: beagle: don't touch omap_device internals

["Menon, Nishanth" <nm@ti.com>]

On Thu, Jul 28, 2011 at 07:57, Cousson, Benoit <b-cousson@ti.com> wrote:
[...]
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
>> b/arch/arm/mach-omap2/omap_hwmod.c
>> index 293fa6c..77d01a2 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>> @@ -142,6 +142,7 @@
>>  #include "powerdomain.h"
>>  #include<plat/clock.h>
>>  #include<plat/omap_hwmod.h>
>> +#include<plat/omap_device.h>
>
> I'd rather put that code inside the omap_device.c instead of here.
> The omap_device layer is on top of the omap_hwmod.
> In order to minimize the dependencies from the low HW description layer to
> the omap_device layer, you should maybe define a omap_device_from_hwmod()
> function or something similar.
Thanks for the review. will check on this.

>
> That being said, do we really need to get the device from the hwmod name?
> Cannot we use the device name instead?
> I do not know all the usecases, that why I'm asking.
mpu.0 , are the device names - which probably lets me walk the kernel
data structrues instead of omap database to get to the right device,
Vs using the common names like "mpu" " make things a little easier to
deal with from driver perspective.

as an example, some of the dev_driver_string(dev):dev_name(dev) (in
bracket hwmod name) I collected from OMAP4 are:
platform:mpu.0 ("mpu")
platform:l3_main_1.0 ('l3_main_1")
pvrsrvkm:pvrsrvkm.0 ("gpu")
rpres:fdif.0 ("fdif")
omap_hsi:omap_hsi.0 ("hsi")
platform:iss.0 ("iss")
etc..

I mean I have'nt been keeping track of the device tree discussions so
dont know if this function could be better done - but I think I agree
with the overall idea that instead of spawning off get_xyz_device() we
need to have some uniform approach to get to the device scaling
silicon - I hoped we could consider the hwmod database/what ever
replacing it to do that.

Regards,
Nishanth Menon