On Tue, Feb 19, 2013 at 08:30:53AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [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.
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.
--
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
