Re: [patch 4/4] MFD: Change mfd platform device usage to wrapper platform_device
From: pHilipp Zabel
Date: Wed Jul 09 2008 - 09:34:50 EST
On Wed, Jul 9, 2008 at 3:28 PM, ian <spyro@xxxxxxx> 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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/