From: arnd@arndb•de (Arnd Bergmann)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v3 0/7] mv643xx.c: Add basic device tree support.
Date: Thu, 9 Aug 2012 11:43:32 +0000 [thread overview]
Message-ID: <201208091143.32972.arnd@arndb.de> (raw)
In-Reply-To: <50239815.6020108@codethink.co.uk>
On 08/08/12 14:19, Ian Molton wrote:
> On 08/08/12 13:39, Arnd Bergmann wrote:
>> On Wednesday 08 August 2012, Ian Molton wrote:
>>> This method would require a small amount of rework in the driver to
>>> set up <n> ports, rather than just one.
>> This looks quite nice, but it is still very much incompatible with the
>> existing binding. Obviously we can abandon an existing binding and
>> introduce a second one for the same hardware, but that should not
>> be taken lightly.
> Fair, however the existing users aren't anywhere near as
> numerous as the new ones.
Depends on how you count the numbers. I see at least three machines
supported in the kernel with the old binding and none with the new one
so far ;-)
>> I don't fully understand your concern with the overlapping
>> registers, mostly because I still don't know all the combinations
>> that are actually valid here. Let me try to say what I understood
>> so far, and you can correct me if that's wrong:
>>
>> * A system can have multiple instances of an mv64360 ethernet
>> block, with a register area of 0x2000 bytes.
>> * Each such block can have three MACs and three PHYs.
>> * The first 0x400 bytes in the register space control the three
>> PHYs and the remaining registers control the MACs.
>> * While this is meant to be used in a way that you assign
>> the each of the three PHYs to one of the MACs, this is not
>> always done, and sometimes you use a different PHY (?), or
>> one from a different instance of the mv64360 ethernet block
>> on the same SoC?.
> Nearly - the whole block is 0x2000 in size, yes. And each one
> can have 3 MACs and PHYs, as you say.
>
> There is SMI @ 0x2000 - just one for all ports, and in many
> (all?) cases, for all all the other controllers on the SoC to
> share. On the armadaXP SoC, for example, each ethernet
> block has its own alias of the same bas SMI reg. (there are
> 4 blocks)
>
> ethernet0@ 0x2400
> ## regs in order: Main regs, MIB counters, Special mcast table, Mcast
> table, Unicast table.
> port0 has regs at +0x0000 *0x1000 +0x1400 +0x1500 +0x1600
> port1 has regs at +0x0400 *0x1080 +0x1800 +0x1900 +0x1a00
> port2 has regs at +0x0800 *0x1100 +0x1c00 +0x1d00 +0x1e00
> ethernet1@ 0x6400
> port0 has regs at +0x0000 *0x1000 +0x1400 +0x1500 +0x1600
> ...
>
> As you can see, instead of putting port1 at +0x1700 or so,
> marvell have overlapped the register files - in fact, doubly
> so, since port1 + 0x1080 is right in the middle of
> (port0 + 0x1000) -> (port0 + 0x16ff), so one cant simply map two
> sets of regs like 0x0000->0x03ff and 0x1000->0x16ff for port one
> either.
This could theoretically be dealt with by having 5 register ranges
per device, but that would cause extra overhead and also be
incompatible with the existing binding. I think showing one
parent device with children at address 0, 1 and 2 is ok. The driver
already knows all those offsets and they are always the same
for all variants of mv643xx, right?
Arnd
next prev parent reply other threads:[~2012-08-09 11:43 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 14:34 [PATCH v3 0/7] mv643xx.c: Add basic device tree support Ian Molton
2012-08-07 14:34 ` [PATCH v3 1/7] Initial csb1724 board support (FDT) Ian Molton
2012-08-07 14:34 ` [PATCH v3 2/7] mv643xx.c: Remove magic numbers Ian Molton
2012-08-07 14:34 ` [PATCH v3 3/7] mv643xx.c: Add basic device tree support Ian Molton
2012-08-07 14:56 ` Arnd Bergmann
2012-08-07 15:56 ` Ian Molton
2012-08-07 20:25 ` Arnd Bergmann
2012-08-07 14:34 ` [PATCH v3 4/7] kirkwood: Add fixups for DT based mv643xx ethernet Ian Molton
2012-08-07 14:34 ` [PATCH v3 5/7] csb1724: Enable device tree based mv643xx ethernet support Ian Molton
2012-08-07 14:34 ` [PATCH v3 6/7] DT: Convert all kirkwood boards with mv643xx that use DT Ian Molton
2012-08-07 14:34 ` [PATCH v3 7/7] NET: mv643xx: remove device name macro Ian Molton
2012-08-07 23:29 ` [PATCH v3 0/7] mv643xx.c: Add basic device tree support David Miller
2012-08-08 0:31 ` Matt Sealey
2012-08-08 8:16 ` Arnd Bergmann
2012-08-08 8:59 ` David Miller
2012-08-08 9:40 ` Ian Molton
2012-08-08 9:42 ` Ian Molton
2012-08-08 11:51 ` Ian Molton
2012-08-08 12:39 ` Arnd Bergmann
2012-08-08 13:19 ` Ian Molton
2012-08-09 10:59 ` Ian Molton
2012-08-09 11:43 ` Arnd Bergmann [this message]
2012-08-09 15:21 ` Ian Molton
2012-08-10 10:49 ` Arnd Bergmann
2012-08-13 10:00 ` Ian Molton
2012-08-16 16:30 ` Ian Molton
2012-09-10 14:22 ` Arnd Bergmann
2012-09-11 6:03 ` Benjamin Herrenschmidt
2012-10-21 1:52 ` Jason Cooper
2012-08-17 12:13 ` Arnd Bergmann
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=201208091143.32972.arnd@arndb.de \
--to=arnd@arndb$(echo .)de \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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