From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 1/2] drivers: misc: omap: add a new driver for ocp2scp
Date: Mon, 25 Jun 2012 16:26:08 +0000 [thread overview]
Message-ID: <201206251626.09666.arnd@arndb.de> (raw)
In-Reply-To: <20120625122449.GA30463@arwen.pp.htv.fi>
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
specific.
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, ...)
ones.
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.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: balbi@ti.com
Cc: "ABRAHAM, KISHON VIJAY" <kishon@ti.com>,
Greg KH <gregkh@linuxfoundation.org>,
grant.likely@secretlab.ca, rob.herring@calxeda.com,
rob@landley.net, linux@arm.linux.org.uk, b-cousson@ti.com,
rnayak@ti.com, tony@atomide.com,
devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 1/2] drivers: misc: omap: add a new driver for ocp2scp
Date: Mon, 25 Jun 2012 16:26:08 +0000 [thread overview]
Message-ID: <201206251626.09666.arnd@arndb.de> (raw)
In-Reply-To: <20120625122449.GA30463@arwen.pp.htv.fi>
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
specific.
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, ...)
ones.
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.
Arnd
next prev parent reply other threads:[~2012-06-25 16:26 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-22 13:15 [RFC PATCH v2 0/2] omap: add ocp2scp as a misc driver Kishon Vijay Abraham I
2012-06-22 13:15 ` Kishon Vijay Abraham I
2012-06-22 13:15 ` Kishon Vijay Abraham I
2012-06-22 13:15 ` [RFC PATCH v2 1/2] drivers: misc: omap: add a new driver for ocp2scp Kishon Vijay Abraham I
2012-06-22 13:15 ` Kishon Vijay Abraham I
2012-06-22 13:15 ` Kishon Vijay Abraham I
2012-06-23 4:44 ` Greg KH
2012-06-23 4:44 ` Greg KH
2012-06-25 5:39 ` ABRAHAM, KISHON VIJAY
2012-06-25 5:39 ` ABRAHAM, KISHON VIJAY
2012-06-25 12:24 ` Felipe Balbi
2012-06-25 12:24 ` Felipe Balbi
2012-06-25 16:26 ` Arnd Bergmann [this message]
2012-06-25 16:26 ` Arnd Bergmann
2012-07-16 8:12 ` Felipe Balbi
2012-07-16 8:12 ` Felipe Balbi
2012-07-16 8:12 ` Felipe Balbi
2012-07-16 8:28 ` ABRAHAM, KISHON VIJAY
2012-07-16 8:28 ` ABRAHAM, KISHON VIJAY
2012-07-16 8:28 ` ABRAHAM, KISHON VIJAY
2012-07-16 19:47 ` Arnd Bergmann
2012-07-16 19:47 ` Arnd Bergmann
2012-07-18 7:35 ` Tony Lindgren
2012-07-18 7:35 ` Tony Lindgren
2012-06-22 13:15 ` [RFC PATCH v2 2/2] arm/dts: omap4: Add ocp2scp data Kishon Vijay Abraham I
2012-06-22 13:15 ` Kishon Vijay Abraham I
2012-06-22 13:15 ` Kishon Vijay Abraham I
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201206251626.09666.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.