On 8/31/2010 4:41 PM, ABRAHAM, KISHON VIJAY wrote:
On Tuesday 31 August 2010 01:43 PM, Felipe Balbi wrote:
On Tue, 31 Aug 2010 10:53:36 +0530, kishon<a0393678@xxxxxx> wrote:
Though driver shouldn't be using hwmod directly, there is no
corresponding API in omap_device to do the same. So we are planning to
store the omap_hwmod structure in platform_data during
arch_initcall (in the callback to omap_hwmod_for_each_by_class). So
whenever the
AUTOIDLE bits need to be reset or set, we pass the stored
omap_hwmod structure to this API. Currently, the functions that needs
AUTOIDLE
bit to be modified (omap_st_on, omap_st_off) resides in plat-omap.
couldn't your API instead be something like:
int omap_hwmod_set_autoidle(struct device *dev, u8 autoidle)
{
struct omap_hwmod *oh = dev_to_hwmod(dev);
if (!oh)
return -ENODEV;
[...]
return 0;
}
Balbi,
I couldn't find "dev_to_hwmod()" function. Do you actually mean
implementing dev_to_hwmod() function?
I created this API based on "omap_hwmod_set_slave_idlemode()"
present in lo (omap_hwmod.c) for changing the smart idle bit
of SYSCONFIG register.
-Kishon
That API does not exist. And since a device can contains several hwmods,
like in your case, this API cannot exist in that form.
The real issue is that we do not want to expose any API relative to PRCM
management to the driver. Even if you hide that behind some pdata, it is
still the driver that will call it.
I know that some IPs like MUSB or McBSP requires some unusual idle mode
change due to HW bugs, but in general, you should try to find a better
way to handle that in the core framework if possible.
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
