RE: [PATCH] [V2] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
I thought it was based on mainline, but I now see the weirdness you're talking
about. I'll dig in on this and let you know more as I'm confused also.
-- John
-Original Message-
From: Grant Likely [mailto:grant.lik...@secretlab.ca]
Sent: Sunday, April 12, 2009 12:15 AM
To: John Linn
Cc: jwbo...@linux.vnet.ibm.com; linux-fbdev-de...@lists.sourceforge.net;
linuxppc-dev@ozlabs.org;
akonova...@ru.mvista.com; adap...@gmail.com; Suneel Garapati
Subject: Re: [PATCH] [V2] Xilinx : Framebuffer Driver: Add PLB support
(non-DCR)
What tree is this patch prepared against? The version in mainline
already does PLB access, and doesn't support DCR at all. It appears
that this driver is based on something that does the opposite.
g.
On Fri, Apr 10, 2009 at 3:17 PM, John Linn john.l...@xilinx.com wrote:
From: Suneel sune...@xilinx.com
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Josh, Grant and others
drivers/video/xilinxfb.c | 213
--
1 files changed, 150 insertions(+), 63 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..d151237 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,13 +1,13 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed as is without any warranty of any
@@ -31,27 +31,31 @@
#include linux/fb.h
#include linux/init.h
#include linux/dma-mapping.h
-#if defined(CONFIG_OF)
#include linux/of_device.h
#include linux/of_platform.h
-#endif
-#include asm/io.h
+#include linux/io.h
#include linux/xilinxfb.h
#include asm/dcr.h
#define DRIVER_NAME xilinxfb
-#define DRIVER_DESCRIPTION Xilinx TFT LCD frame buffer driver
+
/*
* Xilinx calls it PLB TFT LCD Controller though it can also be used for
- * the VGA port on the Xilinx ML40x board. This is a hardware display
controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a 640x480 resolution TFT or VGA screen.
*
* The interface to the framebuffer is nice and simple. There are two
* control registers. The first tells the LCD interface where in memory
* the frame buffer is (only the 11 most significant bits are used, so
* don't start thinking about scrolling). The second allows the LCD to
* be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
*/
#define NUM_REGS 2
#define REG_FB_ADDR 0
@@ -108,10 +112,18 @@ static struct fb_var_screeninfo xilinx_fb_var = {
.activate = FB_ACTIVATE_NOW
};
+
+#define PLB_ACCESS_FLAG 0x1 /* 1 = PLB, 0 = DCR */
+
struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ phys_addr_t regs_phys; /* phys. address of the control
+ registers */
+ void __iomem *regs; /* virt. address of the control
+ registers */
+
dcr_host_t dcr_host;
unsigned int dcr_start;
unsigned int dcr_len;
@@ -120,6 +132,8 @@ struct xilinxfb_drvdata {
dma_addr_t fb_phys; /* phys. address of the frame buffer
*/
int fb_alloced; /* Flag, was the fb memory alloced?
*/
+ u8 flags; /* features of the driver */
+
u32 reg_ctrl_default;
u32 pseudo_palette[PALETTE_ENTRIES_NO];
@@ -130,14 +144,19 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple
Re: [PATCH] [V2] Xilinx : Framebuffer Driver: Add PLB support(non-DCR)
On Mon, Apr 13, 2009 at 10:49 AM, Stephen Neuendorffer
stephen.neuendorf...@xilinx.com wrote:
I think the mainline driver might (still) assume the presence of a PLB-DCR
bridge?
Correct.
So there are really 4 cases:
Core has DCR access, accessed directly using DCR.
Core has DCR access, accessed indirectly using DCR.
Core has DCR access, accessed through plb-dcr bridge.
Core has PLB access.
sounds right to me.
g.
Steve
-Original Message-
From: linuxppc-dev-bounces+stephen.neuendorffer=xilinx@ozlabs.org
[mailto:linuxppc-dev-
bounces+stephen.neuendorffer=xilinx@ozlabs.org] On Behalf Of John Linn
Sent: Monday, April 13, 2009 7:13 AM
To: grant.lik...@secretlab.ca
Cc: linux-fbdev-de...@lists.sourceforge.net; adap...@gmail.com; Suneel
Garapati; linuxppc-
d...@ozlabs.org; akonova...@ru.mvista.com
Subject: RE: [PATCH] [V2] Xilinx : Framebuffer Driver: Add PLB
support(non-DCR)
I thought it was based on mainline, but I now see the weirdness you're
talking about. I'll dig in on
this and let you know more as I'm confused also.
-- John
-Original Message-
From: Grant Likely [mailto:grant.lik...@secretlab.ca]
Sent: Sunday, April 12, 2009 12:15 AM
To: John Linn
Cc: jwbo...@linux.vnet.ibm.com; linux-fbdev-de...@lists.sourceforge.net;
linuxppc-dev@ozlabs.org;
akonova...@ru.mvista.com; adap...@gmail.com; Suneel Garapati
Subject: Re: [PATCH] [V2] Xilinx : Framebuffer Driver: Add PLB support
(non-DCR)
What tree is this patch prepared against? The version in mainline
already does PLB access, and doesn't support DCR at all. It appears
that this driver is based on something that does the opposite.
g.
On Fri, Apr 10, 2009 at 3:17 PM, John Linn john.l...@xilinx.com wrote:
From: Suneel sune...@xilinx.com
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Josh, Grant and others
drivers/video/xilinxfb.c | 213
--
1 files changed, 150 insertions(+), 63 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..d151237 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,13 +1,13 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
* This file is licensed under the terms of the GNU General Public
License
* version 2. This program is licensed as is without any warranty of
any
@@ -31,27 +31,31 @@
#include linux/fb.h
#include linux/init.h
#include linux/dma-mapping.h
-#if defined(CONFIG_OF)
#include linux/of_device.h
#include linux/of_platform.h
-#endif
-#include asm/io.h
+#include linux/io.h
#include linux/xilinxfb.h
#include asm/dcr.h
#define DRIVER_NAME xilinxfb
-#define DRIVER_DESCRIPTION Xilinx TFT LCD frame buffer driver
+
/*
* Xilinx calls it PLB TFT LCD Controller though it can also be used
for
- * the VGA port on the Xilinx ML40x board. This is a hardware display
controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a 640x480 resolution TFT or VGA screen.
*
* The interface to the framebuffer is nice and simple. There are two
* control registers. The first tells the LCD interface where in memory
* the frame buffer is (only the 11 most significant bits are used, so
* don't start thinking about scrolling). The second allows the LCD to
* be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
*/
#define NUM_REGS 2
#define REG_FB_ADDR 0
@@ -108,10 +112,18 @@ static struct fb_var_screeninfo xilinx_fb_var = {
.activate = FB_ACTIVATE_NOW
};
+
+#define PLB_ACCESS_FLAG 0x1 /* 1 = PLB, 0 = DCR */
+
struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ phys_addr_t regs_phys; /* phys. address of the control
RE: [PATCH] [V2] Xilinx : Framebuffer Driver: Add PLB support(non-DCR)
I think the mainline driver might (still) assume the presence of a PLB-DCR
bridge?
So there are really 4 cases:
Core has DCR access, accessed directly using DCR.
Core has DCR access, accessed indirectly using DCR.
Core has DCR access, accessed through plb-dcr bridge.
Core has PLB access.
Steve
-Original Message-
From: linuxppc-dev-bounces+stephen.neuendorffer=xilinx@ozlabs.org
[mailto:linuxppc-dev-
bounces+stephen.neuendorffer=xilinx@ozlabs.org] On Behalf Of John Linn
Sent: Monday, April 13, 2009 7:13 AM
To: grant.lik...@secretlab.ca
Cc: linux-fbdev-de...@lists.sourceforge.net; adap...@gmail.com; Suneel
Garapati; linuxppc-
d...@ozlabs.org; akonova...@ru.mvista.com
Subject: RE: [PATCH] [V2] Xilinx : Framebuffer Driver: Add PLB
support(non-DCR)
I thought it was based on mainline, but I now see the weirdness you're
talking about. I'll dig in on
this and let you know more as I'm confused also.
-- John
-Original Message-
From: Grant Likely [mailto:grant.lik...@secretlab.ca]
Sent: Sunday, April 12, 2009 12:15 AM
To: John Linn
Cc: jwbo...@linux.vnet.ibm.com; linux-fbdev-de...@lists.sourceforge.net;
linuxppc-dev@ozlabs.org;
akonova...@ru.mvista.com; adap...@gmail.com; Suneel Garapati
Subject: Re: [PATCH] [V2] Xilinx : Framebuffer Driver: Add PLB support
(non-DCR)
What tree is this patch prepared against? The version in mainline
already does PLB access, and doesn't support DCR at all. It appears
that this driver is based on something that does the opposite.
g.
On Fri, Apr 10, 2009 at 3:17 PM, John Linn john.l...@xilinx.com wrote:
From: Suneel sune...@xilinx.com
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Josh, Grant and others
drivers/video/xilinxfb.c | 213
--
1 files changed, 150 insertions(+), 63 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..d151237 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,13 +1,13 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed as is without any warranty of
any
@@ -31,27 +31,31 @@
#include linux/fb.h
#include linux/init.h
#include linux/dma-mapping.h
-#if defined(CONFIG_OF)
#include linux/of_device.h
#include linux/of_platform.h
-#endif
-#include asm/io.h
+#include linux/io.h
#include linux/xilinxfb.h
#include asm/dcr.h
#define DRIVER_NAME xilinxfb
-#define DRIVER_DESCRIPTION Xilinx TFT LCD frame buffer driver
+
/*
* Xilinx calls it PLB TFT LCD Controller though it can also be used for
- * the VGA port on the Xilinx ML40x board. This is a hardware display
controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a 640x480 resolution TFT or VGA screen.
*
* The interface to the framebuffer is nice and simple. There are two
* control registers. The first tells the LCD interface where in memory
* the frame buffer is (only the 11 most significant bits are used, so
* don't start thinking about scrolling). The second allows the LCD to
* be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
*/
#define NUM_REGS 2
#define REG_FB_ADDR 0
@@ -108,10 +112,18 @@ static struct fb_var_screeninfo xilinx_fb_var = {
.activate = FB_ACTIVATE_NOW
};
+
+#define PLB_ACCESS_FLAG 0x1 /* 1 = PLB, 0 = DCR */
+
struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ phys_addr_t regs_phys; /* phys. address of the control
+ registers */
+ void __iomem *regs; /* virt. address of the control
Re: [PATCH] [V2] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
What tree is this patch prepared against? The version in mainline
already does PLB access, and doesn't support DCR at all. It appears
that this driver is based on something that does the opposite.
g.
On Fri, Apr 10, 2009 at 3:17 PM, John Linn john.l...@xilinx.com wrote:
From: Suneel sune...@xilinx.com
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Josh, Grant and others
drivers/video/xilinxfb.c | 213
--
1 files changed, 150 insertions(+), 63 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..d151237 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,13 +1,13 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed as is without any warranty of any
@@ -31,27 +31,31 @@
#include linux/fb.h
#include linux/init.h
#include linux/dma-mapping.h
-#if defined(CONFIG_OF)
#include linux/of_device.h
#include linux/of_platform.h
-#endif
-#include asm/io.h
+#include linux/io.h
#include linux/xilinxfb.h
#include asm/dcr.h
#define DRIVER_NAME xilinxfb
-#define DRIVER_DESCRIPTION Xilinx TFT LCD frame buffer driver
+
/*
* Xilinx calls it PLB TFT LCD Controller though it can also be used for
- * the VGA port on the Xilinx ML40x board. This is a hardware display
controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a 640x480 resolution TFT or VGA screen.
*
* The interface to the framebuffer is nice and simple. There are two
* control registers. The first tells the LCD interface where in memory
* the frame buffer is (only the 11 most significant bits are used, so
* don't start thinking about scrolling). The second allows the LCD to
* be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
*/
#define NUM_REGS 2
#define REG_FB_ADDR 0
@@ -108,10 +112,18 @@ static struct fb_var_screeninfo xilinx_fb_var = {
.activate = FB_ACTIVATE_NOW
};
+
+#define PLB_ACCESS_FLAG 0x1 /* 1 = PLB, 0 = DCR */
+
struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ phys_addr_t regs_phys; /* phys. address of the control
+ registers */
+ void __iomem *regs; /* virt. address of the control
+ registers */
+
dcr_host_t dcr_host;
unsigned int dcr_start;
unsigned int dcr_len;
@@ -120,6 +132,8 @@ struct xilinxfb_drvdata {
dma_addr_t fb_phys; /* phys. address of the frame buffer */
int fb_alloced; /* Flag, was the fb memory alloced? */
+ u8 flags; /* features of the driver */
+
u32 reg_ctrl_default;
u32 pseudo_palette[PALETTE_ENTRIES_NO];
@@ -130,14 +144,19 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple to add the direct DCR access
- * when it's needed.
+ * The XPS TFT Controller can be accessed through PLB or DCR interface.
+ * To perform the read/write on the registers we need to check on
+ * which bus its connected and call the appropriate write API.
*/
-#define xilinx_fb_out_be32(driverdata, offset, val) \
- dcr_write(driverdata-dcr_host, offset, val)
+static void xilinx_fb_out_be32(struct xilinxfb_drvdata *drvdata, u32 offset,
+ u32 val)
+{
+ if (drvdata-flags PLB_ACCESS_FLAG)
+ out_be32(drvdata-regs + (offset 2), val);
+ else
+ dcr_write(drvdata-dcr_host, offset, val);
+
