Re: [RFC PATCH v2 1/2] drivers: misc: omap: add a new driver for ocp2scp
From: ABRAHAM, KISHON VIJAY
Date: Mon Jul 16 2012 - 04:28:13 EST
On Mon, Jul 16, 2012 at 1:42 PM, Felipe Balbi <balbi@xxxxxx> wrote:
> On Mon, Jun 25, 2012 at 04:26:08PM +0000, Arnd Bergmann wrote:
>> On Monday 25 June 2012, Felipe Balbi wrote:
>> > > > Can't this live where the scp drivers live? Actually, where is that at?
>> > > > Do we have scp drivers?
>> > > AFAIK, there isn't any driver for scp. But we have a driver for ocp
>> > > and it is present at arch/arm/mach-omap2/omap_l3_noc.c
>> > I don't think this deserves a directory of its own. Maybe
>> > drivers/platform/arm/omap/ ?? the l3_noc is an OMAP-specific
>> > interconnect and the SCP bus is also an OMAP-specific bus. I don't know
>> > of any other arch/soc who uses the same interconnect IP as OMAP and the
>> > same ocp2scp bridge. That bridge was created by TI for all I know.
>> > Greg, would drivers/platform/arm/omap/ work for you ? We could also move
>> > the interconnect drivers there.
>> I really don't like the idea of introducing drivers/platform/arm/ because
>> very little of the stuff that one would put in there are actually ARM
>> I have suggested a drivers/bus/ before and people did not see the need
>> back then, and we agreed to continue having a directory for each bus,
>> as we have for the big ones (pci, usb, i2c, spi, ...) and a lot of
>> simple (amba, rapidio, bcma, ...) or obscure (tc, vlynq, nubus, ...)
>> I think we should reconsider the idea of drivers/bus/ with a file per
>> bus in there at least for new buses, but doing a new drivers/scp/
>> would be ok for me if there is enough opposition against the idea
>> of drivers/bus aggregating different buses.
> I don't mind either way. The fact is that this ocp-to-scp bridge is
> really a TI/OMAP thing. Not sure it deserves a directory of its own.
Ok. Then I'll have a file in drivers/bus/ for ocp2scp driver.
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/