[Ksummit-2013-discuss] [ARM ATTEND] Describing complex, non-probable system topologies

[Greg KH]

On Mon, Aug 05, 2013 at 01:21:38AM -0700, Tony Lindgren wrote:
> * Greg KH <greg at kroah.com> [130805 01:08]:
> > On Mon, Aug 05, 2013 at 12:37:30AM -0700, Tony Lindgren wrote:
> > > * Greg KH <greg at kroah.com> [130805 00:16]:
> > > > On Sun, Aug 04, 2013 at 11:55:35PM -0700, Tony Lindgren wrote:
> > > > > 
> > > > > But for things that are completely bus specific for various SoCs, how
> > > > > would you like to handle those?
> > > > > 
> > > > > For example, we are currently using platform bus and bus notifiers and
> > > > > then the runtime PM calls from device driver trigger the bus specific
> > > > > things.
> > > > > 
> > > > > Would you prefer to instead use a custom bus instead of extending
> > > > > the platform bus for things like that?
> > > > 
> > > > Yes I would.  I would really like to only use the platform bus for very
> > > > few things, if any at all.
> > > 
> > > OK. How would you prefer to set up things from driver point of view
> > > so the device drivers don't need to care which bus it's connected to?
> > 
> > What do you mean by "don't need to care"?  How are these drivers talking
> > to the device on the bus in the first place?  If these are different
> > busses, then they are talked to in different ways, right?
> 
> Let's assume that just ioremap + read/write is needed.

That implies that there is no "bus" at all involved here, so what's the
problem?  :)

> > Any specific examples you have to point to in the kernel today?
> 
> The one I'm struggling with is the _omap_device_notifier_call
> that's not currently doing much, but we've been trying to find
> a clean way to implement runtime PM calls for the bus.
> 
> There are other examples doing notifiers with platform_bus, have
> not checked but I'm guessing they have similar needs:
> 
> $ git grep bus_register_notifier | grep platform_bus_type
> arch/arm/mach-exynos/pm_domains.c:      bus_register_notifier(&platform_bus_type, &platform_nb);
> arch/arm/mach-highbank/highbank.c:      bus_register_notifier(&platform_bus_type, &highbank_platform_nb);
> arch/arm/mach-mvebu/coherency.c:                bus_register_notifier(&platform_bus_type,
> arch/arm/mach-omap2/omap_device.c:      bus_register_notifier(&platform_bus_type, &platform_nb);
> arch/microblaze/kernel/setup.c: bus_register_notifier(&platform_bus_type, &dflt_plat_bus_notifier);
> arch/powerpc/kernel/dma-swiotlb.c:      bus_register_notifier(&platform_bus_type,
> arch/powerpc/platforms/cell/beat_iommu.c:       bus_register_notifier(&platform_bus_type, &celleb_of_bus_notifier);
> arch/powerpc/platforms/cell/iommu.c:    bus_register_notifier(&platform_bus_type, &cell_of_bus_notifier);
> drivers/acpi/acpi_lpss.c:               bus_register_notifier(&platform_bus_type, &acpi_lpss_nb);
> drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c:               err = bus_register_notifier(&platform_bus_type, &wait.notifier);
> drivers/net/ethernet/ibm/emac/core.c:   bus_register_notifier(&platform_bus_type, &emac_of_bus_notifier);
>  
> > > That is, for the let's say 10 - 15 slightly different types of busses
> > > that are currently handled as platform bus?
> > 
> > What makes them "different"?
> 
> How the power and clock domains are done and how the clocks are gated
> or idled. So basically how the devices are reset and idled at the bus
> level.

I think of a "bus" as the way that a device talks to the hardware (i.e.
PCI, USB, i2c, spi, etc.)  You are saying a "bus" is something
different, something that is used to control the "raw" devices that just
do iowrites.

Why not just create a bus for your devices, have them register platform
devices (so you can take advantage of the existing drivers) and have
your own "platform bus" of a specific type?  The code to do that would
only need to be created once "per bus", and that way you can handle all
of the needed reset/idle stuff properly for things "attached" to it.

Perhaps we need to get in front of a whiteboard at the ARM mini summit
and hash this all out...

thanks,

greg k-h