* Re: [BUG] simplefb not showing any output
From: David Herrmann @ 2013-09-06 16:57 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
Hi Tom
( 2 more mails and you might get the fbdev ML right ;) )
On Fri, Sep 6, 2013 at 6:14 PM, Tom Gundersen <teg@jklm.no> wrote:
> Hi guys,
>
> I have been trying simplefb from mainline (v3.11-5058-g57d7309), with
> a couple of patches on top (one to make simplefb actually load on my
> system, posted to x86 earlier today, and one to make it show some
> output posted to this list earlier today).
>
> The driver seems to load ok, but sadly it does not give any output. If
> I boot via the gummiboot menu the screen remains black, and if I don't
> enter the gummiboot menu the screen remains grey (it is a Mac).
>
> Except for that the machine works (I can log on blindly in order to reboot).
>
> Is this a known problem? Any suggestions on where to start debugging?
> Any more info I could provide?
>
> The output given during boot is
>
> calling simplefb_driver_init+0x0/0x14 @ 1
> simple-framebuffer simple-framebuffer.0: simplefb: framebuffer at
> 0x90000000, mapped to 0xffffc90009b00000
> simple-framebuffer simple-framebuffer.0: simplefb: format a8r8g8b8,
> mode is 1366x768x32, linelengthV32
> simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!
> initcall simplefb_driver_init+0x0/0x14 returned 0 after 1072 usecs
Ok, this looks all good. Few questions:
- Is CONFIG_FB_EFI enabled? If not, please enable it and try again
(hint: CONFIG_FB_VESA doesn't hurt either)
- Could you try the _same_ kernel config but disable CONFIG_X86_SYSFB.
This will avoid creating simple-fb devices and instead load efifb
again. Does efifb work? Does efifb print the same offsets as your
simplefb printk()?
- Are you sure that it's an simplefb problem? Please make sure fbcon
is enabled (could you attach your dmesg output?). You could also try
SSH'ing into the machine and starting some fbdev program (like X with
xf86-video-fbdev installed). Or does fbcon with efifb work?
Thanks
David
^ permalink raw reply
* Re: [BUG] simplefb not showing any output
From: Tom Gundersen @ 2013-09-06 17:12 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
On Fri, Sep 6, 2013 at 6:57 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> ( 2 more mails and you might get the fbdev ML right ;) )
Modern technology...
> - Is CONFIG_FB_EFI enabled? If not, please enable it and try again
> (hint: CONFIG_FB_VESA doesn't hurt either)
FB_EFI was enabled, FB_VESA was not, but I'll enable it. Out of
interest, how could this affect the situation? If I understand
correctly these drivers won't be loaded as long as simple-framebuffer
is created, or am I missing something?
> - Could you try the _same_ kernel config but disable CONFIG_X86_SYSFB.
> This will avoid creating simple-fb devices and instead load efifb
> again. Does efifb work? Does efifb print the same offsets as your
> simplefb printk()?
Yeah, efifb works fine, I'll double-check everything and note down the offsets.
> - Are you sure that it's an simplefb problem? Please make sure fbcon
> is enabled (could you attach your dmesg output?). You could also try
> SSH'ing into the machine and starting some fbdev program (like X with
> xf86-video-fbdev installed). Or does fbcon with efifb work?
fbcon with efifb works fine (so I guess trying X is not necessary?).
Cheers,
Tom
^ permalink raw reply
* Re: [BUG] simplefb not showing any output
From: David Herrmann @ 2013-09-06 17:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
Hi
On Fri, Sep 6, 2013 at 7:12 PM, Tom Gundersen <teg@jklm.no> wrote:
> On Fri, Sep 6, 2013 at 6:57 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> ( 2 more mails and you might get the fbdev ML right ;) )
>
> Modern technology...
>
>> - Is CONFIG_FB_EFI enabled? If not, please enable it and try again
>> (hint: CONFIG_FB_VESA doesn't hurt either)
>
> FB_EFI was enabled, FB_VESA was not, but I'll enable it. Out of
> interest, how could this affect the situation? If I understand
> correctly these drivers won't be loaded as long as simple-framebuffer
> is created, or am I missing something?
In case you disable X86_SYSFB vesafb might still be used (I wasn't
sure you used efifb). And there might be some nasty Kconfig-select
logic that I overlooked (like FB_BOOT_VESA_SUPPORT).. Just to be sure.
>> - Could you try the _same_ kernel config but disable CONFIG_X86_SYSFB.
>> This will avoid creating simple-fb devices and instead load efifb
>> again. Does efifb work? Does efifb print the same offsets as your
>> simplefb printk()?
>
> Yeah, efifb works fine, I'll double-check everything and note down the offsets.
Just to be clear, efifb still with the new x86-sysfb infrastructure
works? Because I moved some efifb quirks from efifb.c to
x86/kernel/sysfb_efi.c. So even with CONFIG_X86_SYSFB=n the situation
is still different from pre-3.12.
>> - Are you sure that it's an simplefb problem? Please make sure fbcon
>> is enabled (could you attach your dmesg output?). You could also try
>> SSH'ing into the machine and starting some fbdev program (like X with
>> xf86-video-fbdev installed). Or does fbcon with efifb work?
>
> fbcon with efifb works fine (so I guess trying X is not necessary?).
Yeah, if fbcon+efifb works, no need to test X.
Regards
David
^ permalink raw reply
* [PATCH 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2013-09-06 17:23 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds basic DT bindings for the PL11x CLCD cells
and make their fbdev driver use them.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
.../devicetree/bindings/video/arm,pl11x.txt | 87 +++++++++
drivers/video/Kconfig | 1 +
drivers/video/amba-clcd.c | 214 +++++++++++++++++++++
3 files changed, 302 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt
diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt
new file mode 100644
index 0000000..178aebb
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
@@ -0,0 +1,87 @@
+* ARM PrimeCell Color LCD Controller (CLCD) PL110/PL111
+
+See also Documentation/devicetree/bindings/arm/primecell.txt
+
+Required properties:
+
+- compatible: must be one of:
+ "arm,pl110", "arm,primecell"
+ "arm,pl111", "arm,primecell"
+- reg: base address and size of the control registers block
+- interrupts: either a single interrupt specifier representing the
+ combined interrupt output (CLCDINTR) or an array of
+ four interrupt specifiers for CLCDMBEINTR,
+ CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR; in the
+ latter case interrupt names must be specified
+ (see below)
+- interrupt-names: when four interrupts are specified, their names:
+ "mbe", "vcomp", "lnbu", "fuf"
+ must be specified in order respective to the
+ interrupt specifiers
+- clocks: contains phandle and clock specifier pairs for the entries
+ in the clock-names property. See
+ Documentation/devicetree/binding/clock/clock-bindings.txt
+- clocks names: should contain "clcdclk" and "apb_pclk"
+
+Optional properties:
+
+- video-ram: phandle to a node describing specialized video memory
+ (that is *not* described in the top level "memory" node)
+ that must be used as a framebuffer, eg. due to restrictions
+ of the system interconnect; the node must contain a
+ standard reg property describing the address and the size
+ of the memory area
+- max-framebuffer-size: maximum size in bytes of the framebuffer the
+ system can handle, eg. in terms of available
+ memory bandwidth
+
+In the simplest case of a display panel being connected directly to the
+CLCD, it can be described in the node:
+
+- panel-dimensions: (optional) array of two numbers (width and height)
+ describing physical dimension in mm of the panel
+- panel-type: (required) must be "tft" or "stn", defines panel type
+- panel-tft-interface: (for "tft" panel type) array of 3 numbers defining
+ widths in bits of the R, G and B components
+- panel-tft-rb-swapped: (for "tft" panel type) if present means that
+ the R & B components are swapped on the board
+- panel-stn-color: (for "stn" panel type) if present means that
+ the panel is a colour STN display, if missing
+ is a monochrome display
+- panel-stn-dual: (for "stn" panel type) if present means that there
+ are two STN displays connected
+- panel-stn-4bit: (for monochrome "stn" panel) if present means
+ that the monochrome display is connected
+ via 4 bit-wide interface
+- display-timings: standard display timings sub-node, see
+ Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+ clcd@1f0000 {
+ compatible = "arm,pl111", "arm,primecell";
+ reg = <0x1f0000 0x1000>;
+ interrupts = <14>;
+ clocks = <&v2m_oscclk1>, <&smbclk>;
+ clock-names = "clcdclk", "apb_pclk";
+
+ video-ram = <&v2m_vram>;
+ max-framebuffer-size = <614400>; /* 640x480 16bpp */
+
+ panel-type = "tft";
+ panel-tft-interface = <8 8 8>;
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
+ };
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4cf1e1d..375bf63 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -316,6 +316,7 @@ config FB_ARMCLCD
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select VIDEOMODE_HELPERS if OF
help
This framebuffer device driver is for the ARM PrimeCell PL110
Colour LCD controller. ARM PrimeCells provide the building
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..145ca5a 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -25,6 +25,11 @@
#include <linux/amba/clcd.h>
#include <linux/clk.h>
#include <linux/hardirq.h>
+#include <linux/dma-mapping.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <video/of_display_timing.h>
+#include <video/of_videomode.h>
#include <asm/sizes.h>
@@ -542,6 +547,212 @@ static int clcdfb_register(struct clcd_fb *fb)
return ret;
}
+#ifdef CONFIG_OF
+static int clcdfb_of_get_tft_panel(struct device_node *node,
+ struct clcd_panel *panel)
+{
+ int err;
+ u32 rgb[3];
+ int r, g, b;
+
+ err = of_property_read_u32_array(node, "panel-tft-interface", rgb, 3);
+ if (err)
+ return err;
+
+ r = rgb[0];
+ g = rgb[1];
+ b = rgb[2];
+
+ /* Bypass pixel clock divider, data output on the falling edge */
+ panel->tim2 = TIM2_BCD | TIM2_IPC;
+
+ /* TFT display, vert. comp. interrupt at the start of the back porch */
+ panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
+
+ if (r >= 4 && g >= 4 && b >= 4)
+ panel->caps |= CLCD_CAP_444;
+ if (r >= 5 && g >= 5 && b >= 5)
+ panel->caps |= CLCD_CAP_5551;
+ if (r >= 5 && g >= 6 && b >= 5)
+ panel->caps |= CLCD_CAP_565;
+ if (r >= 8 && g >= 8 && b >= 8)
+ panel->caps |= CLCD_CAP_888;
+
+ if (of_get_property(node, "panel-tft-rb-swapped", NULL))
+ panel->caps &= ~CLCD_CAP_RGB;
+ else
+ panel->caps &= ~CLCD_CAP_BGR;
+
+ return 0;
+}
+
+static int clcdfb_of_init_display(struct clcd_fb *fb)
+{
+ struct device_node *node = fb->dev->dev.of_node;
+ u32 max_size;
+ u32 dimensions[2];
+ char *mode_name;
+ int len, err;
+ const char *panel_type;
+
+ fb->panel = devm_kzalloc(&fb->dev->dev, sizeof(*fb->panel), GFP_KERNEL);
+ if (!fb->panel)
+ return -ENOMEM;
+
+ err = of_get_fb_videomode(fb->dev->dev.of_node, &fb->panel->mode,
+ OF_USE_NATIVE_MODE);
+ if (err)
+ return err;
+
+ len = snprintf(NULL, 0, "%ux%u@%u", fb->panel->mode.xres,
+ fb->panel->mode.yres, fb->panel->mode.refresh);
+ mode_name = devm_kzalloc(&fb->dev->dev, len + 1, GFP_KERNEL);
+ snprintf(mode_name, len + 1, "%ux%u@%u", fb->panel->mode.xres,
+ fb->panel->mode.yres, fb->panel->mode.refresh);
+ fb->panel->mode.name = mode_name;
+
+ err = of_property_read_u32(node, "max-framebuffer-size", &max_size);
+ if (!err)
+ fb->panel->bpp = max_size / (fb->panel->mode.xres *
+ fb->panel->mode.yres) * 8;
+ else
+ fb->panel->bpp = 32;
+
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ fb->panel->cntl |= CNTL_BEBO;
+#endif
+
+ if (of_property_read_u32_array(node, "panel-dimensions",
+ dimensions, 2) == 0) {
+ fb->panel->width = dimensions[0];
+ fb->panel->height = dimensions[1];
+ } else {
+ fb->panel->width = -1;
+ fb->panel->height = -1;
+ }
+
+ panel_type = of_get_property(node, "panel-type", &len);
+ if (strncmp(panel_type, "tft", len) == 0)
+ return clcdfb_of_get_tft_panel(node, fb->panel);
+ else
+ return -EINVAL;
+}
+
+static int clcdfb_of_vram_setup(struct clcd_fb *fb)
+{
+ const __be32 *prop = of_get_property(fb->dev->dev.of_node, "video-ram",
+ NULL);
+ struct device_node *node = of_find_node_by_phandle(be32_to_cpup(prop));
+ u64 size;
+ int err;
+
+ if (!node)
+ return -ENODEV;
+
+ err = clcdfb_of_init_display(fb);
+ if (err)
+ return err;
+
+ fb->fb.screen_base = of_iomap(node, 0);
+ if (!fb->fb.screen_base)
+ return -ENOMEM;
+
+ fb->fb.fix.smem_start = of_translate_address(node,
+ of_get_address(node, 0, &size, NULL));
+ fb->fb.fix.smem_len = size;
+
+ return 0;
+}
+
+static int clcdfb_of_vram_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+ unsigned long off, user_size, kernel_size;
+
+ off = vma->vm_pgoff << PAGE_SHIFT;
+ user_size = vma->vm_end - vma->vm_start;
+ kernel_size = fb->fb.fix.smem_len;
+
+ if (off >= kernel_size || user_size > (kernel_size - off))
+ return -ENXIO;
+
+ return remap_pfn_range(vma, vma->vm_start,
+ __phys_to_pfn(fb->fb.fix.smem_start) + vma->vm_pgoff,
+ user_size,
+ pgprot_writecombine(vma->vm_page_prot));
+}
+
+static void clcdfb_of_vram_remove(struct clcd_fb *fb)
+{
+ iounmap(fb->fb.screen_base);
+}
+
+static int clcdfb_of_dma_setup(struct clcd_fb *fb)
+{
+ unsigned long framesize;
+ dma_addr_t dma;
+ int err;
+
+ err = clcdfb_of_init_display(fb);
+ if (err)
+ return err;
+
+ framesize = fb->panel->mode.xres * fb->panel->mode.yres *
+ fb->panel->bpp / 8;
+ fb->fb.screen_base = dma_alloc_writecombine(&fb->dev->dev, framesize,
+ &dma, GFP_KERNEL);
+ if (!fb->fb.screen_base)
+ return -ENOMEM;
+
+ fb->fb.fix.smem_start = dma;
+ fb->fb.fix.smem_len = framesize;
+
+ return 0;
+}
+
+static int clcdfb_of_dma_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+ return dma_mmap_writecombine(&fb->dev->dev, vma, fb->fb.screen_base,
+ fb->fb.fix.smem_start, fb->fb.fix.smem_len);
+}
+
+static void clcdfb_of_dma_remove(struct clcd_fb *fb)
+{
+ dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
+ fb->fb.screen_base, fb->fb.fix.smem_start);
+}
+
+static struct clcd_board *clcdfb_of_get_board(struct amba_device *dev)
+{
+ struct clcd_board *board = devm_kzalloc(&dev->dev, sizeof(*board),
+ GFP_KERNEL);
+ struct device_node *node = dev->dev.of_node;
+
+ if (!board)
+ return NULL;
+
+ board->name = of_node_full_name(node);
+ board->caps = CLCD_CAP_ALL;
+ board->check = clcdfb_check;
+ board->decode = clcdfb_decode;
+ if (of_find_property(node, "video-ram", NULL)) {
+ board->setup = clcdfb_of_vram_setup;
+ board->mmap = clcdfb_of_vram_mmap;
+ board->remove = clcdfb_of_vram_remove;
+ } else {
+ board->setup = clcdfb_of_dma_setup;
+ board->mmap = clcdfb_of_dma_mmap;
+ board->remove = clcdfb_of_dma_remove;
+ }
+
+ return board;
+}
+#else
+static struct clcd_board *clcdfb_of_get_board(struct amba_dev *dev)
+{
+ return NULL;
+}
+#endif
+
static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
{
struct clcd_board *board = dev->dev.platform_data;
@@ -549,6 +760,9 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
int ret;
if (!board)
+ board = clcdfb_of_get_board(dev);
+
+ if (!board)
return -EINVAL;
ret = amba_request_regions(dev, NULL);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/2] ARM: vexpress: Add CLCD Device Tree properties
From: Pawel Moll @ 2013-09-06 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1378488201-21146-1-git-send-email-pawel.moll@arm.com>
... for V2M-P1 motherboard CLCD (limited to 640x480 16bpp and using
dedicated video RAM bank) and for V2P-CA9 (up to 1024x768 16bpp).
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 25 +++++++++++++++++++++++--
arch/arm/boot/dts/vexpress-v2m.dtsi | 25 +++++++++++++++++++++++--
arch/arm/boot/dts/vexpress-v2p-ca9.dts | 20 ++++++++++++++++++++
3 files changed, 66 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index ac870fb..91dff88 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -41,7 +41,7 @@
bank-width = <4>;
};
- vram@2,00000000 {
+ v2m_vram: vram@2,00000000 {
compatible = "arm,vexpress-vram";
reg = <2 0x00000000 0x00800000>;
};
@@ -233,6 +233,27 @@
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
+
+ video-ram = <&v2m_vram>;
+ max-framebuffer-size = <614400>; /* 640x480 16bpp */
+
+ /* This is the best the CLCD can do here */
+ panel-type = "tft";
+ panel-tft-interface = <8 8 8>;
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
};
};
@@ -282,7 +303,7 @@
/* CLCD clock */
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 1>;
- freq-range = <23750000 63500000>;
+ freq-range = <23750000 65000000>;
#clock-cells = <0>;
clock-output-names = "v2m:oscclk1";
};
diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi
index f142036..4bc348c 100644
--- a/arch/arm/boot/dts/vexpress-v2m.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
@@ -40,7 +40,7 @@
bank-width = <4>;
};
- vram@3,00000000 {
+ v2m_vram: vram@3,00000000 {
compatible = "arm,vexpress-vram";
reg = <3 0x00000000 0x00800000>;
};
@@ -232,6 +232,27 @@
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
+
+ video-ram = <&v2m_vram>;
+ max-framebuffer-size = <614400>; /* 640x480 16bpp */
+
+ /* This is the best the CLCD can do here */
+ panel-type = "tft";
+ panel-tft-interface = <8 8 8>;
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
};
};
@@ -281,7 +302,7 @@
/* CLCD clock */
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 1>;
- freq-range = <23750000 63500000>;
+ freq-range = <23750000 65000000>;
#clock-cells = <0>;
clock-output-names = "v2m:oscclk1";
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
index 62d9b22..fbe1c998 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
@@ -73,6 +73,26 @@
interrupts = <0 44 4>;
clocks = <&oscclk1>, <&oscclk2>;
clock-names = "clcdclk", "apb_pclk";
+
+ max-framebuffer-size = <1572864>; /* 1024x768 16bpp */
+
+ /* This is the best the CLCD can do here */
+ panel-type = "tft";
+ panel-tft-interface = <8 8 8>;
+ display-timings {
+ native-mode = <&clcd_timing0>;
+ clcd_timing0: xga {
+ clock-frequency = <63500127>;
+ hactive = <1024>;
+ hback-porch = <152>;
+ hfront-porch = <48>;
+ hsync-len = <104>;
+ vactive = <768>;
+ vback-porch = <23>;
+ vfront-porch = <3>;
+ vsync-len = <4>;
+ };
+ };
};
memory-controller@100e0000 {
--
1.8.1.2
^ permalink raw reply related
* Re: [BUG] simplefb not showing any output
From: Tom Gundersen @ 2013-09-06 17:46 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
On Fri, Sep 6, 2013 at 7:19 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Fri, Sep 6, 2013 at 7:12 PM, Tom Gundersen <teg@jklm.no> wrote:
>> On Fri, Sep 6, 2013 at 6:57 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>> ( 2 more mails and you might get the fbdev ML right ;) )
>>
>> Modern technology...
>>
>>> - Is CONFIG_FB_EFI enabled? If not, please enable it and try again
>>> (hint: CONFIG_FB_VESA doesn't hurt either)
>>
>> FB_EFI was enabled, FB_VESA was not, but I'll enable it. Out of
>> interest, how could this affect the situation? If I understand
>> correctly these drivers won't be loaded as long as simple-framebuffer
>> is created, or am I missing something?
>
> In case you disable X86_SYSFB vesafb might still be used (I wasn't
> sure you used efifb). And there might be some nasty Kconfig-select
> logic that I overlooked (like FB_BOOT_VESA_SUPPORT).. Just to be sure.
Ok. All is now enabled and the behavior is the same.
>>> - Could you try the _same_ kernel config but disable CONFIG_X86_SYSFB.
>>> This will avoid creating simple-fb devices and instead load efifb
>>> again. Does efifb work? Does efifb print the same offsets as your
>>> simplefb printk()?
>>
>> Yeah, efifb works fine, I'll double-check everything and note down the offsets.
>
> Just to be clear, efifb still with the new x86-sysfb infrastructure
> works? Because I moved some efifb quirks from efifb.c to
> x86/kernel/sysfb_efi.c. So even with CONFIG_X86_SYSFB=n the situation
> is still different from pre-3.12.
Turns out I must have messed up my initial testing (maybe I only
tested with an old kernel on efifb). With the current kernel both
X86_SYSFB=y (i.e., simplefb) and X86_SYSFB=n (i.e., efifb) are broken.
Only when I log in and "modprobe i915" do I get an fbcon, before that
the screen is black.
For the record here is the relevant dmesg outputs (they appear to be ok):
efifb: probing for efifb
efifb: framebuffer at 0x90000000, mapped to 0xffffc90009b00000, using
4224k, total 4224k
efifb: mode is 1366x768x32, linelengthV32, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift$:16:8:0
simple-framebuffer simple-framebuffer.0: framebuffer at 0x90000000,
mapped to 0xffffc90009b00000
simple-framebuffer simple-framebuffer.0: format¨r8g8b8,
mode\x1366x768x32, linelengthV32
simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!
>>> - Are you sure that it's an simplefb problem? Please make sure fbcon
>>> is enabled (could you attach your dmesg output?). You could also try
>>> SSH'ing into the machine and starting some fbdev program (like X with
>>> xf86-video-fbdev installed). Or does fbcon with efifb work?
>>
>> fbcon with efifb works fine (so I guess trying X is not necessary?).
>
> Yeah, if fbcon+efifb works, no need to test X.
Scratch this, I'll have to do some more testing. I'll get back to you.
-t
^ permalink raw reply
* Re: [PATCH] simplefb: print some info about the registered fb
From: Stephen Warren @ 2013-09-06 19:11 UTC (permalink / raw)
To: Tom Gundersen
Cc: linux-fbdev, linux-kernel, tomi.valkeinen, plagnioj,
David Herrmann
In-Reply-To: <1378468153-1375-1-git-send-email-teg@jklm.no>
On 09/06/2013 05:49 AM, Tom Gundersen wrote:
> This is similar to the output printed by efifb.
Fine by me,
Acked-by: Stephen Warren <swarren@nvidia.com>
^ permalink raw reply
* Re: [PATCH] simplefb: print some info about the registered fb
From: David Herrmann @ 2013-09-07 11:16 UTC (permalink / raw)
To: Tom Gundersen
Cc: linux-fbdev@vger.kernel.org, linux-kernel, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Stephen Warren
In-Reply-To: <1378468153-1375-1-git-send-email-teg@jklm.no>
Hi Tom
On Fri, Sep 6, 2013 at 1:49 PM, Tom Gundersen <teg@jklm.no> wrote:
> This is similar to the output printed by efifb.
>
> Signed-off-by: Tom Gundersen <teg@jklm.no>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: David Herrmann <dh.herrmann@gmail.com>
> ---
>
> Hi,
>
> Sorry for the resend, got the ml address wrong.
>
> -t
>
> drivers/video/simplefb.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
> index 8d78106..4196686 100644
> --- a/drivers/video/simplefb.c
> +++ b/drivers/video/simplefb.c
> @@ -220,6 +220,14 @@ static int simplefb_probe(struct platform_device *pdev)
> }
> info->pseudo_palette = (void *)(info + 1);
>
> + dev_info(&pdev->dev, "framebuffer at 0x%lx, mapped to 0x%p\n",
> + info->fix.smem_start, info->screen_base);
Could we get smem_len, too? Something like:
dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%lx bytes, mapped
to 0x%p\n",
info->fix.smem_start, (unsigned
long)info->fix.smem_len, info->screen_base);
(smem_len is __u32, so cast it to avoid truncation if it's defined as
long somewhere. Not sure whether we actually have 16bit int somewhere,
though)
Cheers
David
> + dev_info(&pdev->dev, "format=%s, mode=%dx%dx%d, linelength=%d\n",
> + params.format->name,
> + info->var.xres, info->var.yres,
> + info->var.bits_per_pixel,
> + info->fix.line_length);
> +
> ret = register_framebuffer(info);
> if (ret < 0) {
> dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
> --
> 1.8.4
>
^ permalink raw reply
* [PATCH v2] simplefb: print some info about the registered fb
From: Tom Gundersen @ 2013-09-07 11:43 UTC (permalink / raw)
To: linux-fbdev
Cc: linux-kernel, tomi.valkeinen, plagnioj, Tom Gundersen,
David Herrmann
In-Reply-To: <CANq1E4Rxo3Az0hwCzzQyKz6z_uyVq-9bgAzNzm9StkWoAbkN_A@mail.gmail.com>
This is similar to the output printed by efifb.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
---
v2: also print smem_len as requested by David
drivers/video/simplefb.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index 8d78106..80cf074 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -220,6 +220,14 @@ static int simplefb_probe(struct platform_device *pdev)
}
info->pseudo_palette = (void *)(info + 1);
+ dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%lx bytes, mapped to 0x%p\n",
+ info->fix.smem_start, (unsigned long) info->fix.smem_len,
+ info->screen_base);
+ dev_info(&pdev->dev, "format=%s, mode=%dx%dx%d, linelength=%d\n",
+ params.format->name,
+ info->var.xres, info->var.yres,
+ info->var.bits_per_pixel, info->fix.line_length);
+
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
--
1.8.4
^ permalink raw reply related
* Re: [BUG] simplefb not showing any output
From: Tom Gundersen @ 2013-09-07 11:47 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
On Sat, Sep 7, 2013 at 1:18 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Sat, Sep 7, 2013 at 11:26 AM, Tom Gundersen <teg@jklm.no> wrote:
>> On Fri, Sep 6, 2013 at 6:11 PM, Tom Gundersen <teg@jklm.no> wrote:
>>> The driver seems to load ok, but sadly it does not give any output. If
>>> I boot via the gummiboot menu the screen remains black, and if I don't
>>> enter the gummiboot menu the screen remains grey (it is a Mac).
>>
>> My apologies, this was a config error (I somehow ended up with
>> FRAMEBUFFER_CONSOLE=m, which works fine with inteldrmfb, but obviously
>> not with any of the compiled in ones).
>
> Good, I almost went crazy looking for an error. Does that mean
> simplefb works for you?
Sorry about that! Yes, it now works.
> I guess the x86-sysfb patch is still needed?
Yes, that is still needed.
> Now I only wonder why the i915 issue showed up. Is it also solved with
> a built-in fbcon?
Sadly, no, that problem persists.
A related question: is it expected that simplefb should be
significantly slower than efifb, or is that something worth looking
into? My boot with simplefb is roughly five seconds slower than with
efifb. Coincidentally, I notice the same (or similar slowdown) with
inteldrmfb when I see the oops (but not otherwise).
Cheers,
Tom
^ permalink raw reply
* Re: [BUG] simplefb not showing any output
From: David Herrmann @ 2013-09-07 12:25 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4974 bytes --]
Hi Tom
On Sat, Sep 7, 2013 at 1:47 PM, Tom Gundersen <teg@jklm.no> wrote:
> On Sat, Sep 7, 2013 at 1:18 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> On Sat, Sep 7, 2013 at 11:26 AM, Tom Gundersen <teg@jklm.no> wrote:
>>> On Fri, Sep 6, 2013 at 6:11 PM, Tom Gundersen <teg@jklm.no> wrote:
>>>> The driver seems to load ok, but sadly it does not give any output. If
>>>> I boot via the gummiboot menu the screen remains black, and if I don't
>>>> enter the gummiboot menu the screen remains grey (it is a Mac).
>>>
>>> My apologies, this was a config error (I somehow ended up with
>>> FRAMEBUFFER_CONSOLE=m, which works fine with inteldrmfb, but obviously
>>> not with any of the compiled in ones).
>>
>> Good, I almost went crazy looking for an error. Does that mean
>> simplefb works for you?
>
> Sorry about that! Yes, it now works.
No worries. Going crazy is part of working on the kernel, I guess.
>> I guess the x86-sysfb patch is still needed?
>
> Yes, that is still needed.
Ok, I will keep watching it then.
>> Now I only wonder why the i915 issue showed up. Is it also solved with
>> a built-in fbcon?
>
> Sadly, no, that problem persists.
I will let Daniel know on IRC.
> A related question: is it expected that simplefb should be
> significantly slower than efifb, or is that something worth looking
> into? My boot with simplefb is roughly five seconds slower than with
> efifb. Coincidentally, I notice the same (or similar slowdown) with
> inteldrmfb when I see the oops (but not otherwise).
That is probably related to the missing write-combine tag in ioremap.
Stephen, any objections to this attached patch?
Tom, if this solves the speed-issues, I will send it out once I get home.
Thanks
David
(Patch also attached in case of new-lines issues)
From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
From: David Herrmann <dh.herrmann@gmail.com>
Date: Sat, 7 Sep 2013 14:22:01 +0200
Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
introduce it along the way. Note that ioremap_wc() is aliases to
ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
architectures to either provide it or use the same alias.
Reported-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
drivers/video/simplefb.c | 4 ++--
include/linux/io.h | 2 ++
lib/devres.c | 28 ++++++++++++++++++++++++++++
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index 8d78106..a29f1c4 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -212,8 +212,8 @@ static int simplefb_probe(struct platform_device *pdev)
info->fbops = &simplefb_ops;
info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
- info->screen_base = devm_ioremap(&pdev->dev, info->fix.smem_start,
- info->fix.smem_len);
+ info->screen_base = devm_ioremap_wc(&pdev->dev, info->fix.smem_start,
+ info->fix.smem_len);
if (!info->screen_base) {
framebuffer_release(info);
return -ENODEV;
diff --git a/include/linux/io.h b/include/linux/io.h
index f4f42fa..c529410 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -62,6 +62,8 @@ void __iomem *devm_ioremap(struct device *dev,
resource_size_t offset,
unsigned long size);
void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
unsigned long size);
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ unsigned long size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 8235331..34af7a9 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device
*dev, resource_size_t offset,
EXPORT_SYMBOL(devm_ioremap_nocache);
/**
+ * devm_ioremap_wc - Managed ioremap_wc()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_wc(). Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ unsigned long size)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_wc(offset, size);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_wc);
+
+/**
* devm_iounmap - Managed iounmap()
* @dev: Generic device to unmap for
* @addr: Address to unmap
--
1.8.4
[-- Attachment #2: 0001-devm-simplefb-introduce-and-use-devm_ioremap_wc.patch --]
[-- Type: application/octet-stream, Size: 3229 bytes --]
From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
From: David Herrmann <dh.herrmann@gmail.com>
Date: Sat, 7 Sep 2013 14:22:01 +0200
Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
introduce it along the way. Note that ioremap_wc() is aliases to
ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
architectures to either provide it or use the same alias.
Reported-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
drivers/video/simplefb.c | 4 ++--
include/linux/io.h | 2 ++
lib/devres.c | 28 ++++++++++++++++++++++++++++
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index 8d78106..a29f1c4 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -212,8 +212,8 @@ static int simplefb_probe(struct platform_device *pdev)
info->fbops = &simplefb_ops;
info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
- info->screen_base = devm_ioremap(&pdev->dev, info->fix.smem_start,
- info->fix.smem_len);
+ info->screen_base = devm_ioremap_wc(&pdev->dev, info->fix.smem_start,
+ info->fix.smem_len);
if (!info->screen_base) {
framebuffer_release(info);
return -ENODEV;
diff --git a/include/linux/io.h b/include/linux/io.h
index f4f42fa..c529410 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -62,6 +62,8 @@ void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size);
void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
unsigned long size);
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ unsigned long size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 8235331..34af7a9 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
EXPORT_SYMBOL(devm_ioremap_nocache);
/**
+ * devm_ioremap_wc - Managed ioremap_wc()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_wc(). Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ unsigned long size)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_wc(offset, size);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_wc);
+
+/**
* devm_iounmap - Managed iounmap()
* @dev: Generic device to unmap for
* @addr: Address to unmap
--
1.8.4
^ permalink raw reply related
* Re: [BUG] simplefb not showing any output
From: Tom Gundersen @ 2013-09-07 13:02 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
On Sat, Sep 7, 2013 at 2:25 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Sat, Sep 7, 2013 at 1:47 PM, Tom Gundersen <teg@jklm.no> wrote:
>> A related question: is it expected that simplefb should be
>> significantly slower than efifb, or is that something worth looking
>> into? My boot with simplefb is roughly five seconds slower than with
>> efifb. Coincidentally, I notice the same (or similar slowdown) with
>> inteldrmfb when I see the oops (but not otherwise).
>
> That is probably related to the missing write-combine tag in ioremap.
> Stephen, any objections to this attached patch?
> Tom, if this solves the speed-issues, I will send it out once I get home.
This solves the speed issues. Thanks!
Feel free to add my tested-by.
Cheers,
Tom
> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
> From: David Herrmann <dh.herrmann@gmail.com>
> Date: Sat, 7 Sep 2013 14:22:01 +0200
> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
>
> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
> introduce it along the way. Note that ioremap_wc() is aliases to
> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
> architectures to either provide it or use the same alias.
>
> Reported-by: Tom Gundersen <teg@jklm.no>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
> drivers/video/simplefb.c | 4 ++--
> include/linux/io.h | 2 ++
> lib/devres.c | 28 ++++++++++++++++++++++++++++
> 3 files changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
> index 8d78106..a29f1c4 100644
> --- a/drivers/video/simplefb.c
> +++ b/drivers/video/simplefb.c
> @@ -212,8 +212,8 @@ static int simplefb_probe(struct platform_device *pdev)
>
> info->fbops = &simplefb_ops;
> info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
> - info->screen_base = devm_ioremap(&pdev->dev, info->fix.smem_start,
> - info->fix.smem_len);
> + info->screen_base = devm_ioremap_wc(&pdev->dev, info->fix.smem_start,
> + info->fix.smem_len);
> if (!info->screen_base) {
> framebuffer_release(info);
> return -ENODEV;
> diff --git a/include/linux/io.h b/include/linux/io.h
> index f4f42fa..c529410 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -62,6 +62,8 @@ void __iomem *devm_ioremap(struct device *dev,
> resource_size_t offset,
> unsigned long size);
> void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
> unsigned long size);
> +void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
> + unsigned long size);
> void devm_iounmap(struct device *dev, void __iomem *addr);
> int check_signature(const volatile void __iomem *io_addr,
> const unsigned char *signature, int length);
> diff --git a/lib/devres.c b/lib/devres.c
> index 8235331..34af7a9 100644
> --- a/lib/devres.c
> +++ b/lib/devres.c
> @@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device
> *dev, resource_size_t offset,
> EXPORT_SYMBOL(devm_ioremap_nocache);
>
> /**
> + * devm_ioremap_wc - Managed ioremap_wc()
> + * @dev: Generic device to remap IO address for
> + * @offset: BUS offset to map
> + * @size: Size of map
> + *
> + * Managed ioremap_wc(). Map is automatically unmapped on driver detach.
> + */
> +void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
> + unsigned long size)
> +{
> + void __iomem **ptr, *addr;
> +
> + ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr)
> + return NULL;
> +
> + addr = ioremap_wc(offset, size);
> + if (addr) {
> + *ptr = addr;
> + devres_add(dev, ptr);
> + } else
> + devres_free(ptr);
> +
> + return addr;
> +}
> +EXPORT_SYMBOL(devm_ioremap_wc);
> +
> +/**
> * devm_iounmap - Managed iounmap()
> * @dev: Generic device to unmap for
> * @addr: Address to unmap
> --
> 1.8.4
^ permalink raw reply
* Re: [PATCH v2] simplefb: print some info about the registered fb
From: Geert Uytterhoeven @ 2013-09-07 13:55 UTC (permalink / raw)
To: Tom Gundersen
Cc: Linux Fbdev development list, linux-kernel@vger.kernel.org,
Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD, David Herrmann
In-Reply-To: <1378554210-943-1-git-send-email-teg@jklm.no>
On Sat, Sep 7, 2013 at 1:43 PM, Tom Gundersen <teg@jklm.no> wrote:
> + dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%lx bytes, mapped to 0x%p\n",
> + info->fix.smem_start, (unsigned long) info->fix.smem_len,
Please drop the cast, and use 0x%x. __u32 is unsigned int everywhere (where it
matters --- we don't do 16-bit ints).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v3] simplefb: print some info about the registered fb
From: Tom Gundersen @ 2013-09-07 14:08 UTC (permalink / raw)
To: linux-fbdev
Cc: linux-kernel, tomi.valkeinen, plagnioj, Tom Gundersen,
David Herrmann
In-Reply-To: <CAMuHMdXDAA3PgbgNrccStUZGByDXuSsMG_yJMwwUWXwMvyOfsA@mail.gmail.com>
This is similar to the output printed by efifb.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
---
v2: also print smem_len, as requested by David
v3: don't cast, as requested by Geert
drivers/video/simplefb.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index a29f1c4..50cbceb 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -220,6 +220,14 @@ static int simplefb_probe(struct platform_device *pdev)
}
info->pseudo_palette = (void *)(info + 1);
+ dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
+ info->fix.smem_start, info->fix.smem_len,
+ info->screen_base);
+ dev_info(&pdev->dev, "format=%s, mode=%dx%dx%d, linelength=%d\n",
+ params.format->name,
+ info->var.xres, info->var.yres,
+ info->var.bits_per_pixel, info->fix.line_length);
+
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
--
1.8.4
^ permalink raw reply related
* Re: [PATCH 1/2] video: ARM CLCD: Add DT support
From: Sylwester Nawrocki @ 2013-09-07 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1378488201-21146-1-git-send-email-pawel.moll@arm.com>
Hi,
On 09/06/2013 07:23 PM, Pawel Moll wrote:
> This patch adds basic DT bindings for the PL11x CLCD cells
> and make their fbdev driver use them.
>
> Signed-off-by: Pawel Moll<pawel.moll@arm.com>
> ---
> .../devicetree/bindings/video/arm,pl11x.txt | 87 +++++++++
> drivers/video/Kconfig | 1 +
> drivers/video/amba-clcd.c | 214 +++++++++++++++++++++
> 3 files changed, 302 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt
>
> diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt
> new file mode 100644
> index 0000000..178aebb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
> @@ -0,0 +1,87 @@
> +* ARM PrimeCell Color LCD Controller (CLCD) PL110/PL111
nit: Shouldn't the abbreviation be CLCDC ?
> +See also Documentation/devicetree/bindings/arm/primecell.txt
> +
> +Required properties:
> +
> +- compatible: must be one of:
> + "arm,pl110", "arm,primecell"
> + "arm,pl111", "arm,primecell"
> +- reg: base address and size of the control registers block
> +- interrupts: either a single interrupt specifier representing the
> + combined interrupt output (CLCDINTR) or an array of
> + four interrupt specifiers for CLCDMBEINTR,
> + CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR; in the
> + latter case interrupt names must be specified
> + (see below)
> +- interrupt-names: when four interrupts are specified, their names:
> + "mbe", "vcomp", "lnbu", "fuf"
> + must be specified in order respective to the
> + interrupt specifiers
> +- clocks: contains phandle and clock specifier pairs for the entries
> + in the clock-names property. See
> + Documentation/devicetree/binding/clock/clock-bindings.txt
> +- clocks names: should contain "clcdclk" and "apb_pclk"
> +
> +Optional properties:
> +
> +- video-ram: phandle to a node describing specialized video memory
> + (that is *not* described in the top level "memory" node)
> + that must be used as a framebuffer, eg. due to restrictions
> + of the system interconnect; the node must contain a
> + standard reg property describing the address and the size
> + of the memory area
It seems the "specialized video memory" is described by some vendor specific
DT binding ? Is it documented ? It sounds like you are unnecessarily
repeating
the memory node details here.
Perhaps this binding/driver should use the common reserved memory bindings,
see thread http://www.spinics.net/lists/devicetree/msg02880.html
> +- max-framebuffer-size: maximum size in bytes of the framebuffer the
> + system can handle, eg. in terms of available
> + memory bandwidth
> +
> +In the simplest case of a display panel being connected directly to the
> +CLCD, it can be described in the node:
> +
> +- panel-dimensions: (optional) array of two numbers (width and height)
> + describing physical dimension in mm of the panel
> +- panel-type: (required) must be "tft" or "stn", defines panel type
> +- panel-tft-interface: (for "tft" panel type) array of 3 numbers defining
> + widths in bits of the R, G and B components
> +- panel-tft-rb-swapped: (for "tft" panel type) if present means that
> + the R& B components are swapped on the board
> +- panel-stn-color: (for "stn" panel type) if present means that
> + the panel is a colour STN display, if missing
> + is a monochrome display
> +- panel-stn-dual: (for "stn" panel type) if present means that there
> + are two STN displays connected
> +- panel-stn-4bit: (for monochrome "stn" panel) if present means
> + that the monochrome display is connected
> + via 4 bit-wide interface
Are this vendor specific or common properties ? Shouldn't those be prefixed
with the vendor name ?
Anyway I think we need an RFC to possibly standardize properties that are
common across multiple panels and have them listed in a common DT binding.
It sounds a bit disappointing that for same class devices there are being
introduced custom DT properties for each available device. For instance,
the first 3 properties above look like they could apply to various display
panels and controllers.
> +- display-timings: standard display timings sub-node, see
> + Documentation/devicetree/bindings/video/display-timing.txt
> +
> +Example:
> +
> + clcd@1f0000 {
> + compatible = "arm,pl111", "arm,primecell";
> + reg =<0x1f0000 0x1000>;
> + interrupts =<14>;
> + clocks =<&v2m_oscclk1>,<&smbclk>;
> + clock-names = "clcdclk", "apb_pclk";
> +
> + video-ram =<&v2m_vram>;
> + max-framebuffer-size =<614400>; /* 640x480 16bpp */
> +
> + panel-type = "tft";
> + panel-tft-interface =<8 8 8>;
> + display-timings {
> + native-mode =<&v2m_clcd_timing0>;
> + v2m_clcd_timing0: vga {
> + clock-frequency =<25175000>;
> + hactive =<640>;
> + hback-porch =<40>;
> + hfront-porch =<24>;
> + hsync-len =<96>;
> + vactive =<480>;
> + vback-porch =<32>;
> + vfront-porch =<11>;
> + vsync-len =<2>;
> + };
> + };
> + };
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 4cf1e1d..375bf63 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -316,6 +316,7 @@ config FB_ARMCLCD
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> + select VIDEOMODE_HELPERS if OF
> help
> This framebuffer device driver is for the ARM PrimeCell PL110
> Colour LCD controller. ARM PrimeCells provide the building
> diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
> index 0a2cce7..145ca5a 100644
> --- a/drivers/video/amba-clcd.c
> +++ b/drivers/video/amba-clcd.c
> @@ -25,6 +25,11 @@
> #include<linux/amba/clcd.h>
> #include<linux/clk.h>
> #include<linux/hardirq.h>
> +#include<linux/dma-mapping.h>
> +#include<linux/of.h>
> +#include<linux/of_address.h>
> +#include<video/of_display_timing.h>
> +#include<video/of_videomode.h>
>
> #include<asm/sizes.h>
>
> @@ -542,6 +547,212 @@ static int clcdfb_register(struct clcd_fb *fb)
> return ret;
> }
>
> +#ifdef CONFIG_OF
> +static int clcdfb_of_get_tft_panel(struct device_node *node,
> + struct clcd_panel *panel)
> +{
> + int err;
> + u32 rgb[3];
> + int r, g, b;
Couldn't these be 'unsigned int' ?
> + err = of_property_read_u32_array(node, "panel-tft-interface", rgb, 3);
> + if (err)
> + return err;
> +
> + r = rgb[0];
> + g = rgb[1];
> + b = rgb[2];
> +
> + /* Bypass pixel clock divider, data output on the falling edge */
> + panel->tim2 = TIM2_BCD | TIM2_IPC;
> +
> + /* TFT display, vert. comp. interrupt at the start of the back porch */
> + panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
> +
> + if (r>= 4&& g>= 4&& b>= 4)
> + panel->caps |= CLCD_CAP_444;
> + if (r>= 5&& g>= 5&& b>= 5)
> + panel->caps |= CLCD_CAP_5551;
> + if (r>= 5&& g>= 6&& b>= 5)
> + panel->caps |= CLCD_CAP_565;
> + if (r>= 8&& g>= 8&& b>= 8)
> + panel->caps |= CLCD_CAP_888;
> +
> + if (of_get_property(node, "panel-tft-rb-swapped", NULL))
> + panel->caps&= ~CLCD_CAP_RGB;
> + else
> + panel->caps&= ~CLCD_CAP_BGR;
> +
> + return 0;
> +}
> +
> +static int clcdfb_of_init_display(struct clcd_fb *fb)
> +{
> + struct device_node *node = fb->dev->dev.of_node;
> + u32 max_size;
> + u32 dimensions[2];
> + char *mode_name;
> + int len, err;
> + const char *panel_type;
> +
> + fb->panel = devm_kzalloc(&fb->dev->dev, sizeof(*fb->panel), GFP_KERNEL);
> + if (!fb->panel)
> + return -ENOMEM;
> +
> + err = of_get_fb_videomode(fb->dev->dev.of_node,&fb->panel->mode,
'node' could be reused here.
> + OF_USE_NATIVE_MODE);
> + if (err)
> + return err;
> +
> + len = snprintf(NULL, 0, "%ux%u@%u", fb->panel->mode.xres,
> + fb->panel->mode.yres, fb->panel->mode.refresh);
> + mode_name = devm_kzalloc(&fb->dev->dev, len + 1, GFP_KERNEL);
> + snprintf(mode_name, len + 1, "%ux%u@%u", fb->panel->mode.xres,
> + fb->panel->mode.yres, fb->panel->mode.refresh);
Don't you want to just use kasprintf() here instead and free mode_name
manually in the remove() callback ?
> + fb->panel->mode.name = mode_name;
> +
> + err = of_property_read_u32(node, "max-framebuffer-size",&max_size);
> + if (!err)
> + fb->panel->bpp = max_size / (fb->panel->mode.xres *
> + fb->panel->mode.yres) * 8;
> + else
> + fb->panel->bpp = 32;
> +
> +#ifdef CONFIG_CPU_BIG_ENDIAN
> + fb->panel->cntl |= CNTL_BEBO;
> +#endif
> +
> + if (of_property_read_u32_array(node, "panel-dimensions",
> + dimensions, 2) = 0) {
> + fb->panel->width = dimensions[0];
> + fb->panel->height = dimensions[1];
> + } else {
> + fb->panel->width = -1;
> + fb->panel->height = -1;
> + }
> +
> + panel_type = of_get_property(node, "panel-type",&len);
> + if (strncmp(panel_type, "tft", len) = 0)
> + return clcdfb_of_get_tft_panel(node, fb->panel);
> + else
> + return -EINVAL;
> +}
> +
> +static int clcdfb_of_vram_setup(struct clcd_fb *fb)
> +{
> + const __be32 *prop = of_get_property(fb->dev->dev.of_node, "video-ram",
> + NULL);
> + struct device_node *node = of_find_node_by_phandle(be32_to_cpup(prop));
This looks like open coding function of_parse_phandle(), why not just:
struct device_node *node = of_parse_phandle(fb->dev->dev.of_node,
"video-ram", 0);
?
> + u64 size;
> + int err;
> +
> + if (!node)
> + return -ENODEV;
> +
> + err = clcdfb_of_init_display(fb);
> + if (err)
> + return err;
> +
> + fb->fb.screen_base = of_iomap(node, 0);
> + if (!fb->fb.screen_base)
> + return -ENOMEM;
> +
> + fb->fb.fix.smem_start = of_translate_address(node,
> + of_get_address(node, 0,&size, NULL));
> + fb->fb.fix.smem_len = size;
> +
> + return 0;
> +}
--
Thanks,
Sylwester
^ permalink raw reply
* Re: [BUG] simplefb not showing any output
From: Alexandre Courbot @ 2013-09-09 2:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
On Sat, Sep 7, 2013 at 9:25 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
> From: David Herrmann <dh.herrmann@gmail.com>
> Date: Sat, 7 Sep 2013 14:22:01 +0200
> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
>
> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
> introduce it along the way. Note that ioremap_wc() is aliases to
> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
> architectures to either provide it or use the same alias.
>
> Reported-by: Tom Gundersen <teg@jklm.no>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
Tried this on SHIELD, and it dramatically increases performance.
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Alex.
^ permalink raw reply
* Re: [BUG] simplefb not showing any output
From: Alexandre Courbot @ 2013-09-09 2:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
On Mon, Sep 9, 2013 at 11:36 AM, Alexandre Courbot <gnurou@gmail.com> wrote:
> On Sat, Sep 7, 2013 at 9:25 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
>> From: David Herrmann <dh.herrmann@gmail.com>
>> Date: Sat, 7 Sep 2013 14:22:01 +0200
>> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
>>
>> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
>> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
>> introduce it along the way. Note that ioremap_wc() is aliases to
>> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
>> architectures to either provide it or use the same alias.
>>
>> Reported-by: Tom Gundersen <teg@jklm.no>
>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>> Cc: Stephen Warren <swarren@wwwdotorg.org>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>
> Tried this on SHIELD, and it dramatically increases performance.
>
> Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Maybe the patch should be split into two though, one that adds
devm_ioremap_wc() and another that takes advantage of it for simplefb.
Alex.
^ permalink raw reply
* [PATCH] video: au1100fb: Remove casting the return value which is a void pointer
From: Jingoo Han @ 2013-09-09 5:49 UTC (permalink / raw)
To: linux-fbdev
Casting the return value which is a void pointer is redundant.
The conversion from void pointer to any other pointer type is
guaranteed by the C programming language.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/au1100fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/au1100fb.c b/drivers/video/au1100fb.c
index a54ccdc..248abd5 100644
--- a/drivers/video/au1100fb.c
+++ b/drivers/video/au1100fb.c
@@ -588,7 +588,7 @@ int au1100fb_drv_remove(struct platform_device *dev)
if (!dev)
return -ENODEV;
- fbdev = (struct au1100fb_device *) platform_get_drvdata(dev);
+ fbdev = platform_get_drvdata(dev);
#if !defined(CONFIG_FRAMEBUFFER_CONSOLE) && defined(CONFIG_LOGO)
au1100fb_fb_blank(VESA_POWERDOWN, &fbdev->info);
--
1.7.10.4
^ permalink raw reply related
* Re: [BUG] simplefb not showing any output
From: David Herrmann @ 2013-09-09 9:46 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
Hi
On Mon, Sep 9, 2013 at 4:40 AM, Alexandre Courbot <gnurou@gmail.com> wrote:
> On Mon, Sep 9, 2013 at 11:36 AM, Alexandre Courbot <gnurou@gmail.com> wrote:
>> On Sat, Sep 7, 2013 at 9:25 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
>>> From: David Herrmann <dh.herrmann@gmail.com>
>>> Date: Sat, 7 Sep 2013 14:22:01 +0200
>>> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
>>>
>>> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
>>> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
>>> introduce it along the way. Note that ioremap_wc() is aliases to
>>> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
>>> architectures to either provide it or use the same alias.
>>>
>>> Reported-by: Tom Gundersen <teg@jklm.no>
>>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>>> Cc: Stephen Warren <swarren@wwwdotorg.org>
>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>
>> Tried this on SHIELD, and it dramatically increases performance.
>>
>> Tested-by: Alexandre Courbot <acourbot@nvidia.com>
>
> Maybe the patch should be split into two though, one that adds
> devm_ioremap_wc() and another that takes advantage of it for simplefb.
Thanks for testing! I added your tested-by. I also changed the patches
slightly to no longer use devm_*. The *_wc patch is now split off,
too. I will send it later today.
Thanks
David
^ permalink raw reply
* Re: [PATCH 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2013-09-09 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <522BAED9.4020301@gmail.com>
On Sat, 2013-09-07 at 23:55 +0100, Sylwester Nawrocki wrote:
> H --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
> > @@ -0,0 +1,87 @@
> > +* ARM PrimeCell Color LCD Controller (CLCD) PL110/PL111
>
> nit: Shouldn't the abbreviation be CLCDC ?
The commonly used acronym for this cell is CLCD. For what its worth, I
can make the line read:
ARM PrimeCell Color LCD (CLCD) Controller PL110/PL111
> > +- video-ram: phandle to a node describing specialized video memory
> > + (that is *not* described in the top level "memory" node)
> > + that must be used as a framebuffer, eg. due to restrictions
> > + of the system interconnect; the node must contain a
> > + standard reg property describing the address and the size
> > + of the memory area
>
> It seems the "specialized video memory" is described by some vendor specific
> DT binding ? Is it documented ? It sounds like you are unnecessarily
> repeating the memory node details here.
I appreciate this property being the hardest to swallow, but the problem
it is trying to solve is quite simple, really. System can be designed in
such a way that CLCD is *not* able to read data from the main memory. In
such case there will be a separate block of (usually static) memory
"next" to CLCD, which *must* be used for the framebuffer. And I've got
two choices here: to simply define an address and size, or to define a
phandle to a node with standard reg property. I'll be really grateful
for ideas how to describe the situation better.
> Perhaps this binding/driver should use the common reserved memory bindings,
> see thread http://www.spinics.net/lists/devicetree/msg02880.html
No, not really - as I said, this is *not* the main RAM of the system.
CMA doesn't even know about its existence.
> > +- max-framebuffer-size: maximum size in bytes of the framebuffer the
> > + system can handle, eg. in terms of available
> > + memory bandwidth
> > +
> > +In the simplest case of a display panel being connected directly to the
> > +CLCD, it can be described in the node:
> > +
> > +- panel-dimensions: (optional) array of two numbers (width and height)
> > + describing physical dimension in mm of the panel
> > +- panel-type: (required) must be "tft" or "stn", defines panel type
> > +- panel-tft-interface: (for "tft" panel type) array of 3 numbers defining
> > + widths in bits of the R, G and B components
> > +- panel-tft-rb-swapped: (for "tft" panel type) if present means that
> > + the R& B components are swapped on the board
> > +- panel-stn-color: (for "stn" panel type) if present means that
> > + the panel is a colour STN display, if missing
> > + is a monochrome display
> > +- panel-stn-dual: (for "stn" panel type) if present means that there
> > + are two STN displays connected
> > +- panel-stn-4bit: (for monochrome "stn" panel) if present means
> > + that the monochrome display is connected
> > + via 4 bit-wide interface
>
> Are this vendor specific or common properties ? Shouldn't those be prefixed
> with the vendor name ?
I have no answer to this question. My guts are telling me - nope. TFT is
TFT, STN is STN, nothing to do with "arm,". But I welcome other
opinions.
> Anyway I think we need an RFC to possibly standardize properties that are
> common across multiple panels and have them listed in a common DT binding.
>
> It sounds a bit disappointing that for same class devices there are being
> introduced custom DT properties for each available device. For instance,
> the first 3 properties above look like they could apply to various display
> panels and controllers.
No argument from here. The Common Display Framework was supposed to
address this issue. And the first version of this patch used it:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/63417
But you'll notice that it's been almost 10 months since the last version
of CDF saw the daylight, and Laurent seems to be too busy with other
duties to carry on with this. Additionally the KMS/DRM guys don't look
too kindly on it. The bottom line is: there are 3 different platform
suffering from lack of DT bindings for CLCD and I've got fed up with
waiting. Anyway, I've intentionally kept the panel properties in a
separate section and wrote "can be described", to keep an open way for
future "display bindings", if and when they appear.
> > +#ifdef CONFIG_OF
> > +static int clcdfb_of_get_tft_panel(struct device_node *node,
> > + struct clcd_panel *panel)
> > +{
> > + int err;
> > + u32 rgb[3];
> > + int r, g, b;
>
> Couldn't these be 'unsigned int' ?
They could indeed.
> > + err = of_property_read_u32_array(node, "panel-tft-interface", rgb, 3);
> > + if (err)
> > + return err;
> > +
> > + r = rgb[0];
> > + g = rgb[1];
> > + b = rgb[2];
> > +
> > + /* Bypass pixel clock divider, data output on the falling edge */
> > + panel->tim2 = TIM2_BCD | TIM2_IPC;
> > +
> > + /* TFT display, vert. comp. interrupt at the start of the back porch */
> > + panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
> > +
> > + if (r>= 4&& g>= 4&& b>= 4)
> > + panel->caps |= CLCD_CAP_444;
> > + if (r>= 5&& g>= 5&& b>= 5)
> > + panel->caps |= CLCD_CAP_5551;
> > + if (r>= 5&& g>= 6&& b>= 5)
> > + panel->caps |= CLCD_CAP_565;
> > + if (r>= 8&& g>= 8&& b>= 8)
> > + panel->caps |= CLCD_CAP_888;
> > +
> > + if (of_get_property(node, "panel-tft-rb-swapped", NULL))
> > + panel->caps&= ~CLCD_CAP_RGB;
> > + else
> > + panel->caps&= ~CLCD_CAP_BGR;
> > +
> > + return 0;
> > +}
> > +
> > +static int clcdfb_of_init_display(struct clcd_fb *fb)
> > +{
> > + struct device_node *node = fb->dev->dev.of_node;
> > + u32 max_size;
> > + u32 dimensions[2];
> > + char *mode_name;
> > + int len, err;
> > + const char *panel_type;
> > +
> > + fb->panel = devm_kzalloc(&fb->dev->dev, sizeof(*fb->panel), GFP_KERNEL);
> > + if (!fb->panel)
> > + return -ENOMEM;
> > +
> > + err = of_get_fb_videomode(fb->dev->dev.of_node,&fb->panel->mode,
>
> 'node' could be reused here.
Of course, well spotted.
> > + OF_USE_NATIVE_MODE);
> > + if (err)
> > + return err;
> > +
> > + len = snprintf(NULL, 0, "%ux%u@%u", fb->panel->mode.xres,
> > + fb->panel->mode.yres, fb->panel->mode.refresh);
> > + mode_name = devm_kzalloc(&fb->dev->dev, len + 1, GFP_KERNEL);
> > + snprintf(mode_name, len + 1, "%ux%u@%u", fb->panel->mode.xres,
> > + fb->panel->mode.yres, fb->panel->mode.refresh);
>
> Don't you want to just use kasprintf() here instead and free mode_name
> manually in the remove() callback ?
> > +static int clcdfb_of_vram_setup(struct clcd_fb *fb)
> > +{
> > + const __be32 *prop = of_get_property(fb->dev->dev.of_node, "video-ram",
> > + NULL);
> > + struct device_node *node = of_find_node_by_phandle(be32_to_cpup(prop));
>
> This looks like open coding function of_parse_phandle(), why not just:
>
> struct device_node *node = of_parse_phandle(fb->dev->dev.of_node,
> "video-ram", 0);
> ?
I'm not sure why did I write it like this (and it's been a while since
this happened), but you're right - it should be of_parse_phandle().
Thanks!
Pawel
^ permalink raw reply
* Re: [BUG] simplefb not showing any output
From: Stephen Warren @ 2013-09-09 15:47 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
On 09/07/2013 06:25 AM, David Herrmann wrote:
> On Sat, Sep 7, 2013 at 1:47 PM, Tom Gundersen <teg@jklm.no> wrote:
...
>> A related question: is it expected that simplefb should be
>> significantly slower than efifb, or is that something worth looking
>> into? My boot with simplefb is roughly five seconds slower than with
>> efifb. Coincidentally, I notice the same (or similar slowdown) with
>> inteldrmfb when I see the oops (but not otherwise).
>
> That is probably related to the missing write-combine tag in ioremap.
> Stephen, any objections to this attached patch?
> Tom, if this solves the speed-issues, I will send it out once I get home.
>
> Thanks
> David
>
> (Patch also attached in case of new-lines issues)
>
> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
> From: David Herrmann <dh.herrmann@gmail.com>
> Date: Sat, 7 Sep 2013 14:22:01 +0200
> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
>
> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
> introduce it along the way. Note that ioremap_wc() is aliases to
> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
> architectures to either provide it or use the same alias.
I'm fine with this so long as wc mappings are always possible, or
automatically fall back to uc if not. This certainly works on Tegra, and
I'll try to remember to test it on Raspberry Pi tonight.
^ permalink raw reply
* Re: [BUG] simplefb not showing any output
From: Stephen Warren @ 2013-09-10 2:34 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAG-2HqXhLcRX-oi4JchD=m7tZpDYyePKhWvkFU1ZZPEuqJ2JqQ@mail.gmail.com>
On 09/07/2013 06:25 AM, David Herrmann wrote:
> On Sat, Sep 7, 2013 at 1:47 PM, Tom Gundersen <teg@jklm.no> wrote:
...
>> A related question: is it expected that simplefb should be
>> significantly slower than efifb, or is that something worth looking
>> into? My boot with simplefb is roughly five seconds slower than with
>> efifb. Coincidentally, I notice the same (or similar slowdown) with
>> inteldrmfb when I see the oops (but not otherwise).
>
> That is probably related to the missing write-combine tag in ioremap.
> Stephen, any objections to this attached patch?
> Tom, if this solves the speed-issues, I will send it out once I get home.
>
> Thanks
> David
>
> (Patch also attached in case of new-lines issues)
>
> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
> From: David Herrmann <dh.herrmann@gmail.com>
> Date: Sat, 7 Sep 2013 14:22:01 +0200
> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
>
> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
> introduce it along the way. Note that ioremap_wc() is aliases to
> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
> architectures to either provide it or use the same alias.
OK, that works fine on the Raspberry Pi too, so,
Tested-by: Stephen Warren <swarren@wwwdotorg.org>
^ permalink raw reply
* [PATCH v2 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2013-09-10 10:25 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds basic DT bindings for the PL11x CLCD cells
and make their fbdev driver use them.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
Changes since v1:
- minor code cleanups as suggested by Sylwester Nawrocki
.../devicetree/bindings/video/arm,pl11x.txt | 87 +++++++++
drivers/video/Kconfig | 1 +
drivers/video/amba-clcd.c | 211 +++++++++++++++++++++
3 files changed, 299 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt
diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt
new file mode 100644
index 0000000..7eb77aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
@@ -0,0 +1,87 @@
+* ARM PrimeCell Color LCD (CLCD) Controller PL110/PL111
+
+See also Documentation/devicetree/bindings/arm/primecell.txt
+
+Required properties:
+
+- compatible: must be one of:
+ "arm,pl110", "arm,primecell"
+ "arm,pl111", "arm,primecell"
+- reg: base address and size of the control registers block
+- interrupts: either a single interrupt specifier representing the
+ combined interrupt output (CLCDINTR) or an array of
+ four interrupt specifiers for CLCDMBEINTR,
+ CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR; in the
+ latter case interrupt names must be specified
+ (see below)
+- interrupt-names: when four interrupts are specified, their names:
+ "mbe", "vcomp", "lnbu", "fuf"
+ must be specified in order respective to the
+ interrupt specifiers
+- clocks: contains phandle and clock specifier pairs for the entries
+ in the clock-names property. See
+ Documentation/devicetree/binding/clock/clock-bindings.txt
+- clocks names: should contain "clcdclk" and "apb_pclk"
+
+Optional properties:
+
+- video-ram: phandle to a node describing specialized video memory
+ (that is *not* described in the top level "memory" node)
+ that must be used as a framebuffer, eg. due to restrictions
+ of the system interconnect; the node must contain a
+ standard reg property describing the address and the size
+ of the memory area
+- max-framebuffer-size: maximum size in bytes of the framebuffer the
+ system can handle, eg. in terms of available
+ memory bandwidth
+
+In the simplest case of a display panel being connected directly to the
+CLCD, it can be described in the node:
+
+- panel-dimensions: (optional) array of two numbers (width and height)
+ describing physical dimension in mm of the panel
+- panel-type: (required) must be "tft" or "stn", defines panel type
+- panel-tft-interface: (for "tft" panel type) array of 3 numbers defining
+ widths in bits of the R, G and B components
+- panel-tft-rb-swapped: (for "tft" panel type) if present means that
+ the R & B components are swapped on the board
+- panel-stn-color: (for "stn" panel type) if present means that
+ the panel is a colour STN display, if missing
+ is a monochrome display
+- panel-stn-dual: (for "stn" panel type) if present means that there
+ are two STN displays connected
+- panel-stn-4bit: (for monochrome "stn" panel) if present means
+ that the monochrome display is connected
+ via 4 bit-wide interface
+- display-timings: standard display timings sub-node, see
+ Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+ clcd@1f0000 {
+ compatible = "arm,pl111", "arm,primecell";
+ reg = <0x1f0000 0x1000>;
+ interrupts = <14>;
+ clocks = <&v2m_oscclk1>, <&smbclk>;
+ clock-names = "clcdclk", "apb_pclk";
+
+ video-ram = <&v2m_vram>;
+ max-framebuffer-size = <614400>; /* 640x480 16bpp */
+
+ panel-type = "tft";
+ panel-tft-interface = <8 8 8>;
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
+ };
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4cf1e1d..375bf63 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -316,6 +316,7 @@ config FB_ARMCLCD
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select VIDEOMODE_HELPERS if OF
help
This framebuffer device driver is for the ARM PrimeCell PL110
Colour LCD controller. ARM PrimeCells provide the building
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..7f36964 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -25,6 +25,11 @@
#include <linux/amba/clcd.h>
#include <linux/clk.h>
#include <linux/hardirq.h>
+#include <linux/dma-mapping.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <video/of_display_timing.h>
+#include <video/of_videomode.h>
#include <asm/sizes.h>
@@ -542,6 +547,209 @@ static int clcdfb_register(struct clcd_fb *fb)
return ret;
}
+#ifdef CONFIG_OF
+static int clcdfb_of_get_tft_panel(struct device_node *node,
+ struct clcd_panel *panel)
+{
+ int err;
+ u32 rgb[3];
+
+ err = of_property_read_u32_array(node, "panel-tft-interface", rgb, 3);
+ if (err)
+ return err;
+
+ /* Bypass pixel clock divider, data output on the falling edge */
+ panel->tim2 = TIM2_BCD | TIM2_IPC;
+
+ /* TFT display, vert. comp. interrupt at the start of the back porch */
+ panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
+
+ if (rgb[0] >= 4 && rgb[1] >= 4 && rgb[2] >= 4)
+ panel->caps |= CLCD_CAP_444;
+ if (rgb[0] >= 5 && rgb[1] >= 5 && rgb[2] >= 5)
+ panel->caps |= CLCD_CAP_5551;
+ if (rgb[0] >= 5 && rgb[1] >= 6 && rgb[2] >= 5)
+ panel->caps |= CLCD_CAP_565;
+ if (rgb[0] >= 8 && rgb[1] >= 8 && rgb[2] >= 8)
+ panel->caps |= CLCD_CAP_888;
+
+ if (of_get_property(node, "panel-tft-rb-swapped", NULL))
+ panel->caps &= ~CLCD_CAP_RGB;
+ else
+ panel->caps &= ~CLCD_CAP_BGR;
+
+ return 0;
+}
+
+static int clcdfb_snprintf_mode(char *buf, int size, struct fb_videomode *mode)
+{
+ return snprintf(buf, size, "%ux%u@%u", mode->xres, mode->yres,
+ mode->refresh);
+}
+
+static int clcdfb_of_init_display(struct clcd_fb *fb)
+{
+ struct device_node *node = fb->dev->dev.of_node;
+ int err, len;
+ char *mode_name;
+ u32 max_size;
+ u32 dimensions[2];
+ const char *panel_type;
+
+ fb->panel = devm_kzalloc(&fb->dev->dev, sizeof(*fb->panel), GFP_KERNEL);
+ if (!fb->panel)
+ return -ENOMEM;
+
+ err = of_get_fb_videomode(node, &fb->panel->mode, OF_USE_NATIVE_MODE);
+ if (err)
+ return err;
+
+ len = clcdfb_snprintf_mode(NULL, 0, &fb->panel->mode);
+ mode_name = devm_kzalloc(&fb->dev->dev, len + 1, GFP_KERNEL);
+ clcdfb_snprintf_mode(mode_name, len + 1, &fb->panel->mode);
+ fb->panel->mode.name = mode_name;
+
+ err = of_property_read_u32(node, "max-framebuffer-size", &max_size);
+ if (!err)
+ fb->panel->bpp = max_size / (fb->panel->mode.xres *
+ fb->panel->mode.yres) * 8;
+ else
+ fb->panel->bpp = 32;
+
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ fb->panel->cntl |= CNTL_BEBO;
+#endif
+
+ if (of_property_read_u32_array(node, "panel-dimensions",
+ dimensions, 2) == 0) {
+ fb->panel->width = dimensions[0];
+ fb->panel->height = dimensions[1];
+ } else {
+ fb->panel->width = -1;
+ fb->panel->height = -1;
+ }
+
+ panel_type = of_get_property(node, "panel-type", &len);
+ if (strncmp(panel_type, "tft", len) == 0)
+ return clcdfb_of_get_tft_panel(node, fb->panel);
+ else
+ return -EINVAL;
+}
+
+static int clcdfb_of_vram_setup(struct clcd_fb *fb)
+{
+ struct device_node *node = of_parse_phandle(fb->dev->dev.of_node,
+ "video-ram", 0);
+ u64 size;
+ int err;
+
+ if (!node)
+ return -ENODEV;
+
+ err = clcdfb_of_init_display(fb);
+ if (err)
+ return err;
+
+ fb->fb.screen_base = of_iomap(node, 0);
+ if (!fb->fb.screen_base)
+ return -ENOMEM;
+
+ fb->fb.fix.smem_start = of_translate_address(node,
+ of_get_address(node, 0, &size, NULL));
+ fb->fb.fix.smem_len = size;
+
+ return 0;
+}
+
+static int clcdfb_of_vram_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+ unsigned long off, user_size, kernel_size;
+
+ off = vma->vm_pgoff << PAGE_SHIFT;
+ user_size = vma->vm_end - vma->vm_start;
+ kernel_size = fb->fb.fix.smem_len;
+
+ if (off >= kernel_size || user_size > (kernel_size - off))
+ return -ENXIO;
+
+ return remap_pfn_range(vma, vma->vm_start,
+ __phys_to_pfn(fb->fb.fix.smem_start) + vma->vm_pgoff,
+ user_size,
+ pgprot_writecombine(vma->vm_page_prot));
+}
+
+static void clcdfb_of_vram_remove(struct clcd_fb *fb)
+{
+ iounmap(fb->fb.screen_base);
+}
+
+static int clcdfb_of_dma_setup(struct clcd_fb *fb)
+{
+ unsigned long framesize;
+ dma_addr_t dma;
+ int err;
+
+ err = clcdfb_of_init_display(fb);
+ if (err)
+ return err;
+
+ framesize = fb->panel->mode.xres * fb->panel->mode.yres *
+ fb->panel->bpp / 8;
+ fb->fb.screen_base = dma_alloc_writecombine(&fb->dev->dev, framesize,
+ &dma, GFP_KERNEL);
+ if (!fb->fb.screen_base)
+ return -ENOMEM;
+
+ fb->fb.fix.smem_start = dma;
+ fb->fb.fix.smem_len = framesize;
+
+ return 0;
+}
+
+static int clcdfb_of_dma_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+ return dma_mmap_writecombine(&fb->dev->dev, vma, fb->fb.screen_base,
+ fb->fb.fix.smem_start, fb->fb.fix.smem_len);
+}
+
+static void clcdfb_of_dma_remove(struct clcd_fb *fb)
+{
+ dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
+ fb->fb.screen_base, fb->fb.fix.smem_start);
+}
+
+static struct clcd_board *clcdfb_of_get_board(struct amba_device *dev)
+{
+ struct clcd_board *board = devm_kzalloc(&dev->dev, sizeof(*board),
+ GFP_KERNEL);
+ struct device_node *node = dev->dev.of_node;
+
+ if (!board)
+ return NULL;
+
+ board->name = of_node_full_name(node);
+ board->caps = CLCD_CAP_ALL;
+ board->check = clcdfb_check;
+ board->decode = clcdfb_decode;
+ if (of_find_property(node, "video-ram", NULL)) {
+ board->setup = clcdfb_of_vram_setup;
+ board->mmap = clcdfb_of_vram_mmap;
+ board->remove = clcdfb_of_vram_remove;
+ } else {
+ board->setup = clcdfb_of_dma_setup;
+ board->mmap = clcdfb_of_dma_mmap;
+ board->remove = clcdfb_of_dma_remove;
+ }
+
+ return board;
+}
+#else
+static struct clcd_board *clcdfb_of_get_board(struct amba_dev *dev)
+{
+ return NULL;
+}
+#endif
+
static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
{
struct clcd_board *board = dev->dev.platform_data;
@@ -549,6 +757,9 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
int ret;
if (!board)
+ board = clcdfb_of_get_board(dev);
+
+ if (!board)
return -EINVAL;
ret = amba_request_regions(dev, NULL);
--
1.8.1.2
^ permalink raw reply related
* [PATCH v2 2/2] ARM: vexpress: Add CLCD Device Tree properties
From: Pawel Moll @ 2013-09-10 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1378808726-32535-1-git-send-email-pawel.moll@arm.com>
... for V2M-P1 motherboard CLCD (limited to 640x480 16bpp and using
dedicated video RAM bank) and for V2P-CA9 (up to 1024x768 16bpp).
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 25 +++++++++++++++++++++++--
arch/arm/boot/dts/vexpress-v2m.dtsi | 25 +++++++++++++++++++++++--
arch/arm/boot/dts/vexpress-v2p-ca9.dts | 20 ++++++++++++++++++++
3 files changed, 66 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index ac870fb..91dff88 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -41,7 +41,7 @@
bank-width = <4>;
};
- vram@2,00000000 {
+ v2m_vram: vram@2,00000000 {
compatible = "arm,vexpress-vram";
reg = <2 0x00000000 0x00800000>;
};
@@ -233,6 +233,27 @@
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
+
+ video-ram = <&v2m_vram>;
+ max-framebuffer-size = <614400>; /* 640x480 16bpp */
+
+ /* This is the best the CLCD can do here */
+ panel-type = "tft";
+ panel-tft-interface = <8 8 8>;
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
};
};
@@ -282,7 +303,7 @@
/* CLCD clock */
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 1>;
- freq-range = <23750000 63500000>;
+ freq-range = <23750000 65000000>;
#clock-cells = <0>;
clock-output-names = "v2m:oscclk1";
};
diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi
index f142036..4bc348c 100644
--- a/arch/arm/boot/dts/vexpress-v2m.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
@@ -40,7 +40,7 @@
bank-width = <4>;
};
- vram@3,00000000 {
+ v2m_vram: vram@3,00000000 {
compatible = "arm,vexpress-vram";
reg = <3 0x00000000 0x00800000>;
};
@@ -232,6 +232,27 @@
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
+
+ video-ram = <&v2m_vram>;
+ max-framebuffer-size = <614400>; /* 640x480 16bpp */
+
+ /* This is the best the CLCD can do here */
+ panel-type = "tft";
+ panel-tft-interface = <8 8 8>;
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
};
};
@@ -281,7 +302,7 @@
/* CLCD clock */
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 1>;
- freq-range = <23750000 63500000>;
+ freq-range = <23750000 65000000>;
#clock-cells = <0>;
clock-output-names = "v2m:oscclk1";
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
index 62d9b22..fbe1c998 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
@@ -73,6 +73,26 @@
interrupts = <0 44 4>;
clocks = <&oscclk1>, <&oscclk2>;
clock-names = "clcdclk", "apb_pclk";
+
+ max-framebuffer-size = <1572864>; /* 1024x768 16bpp */
+
+ /* This is the best the CLCD can do here */
+ panel-type = "tft";
+ panel-tft-interface = <8 8 8>;
+ display-timings {
+ native-mode = <&clcd_timing0>;
+ clcd_timing0: xga {
+ clock-frequency = <63500127>;
+ hactive = <1024>;
+ hback-porch = <152>;
+ hfront-porch = <48>;
+ hsync-len = <104>;
+ vactive = <768>;
+ vback-porch = <23>;
+ vfront-porch = <3>;
+ vsync-len = <4>;
+ };
+ };
};
memory-controller@100e0000 {
--
1.8.1.2
^ permalink raw reply related
* [PATCH 3/3] fbdev/ps3fb: fix section mismatch warning for ps3fb_probe
From: Vladimir Murzin @ 2013-09-10 16:46 UTC (permalink / raw)
To: linux-fbdev, cbe-oss-dev, linuxppc-dev
Cc: geoff, Vladimir Murzin, tomi.valkeinen, plagnioj
While cross-building for PPC64 I've got
WARNING: drivers/video/built-in.o(.text+0x9f9ca): Section mismatch in
reference from the function .ps3fb_probe() to th e variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix. This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
WARNING: drivers/video/built-in.o(.text+0x9f9d2): Section mismatch in
reference from the function .ps3fb_probe() to the variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix. This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
WARNING: drivers/built-in.o(.text+0xe222a): Section mismatch in
reference from the function .ps3fb_probe() to the variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix. This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
WARNING: drivers/built-in.o(.text+0xe2232): Section mismatch in
reference from the function .ps3fb_probe() to the variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix. This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
WARNING: vmlinux.o(.text+0x561d4a): Section mismatch in reference from
the function .ps3fb_probe() to the variable .init.data:ps3fb_fix The
function .ps3fb_probe() references the variable __initdata ps3fb_fix.
This is often because .ps3fb_probe lacks a __initdata annotation or
the annotation of ps3fb_fix is wrong.
Mismatch was introduced with 48c68c4f "Drivers: video: remove __dev*
attributes."
Remove __init data annotation from ps3fb_fix.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
---
drivers/video/ps3fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
index dbfe2c1..b269abd 100644
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -952,7 +952,7 @@ static struct fb_ops ps3fb_ops = {
.fb_compat_ioctl = ps3fb_ioctl
};
-static struct fb_fix_screeninfo ps3fb_fix __initdata = {
+static struct fb_fix_screeninfo ps3fb_fix = {
.id = DEVICE_NAME,
.type = FB_TYPE_PACKED_PIXELS,
.visual = FB_VISUAL_TRUECOLOR,
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox