* [PATCH v5 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2014-03-05 16: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>
---
Changes since v4:
- simplified the pads description property and made it optional
Changes since v3:
- changed wording and order of interrupt-names and interrupts
properties documentation
- changed wording of arm,pl11x,framebuffer-base property
documentation
- cleaned up binding documentation indentation
Changes since v2:
- replaced video-ram phandle with arm,pl11x,framebuffer-base
- replaced panel-* properties with arm,pl11x,panel-data-pads
- replaced max-framebuffer-size with max-memory-bandwidth
- modified clcdfb_of_init_tft_panel() to use the pads
data and take differences between PL110 and PL110 into
account
Changes since v1:
- minor code cleanups as suggested by Sylwester Nawrocki
.../devicetree/bindings/video/arm,pl11x.txt | 83 ++++++++
drivers/video/Kconfig | 1 +
drivers/video/amba-clcd.c | 219 +++++++++++++++++++++
3 files changed, 303 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..75da7b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
@@ -0,0 +1,83 @@
+* ARM PrimeCell Color LCD 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
+
+- interrupt-names: either the single entry "combined" representing a
+ combined interrupt output (CLCDINTR), or the four entries
+ "mbe", "vcomp", "lnbu", "fuf" representing the individual
+ CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts
+
+- interrupts: contains an interrupt specifier for each entry in
+ interrupt-names
+
+- clocks-names: should contain "clcdclk" and "apb_pclk"
+
+- clocks: contains phandle and clock specifier pairs for the entries
+ in the clock-names property. See
+ Documentation/devicetree/binding/clock/clock-bindings.txt
+
+Optional properties:
+
+- arm,pl11x,framebuffer-base: a pair of two 32-bit values, address and size,
+ defining the framebuffer that must be used; if not present, the
+ framebuffer may be located anywhere in the memory
+
+- arm,pl11x,tft-r0g0b0-pads: when connected to a TFT panel, an array of three
+ 32-bit values, defining the way CLD pads are wired up; this implicitly
+ defines available color modes, for example:
+ - PL111 TFT 4:4:4 panel:
+ arm,pl11x,tft-r0g0b0-pads = <4 15 20>;
+ - PL110 TFT (1:)5:5:5 panel:
+ arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
+ - PL111 TFT (1:)5:5:5 panel:
+ arm,pl11x,tft-r0g0b0-pads = <3 11 19>;
+ - PL111 TFT 5:6:5 panel:
+ arm,pl11x,tft-r0g0b0-pads = <3 10 19>;
+ - PL110 and PL111 TFT 8:8:8 panel:
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ - PL110 and PL111 TFT 8:8:8 panel, R & B components swapped:
+ arm,pl11x,tft-r0g0b0-pads = <16 8 0>;
+
+- max-memory-bandwidth: maximum bandwidth in bytes per second that the
+ cell's memory interface can handle
+
+- display-timings: standard display timings sub-node, defining possible
+ video modes of a connected panel; for details see
+ Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+ clcd@1f0000 {
+ compatible = "arm,pl111", "arm,primecell";
+ reg = <0x1f0000 0x1000>;
+ interrupt-names = "combined";
+ interrupts = <14>;
+ clock-names = "clcdclk", "apb_pclk";
+ clocks = <&v2m_oscclk1>, <&smbclk>;
+
+ arm,pl11x,framebuffer-base = <0x18000000 0x00800000>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ max-memory-bandwidth = <36864000>; /* bps, 640x480@60 16bpp */
+ 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 dade5b7..c1d25c9 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -317,6 +317,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 14d6b37..5a165dd 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -26,6 +26,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>
@@ -543,6 +548,217 @@ static int clcdfb_register(struct clcd_fb *fb)
return ret;
}
+#ifdef CONFIG_OF
+static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
+{
+ static struct {
+ unsigned int part;
+ u32 r0, g0, b0;
+ u32 caps;
+ } panels[] = {
+ { 0x110, 1, 7, 13, CLCD_CAP_5551 },
+ { 0x110, 0, 8, 16, CLCD_CAP_888 },
+ { 0x111, 4, 14, 20, CLCD_CAP_444 },
+ { 0x111, 3, 11, 19, CLCD_CAP_444 | CLCD_CAP_5551 },
+ { 0x111, 3, 10, 19, CLCD_CAP_444 | CLCD_CAP_5551 |
+ CLCD_CAP_565 },
+ { 0x111, 0, 8, 16, CLCD_CAP_444 | CLCD_CAP_5551 |
+ CLCD_CAP_565 | CLCD_CAP_888 },
+ };
+ int i;
+
+ /* Bypass pixel clock divider, data output on the falling edge */
+ fb->panel->tim2 = TIM2_BCD | TIM2_IPC;
+
+ /* TFT display, vert. comp. interrupt at the start of the back porch */
+ fb->panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
+
+ fb->panel->caps = 0;
+
+ /* Match the setup with known variants */
+ for (i = 0; i < ARRAY_SIZE(panels) && !fb->panel->caps; i++) {
+ if (amba_part(fb->dev) != panels[i].part)
+ continue;
+ if (g0 != panels[i].g0)
+ continue;
+ if (r0 = panels[i].r0 && b0 = panels[i].b0)
+ fb->panel->caps = panels[i].caps & CLCD_CAP_RGB;
+ if (r0 = panels[i].b0 && b0 = panels[i].r0)
+ fb->panel->caps = panels[i].caps & CLCD_CAP_BGR;
+ }
+
+ return fb->panel->caps ? 0 : -EINVAL;
+}
+
+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_bandwidth;
+ u32 tft_r0b0g0[3];
+
+ 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-memory-bandwidth",
+ &max_bandwidth);
+ if (!err)
+ fb->panel->bpp = 8 * max_bandwidth / (fb->panel->mode.xres *
+ fb->panel->mode.yres * fb->panel->mode.refresh);
+ else
+ fb->panel->bpp = 32;
+
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ fb->panel->cntl |= CNTL_BEBO;
+#endif
+ fb->panel->width = -1;
+ fb->panel->height = -1;
+
+ if (of_property_read_u32_array(node, "arm,pl11x,tft-r0g0b0-pads",
+ tft_r0b0g0, ARRAY_SIZE(tft_r0b0g0)) = 0)
+ return clcdfb_of_init_tft_panel(fb, tft_r0b0g0[0],
+ tft_r0b0g0[1], tft_r0b0g0[2]);
+
+ return -ENOENT;
+}
+
+static int clcdfb_of_vram_setup(struct clcd_fb *fb)
+{
+ int err;
+ u32 values[2];
+ phys_addr_t phys_base;
+ size_t size;
+
+ err = clcdfb_of_init_display(fb);
+ if (err)
+ return err;
+
+ err = of_property_read_u32_array(fb->dev->dev.of_node,
+ "arm,pl11x,framebuffer-base",
+ values, ARRAY_SIZE(values));
+ if (err)
+ return err;
+
+ phys_base = values[0];
+ size = values[1];
+
+ fb->fb.screen_base = ioremap(phys_base, size);
+ if (!fb->fb.screen_base)
+ return -ENOMEM;
+
+ fb->fb.fix.smem_start = phys_base;
+ 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, "arm,pl11x,framebuffer-base", 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_get_platdata(&dev->dev);
@@ -550,6 +766,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 = dma_set_mask_and_coherent(&dev->dev, DMA_BIT_MASK(32));
--
1.8.3.2
^ permalink raw reply related
* [PATCH v5 2/2] ARM: vexpress: Add CLCD Device Tree properties
From: Pawel Moll @ 2014-03-05 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1394036606-17784-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 | 21 ++++++++++++++++++++-
arch/arm/boot/dts/vexpress-v2m.dtsi | 21 ++++++++++++++++++++-
arch/arm/boot/dts/vexpress-v2p-ca9.dts | 18 ++++++++++++++++++
3 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index ac870fb..c95a4cb 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -230,9 +230,28 @@
clcd@1f0000 {
compatible = "arm,pl111", "arm,primecell";
reg = <0x1f0000 0x1000>;
+ interrupt-names = "combined";
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
+
+ arm,pl11x,framebuffer-base = <0x18000000 0x00800000>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ max-memory-bandwidth = <36864000>; /* Bps, 640x480@60 16bpp */
+ 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 +301,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..9224834 100644
--- a/arch/arm/boot/dts/vexpress-v2m.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
@@ -229,9 +229,28 @@
clcd@1f000 {
compatible = "arm,pl111", "arm,primecell";
reg = <0x1f000 0x1000>;
+ interrupt-names = "combined";
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
+
+ arm,pl11x,framebuffer-base = <0x4c000000 0x00800000>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ max-memory-bandwidth = <36864000>; /* Bps, 640x480@60 16bpp */
+ 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 +300,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..ed4f223 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
@@ -70,9 +70,27 @@
clcd@10020000 {
compatible = "arm,pl111", "arm,primecell";
reg = <0x10020000 0x1000>;
+ interrupt-names = "combined";
interrupts = <0 44 4>;
clocks = <&oscclk1>, <&oscclk2>;
clock-names = "clcdclk", "apb_pclk";
+
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ max-memory-bandwidth = <94371840>; /* Bps, 1024x768@60 16bpp */
+ 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.3.2
^ permalink raw reply related
* [PATCH] video: da8xx-fb: Add support for Densitron 84-0023-001T
From: jon @ 2014-03-05 18:05 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen; +Cc: linux-fbdev, linux-kernel, Jon Ringle
From: Jon Ringle <jringle@gridpoint.com>
Signed-off-by: Jon Ringle <jringle@gridpoint.com>
---
drivers/video/da8xx-fb.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index e7f5937..83c43b2 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -243,6 +243,20 @@ static struct fb_videomode known_lcd_panels[] = {
.sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
.flag = 0,
},
+ [3] = {
+ /* Densitron 84-0023-001T */
+ .name = "Densitron_LCD",
+ .xres = 320,
+ .yres = 240,
+ .pixclock = KHZ2PICOS(6400),
+ .left_margin = 0,
+ .right_margin = 0,
+ .upper_margin = 0,
+ .lower_margin = 0,
+ .hsync_len = 30,
+ .vsync_len = 3,
+ .sync = 0,
+ },
};
static bool da8xx_fb_is_raster_enabled(void)
--
1.8.5.4
^ permalink raw reply related
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Haojian Zhuang @ 2014-03-06 2:09 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
On Thu, Mar 6, 2014 at 12:12 AM, Daniel Mack <zonque@gmail.com> wrote:
> Here are some cleanups for the pxa3xx-gcu driver. Patch 3/4 is actually
> a real bugfix that is needed since the misc code doesn't set
> file->private_data for us implicitly anymore.
>
> The rest are just straight-forward cleanups.
>
> Thanks,
> Daniel
>
>
> Daniel Mack (4):
> video: pxa3xx-gcu: rename some symbols
> video: pxa3xx-gcu: pass around struct device *
> video: pxa3xx-gcu: provide an empty .open call
> video: pxa3xx-gcu: switch to devres functions
>
> drivers/video/pxa3xx-gcu.c | 191 +++++++++++++++++++--------------------------
> 1 file changed, 81 insertions(+), 110 deletions(-)
>
> --
> 1.8.5.3
>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
^ permalink raw reply
* Re: [PATCHv3 00/41] OMAPDSS: DT support v3
From: Tomi Valkeinen @ 2014-03-06 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
Hi Tony,
On 21/01/14 12:56, Tomi Valkeinen wrote:
> Hi,
>
> Here's version 3 of the DSS DT series.
Can you have a look at the arch/arm/ parts in the series and ack if
they're ok, i.e, patches 1, 2, 32.
Then there are the .dts patches, 22-30, for which I haven't been able to
get any acks. I'm not sure who I should get acks from for those, but I
don't mind adding yours if you want to give it.
The .dts patches have had minor changes compared to the ones posted
here, according to the DT bindings review comments, but nothing much has
changed.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Geert Uytterhoeven @ 2014-03-06 8:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree@vger.kernel.org, Linux Fbdev development list,
Russell King - ARM Linux, DRI Development, Andrzej Hajda,
Laurent Pinchart, linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth
In-Reply-To: <5316E31F.9050308@ti.com>
On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 28/02/14 18:23, Russell King - ARM Linux wrote:
>
>> That's rather a lot of compatible strings. Another possibility is:
>>
>> compatible = "dvi-connector";
>> analog;
>> digital;
>> single-link;
>> dual-link;
>
> I made the following changes compared to the posted version. I decided
> to leave the "single-link" out, as it's implied if "digital" is set.
>
> Tomi
>
> @@ -6,11 +6,16 @@ Required properties:
>
> Optional properties:
> - label: a symbolic name for the connector
> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> +- analog: the connector has DVI analog pins
> +- digital: the connector has DVI digital pins
> +- dual-link: the connector has pins for DVI dual-link
>
> Required nodes:
> - Video port for DVI input
>
> +Note: One (or both) of 'analog' or 'digital' must be set.
So dual-link needs both "digital" and "dual-link"?
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
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Tomi Valkeinen @ 2014-03-06 8:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King - ARM Linux, Linux Fbdev development list,
DRI Development,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Philipp Zabel, Laurent Pinchart, Sascha Hauer,
Sebastian Hesselbarth, Rob Clark, Inki Dae, Andrzej Hajda,
Tomasz Figa, Thierry Reding, Daniel Vetter
In-Reply-To: <CAMuHMdWVSfKrudBhE7FW-ZWBvMOLWjrQZvn1qZUfRt_H+P7A2w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]
On 06/03/14 10:39, Geert Uytterhoeven wrote:
> On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 28/02/14 18:23, Russell King - ARM Linux wrote:
>>
>>> That's rather a lot of compatible strings. Another possibility is:
>>>
>>> compatible = "dvi-connector";
>>> analog;
>>> digital;
>>> single-link;
>>> dual-link;
>>
>> I made the following changes compared to the posted version. I decided
>> to leave the "single-link" out, as it's implied if "digital" is set.
>>
>> Tomi
>>
>> @@ -6,11 +6,16 @@ Required properties:
>>
>> Optional properties:
>> - label: a symbolic name for the connector
>> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
>> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
>> +- analog: the connector has DVI analog pins
>> +- digital: the connector has DVI digital pins
>> +- dual-link: the connector has pins for DVI dual-link
>>
>> Required nodes:
>> - Video port for DVI input
>>
>> +Note: One (or both) of 'analog' or 'digital' must be set.
>
> So dual-link needs both "digital" and "dual-link"?
Yes. It is extra, but it felt clearer to me to have 'digital' as a
matching property for 'analog'.
Alternatively we could have three options:
analog;
digital-single-link;
digital-dual-link;
My reasoning to the format I chose was basically that when a connector
supports 'digital', it contains TMDS clock and TMDS data for link 1.
Adding dual link to that adds only TMDS data for link 2, so the second
data link is kind of an additional feature, marked with a flag.
Not a very big argument, and I'm fine with other format suggestions.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Daniel Mack @ 2014-03-06 9:09 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
On 03/06/2014 03:09 AM, Haojian Zhuang wrote:
> On Thu, Mar 6, 2014 at 12:12 AM, Daniel Mack <zonque@gmail.com> wrote:
>> Here are some cleanups for the pxa3xx-gcu driver. Patch 3/4 is actually
>> a real bugfix that is needed since the misc code doesn't set
>> file->private_data for us implicitly anymore.
>>
>> The rest are just straight-forward cleanups.
>>
>> Thanks,
>> Daniel
>>
>>
>> Daniel Mack (4):
>> video: pxa3xx-gcu: rename some symbols
>> video: pxa3xx-gcu: pass around struct device *
>> video: pxa3xx-gcu: provide an empty .open call
>> video: pxa3xx-gcu: switch to devres functions
>>
>> drivers/video/pxa3xx-gcu.c | 191 +++++++++++++++++++--------------------------
>> 1 file changed, 81 insertions(+), 110 deletions(-)
>>
> Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Thanks Haojian!
Given that this driver doesn't actually have any connection points to
the framebuffer or video subsystem (despite its location) maybe you can
just take these patches through your pxa tree? It's a PXA3xx specific
device, after all. Jean-Christophe, Tomi - any objections?
The driver is also broken since awhile, and the fact that nobody noticed
tells me that our platform is most probably the only real user.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Haojian Zhuang @ 2014-03-06 9:15 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
On Thu, Mar 6, 2014 at 5:09 PM, Daniel Mack <zonque@gmail.com> wrote:
> On 03/06/2014 03:09 AM, Haojian Zhuang wrote:
>> On Thu, Mar 6, 2014 at 12:12 AM, Daniel Mack <zonque@gmail.com> wrote:
>>> Here are some cleanups for the pxa3xx-gcu driver. Patch 3/4 is actually
>>> a real bugfix that is needed since the misc code doesn't set
>>> file->private_data for us implicitly anymore.
>>>
>>> The rest are just straight-forward cleanups.
>>>
>>> Thanks,
>>> Daniel
>>>
>>>
>>> Daniel Mack (4):
>>> video: pxa3xx-gcu: rename some symbols
>>> video: pxa3xx-gcu: pass around struct device *
>>> video: pxa3xx-gcu: provide an empty .open call
>>> video: pxa3xx-gcu: switch to devres functions
>>>
>>> drivers/video/pxa3xx-gcu.c | 191 +++++++++++++++++++--------------------------
>>> 1 file changed, 81 insertions(+), 110 deletions(-)
>>>
>
>> Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
>
> Thanks Haojian!
>
> Given that this driver doesn't actually have any connection points to
> the framebuffer or video subsystem (despite its location) maybe you can
> just take these patches through your pxa tree? It's a PXA3xx specific
> device, after all. Jean-Christophe, Tomi - any objections?
>
If Jean or Tomi acked on this series, I can merge them into my pxa tree.
Best Regards
Haojian
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Tomi Valkeinen @ 2014-03-06 9:23 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]
On 06/03/14 11:09, Daniel Mack wrote:
> On 03/06/2014 03:09 AM, Haojian Zhuang wrote:
>> On Thu, Mar 6, 2014 at 12:12 AM, Daniel Mack <zonque@gmail.com> wrote:
>>> Here are some cleanups for the pxa3xx-gcu driver. Patch 3/4 is actually
>>> a real bugfix that is needed since the misc code doesn't set
>>> file->private_data for us implicitly anymore.
>>>
>>> The rest are just straight-forward cleanups.
>>>
>>> Thanks,
>>> Daniel
>>>
>>>
>>> Daniel Mack (4):
>>> video: pxa3xx-gcu: rename some symbols
>>> video: pxa3xx-gcu: pass around struct device *
>>> video: pxa3xx-gcu: provide an empty .open call
>>> video: pxa3xx-gcu: switch to devres functions
>>>
>>> drivers/video/pxa3xx-gcu.c | 191 +++++++++++++++++++--------------------------
>>> 1 file changed, 81 insertions(+), 110 deletions(-)
>>>
>
>> Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
>
> Thanks Haojian!
>
> Given that this driver doesn't actually have any connection points to
> the framebuffer or video subsystem (despite its location) maybe you can
> just take these patches through your pxa tree? It's a PXA3xx specific
> device, after all. Jean-Christophe, Tomi - any objections?
>
> The driver is also broken since awhile, and the fact that nobody noticed
> tells me that our platform is most probably the only real user.
If these do not have any dependencies to non-fbdev patches, and nothing
else has dependencies to these patches, I'd rather take them via fbdev
tree, based on the file location. There shouldn't be any conflicts, but
just in case...
As a side note, I've got a drivers/video/ reorg patch series, possibly
headed for v3.15, which moves the pxa3xx-gcu file to
drivers/video/fbdev/. That's clearly not the right place for it, but I
think it's easier to move it along the other files, and later move it
back to drivers/video/.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: uvesafb: Remove redundant NULL check in uvesafb_remove
From: Tomi Valkeinen @ 2014-03-06 9:31 UTC (permalink / raw)
To: Wang YanQing; +Cc: plagnioj, linux-fbdev, linux-kernel, fengguang.wu
In-Reply-To: <20140305155418.GA32106@udknight>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
On 05/03/14 17:54, Wang YanQing wrote:
> Because uvesafb_par is allocated as part of fb_info in uvesafb_probe,
> so we don't need to do NULL check for both fb_info and uvesafb_par in
> uvesafb_remove.
>
> [ This patch also fix a warning report by fengguang.wu@intel.com
> "drivers/video/fbdev/uvesafb.c:1815 uvesafb_remove()
> warn: variable dereferenced before check 'par'" ]
>
> Signed-off-by: Wang YanQing <udknight@gmail.com>
> ---
> drivers/video/fbdev/uvesafb.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
> index 1f38445..18352b2 100644
> --- a/drivers/video/fbdev/uvesafb.c
> +++ b/drivers/video/fbdev/uvesafb.c
> @@ -1812,11 +1812,9 @@ static int uvesafb_remove(struct platform_device *dev)
> fb_destroy_modedb(info->monspecs.modedb);
> fb_dealloc_cmap(&info->cmap);
>
> - if (par) {
> - kfree(par->vbe_modes);
> - kfree(par->vbe_state_orig);
> - kfree(par->vbe_state_saved);
> - }
> + kfree(par->vbe_modes);
> + kfree(par->vbe_state_orig);
> + kfree(par->vbe_state_saved);
>
> framebuffer_release(info);
> }
>
Thanks, queuing for 3.15.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: uvesafb: Remove impossible code path in uvesafb_init_info
From: Tomi Valkeinen @ 2014-03-06 9:32 UTC (permalink / raw)
To: Wang YanQing; +Cc: plagnioj, fengguang.wu, linux-fbdev, linux-kernel
In-Reply-To: <20140305155619.GA32166@udknight>
[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]
On 05/03/14 17:56, Wang YanQing wrote:
> Because uvesafb_vbe_init will fail when get zero avaiable modes,
> and we have checked the return value of uvesafb_vbe_init_mode,
> so it is impossible to pass NULL as mode into uvesafb_init_info.
>
> [ This patch fix warning report by fengguang.wu@intel.com
> "drivers/video/fbdev/uvesafb.c:1509 uvesafb_init_info()
> error: we previously assumed 'mode' could be null" ]
>
> Signed-off-by: Wang YanQing <udknight@gmail.com>
> ---
> drivers/video/fbdev/uvesafb.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
> index 18352b2..509d452 100644
> --- a/drivers/video/fbdev/uvesafb.c
> +++ b/drivers/video/fbdev/uvesafb.c
> @@ -1474,12 +1474,7 @@ static void uvesafb_init_info(struct fb_info *info, struct vbe_mode_ib *mode)
> * used video mode, i.e. the minimum amount of
> * memory we need.
> */
> - if (mode != NULL) {
> - size_vmode = info->var.yres * mode->bytes_per_scan_line;
> - } else {
> - size_vmode = info->var.yres * info->var.xres *
> - ((info->var.bits_per_pixel + 7) >> 3);
> - }
> + size_vmode = info->var.yres * mode->bytes_per_scan_line;
>
> /*
> * size_total -- all video memory we have. Used for mtrr
>
Thanks, queuing for 3.15.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: uvesafb: use CONFIG_X86_PAE surround _PAGE_NX check code
From: Tomi Valkeinen @ 2014-03-06 9:56 UTC (permalink / raw)
To: Wang YanQing; +Cc: plagnioj, fengguang.wu, linux-fbdev, linux-kernel
In-Reply-To: <20140305161611.GA32461@udknight>
[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]
On 05/03/14 18:16, Wang YanQing wrote:
> Because _PAGE_NX check will always false when we don't define
> CONFIG_X86_PAE for CONFIG_X86_32, so use CONFIG_X86_PAE surround
> the check code.
>
> Although I believe "smart" compile will optimize out and generate
> the same code, but use CONFIG_X86_PAE surround check code will
> clear it and prohibit warning from static source code analyze tool.
>
> [ This patch fix warning report by fengguang.wu@intel.com
> "drivers/video/fbdev/uvesafb.c:816 uvesafb_vbe_init()
> warn: bitwise AND condition is false here" ]
>
> Signed-off-by: Wang YanQing <udknight@gmail.com>
> ---
> drivers/video/fbdev/uvesafb.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
> index 509d452..102858c 100644
> --- a/drivers/video/fbdev/uvesafb.c
> +++ b/drivers/video/fbdev/uvesafb.c
> @@ -813,6 +813,7 @@ static int uvesafb_vbe_init(struct fb_info *info)
> par->ypan = ypan;
>
> if (par->pmi_setpal || par->ypan) {
> +#ifdef CONFIG_X86_PAE
> if (__supported_pte_mask & _PAGE_NX) {
> par->pmi_setpal = par->ypan = 0;
> printk(KERN_WARNING "uvesafb: NX protection is active, "
> @@ -820,6 +821,9 @@ static int uvesafb_vbe_init(struct fb_info *info)
> } else {
> uvesafb_vbe_getpmi(task, par);
> }
> +#else
> + uvesafb_vbe_getpmi(task, par);
> +#endif
> }
I don't like this, I think this makes the code more messy, just to avoid
that warning.
And it might even be buggy. For your patch to work correctly, you need
to know the internals of _PAGE_NX, i.e. that when CONFIG_X86_PAE is not
defined, _PAGE_NX is 0. But the driver should not depend on things like
that. If _PAGE_NX is changed later, the driver will not work correctly.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Daniel Mack @ 2014-03-06 10:18 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
On 03/06/2014 10:23 AM, Tomi Valkeinen wrote:
> On 06/03/14 11:09, Daniel Mack wrote:
>> Given that this driver doesn't actually have any connection points to
>> the framebuffer or video subsystem (despite its location) maybe you can
>> just take these patches through your pxa tree? It's a PXA3xx specific
>> device, after all. Jean-Christophe, Tomi - any objections?
>>
>> The driver is also broken since awhile, and the fact that nobody noticed
>> tells me that our platform is most probably the only real user.
>
> If these do not have any dependencies to non-fbdev patches, and nothing
> else has dependencies to these patches, I'd rather take them via fbdev
> tree, based on the file location. There shouldn't be any conflicts, but
> just in case...
Ok for me. I really don't mind :)
> As a side note, I've got a drivers/video/ reorg patch series, possibly
> headed for v3.15, which moves the pxa3xx-gcu file to
> drivers/video/fbdev/.
Ah, ok. So then they really better go via your tree then.
> That's clearly not the right place for it, but I
> think it's easier to move it along the other files, and later move it
> back to drivers/video/.
Maybe it might be worth adding a subdirectory for hardware accelerators?
Because this is what the pxa3xx-gcu thing is all about really. And it's
only a tiny transport layer that passed commands between the hardware
block and a DirectFB userspace driver.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH v5 1/2] video: ARM CLCD: Add DT support
From: Tomi Valkeinen @ 2014-03-06 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1394036606-17784-1-git-send-email-pawel.moll@arm.com>
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
Hi Pawel,
On 05/03/14 18:23, Pawel Moll wrote:
> This patch adds basic DT bindings for the PL11x CLCD cells
> and make their fbdev driver use them.
Is this an old HW, and presumably there won't be new users for it? If
yes, this is probably fine. If not, you might want to look at the video
ports and endpoints, which is used by at least three not-yet-merged series:
[PATCHv3 00/41] OMAPDSS: DT support v3
[PATCH v5 00/11] imx-drm dt bindings
[RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
Using bindings like that would be more future proof, even if the current
driver doesn't use them.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Tomi Valkeinen @ 2014-03-06 10:30 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
On 06/03/14 12:18, Daniel Mack wrote:
>> As a side note, I've got a drivers/video/ reorg patch series, possibly
>> headed for v3.15, which moves the pxa3xx-gcu file to
>> drivers/video/fbdev/.
>
> Ah, ok. So then they really better go via your tree then.
Git should handle it fine, so it's not mandatory here. Still, I'd rather
have them via fbdev tree.
>> That's clearly not the right place for it, but I
>> think it's easier to move it along the other files, and later move it
>> back to drivers/video/.
>
> Maybe it might be worth adding a subdirectory for hardware accelerators?
> Because this is what the pxa3xx-gcu thing is all about really. And it's
> only a tiny transport layer that passed commands between the hardware
> block and a DirectFB userspace driver.
Well, there's drivers/gpu/. It sounds like a good match, and by "sounds"
I mean the word "gpu" sounds like a good match. I'm not sure if other
people have opinions on what drivers/gpu/ should contain, though.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: uvesafb: use CONFIG_X86_PAE surround _PAGE_NX check code
From: Wang YanQing @ 2014-03-06 10:33 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: plagnioj, fengguang.wu, linux-fbdev, linux-kernel
In-Reply-To: <53184655.2090106@ti.com>
On Thu, Mar 06, 2014 at 11:56:37AM +0200, Tomi Valkeinen wrote:
> I don't like this, I think this makes the code more messy, just to avoid
> that warning.
>
> And it might even be buggy. For your patch to work correctly, you need
> to know the internals of _PAGE_NX, i.e. that when CONFIG_X86_PAE is not
> defined, _PAGE_NX is 0. But the driver should not depend on things like
> that. If _PAGE_NX is changed later, the driver will not work correctly.
>
Very right! Thanks.
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Daniel Mack @ 2014-03-06 10:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
On 03/06/2014 11:30 AM, Tomi Valkeinen wrote:
> On 06/03/14 12:18, Daniel Mack wrote:
>>> That's clearly not the right place for it, but I
>>> think it's easier to move it along the other files, and later move it
>>> back to drivers/video/.
>>
>> Maybe it might be worth adding a subdirectory for hardware accelerators?
>> Because this is what the pxa3xx-gcu thing is all about really. And it's
>> only a tiny transport layer that passed commands between the hardware
>> block and a DirectFB userspace driver.
>
> Well, there's drivers/gpu/. It sounds like a good match, and by "sounds"
> I mean the word "gpu" sounds like a good match. I'm not sure if other
> people have opinions on what drivers/gpu/ should contain, though.
Yes, you're right. Do you think we should do that in a 2nd step maybe,
after 3.15?
Daniel
^ permalink raw reply
* Re: [PATCH 00/11] SimpleDRM & Sysfb
From: David Herrmann @ 2014-03-06 12:16 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev@vger.kernel.org, Daniel Vetter, linux-kernel,
dri-devel@lists.freedesktop.org, Ingo Molnar
In-Reply-To: <531465FF.1000201@ti.com>
Hi Tomi
On Mon, Mar 3, 2014 at 12:22 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 03/03/14 13:09, David Herrmann wrote:
>
>>> What do you think, would it be possible to keep the sysfb stuff in
>>> arch/x86, and still be able to do the rest of the stuff here? And then
>>> move the sysfs from arch/x86 to drivers/video later?
>>
>> I don't think there's any need for that. Linus does conflict
>> resolution all day long, so a short hint in Dave's pull-request (plus
>> an example merge) should be enough. Same is true for -next, I think.
>
> True, but, well, the conflict with this one is not a few lines. "git
> diff |wc -l" gives 2494 lines for the conflict. It's not really complex
> to resolve that one, though, as it's really about copying all the stuff
> into its new place.
>
> So I'm not sure if that makes Linus think "this is simple one, 30 secs
> and done" or "who the f*** sends me this crap" ;). Especially for two
> reasons:
>
> - The fb-reogranization is not very critical, and often clean-ups are
> not worth it (although I think this one is good one, of course).
> - Conflicting fbdev changes coming from another tree
>
>> And this is really just a mechanical thing, nothing hard to do. But of
>> course, it's your decision. However, keeping the code in x86 is the
>> wrong thing to do. As discussed with Ingo, the patch that extends
>
> Yes, I didn't mean keeping the code in x86 for good, but just for one
> kernel version to make merging easier.
>
>> x86/sysfb is only provided for easier backporting. The followup patch
>> immediately removes it again and adds proper video/sysfb. I'd dislike
>> splitting these just to avoid merge conflicts. I can also maintain a
>> merge-fixup branch in my tree, if anyone wants that.
>
> You can have a try at merging. If you think it's trivial, maybe it is
> and we can just let Linus handle it:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
> work/fb-reorder
Ok, I'm fine with delaying this one more merge-window. However, to
make things easier, could you pick up the two fbdev cleanups? These
are:
fbdev: efifb: add dev->remove() callback
fbdev: vesafb: add dev->remove() callback
They only add ->remove() callbacks which are never triggered currently
except with my sysfb series. But I'd like to drop both to make the
series smaller.
Thanks
David
^ permalink raw reply
* Re: [PATCH v5 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2014-03-06 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53184C2E.3000807@ti.com>
On Thu, 2014-03-06 at 10:21 +0000, Tomi Valkeinen wrote:
> Is this an old HW, and presumably there won't be new users for it? If
> yes, this is probably fine.
There is a DRM driver in the works, actually...
> If not, you might want to look at the video
> ports and endpoints, which is used by at least three not-yet-merged series:
>
> [PATCHv3 00/41] OMAPDSS: DT support v3
> [PATCH v5 00/11] imx-drm dt bindings
> [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
>
> Using bindings like that would be more future proof, even if the current
> driver doesn't use them.
... and this makes me try to get out of its way. In other words, I fully
agree with you, but I don't think this applies to this particular patch,
as I'm not even trying to represent the display pipeline. The (optional)
"display-timings" sub-node has been "borrowed" from other older drivers
and can be easily deprecated in the future, replaced by standard ones
(whatever final shape they will take :-). All other extra properties are
CLCD-specific and orthogonal.
Pawel
^ permalink raw reply
* [PATCH] lib: remove FBCON dependency for fonts
From: David Herrmann @ 2014-03-07 10:14 UTC (permalink / raw)
To: linux-kernel
Cc: Geert Uytterhoeven, linux-fbdev, Tomi Valkeinen, Andrew Morton,
Greg Kroah-Hartman, David Herrmann
Fonts don't depend on CONFIG_FRAMEBUFFER_CONSOLE at all. Remove that.
Besides, CONFIG_FONT_SUPPORT is 'select'ed anyway, so the dependencies
aren't checked by most higher-level options.
It's a relict of the times when fonts where exclusive to the VT layer and
fbcon.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
lib/fonts/Kconfig | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/lib/fonts/Kconfig b/lib/fonts/Kconfig
index 4dc1b99..0ca66a3 100644
--- a/lib/fonts/Kconfig
+++ b/lib/fonts/Kconfig
@@ -9,7 +9,6 @@ if FONT_SUPPORT
config FONTS
bool "Select compiled-in fonts"
- depends on FRAMEBUFFER_CONSOLE
help
Say Y here if you would like to use fonts other than the default
your frame buffer console usually use.
@@ -22,7 +21,6 @@ config FONTS
config FONT_8x8
bool "VGA 8x8 font" if FONTS
- depends on FRAMEBUFFER_CONSOLE
default y if !SPARC && !FONTS
help
This is the "high resolution" font for the VGA frame buffer (the one
@@ -45,7 +43,6 @@ config FONT_8x16
config FONT_6x11
bool "Mac console 6x11 font (not supported by all drivers)" if FONTS
- depends on FRAMEBUFFER_CONSOLE
default y if !SPARC && !FONTS && MAC
help
Small console font with Macintosh-style high-half glyphs. Some Mac
@@ -53,7 +50,6 @@ config FONT_6x11
config FONT_7x14
bool "console 7x14 font (not supported by all drivers)" if FONTS
- depends on FRAMEBUFFER_CONSOLE
help
Console font with characters just a bit smaller than the default.
If the standard 8x16 font is a little too big for you, say Y.
@@ -61,7 +57,6 @@ config FONT_7x14
config FONT_PEARL_8x8
bool "Pearl (old m68k) console 8x8 font" if FONTS
- depends on FRAMEBUFFER_CONSOLE
default y if !SPARC && !FONTS && AMIGA
help
Small console font with PC-style control-character and high-half
@@ -69,7 +64,6 @@ config FONT_PEARL_8x8
config FONT_ACORN_8x8
bool "Acorn console 8x8 font" if FONTS
- depends on FRAMEBUFFER_CONSOLE
default y if !SPARC && !FONTS && ARM && ARCH_ACORN
help
Small console font with PC-style control characters and high-half
@@ -81,13 +75,13 @@ config FONT_MINI_4x6
config FONT_SUN8x16
bool "Sparc console 8x16 font"
- depends on FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC)
+ depends on !SPARC && FONTS || SPARC
help
This is the high resolution console font for Sun machines. Say Y.
config FONT_SUN12x22
bool "Sparc console 12x22 font (not supported by all drivers)"
- depends on FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC)
+ depends on !SPARC && FONTS || SPARC
help
This is the high resolution console font for Sun machines with very
big letters (like the letters used in the SPARC PROM). If the
@@ -95,7 +89,6 @@ config FONT_SUN12x22
config FONT_10x18
bool "console 10x18 font (not supported by all drivers)" if FONTS
- depends on FRAMEBUFFER_CONSOLE
help
This is a high resolution console font for machines with very
big letters. It fits between the sun 12x22 and the normal 8x16 font.
--
1.9.0
^ permalink raw reply related
* Re: [PATCH] lib: remove FBCON dependency for fonts
From: Geert Uytterhoeven @ 2014-03-07 10:39 UTC (permalink / raw)
To: David Herrmann
Cc: linux-kernel@vger.kernel.org, Linux Fbdev development list,
Tomi Valkeinen, Andrew Morton, Greg Kroah-Hartman
In-Reply-To: <1394187271-5857-1-git-send-email-dh.herrmann@gmail.com>
On Fri, Mar 7, 2014 at 11:14 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Fonts don't depend on CONFIG_FRAMEBUFFER_CONSOLE at all. Remove that.
> Besides, CONFIG_FONT_SUPPORT is 'select'ed anyway, so the dependencies
> aren't checked by most higher-level options.
CONFIG_FONT_SUPPORT is indeed selected, but the other options are about
which fonts to include by default. No dependencies are bypassed by the select.
Without the "depends on FRAMEBUFFER_CONSOLE", people who don't
have FRAMEBUFFER_CONSOLE set, but have set any of these:
config EARLY_PRINTK_EFI
select FONT_SUPPORT
config VIDEO_VIVI
select FONT_SUPPORT
select FONT_8x16
config SOLO6X10
select FONT_SUPPORT
select FONT_8x16
config USB_SISUSBVGA
select FONT_SUPPORT
...
select FONT_8x16
config SGI_NEWPORT_CONSOLE
select FONT_SUPPORT
config STI_CONSOLE
select FONT_SUPPORT
will now get more (unused) fonts in their kernel image.
> It's a relict of the times when fonts where exclusive to the VT layer and
> fbcon.
>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> ---
> lib/fonts/Kconfig | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/lib/fonts/Kconfig b/lib/fonts/Kconfig
> index 4dc1b99..0ca66a3 100644
> --- a/lib/fonts/Kconfig
> +++ b/lib/fonts/Kconfig
> @@ -9,7 +9,6 @@ if FONT_SUPPORT
>
> config FONTS
> bool "Select compiled-in fonts"
> - depends on FRAMEBUFFER_CONSOLE
> help
> Say Y here if you would like to use fonts other than the default
> your frame buffer console usually use.
> @@ -22,7 +21,6 @@ config FONTS
>
> config FONT_8x8
> bool "VGA 8x8 font" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> default y if !SPARC && !FONTS
> help
> This is the "high resolution" font for the VGA frame buffer (the one
> @@ -45,7 +43,6 @@ config FONT_8x16
>
> config FONT_6x11
> bool "Mac console 6x11 font (not supported by all drivers)" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> default y if !SPARC && !FONTS && MAC
> help
> Small console font with Macintosh-style high-half glyphs. Some Mac
> @@ -53,7 +50,6 @@ config FONT_6x11
>
> config FONT_7x14
> bool "console 7x14 font (not supported by all drivers)" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> help
> Console font with characters just a bit smaller than the default.
> If the standard 8x16 font is a little too big for you, say Y.
> @@ -61,7 +57,6 @@ config FONT_7x14
>
> config FONT_PEARL_8x8
> bool "Pearl (old m68k) console 8x8 font" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> default y if !SPARC && !FONTS && AMIGA
> help
> Small console font with PC-style control-character and high-half
> @@ -69,7 +64,6 @@ config FONT_PEARL_8x8
>
> config FONT_ACORN_8x8
> bool "Acorn console 8x8 font" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> default y if !SPARC && !FONTS && ARM && ARCH_ACORN
> help
> Small console font with PC-style control characters and high-half
> @@ -81,13 +75,13 @@ config FONT_MINI_4x6
>
> config FONT_SUN8x16
> bool "Sparc console 8x16 font"
> - depends on FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC)
> + depends on !SPARC && FONTS || SPARC
> help
> This is the high resolution console font for Sun machines. Say Y.
>
> config FONT_SUN12x22
> bool "Sparc console 12x22 font (not supported by all drivers)"
> - depends on FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC)
> + depends on !SPARC && FONTS || SPARC
> help
> This is the high resolution console font for Sun machines with very
> big letters (like the letters used in the SPARC PROM). If the
> @@ -95,7 +89,6 @@ config FONT_SUN12x22
>
> config FONT_10x18
> bool "console 10x18 font (not supported by all drivers)" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> help
> This is a high resolution console font for machines with very
> big letters. It fits between the sun 12x22 and the normal 8x16 font.
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
* Re: [PATCH] lib: remove FBCON dependency for fonts
From: David Herrmann @ 2014-03-07 10:47 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-kernel@vger.kernel.org, Linux Fbdev development list,
Tomi Valkeinen, Andrew Morton, Greg Kroah-Hartman
In-Reply-To: <CAMuHMdVxE2jXQE11swi8sM251GcWcdDYpgE37pCoxpb7oF1-Rg@mail.gmail.com>
Hi
On Fri, Mar 7, 2014 at 11:39 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Mar 7, 2014 at 11:14 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> Fonts don't depend on CONFIG_FRAMEBUFFER_CONSOLE at all. Remove that.
>> Besides, CONFIG_FONT_SUPPORT is 'select'ed anyway, so the dependencies
>> aren't checked by most higher-level options.
>
> CONFIG_FONT_SUPPORT is indeed selected, but the other options are about
> which fonts to include by default. No dependencies are bypassed by the select.
Indeed, I missed that, sorry.
> Without the "depends on FRAMEBUFFER_CONSOLE", people who don't
> have FRAMEBUFFER_CONSOLE set, but have set any of these:
>
> config EARLY_PRINTK_EFI
> select FONT_SUPPORT
>
> config VIDEO_VIVI
> select FONT_SUPPORT
> select FONT_8x16
>
> config SOLO6X10
> select FONT_SUPPORT
> select FONT_8x16
>
> config USB_SISUSBVGA
> select FONT_SUPPORT
> ...
> select FONT_8x16
>
> config SGI_NEWPORT_CONSOLE
> select FONT_SUPPORT
>
> config STI_CONSOLE
> select FONT_SUPPORT
>
> will now get more (unused) fonts in their kernel image.
Why would they get more unused fonts? All those fonts are "default n"
(except for some arch-specific stuff and 8x8 and obviously 8x16). I
don't mind if we drop this, but it makes font-selection impossible if
fbcon is disabled, which is kinda unexpected.
Thanks
David
^ permalink raw reply
* Re: [PATCH] lib: remove FBCON dependency for fonts
From: Geert Uytterhoeven @ 2014-03-07 10:54 UTC (permalink / raw)
To: David Herrmann
Cc: linux-kernel@vger.kernel.org, Linux Fbdev development list,
Tomi Valkeinen, Andrew Morton, Greg Kroah-Hartman
In-Reply-To: <CANq1E4SbA5jCh+5UqyJ=oxdiYdbfkUcfrbB=jGjKRZJ-LAuaXg@mail.gmail.com>
On Fri, Mar 7, 2014 at 11:47 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> Without the "depends on FRAMEBUFFER_CONSOLE", people who don't
>> have FRAMEBUFFER_CONSOLE set, but have set any of these:
>>
>> config EARLY_PRINTK_EFI
>> select FONT_SUPPORT
>>
>> config VIDEO_VIVI
>> select FONT_SUPPORT
>> select FONT_8x16
>>
>> config SOLO6X10
>> select FONT_SUPPORT
>> select FONT_8x16
>>
>> config USB_SISUSBVGA
>> select FONT_SUPPORT
>> ...
>> select FONT_8x16
>>
>> config SGI_NEWPORT_CONSOLE
>> select FONT_SUPPORT
>>
>> config STI_CONSOLE
>> select FONT_SUPPORT
>>
>> will now get more (unused) fonts in their kernel image.
>
> Why would they get more unused fonts? All those fonts are "default n"
> (except for some arch-specific stuff and 8x8 and obviously 8x16). I
So they get the 8x8 and the arch-specific ones by default (FONTS=n).
> don't mind if we drop this, but it makes font-selection impossible if
> fbcon is disabled, which is kinda unexpected.
IIRC, drivers that "select FONT_8x16" have the font name hardcoded in
the driver, so allowing to select more fonts doesn't gain anything for them.
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
* Re: [PATCH] lib: remove FBCON dependency for fonts
From: David Herrmann @ 2014-03-07 10:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-kernel@vger.kernel.org, Linux Fbdev development list,
Tomi Valkeinen, Andrew Morton, Greg Kroah-Hartman
In-Reply-To: <CAMuHMdUheaE00m289h=x0gxf+PAbPjhhdAKATAHGgOgk9YROVQ@mail.gmail.com>
Hi
On Fri, Mar 7, 2014 at 11:54 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Mar 7, 2014 at 11:47 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>> Without the "depends on FRAMEBUFFER_CONSOLE", people who don't
>>> have FRAMEBUFFER_CONSOLE set, but have set any of these:
>>>
>>> config EARLY_PRINTK_EFI
>>> select FONT_SUPPORT
>>>
>>> config VIDEO_VIVI
>>> select FONT_SUPPORT
>>> select FONT_8x16
>>>
>>> config SOLO6X10
>>> select FONT_SUPPORT
>>> select FONT_8x16
>>>
>>> config USB_SISUSBVGA
>>> select FONT_SUPPORT
>>> ...
>>> select FONT_8x16
>>>
>>> config SGI_NEWPORT_CONSOLE
>>> select FONT_SUPPORT
>>>
>>> config STI_CONSOLE
>>> select FONT_SUPPORT
>>>
>>> will now get more (unused) fonts in their kernel image.
>>
>> Why would they get more unused fonts? All those fonts are "default n"
>> (except for some arch-specific stuff and 8x8 and obviously 8x16). I
>
> So they get the 8x8 and the arch-specific ones by default (FONTS=n).
They also get it if they enable FRAMEBUFFER_CONSOLE (which most people
do, right?). I don't understand why we want multiple fonts compiled-in
at all, but ok, that's not up to me.
>> don't mind if we drop this, but it makes font-selection impossible if
>> fbcon is disabled, which is kinda unexpected.
>
> IIRC, drivers that "select FONT_8x16" have the font name hardcoded in
> the driver, so allowing to select more fonts doesn't gain anything for them.
I don't. I use get_default_font() in the new drm_log.c patches.
Anyhow, I'm fine with 8x16, I just thought people might want to select
other fonts. But I guess it's up to them to deal with that, as long as
I use get_default_font() I guess I don't care.
Feel free to drop this patch then.
Thanks
David
^ permalink raw reply
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