From: David Gibson <david@gibson•dropbear.id.au>
To: Segher Boessenkool <segher@kernel•crashing.org>
Cc: linuxppc-dev@ozlabs•org
Subject: Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcr infrastructure.
Date: Thu, 8 May 2008 11:57:04 +1000 [thread overview]
Message-ID: <20080508015704.GF5156@yookeroo.seuss> (raw)
In-Reply-To: <4777b221c199009151e8f5b7b5f16de3@kernel.crashing.org>
On Tue, May 06, 2008 at 12:56:44PM +0200, Segher Boessenkool wrote:
>> Current standard practice is not to represent the DCR bus as node with
>> subnodes for the DCR-controlled devices. That's because the DCR bus
>> tends to run in addition to other on-chip busses, and some things have
>> to go on another on-chip bus to make sense, but still have DCR control
>> registers (for example the internal bus bridges on 4xx).
>
> Yeah.
>
>> Arguably for DCR-only devices we should instead have a node
>> representing the DCR bus and just put the devices under it with the
>> DCR number encoded in reg in the normal way.
>
> Right.
>
>> But then its
>> inconsistent with the devices that need the other DCR representation.
>
> OTOH, it _is_ consistent with all other (non-DCR) devices that way.
>
> What you could do right now is to give such DCR-only devices both
> normal "reg" etc., and the "dcr-reg" etc. properties, containing
> both the same info. If you do that, your device tree will be
> correct (because you got all the standard stuff right), and the
> kernel will like it as well (because it looks for the "dcr-reg"
> stuff).
> Then maybe later, if/when the kernel supports the standard addressing
> for DCR as well, you could drop the "dcr-reg" things from your DTS.
> Or you could just keep it.
>
> David, will this work, do you think?
Um.. yeah, I guess that should work. Don't forget to slap on
"simple-bus" as appropriate.
>> Segher and I did toss around some ideas for generalizing the DCR
>> representation to a way of representing that any node has some
>> presence on a bus other than its "primary" parent (e.g. other-bus-reg
>> = <&dcr-bus 0x0d0 0x010 &strange-i2c-control-bus 0xabc>). Then
>> DCR-only devices would use normal "reg", devices that sit on another
>> bus would sit on that bus and use this representation to show their
>> DCR control registers. Maybe one day.
>
> One day perhaps, yes :-)
>
> It sounds cleaner to split such a prop into separate props per bus.
> Maybe I said the opposite before, heh :-)
No I think you said that before, too, but I'm not sure I agree.
Seperate props per bus (well, per bus type, really) is probably more
human-readable, but a single prop has the advantage that we can have a
common parser that will interpret future variations on this theme
correctly without having to add things to some list of properties to
look for.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
next prev parent reply other threads:[~2008-05-08 1:57 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1206401313-1625-1-git-send-email-stephen.neuendorffer@xilinx.com>
2008-03-28 16:23 ` [PATCH 1/5] [v2][POWERPC] refactor dcr code Stephen Neuendorffer
2008-03-30 22:02 ` Benjamin Herrenschmidt
2008-04-01 20:16 ` Stephen Neuendorffer
2008-04-04 22:02 ` Stephen Neuendorffer
2008-04-04 22:10 ` Benjamin Herrenschmidt
2008-04-18 21:49 ` Stephen Neuendorffer
2008-04-18 21:55 ` [PATCH 1/2] [v3][POWERPC] " Stephen Neuendorffer
2008-04-19 2:30 ` Grant Likely
2008-04-19 3:04 ` Benjamin Herrenschmidt
2008-04-19 14:35 ` Josh Boyer
2008-04-21 3:56 ` Stephen Neuendorffer
2008-04-21 13:03 ` Josh Boyer
2008-05-05 17:56 ` [PATCH 0/4] [v4][POWERPC] " Stephen Neuendorffer
[not found] ` <1210010201-28436-1-git-send-email-stephen.neuendorffer@xilinx.com>
2008-05-05 17:56 ` [PATCH 1/4] " Stephen Neuendorffer
2008-05-06 0:12 ` Benjamin Herrenschmidt
2008-05-06 3:40 ` Stephen Rothwell
2008-05-06 4:02 ` Benjamin Herrenschmidt
2008-05-06 17:34 ` Stephen Neuendorffer
2008-05-06 17:40 ` Josh Boyer
2008-05-06 18:29 ` [PATCH 1/4] [v5][POWERPC] " Stephen Neuendorffer
[not found] ` <1210010201-28436-2-git-send-email-stephen.neuendorffer@xilinx.com>
2008-05-05 17:56 ` [PATCH 2/4] [POWERPC] Xilinx: Virtex: Enable dcr for MMIO and NATIVE Stephen Neuendorffer
2008-05-06 0:11 ` Benjamin Herrenschmidt
2008-05-06 17:33 ` [PATCH 2/4] [POWERPC] Xilinx: Virtex: Enable dcr for MMIO andNATIVE Stephen Neuendorffer
[not found] ` <1210010201-28436-3-git-send-email-stephen.neuendorffer@xilinx.com>
2008-05-05 17:56 ` [PATCH 3/4] [POWERPC] Xilinx: Framebuffer: remove platform device support Stephen Neuendorffer
[not found] ` <1210010201-28436-4-git-send-email-stephen.neuendorffer@xilinx.com>
2008-05-05 17:56 ` [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcr infrastructure Stephen Neuendorffer
2008-05-06 4:55 ` Grant Likely
2008-05-06 6:14 ` David Gibson
2008-05-06 10:56 ` Segher Boessenkool
2008-05-08 1:57 ` David Gibson [this message]
2008-05-06 17:43 ` [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcrinfrastructure Stephen Neuendorffer
2008-05-08 1:59 ` David Gibson
2008-05-08 4:46 ` [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Usedcrinfrastructure Stephen Neuendorffer
2008-05-08 7:01 ` David Gibson
[not found] ` <1208555704-8978-1-git-send-email-stephen.neuendorffer@xilinx.com>
2008-04-18 21:55 ` [PATCH 2/2] [POWERPC] Xilinx: Virtex: Enable dcr for MMIO and NATIVE Stephen Neuendorffer
2008-04-19 2:31 ` Grant Likely
[not found] ` <1206721429-18276-1-git-send-email-stephen.neuendorffer@xilinx.com>
2008-03-28 16:23 ` [PATCH 2/5] " Stephen Neuendorffer
[not found] ` <1206721429-18276-2-git-send-email-stephen.neuendorffer@xilinx.com>
2008-03-28 16:23 ` [PATCH 3/5] [POWERPC] explicit dcr support Stephen Neuendorffer
2008-03-30 22:04 ` Benjamin Herrenschmidt
[not found] ` <1206721429-18276-3-git-send-email-stephen.neuendorffer@xilinx.com>
2008-03-28 16:23 ` [PATCH 4/5] [POWERPC] Xilinx: Framebuffer: Use dcr infrastructure Stephen Neuendorffer
[not found] ` <1206721429-18276-4-git-send-email-stephen.neuendorffer@xilinx.com>
2008-03-28 16:23 ` [PATCH 5/5] [RFC][PPC] Use DCR for arch ppc, and enable MMIO and NATIVE for virtex Stephen Neuendorffer
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=20080508015704.GF5156@yookeroo.seuss \
--to=david@gibson$(echo .)dropbear.id.au \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=segher@kernel$(echo .)crashing.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