From: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx•com>
To: "David Gibson" <david@gibson•dropbear.id.au>,
"Grant Likely" <grant.likely@secretlab•ca>
Cc: linuxppc-dev@ozlabs•org
Subject: RE: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcrinfrastructure.
Date: Tue, 6 May 2008 10:43:50 -0700 [thread overview]
Message-ID: <20080506174352.52C857D805C@mail62-va3.bigfish.com> (raw)
In-Reply-To: <20080506061444.GB17798@yookeroo.seuss>
> -----Original Message-----
> From: David Gibson [mailto:david@gibson•dropbear.id.au]
> Sent: Monday, May 05, 2008 11:15 PM
> To: Grant Likely
> Cc: Stephen Neuendorffer; linuxppc-dev@ozlabs•org
> Subject: Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use
dcrinfrastructure.
>=20
> On Mon, May 05, 2008 at 10:55:53PM -0600, Grant Likely wrote:
> > On Mon, May 5, 2008 at 11:56 AM, Stephen Neuendorffer
> > <stephen.neuendorffer@xilinx•com> wrote:
> > > This device contains a dcr interface. Previously, the dcr
interface
> > > was assumed to be used in mmio mode, and the register space of
the dcr
> > > interface was precomputed and stuffed in the device tree. This
patch
> > > makes use of the new dcr infrastructure to represent the dcr
interface
> > > as any other dcr interface in the device tree. This enables the
dcr
> > > interface to be connected directly to a native dcr interface in a
> > > clean way.
> > >
> > > In particular, the device tree expected looks like:
> > >
> > > dcr_v29_0: dcr@0 {
> > > #address-cells =3D <1>;
> > > #size-cells =3D <1>;
> > > compatible =3D
"xlnx,dcr-v29-1.00.a";
> > > VGA_FrameBuffer: tft@80 {
> > > compatible =3D
"xlnx,plb-tft-cntlr-ref-1.00.a";
> > > dcr-parent =3D
<&opb2dcr_bridge_0>;
> > > dcr-reg =3D < 80 2 >;
> > > xlnx,default-tft-base-addr
=3D <7f>;
> > > xlnx,dps-init =3D <1>;
> > > xlnx,on-init =3D <1>;
> > >
xlnx,pixclk-is-busclk-divby4 =3D <1>;
> > > } ;
> > > } ;
> > >
> > > opb2dcr_bridge_0: opb2dcr-bridge@40700000
{
> > > compatible =3D
"xlnx,opb2dcr-bridge-1.00.b";
> > > dcr-access-method =3D "mmio";
> > > dcr-controller ;
> > > dcr-mmio-range =3D < 40700000 1000
>;
> > > dcr-mmio-stride =3D <4>;
> > > reg =3D < 40700000 1000 >;
> > > xlnx,family =3D "virtex2p";
> > > } ;
> >
> > Hmmm, something doesn't quite feel right about this. The node
> > describing the tft device is a child of the dcr@0 node which is the
> > dcr bus. However, dcr bindings use dcr-bus and dcr-reg instead of
> > parent-child relationship to specify how to access the dcr
registers.
> > So, in this example; if the device is described by tft@80, and the
dcr
> > bus is described by opb2dcr-bridge@40700000, then what does dcr@0
> > describe? (I do understand what they really describe in EDK terms;
> > but I'm looking at it through device tree glasses).
> >
> > I don't think the presence of a dcr@0 node is a problem, but in this
> > case #size/address-cells doesn't have any meaning (the child doesn't
> > have a reg property) and it looks like it should be a child of the
> > opb2dcr-bridge node (otherwise, what is it attached to?).
>=20
> Yes, indeed. If dcr@0 is representing the DCR bus / interface it
> should really have the dcr-access-method property and have all the
> dcr-parent handles point at it.
Hmm, I tend to agree. Certainly the address-cells and size-cells can
go. Part of the nastiness is that I'm trying to maintain a modicum of
backward compatibility at the moment in the device tree generator. This
structure allow the dcr@0 node to have ranges; and the tft node to have
a properly translated reg =3D <> property for the existing driver which
only understands mmio. I don't think it really works for the opb2dcr
bridge to be a bridge and a dcr-controller at the same time. :) This
structure is also very similar to what is generated if the
dcr-controller is native from the processor (there's just no bridge).
> 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).
>=20
> 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. But then its
> inconsistent with the devices that need the other DCR representation.
Yup, it's exactly this problem I'm trying to fix in the case of the tft
driver.
> 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
> =3D <&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.
Don't know if I like this, since it obscures the types of the
interfaces.
Steve
next prev parent reply other threads:[~2008-05-06 17:43 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
2008-05-06 17:43 ` Stephen Neuendorffer [this message]
2008-05-08 1:59 ` [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcrinfrastructure 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=20080506174352.52C857D805C@mail62-va3.bigfish.com \
--to=stephen.neuendorffer@xilinx$(echo .)com \
--cc=david@gibson$(echo .)dropbear.id.au \
--cc=grant.likely@secretlab$(echo .)ca \
--cc=linuxppc-dev@ozlabs$(echo .)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