linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] drivers/amba: probe via device tree
Date: Fri, 20 May 2011 10:17:40 -0500	[thread overview]
Message-ID: <4DD68614.6090209@gmail.com> (raw)
In-Reply-To: <201105201621.03801.arnd@arndb.de>

Arnd,

On 05/20/2011 09:21 AM, Arnd Bergmann wrote:
> On Friday 20 May 2011 15:24:26 Rob Herring wrote:
>> Maybe we are looking this in the wrong way.
>>
>> AMBA is not really the bus, but certain types of devices on the bus.
>> Granted, it may actually be an AMBA bus vs. vendor bus (i.MX AIPS), but
>> that is really transparent to s/w. Separating AMBA devices in the
>> devicetree is really Linux requirements defining the devicetree
>> structure. It is certainly conceivable that an OS could make no
>> distinction. In my case, there is a mixture of regular platform devices
>> and AMBA(Primecell really) devices all interleaved on the same bus.
>
> I don't see how that would work. If the bus is AMBA, it should
> only have AMBA devices on it, otherwise how would they be connected?
>
The ARM definition of AMBA encompasses a lot of things. It is the 
definition of the AXI, AHB and APB buses. It also has the definition of 
the peripheral ID register definitions which primarily only ARM Ltd 
peripherals implement. You can have those bus types yet not have any 
peripherals with the ID registers. The Linux amba bus primarily deals 
with just the peripheral ID for probe matching. There is also bus clock 
handling, but that's not really unique to an AMBA bus. Arguably the 
platform bus could have bus clock handling as well.

> Whether software is supposed to know care about this is a different
> question. The device tree should generally reflect the block
> diagram of the hardware,

Agreed.

> and I would expect the AMBA devices be
> on a different level from the rest there.
>
But this part is not true.

>> Based on this, I think of_platform_populate should always just match
>> against "simple-bus" and make the matches parameter define the device
>> creation hook rather than the bus type. Or you could have both
>> bus_matches and dev_matches parameters.
>
> I think it would be much better to only look at the parent bus for
> device to add, never at the device itself.
>
> If the bus is AMBA, add all devices as amba_device, if it's simple-bus,
> add all devices as platform_device.
>
That is how it is currently, but the reality is that I only have 1 bus 
with both ARM Primecell peripherals and other peripherals which are 
standard platform bus devices. i2c-designware is one example. It is on 
the APB just like the pl011 uart. So do you propose I create a amba 
driver for it? It has no peripheral ID registers, so that may not even work.

Rob

  reply	other threads:[~2011-05-20 15:17 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-19 18:28 [PATCH v2 0/2] amba bus device tree probing Rob Herring
2011-05-19 18:28 ` [PATCH 1/2] dt: check for devices already created fron DT scan Rob Herring
2011-05-19 19:54   ` Grant Likely
2011-05-19 18:28 ` [PATCH 2/2] drivers/amba: probe via device tree Rob Herring
2011-05-19 20:01   ` Grant Likely
2011-05-19 23:30     ` Rob Herring
2011-05-19 23:39       ` Grant Likely
2011-05-20 13:24         ` Rob Herring
2011-05-20 14:21           ` Arnd Bergmann
2011-05-20 15:17             ` Rob Herring [this message]
2011-05-20 16:08               ` Stephen Neuendorffer
2011-05-21 17:42                 ` Grant Likely
2011-05-21 23:47                   ` Russell King - ARM Linux
2011-05-22 10:00                     ` Rafael J. Wysocki
2011-05-22 15:46                     ` Rob Herring
2011-05-23 15:23                     ` Grant Likely
2011-05-22 10:03                   ` Arnd Bergmann
2011-05-25  9:03                     ` Linus Walleij
2011-05-23  9:37                   ` Kristoffer Glembo
2011-05-23  9:58                     ` Russell King - ARM Linux
2011-05-23 15:09                       ` Grant Likely
2011-05-24 15:03                         ` Rob Herring
2011-05-25  3:02                           ` Shawn Guo
2011-05-25  9:07                           ` Linus Walleij
2011-05-21 23:35                 ` Russell King - ARM Linux
2011-05-23 15:00                   ` Stephen Neuendorffer
2011-05-23 15:47                     ` Russell King - ARM Linux
2011-05-21  4:00               ` Segher Boessenkool
2011-05-21 14:55                 ` Rob Herring
2011-05-21 15:18                   ` Segher Boessenkool
2011-05-21 17:43                     ` Grant Likely

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=4DD68614.6090209@gmail.com \
    --to=robherring2@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).