Messages in this thread | | | Date | Wed, 9 Jul 2008 15:34:29 +0200 | From | "pHilipp Zabel" <> | Subject | Re: [patch 4/4] MFD: Change mfd platform device usage to wrapper platform_device |
| |
On Wed, Jul 9, 2008 at 3:28 PM, ian <spyro@f2s.com> wrote: > On Wed, 2008-07-09 at 13:07 +0100, Ben Dooks wrote: >> > They should be here for exactly the same reason. They are used by >> the drivers >> > that will be submitted later. E.g. OHCI driver needs such >> > suspend/resume handling. >> >> No, you don't understand. I'll make a rather explicit point about the >> very clever way the device tree works since the devices are registered >> with their parent device set. > > Actually I misthought here too. > > The problem comes when the subdevices arent *quite* truely independant > of their core, and thus need to ask the core to turn off power / > clokcs / etc. for them
I agree "power" and "etc." are issues. Clocks should be handled by the clock API just fine.
> they cant just do it themselves because the subdevices may be used on > more than one core that does this hanling in different ways (eg. T7L and > TC6393XB handle the 32KHz clock completely differently.
That shouln't matter with generic clocks. If they clk_get(&mfd_cell->pdev.dev, "my_clk_input"), that should be dispatched to the correct MFD clock regardless of the actual chip.
> on tc6393xb, > theres a clock gate on the MFD core chip and on t7l66xb the clock has to > be handled right back at the platform layer, in board specific code > because the core has no gate, and the clock is fed to it from an > external pin.
Still, that could be done inside the MFD driver's custom clock enable/disable methods.
> Thats one example - there are others, not all clocks. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
| |