[PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcr infrastructure.

Subsystems: framebuffer layer, the rest · Maintainers: Helge Deller, Linus Torvalds

STALE6746d

9 messages, 4 authors, 2008-05-08 · open the first message on its own page

[PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcr infrastructure.

From: Stephen Neuendorffer <hidden>
Date: 2008-05-05 18:02:52

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 = <1>;
				#size-cells = <1>;
				compatible = "xlnx,dcr-v29-1.00.a";
				VGA_FrameBuffer: tft@80 {
					compatible = "xlnx,plb-tft-cntlr-ref-1.00.a";
					dcr-parent = <&opb2dcr_bridge_0>;
					dcr-reg = < 80 2 >;
					xlnx,default-tft-base-addr = <7f>;
					xlnx,dps-init = <1>;
					xlnx,on-init = <1>;
					xlnx,pixclk-is-busclk-divby4 = <1>;
				} ;
			} ;

			opb2dcr_bridge_0: opb2dcr-bridge@40700000 {
				compatible = "xlnx,opb2dcr-bridge-1.00.b";
				dcr-access-method = "mmio";
				dcr-controller ;
				dcr-mmio-range = < 40700000 1000 >;
				dcr-mmio-stride = <4>;
				reg = < 40700000 1000 >;
				xlnx,family = "virtex2p";
			} ;

Signed-off-by: Stephen Neuendorffer <redacted>
---
 drivers/video/xilinxfb.c |   54 +++++++++++++++++-----------------------------
 1 files changed, 20 insertions(+), 34 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 4d64402..848752e 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -37,6 +37,7 @@
 #endif
 #include <asm/io.h>
 #include <linux/xilinxfb.h>
+#include <asm/dcr.h>
 
 #define DRIVER_NAME		"xilinxfb"
 #define DRIVER_DESCRIPTION	"Xilinx TFT LCD frame buffer driver"
@@ -111,8 +112,9 @@ struct xilinxfb_drvdata {
 
 	struct fb_info	info;		/* FB driver info record */
 
-	u32		regs_phys;	/* phys. address of the control registers */
-	u32 __iomem	*regs;		/* virt. address of the control registers */
+	dcr_host_t      dcr_host;
+	unsigned int    dcr_start;
+	unsigned int    dcr_len;
 
 	void		*fb_virt;	/* virt. address of the frame buffer */
 	dma_addr_t	fb_phys;	/* phys. address of the frame buffer */
@@ -135,7 +137,7 @@ struct xilinxfb_drvdata {
  * when it's needed.
  */
 #define xilinx_fb_out_be32(driverdata, offset, val) \
-	out_be32(driverdata->regs + offset, val)
+	dcr_write(driverdata->dcr_host, offset, val)
 
 static int
 xilinx_fb_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned blue,
@@ -203,7 +205,8 @@ static struct fb_ops xilinxfb_ops =
  * Bus independent setup/teardown
  */
 
-static int xilinxfb_assign(struct device *dev, unsigned long physaddr,
+static int xilinxfb_assign(struct device *dev, dcr_host_t dcr_host,
+			   unsigned int dcr_start, unsigned int dcr_len,
 			   struct xilinxfb_platform_data *pdata)
 {
 	struct xilinxfb_drvdata *drvdata;
@@ -218,21 +221,9 @@ static int xilinxfb_assign(struct device *dev, unsigned long physaddr,
 	}
 	dev_set_drvdata(dev, drvdata);
 
-	/* Map the control registers in */
-	if (!request_mem_region(physaddr, 8, DRIVER_NAME)) {
-		dev_err(dev, "Couldn't lock memory region at 0x%08lX\n",
-			physaddr);
-		rc = -ENODEV;
-		goto err_region;
-	}
-	drvdata->regs_phys = physaddr;
-	drvdata->regs = ioremap(physaddr, 8);
-	if (!drvdata->regs) {
-		dev_err(dev, "Couldn't lock memory region at 0x%08lX\n",
-			physaddr);
-		rc = -ENODEV;
-		goto err_map;
-	}
+	drvdata->dcr_start = dcr_start;
+	drvdata->dcr_len = dcr_len;
+	drvdata->dcr_host = dcr_host;
 
 	/* Allocate the framebuffer memory */
 	if (pdata->fb_phys) {
@@ -247,7 +238,7 @@ static int xilinxfb_assign(struct device *dev, unsigned long physaddr,
 	if (!drvdata->fb_virt) {
 		dev_err(dev, "Could not allocate frame buffer memory\n");
 		rc = -ENOMEM;
-		goto err_fbmem;
+		goto err_region;
 	}
 
 	/* Clear (turn to black) the framebuffer */
@@ -297,7 +288,6 @@ static int xilinxfb_assign(struct device *dev, unsigned long physaddr,
 	}
 
 	/* Put a banner in the log (for DEBUG) */
-	dev_dbg(dev, "regs: phys=%lx, virt=%p\n", physaddr, drvdata->regs);
 	dev_dbg(dev, "fb: phys=%p, virt=%p, size=%x\n",
 		(void*)drvdata->fb_phys, drvdata->fb_virt, fbsize);
 
@@ -313,12 +303,6 @@ err_cmap:
 	/* Turn off the display */
 	xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
 
-err_fbmem:
-	iounmap(drvdata->regs);
-
-err_map:
-	release_mem_region(physaddr, 8);
-
 err_region:
 	kfree(drvdata);
 	dev_set_drvdata(dev, NULL);
@@ -344,9 +328,8 @@ static int xilinxfb_release(struct device *dev)
 
 	/* Turn off the display */
 	xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
-	iounmap(drvdata->regs);
 
-	release_mem_region(drvdata->regs_phys, 8);
+	dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
 
 	kfree(drvdata);
 	dev_set_drvdata(dev, NULL);
@@ -362,20 +345,23 @@ static int xilinxfb_release(struct device *dev)
 static int __devinit
 xilinxfb_of_probe(struct of_device *op, const struct of_device_id *match)
 {
-	struct resource res;
 	const u32 *prop;
 	struct xilinxfb_platform_data pdata;
 	int size, rc;
+	int start, len;
+	dcr_host_t dcr_host;
 
 	/* Copy with the default pdata (not a ptr reference!) */
 	pdata = xilinx_fb_default_pdata;
 
 	dev_dbg(&op->dev, "xilinxfb_of_probe(%p, %p)\n", op, match);
 
-	rc = of_address_to_resource(op->node, 0, &res);
-	if (rc) {
+	start = dcr_resource_start(op->node, 0);
+	len = dcr_resource_len(op->node, 0);
+	dcr_host = dcr_map(op->node, start, len);
+	if (!DCR_MAP_OK(dcr_host)) {
 		dev_err(&op->dev, "invalid address\n");
-		return rc;
+		return -ENODEV;
 	}
 
 	prop = of_get_property(op->node, "phys-size", &size);
@@ -399,7 +385,7 @@ xilinxfb_of_probe(struct of_device *op, const struct of_device_id *match)
 	if (of_find_property(op->node, "rotate-display", NULL))
 		pdata.rotate_screen = 1;
 
-	return xilinxfb_assign(&op->dev, res.start, &pdata);
+	return xilinxfb_assign(&op->dev, dcr_host, start, len, &pdata);
 }
 
 static int __devexit xilinxfb_of_remove(struct of_device *op)
-- 
1.5.3.4-dirty

Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcr infrastructure.

From: Grant Likely <hidden>
Date: 2008-05-06 04:55:54

On Mon, May 5, 2008 at 11:56 AM, Stephen Neuendorffer
[off-list ref] 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 = <1>;
                                #size-cells = <1>;
                                compatible = "xlnx,dcr-v29-1.00.a";
                                VGA_FrameBuffer: tft@80 {
                                        compatible = "xlnx,plb-tft-cntlr-ref-1.00.a";
                                        dcr-parent = <&opb2dcr_bridge_0>;
                                        dcr-reg = < 80 2 >;
                                        xlnx,default-tft-base-addr = <7f>;
                                        xlnx,dps-init = <1>;
                                        xlnx,on-init = <1>;
                                        xlnx,pixclk-is-busclk-divby4 = <1>;
                                } ;
                        } ;

                        opb2dcr_bridge_0: opb2dcr-bridge@40700000 {
                                compatible = "xlnx,opb2dcr-bridge-1.00.b";
                                dcr-access-method = "mmio";
                                dcr-controller ;
                                dcr-mmio-range = < 40700000 1000 >;
                                dcr-mmio-stride = <4>;
                                reg = < 40700000 1000 >;
                                xlnx,family = "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?).

Cheers,
g.
 Signed-off-by: Stephen Neuendorffer [off-list ref]
 ---
  drivers/video/xilinxfb.c |   54 +++++++++++++++++-----------------------------
  1 files changed, 20 insertions(+), 34 deletions(-)

 diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
 index 4d64402..848752e 100644
 --- a/drivers/video/xilinxfb.c
 +++ b/drivers/video/xilinxfb.c
 @@ -37,6 +37,7 @@
  #endif
  #include <asm/io.h>
  #include <linux/xilinxfb.h>
 +#include <asm/dcr.h>

  #define DRIVER_NAME            "xilinxfb"
  #define DRIVER_DESCRIPTION     "Xilinx TFT LCD frame buffer driver"
 @@ -111,8 +112,9 @@ struct xilinxfb_drvdata {

        struct fb_info  info;           /* FB driver info record */

 -       u32             regs_phys;      /* phys. address of the control registers */
 -       u32 __iomem     *regs;          /* virt. address of the control registers */
 +       dcr_host_t      dcr_host;
 +       unsigned int    dcr_start;
 +       unsigned int    dcr_len;

        void            *fb_virt;       /* virt. address of the frame buffer */
        dma_addr_t      fb_phys;        /* phys. address of the frame buffer */
 @@ -135,7 +137,7 @@ struct xilinxfb_drvdata {
  * when it's needed.
  */
  #define xilinx_fb_out_be32(driverdata, offset, val) \
 -       out_be32(driverdata->regs + offset, val)
 +       dcr_write(driverdata->dcr_host, offset, val)

  static int
  xilinx_fb_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned blue,
 @@ -203,7 +205,8 @@ static struct fb_ops xilinxfb_ops =

118 more quoted lines



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcr infrastructure.

From: David Gibson <hidden>
Date: 2008-05-06 06:14:44

On Mon, May 05, 2008 at 10:55:53PM -0600, Grant Likely wrote:
On Mon, May 5, 2008 at 11:56 AM, Stephen Neuendorffer
[off-list ref] wrote:
quoted
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 = <1>;
                                #size-cells = <1>;
                                compatible = "xlnx,dcr-v29-1.00.a";
                                VGA_FrameBuffer: tft@80 {
                                        compatible = "xlnx,plb-tft-cntlr-ref-1.00.a";
                                        dcr-parent = <&opb2dcr_bridge_0>;
                                        dcr-reg = < 80 2 >;
                                        xlnx,default-tft-base-addr = <7f>;
                                        xlnx,dps-init = <1>;
                                        xlnx,on-init = <1>;
                                        xlnx,pixclk-is-busclk-divby4 = <1>;
                                } ;
                        } ;

                        opb2dcr_bridge_0: opb2dcr-bridge@40700000 {
                                compatible = "xlnx,opb2dcr-bridge-1.00.b";
                                dcr-access-method = "mmio";
                                dcr-controller ;
                                dcr-mmio-range = < 40700000 1000 >;
                                dcr-mmio-stride = <4>;
                                reg = < 40700000 1000 >;
                                xlnx,family = "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

10 more quoted lines

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.

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).

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.

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.

-- 
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

Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcr infrastructure.

From: Segher Boessenkool <hidden>
Date: 2008-05-06 10:56:44

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?
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 :-)


Segher

RE: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcrinfrastructure.

From: Stephen Neuendorffer <hidden>
Date: 2008-05-06 17:43:56

-----Original Message-----
From: David Gibson [mailto:<redacted>]
Sent: Monday, May 05, 2008 11:15 PM
To: Grant Likely
Cc: Stephen Neuendorffer; <redacted>
Subject: Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use
dcrinfrastructure.
=20
On Mon, May 05, 2008 at 10:55:53PM -0600, Grant Likely wrote:
quoted
On Mon, May 5, 2008 at 11:56 AM, Stephen Neuendorffer
[off-list ref] wrote:
quoted
This device contains a dcr interface.  Previously, the dcr
interface
quoted
quoted
 was assumed to be used in mmio mode, and the register space of
the dcr
quoted
quoted
 interface was precomputed and stuffed in the device tree.  This
patch
quoted
quoted
 makes use of the new dcr infrastructure to represent the dcr
interface
quoted
quoted
 as any other dcr interface in the device tree.  This enables the
dcr
quoted
quoted
 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";
quoted
quoted
                                VGA_FrameBuffer: tft@80 {
                                        compatible =3D
"xlnx,plb-tft-cntlr-ref-1.00.a";
quoted
quoted
                                        dcr-parent =3D
<&opb2dcr_bridge_0>;
quoted
quoted
                                        dcr-reg =3D < 80 2 >;
                                        xlnx,default-tft-base-addr
=3D <7f>;
quoted
quoted
                                        xlnx,dps-init =3D <1>;
                                        xlnx,on-init =3D <1>;
xlnx,pixclk-is-busclk-divby4 =3D <1>;
quoted
quoted
                                } ;
                        } ;

                        opb2dcr_bridge_0: opb2dcr-bridge@40700000
{
quoted
quoted
                                compatible =3D
"xlnx,opb2dcr-bridge-1.00.b";
quoted
quoted
                                dcr-access-method =3D "mmio";
                                dcr-controller ;
                                dcr-mmio-range =3D < 40700000 1000
;
quoted
quoted
                                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.
quoted
So, in this example; if the device is described by tft@80, and the
dcr
quoted
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

Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcr infrastructure.

From: David Gibson <hidden>
Date: 2008-05-08 01:57:04

On Tue, May 06, 2008 at 12:56:44PM +0200, Segher Boessenkool wrote:
quoted
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.
quoted
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.
quoted
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.
quoted
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

Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcrinfrastructure.

From: David Gibson <hidden>
Date: 2008-05-08 01:59:48

On Tue, May 06, 2008 at 10:43:50AM -0700, Stephen Neuendorffer wrote:
[snip]
quoted
quoted
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.
quoted
quoted
So, in this example; if the device is described by tft@80, and the
dcr
quoted
quoted
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?).
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 = <> 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).
I don't really understand what you're getting at here, sorry.  Perhaps
you could describe what you're doing with the tft device in more
detail?
quoted
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).

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.
-- 
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

RE: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Usedcrinfrastructure.

From: Stephen Neuendorffer <hidden>
Date: 2008-05-08 04:46:56

The problem is that the tft driver currently in mainline assumes that the dcr control registers
are accessed through mmio, and probes for a reg=<> property.  Since the device is actually a dcr device,
it can be connected via mmio through a bride, or to the native dcr bus of the processor.  For the time being,
I'd like to generate device trees compatible with either mechanism.

so, the problem is that the tree-parents of the tft node all have ranges, and if the dcr-parent of the node is a bridge, then it has a reg=<> property,
But if the dcr-parent is also a tree-parent, then it has to have ranges; and a reg=<> property, which seems very strange, and not something I think is
a good thing to do.

Steve

-----Original Message-----
From: David Gibson [mailto:<redacted>]
Sent: Wed 5/7/2008 6:59 PM
To: Stephen Neuendorffer
Cc: Grant Likely; <redacted>
Subject: Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Usedcrinfrastructure.
 
On Tue, May 06, 2008 at 10:43:50AM -0700, Stephen Neuendorffer wrote:
[snip]
quoted
quoted
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.
quoted
quoted
So, in this example; if the device is described by tft@80, and the
dcr
quoted
quoted
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?).
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 = <> 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).
I don't really understand what you're getting at here, sorry.  Perhaps
you could describe what you're doing with the tft device in more
detail?
quoted
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).

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.
-- 
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

Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Usedcrinfrastructure.

From: David Gibson <hidden>
Date: 2008-05-08 07:01:28

On Wed, May 07, 2008 at 09:46:51PM -0700, Stephen Neuendorffer wrote:
The problem is that the tft driver currently in mainline assumes
that the dcr control registers are accessed through mmio, and probes
for a reg=<> property.  Since the device is actually a dcr device,
it can be connected via mmio through a bride, or to the native dcr
bus of the processor.  For the time being, I'd like to generate
device trees compatible with either mechanism.
Ah, I think I see.  The current driver expects the device to be
represented as if it were an mmio device, not using the standard dcr
notation.  It can get away with this because the DCRs are
memory-mapped, in a way representable by 'ranges'.
so, the problem is that the tree-parents of the tft node all have
ranges, and if the dcr-parent of the node is a bridge, then it has a
reg=<> property, But if the dcr-parent is also a tree-parent, then
it has to have ranges; and a reg=<> property, which seems very
strange, and not something I think is a good thing to do.
This I don't follow.

But I don't think it matters.  The representation suggested by Segher,
which has the DCR addressing redundantly described in 'reg' and
'dcr-reg' properties should work for you.

-- 
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help