Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency

[Tony Lindgren <tony@atomide.com>]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [130219 10:26]:
> On Tue, Feb 19, 2013 at 08:30:53AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [130219 07:49]:
> > > If you want such things as pci_enable_device(), then what you're actually
> > > asking for is omap_enable_device() for OMAP devices.  OMAP devices are
> > > already specific enough to OMAP SoCs (god knows, they have really complex
> > > and obscure behaviours that no one else in their right mind would want
> > > to copy) that calling out to omap specific functions would never really
> > > be a problem.
> > 
> > I'd rather avoid adding omap_enable_device() calls to drivers as we really
> > want to keep the drivers generic. But maybe there could be some generic
> > bus_enable_device() function pointer that could be populated by the bus
> > code during init.
> 
> What you're not getting is that pci_enable_device() is a PCI thing which
> is mostly a no-op - and where it isn't a no-op, it's something that must
> be done _before_ PCI resources are used or even reserved (because
> conceptually, this is to do with getting the resources correct.)
> 
> The PCI case is:
> 
> pci_device_probe(pci_dev)
> {
> 	pci_enable_device(pci_dev);
> 
> 	pci_request_regions(pci_dev);
> 
> 	regs = pci_iomap(pci_dev, BAR, size);
> ...
> }
> 
> That's different from what you're wanting on OMAP - what you're wanting
> there is some way to record the platform device has been ioremapped, so
> that you can then fiddle with its idle/reset register from "bus" code.
> 
> If you think about it in light of the above sequence, the "enable device"
> stage *doesn't* suit your needs because that happens before the driver
> has done anything.

Right.. that won't help then. It sounds like the proper place would
be something like pm_runtime_init() as these register manage things
like autoidle etc.
 
> However... if you think you're going to get away with another total
> rewrite of OMAP device support away from hwmod to a new scheme with a
> new load of huge churn, think again.  Remember, churn is evil.  I've
> complained to you about the amount of churn that OMAP manufactures
> in the past.  Linus has complained about it too.  You can't continue
> like this.

I don't think there's any churn needed here if done properly. It's
mostly a question of dropping duplicate data from hwmod that we
already have available in device tree. That means we can shrink the
hwmod data needed.

Regards,

Tony