* [PATCH 00/11] CLCD Nomadik+Versatile support
@ 2016-02-04 14:04 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
This is the result of some tiresome work to adopt the CLCD
driver to use device tree properly for Nomadik, Integrator,
Versatile and RealView.
The Nomadik support basically just adds some vendor data stuff
similar to what we have done for other drivers, but also add
as per-vendor .board_init() and .panel_init() hook.
These hooks are then used to handle panels on these boards.
Versatile is the most elaborate and took the most time, as it
is doing autodetection of the panel at runtime, and thus we
encode all possible panels in the DT and select the detected
panel at .panel_init() time.
The patches have been tested quite extensively on my Nomadik
NHK8815 and the ARM Integrator, Versatile, and RealView
reference designs, as well as on the more forgiving QEMU
emulation of Versatile.
Eventually I would like to have patches 1 thru 8 (those with
patches to CLCD or the DT bindings) applied through the FBDEV
subsystem, while I will take the SoC specifics (patches 9 thru 11,
and some non-included Nomadik patches) separately as it affects
multiple ARM SoC files.
Linus Walleij (11):
video: ARM CLCD: backlight support for OF
video: ARM CLCD: support DT signal inversion flags
video: ARM CLCD: support pads connected in reverse order
video: ARM CLCD: support Nomadik variant
video: ARM CLCD: add special board and panel hooks for Nomadik
Documentation/DT: add blurb for IB2 syscon to Versatile
Documentation/DT: add Versatile display bindings
video: ARM CLCD: add special panel hook for Versatiles
ARM: PB11MPCore: define a standard VGA panel
ARM: PB1176: define a standard VGA panel
ARM: versatile: move CLCD configuration to device tree
Documentation/devicetree/bindings/arm/arm-boards | 8 +
.../bindings/display/panel/epson,l2f50113t00.txt | 7 +
.../bindings/display/panel/sanyo,alr252rgt.txt | 7 +
.../bindings/display/panel/sanyo,tm38qv67a02a.txt | 7 +
.../bindings/display/panel/sharp,lq084v1dg21.txt | 7 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/arm-realview-pb1176.dts | 40 ++
arch/arm/boot/dts/arm-realview-pb11mp.dts | 19 +-
arch/arm/boot/dts/versatile-ab-ib2.dts | 20 +
arch/arm/boot/dts/versatile-ab.dts | 203 ++++++++++-
arch/arm/mach-versatile/versatile_dt.c | 162 --------
drivers/video/fbdev/Kconfig | 6 +-
drivers/video/fbdev/Makefile | 1 +
drivers/video/fbdev/amba-clcd-nomadik.c | 263 +++++++++++++
drivers/video/fbdev/amba-clcd-nomadik.h | 24 ++
drivers/video/fbdev/amba-clcd-versatile.c | 406 +++++++++++++++++++++
drivers/video/fbdev/amba-clcd-versatile.h | 17 +
drivers/video/fbdev/amba-clcd.c | 205 ++++++++++-
include/linux/amba/clcd.h | 76 +++-
20 files changed, 1279 insertions(+), 201 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt
create mode 100644 arch/arm/boot/dts/versatile-ab-ib2.dts
create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.c
create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.h
create mode 100644 drivers/video/fbdev/amba-clcd-versatile.h
--
2.4.3
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 01/11] video: ARM CLCD: backlight support for OF
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-04 14:04 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
If the device is probed from device tree, we can support
backlight. This is used with some systems such as the
ST Microelectronics Nomadik.
We have to add HAS_IOMEM to the dependencies of CLCD since
the backlight class device will now be selected, and if it
gets selected on an arch that does not have IOMEM,
compilation will fail.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/video/fbdev/Kconfig | 4 +++-
drivers/video/fbdev/amba-clcd.c | 40 ++++++++++++++++++++++++++++++++++++++++
include/linux/amba/clcd.h | 3 +++
3 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8ea45a5cd806..6dcd91237551 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -284,12 +284,14 @@ config FB_PM2_FIFO_DISCONNECT
config FB_ARMCLCD
tristate "ARM PrimeCell PL110 support"
depends on ARM || ARM64 || COMPILE_TEST
- depends on FB && ARM_AMBA
+ depends on FB && ARM_AMBA && HAS_IOMEM
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select FB_MODE_HELPERS if OF
select VIDEOMODE_HELPERS if OF
+ select BACKLIGHT_LCD_SUPPORT if OF
+ select BACKLIGHT_CLASS_DEVICE 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/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index f9ef06d0cd48..c5d1e9ca81ab 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -30,6 +30,7 @@
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_graph.h>
+#include <linux/backlight.h>
#include <video/display_timing.h>
#include <video/of_display_timing.h>
#include <video/videomode.h>
@@ -73,6 +74,11 @@ static void clcdfb_disable(struct clcd_fb *fb)
if (fb->board->disable)
fb->board->disable(fb);
+ if (fb->panel->backlight) {
+ fb->panel->backlight->props.power = FB_BLANK_POWERDOWN;
+ backlight_update_status(fb->panel->backlight);
+ }
+
val = readl(fb->regs + fb->off_cntl);
if (val & CNTL_LCDPWR) {
val &= ~CNTL_LCDPWR;
@@ -119,6 +125,14 @@ static void clcdfb_enable(struct clcd_fb *fb, u32 cntl)
writel(cntl, fb->regs + fb->off_cntl);
/*
+ * Turn on backlight
+ */
+ if (fb->panel->backlight) {
+ fb->panel->backlight->props.power = FB_BLANK_UNBLANK;
+ backlight_update_status(fb->panel->backlight);
+ }
+
+ /*
* finally, enable the interface.
*/
if (fb->board->enable)
@@ -578,6 +592,28 @@ static int clcdfb_snprintf_mode(char *buf, int size, struct fb_videomode *mode)
mode->refresh);
}
+static int clcdfb_of_get_backlight(struct device_node *endpoint,
+ struct clcd_panel *clcd_panel)
+{
+ struct device_node *panel;
+ struct device_node *backlight;
+
+ panel = of_graph_get_remote_port_parent(endpoint);
+ if (!panel)
+ return -ENODEV;
+
+ /* Look up the optional backlight phandle */
+ backlight = of_parse_phandle(panel, "backlight", 0);
+ if (backlight) {
+ clcd_panel->backlight = of_find_backlight_by_node(backlight);
+ of_node_put(backlight);
+
+ if (!clcd_panel->backlight)
+ return -EPROBE_DEFER;
+ }
+ return 0;
+}
+
static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
struct fb_videomode *mode)
{
@@ -664,6 +700,10 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
if (!endpoint)
return -ENODEV;
+ err = clcdfb_of_get_backlight(endpoint, fb->panel);
+ if (err)
+ return err;
+
err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, &fb->panel->mode);
if (err)
return err;
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index e82e3ee2c54a..e64c1ccebb76 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -93,6 +93,8 @@ enum {
CLCD_CAP_ALL = CLCD_CAP_BGR | CLCD_CAP_RGB,
};
+struct backlight_device;
+
struct clcd_panel {
struct fb_videomode mode;
signed short width; /* width in mm */
@@ -105,6 +107,7 @@ struct clcd_panel {
fixedtimings:1,
grayscale:1;
unsigned int connector;
+ struct backlight_device *backlight;
};
struct clcd_regs {
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread* [PATCH 01/11] video: ARM CLCD: backlight support for OF
@ 2016-02-04 14:04 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
If the device is probed from device tree, we can support
backlight. This is used with some systems such as the
ST Microelectronics Nomadik.
We have to add HAS_IOMEM to the dependencies of CLCD since
the backlight class device will now be selected, and if it
gets selected on an arch that does not have IOMEM,
compilation will fail.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/video/fbdev/Kconfig | 4 +++-
drivers/video/fbdev/amba-clcd.c | 40 ++++++++++++++++++++++++++++++++++++++++
include/linux/amba/clcd.h | 3 +++
3 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8ea45a5cd806..6dcd91237551 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -284,12 +284,14 @@ config FB_PM2_FIFO_DISCONNECT
config FB_ARMCLCD
tristate "ARM PrimeCell PL110 support"
depends on ARM || ARM64 || COMPILE_TEST
- depends on FB && ARM_AMBA
+ depends on FB && ARM_AMBA && HAS_IOMEM
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select FB_MODE_HELPERS if OF
select VIDEOMODE_HELPERS if OF
+ select BACKLIGHT_LCD_SUPPORT if OF
+ select BACKLIGHT_CLASS_DEVICE 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/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index f9ef06d0cd48..c5d1e9ca81ab 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -30,6 +30,7 @@
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_graph.h>
+#include <linux/backlight.h>
#include <video/display_timing.h>
#include <video/of_display_timing.h>
#include <video/videomode.h>
@@ -73,6 +74,11 @@ static void clcdfb_disable(struct clcd_fb *fb)
if (fb->board->disable)
fb->board->disable(fb);
+ if (fb->panel->backlight) {
+ fb->panel->backlight->props.power = FB_BLANK_POWERDOWN;
+ backlight_update_status(fb->panel->backlight);
+ }
+
val = readl(fb->regs + fb->off_cntl);
if (val & CNTL_LCDPWR) {
val &= ~CNTL_LCDPWR;
@@ -119,6 +125,14 @@ static void clcdfb_enable(struct clcd_fb *fb, u32 cntl)
writel(cntl, fb->regs + fb->off_cntl);
/*
+ * Turn on backlight
+ */
+ if (fb->panel->backlight) {
+ fb->panel->backlight->props.power = FB_BLANK_UNBLANK;
+ backlight_update_status(fb->panel->backlight);
+ }
+
+ /*
* finally, enable the interface.
*/
if (fb->board->enable)
@@ -578,6 +592,28 @@ static int clcdfb_snprintf_mode(char *buf, int size, struct fb_videomode *mode)
mode->refresh);
}
+static int clcdfb_of_get_backlight(struct device_node *endpoint,
+ struct clcd_panel *clcd_panel)
+{
+ struct device_node *panel;
+ struct device_node *backlight;
+
+ panel = of_graph_get_remote_port_parent(endpoint);
+ if (!panel)
+ return -ENODEV;
+
+ /* Look up the optional backlight phandle */
+ backlight = of_parse_phandle(panel, "backlight", 0);
+ if (backlight) {
+ clcd_panel->backlight = of_find_backlight_by_node(backlight);
+ of_node_put(backlight);
+
+ if (!clcd_panel->backlight)
+ return -EPROBE_DEFER;
+ }
+ return 0;
+}
+
static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
struct fb_videomode *mode)
{
@@ -664,6 +700,10 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
if (!endpoint)
return -ENODEV;
+ err = clcdfb_of_get_backlight(endpoint, fb->panel);
+ if (err)
+ return err;
+
err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, &fb->panel->mode);
if (err)
return err;
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index e82e3ee2c54a..e64c1ccebb76 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -93,6 +93,8 @@ enum {
CLCD_CAP_ALL = CLCD_CAP_BGR | CLCD_CAP_RGB,
};
+struct backlight_device;
+
struct clcd_panel {
struct fb_videomode mode;
signed short width; /* width in mm */
@@ -105,6 +107,7 @@ struct clcd_panel {
fixedtimings:1,
grayscale:1;
unsigned int connector;
+ struct backlight_device *backlight;
};
struct clcd_regs {
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread
* [PATCH 02/11] video: ARM CLCD: support DT signal inversion flags
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-04 14:04 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
The device tree bindings from display-timing.txt allows us to
specify if data enable, hsync, vsync or the pixed clock should be
inverted on the way to the display. The driver does not currently
handle this so add support for those flags as it is needed for
the Versatile Sanyo LCD display.
Note that the previous behaviour was to invert the pixel clock
for all displays, so unless the pixel clock polarity is
explicitly defined in the device tree (i.e. the timings node
has the "pixelclk-active" property) we fall back to inverting
the pixel clock. This needs some extra compatibility code.
Since the timing flags have to be set up inside the struct
clcd_panel, we need to refactor the code a bit to pass around
the panel rather than just the mode.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/video/fbdev/amba-clcd.c | 41 ++++++++++++++++++++++++++++++++++-------
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index c5d1e9ca81ab..8903a42c4122 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -567,10 +567,11 @@ static int clcdfb_register(struct clcd_fb *fb)
#ifdef CONFIG_OF
static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
- struct fb_videomode *mode)
+ struct clcd_panel *clcd_panel)
{
int err;
struct display_timing timing;
+ struct device_node *timnp;
struct videomode video;
err = of_get_display_timing(node, "panel-timing", &timing);
@@ -579,10 +580,34 @@ static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
videomode_from_timing(&timing, &video);
- err = fb_videomode_from_videomode(&video, mode);
+ err = fb_videomode_from_videomode(&video, &clcd_panel->mode);
if (err)
return err;
+ /* Set up some inversion flags */
+ timnp = of_get_child_by_name(node, "panel-timing");
+ if (timnp && of_property_read_bool(timnp, "pixelclk-active")) {
+ if (timing.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+ clcd_panel->tim2 |= TIM2_IPC;
+ } else {
+ /*
+ * To preserve backwards compatibility, the IPC (inverted
+ * pixel clock) flag needs to be set on any display that
+ * doesn't explicitly specify that the pixel clock is
+ * active on the negative edge.
+ */
+ clcd_panel->tim2 |= TIM2_IPC;
+ }
+
+ if (timing.flags & DISPLAY_FLAGS_HSYNC_LOW)
+ clcd_panel->tim2 |= TIM2_IHS;
+
+ if (timing.flags & DISPLAY_FLAGS_VSYNC_LOW)
+ clcd_panel->tim2 |= TIM2_IVS;
+
+ if (timing.flags & DISPLAY_FLAGS_DE_LOW)
+ clcd_panel->tim2 |= TIM2_IOE;
+
return 0;
}
@@ -615,10 +640,11 @@ static int clcdfb_of_get_backlight(struct device_node *endpoint,
}
static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
- struct fb_videomode *mode)
+ struct clcd_panel *clcd_panel)
{
int err;
struct device_node *panel;
+ struct fb_videomode *mode;
char *name;
int len;
@@ -628,11 +654,12 @@ static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
/* Only directly connected DPI panels supported for now */
if (of_device_is_compatible(panel, "panel-dpi"))
- err = clcdfb_of_get_dpi_panel_mode(panel, mode);
+ err = clcdfb_of_get_dpi_panel_mode(panel, clcd_panel);
else
err = -ENOENT;
if (err)
return err;
+ mode = &clcd_panel->mode;
len = clcdfb_snprintf_mode(NULL, 0, mode);
name = devm_kzalloc(dev, len + 1, GFP_KERNEL);
@@ -663,8 +690,8 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
};
int i;
- /* Bypass pixel clock divider, data output on the falling edge */
- fb->panel->tim2 = TIM2_BCD | TIM2_IPC;
+ /* Bypass pixel clock divider */
+ fb->panel->tim2 |= TIM2_BCD;
/* TFT display, vert. comp. interrupt at the start of the back porch */
fb->panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
@@ -704,7 +731,7 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
if (err)
return err;
- err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, &fb->panel->mode);
+ err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, fb->panel);
if (err)
return err;
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread* [PATCH 02/11] video: ARM CLCD: support DT signal inversion flags
@ 2016-02-04 14:04 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
The device tree bindings from display-timing.txt allows us to
specify if data enable, hsync, vsync or the pixed clock should be
inverted on the way to the display. The driver does not currently
handle this so add support for those flags as it is needed for
the Versatile Sanyo LCD display.
Note that the previous behaviour was to invert the pixel clock
for all displays, so unless the pixel clock polarity is
explicitly defined in the device tree (i.e. the timings node
has the "pixelclk-active" property) we fall back to inverting
the pixel clock. This needs some extra compatibility code.
Since the timing flags have to be set up inside the struct
clcd_panel, we need to refactor the code a bit to pass around
the panel rather than just the mode.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/video/fbdev/amba-clcd.c | 41 ++++++++++++++++++++++++++++++++++-------
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index c5d1e9ca81ab..8903a42c4122 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -567,10 +567,11 @@ static int clcdfb_register(struct clcd_fb *fb)
#ifdef CONFIG_OF
static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
- struct fb_videomode *mode)
+ struct clcd_panel *clcd_panel)
{
int err;
struct display_timing timing;
+ struct device_node *timnp;
struct videomode video;
err = of_get_display_timing(node, "panel-timing", &timing);
@@ -579,10 +580,34 @@ static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
videomode_from_timing(&timing, &video);
- err = fb_videomode_from_videomode(&video, mode);
+ err = fb_videomode_from_videomode(&video, &clcd_panel->mode);
if (err)
return err;
+ /* Set up some inversion flags */
+ timnp = of_get_child_by_name(node, "panel-timing");
+ if (timnp && of_property_read_bool(timnp, "pixelclk-active")) {
+ if (timing.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+ clcd_panel->tim2 |= TIM2_IPC;
+ } else {
+ /*
+ * To preserve backwards compatibility, the IPC (inverted
+ * pixel clock) flag needs to be set on any display that
+ * doesn't explicitly specify that the pixel clock is
+ * active on the negative edge.
+ */
+ clcd_panel->tim2 |= TIM2_IPC;
+ }
+
+ if (timing.flags & DISPLAY_FLAGS_HSYNC_LOW)
+ clcd_panel->tim2 |= TIM2_IHS;
+
+ if (timing.flags & DISPLAY_FLAGS_VSYNC_LOW)
+ clcd_panel->tim2 |= TIM2_IVS;
+
+ if (timing.flags & DISPLAY_FLAGS_DE_LOW)
+ clcd_panel->tim2 |= TIM2_IOE;
+
return 0;
}
@@ -615,10 +640,11 @@ static int clcdfb_of_get_backlight(struct device_node *endpoint,
}
static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
- struct fb_videomode *mode)
+ struct clcd_panel *clcd_panel)
{
int err;
struct device_node *panel;
+ struct fb_videomode *mode;
char *name;
int len;
@@ -628,11 +654,12 @@ static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
/* Only directly connected DPI panels supported for now */
if (of_device_is_compatible(panel, "panel-dpi"))
- err = clcdfb_of_get_dpi_panel_mode(panel, mode);
+ err = clcdfb_of_get_dpi_panel_mode(panel, clcd_panel);
else
err = -ENOENT;
if (err)
return err;
+ mode = &clcd_panel->mode;
len = clcdfb_snprintf_mode(NULL, 0, mode);
name = devm_kzalloc(dev, len + 1, GFP_KERNEL);
@@ -663,8 +690,8 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
};
int i;
- /* Bypass pixel clock divider, data output on the falling edge */
- fb->panel->tim2 = TIM2_BCD | TIM2_IPC;
+ /* Bypass pixel clock divider */
+ fb->panel->tim2 |= TIM2_BCD;
/* TFT display, vert. comp. interrupt at the start of the back porch */
fb->panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
@@ -704,7 +731,7 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
if (err)
return err;
- err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, &fb->panel->mode);
+ err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, fb->panel);
if (err)
return err;
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread* Re: [02/11] video: ARM CLCD: support DT signal inversion flags
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-17 18:10 ` Ray Jui
-1 siblings, 0 replies; 145+ messages in thread
From: Ray Jui @ 2016-02-17 18:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
A somewhat related question, how do you see the CLKSEL bit in the TIM2
register will be supported in the future? There are some cases where the
CLKSEL bit needs to be set, and therefore the "CLCDCLK" instead of
"HCLK" reference clock source is selected.
Thanks!
Ray
On 2/4/2016 6:04 AM, Linus Walleij wrote:
> The device tree bindings from display-timing.txt allows us to
> specify if data enable, hsync, vsync or the pixed clock should be
> inverted on the way to the display. The driver does not currently
> handle this so add support for those flags as it is needed for
> the Versatile Sanyo LCD display.
>
> Note that the previous behaviour was to invert the pixel clock
> for all displays, so unless the pixel clock polarity is
> explicitly defined in the device tree (i.e. the timings node
> has the "pixelclk-active" property) we fall back to inverting
> the pixel clock. This needs some extra compatibility code.
>
> Since the timing flags have to be set up inside the struct
> clcd_panel, we need to refactor the code a bit to pass around
> the panel rather than just the mode.
>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> ---
> drivers/video/fbdev/amba-clcd.c | 41 ++++++++++++++++++++++++++++++++++-------
> 1 file changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
> index c5d1e9ca81ab..8903a42c4122 100644
> --- a/drivers/video/fbdev/amba-clcd.c
> +++ b/drivers/video/fbdev/amba-clcd.c
> @@ -567,10 +567,11 @@ static int clcdfb_register(struct clcd_fb *fb)
>
> #ifdef CONFIG_OF
> static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
> - struct fb_videomode *mode)
> + struct clcd_panel *clcd_panel)
> {
> int err;
> struct display_timing timing;
> + struct device_node *timnp;
> struct videomode video;
>
> err = of_get_display_timing(node, "panel-timing", &timing);
> @@ -579,10 +580,34 @@ static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
>
> videomode_from_timing(&timing, &video);
>
> - err = fb_videomode_from_videomode(&video, mode);
> + err = fb_videomode_from_videomode(&video, &clcd_panel->mode);
> if (err)
> return err;
>
> + /* Set up some inversion flags */
> + timnp = of_get_child_by_name(node, "panel-timing");
> + if (timnp && of_property_read_bool(timnp, "pixelclk-active")) {
> + if (timing.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> + clcd_panel->tim2 |= TIM2_IPC;
> + } else {
> + /*
> + * To preserve backwards compatibility, the IPC (inverted
> + * pixel clock) flag needs to be set on any display that
> + * doesn't explicitly specify that the pixel clock is
> + * active on the negative edge.
> + */
> + clcd_panel->tim2 |= TIM2_IPC;
> + }
> +
> + if (timing.flags & DISPLAY_FLAGS_HSYNC_LOW)
> + clcd_panel->tim2 |= TIM2_IHS;
> +
> + if (timing.flags & DISPLAY_FLAGS_VSYNC_LOW)
> + clcd_panel->tim2 |= TIM2_IVS;
> +
> + if (timing.flags & DISPLAY_FLAGS_DE_LOW)
> + clcd_panel->tim2 |= TIM2_IOE;
> +
> return 0;
> }
>
> @@ -615,10 +640,11 @@ static int clcdfb_of_get_backlight(struct device_node *endpoint,
> }
>
> static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
> - struct fb_videomode *mode)
> + struct clcd_panel *clcd_panel)
> {
> int err;
> struct device_node *panel;
> + struct fb_videomode *mode;
> char *name;
> int len;
>
> @@ -628,11 +654,12 @@ static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
>
> /* Only directly connected DPI panels supported for now */
> if (of_device_is_compatible(panel, "panel-dpi"))
> - err = clcdfb_of_get_dpi_panel_mode(panel, mode);
> + err = clcdfb_of_get_dpi_panel_mode(panel, clcd_panel);
> else
> err = -ENOENT;
> if (err)
> return err;
> + mode = &clcd_panel->mode;
>
> len = clcdfb_snprintf_mode(NULL, 0, mode);
> name = devm_kzalloc(dev, len + 1, GFP_KERNEL);
> @@ -663,8 +690,8 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
> };
> int i;
>
> - /* Bypass pixel clock divider, data output on the falling edge */
> - fb->panel->tim2 = TIM2_BCD | TIM2_IPC;
> + /* Bypass pixel clock divider */
> + fb->panel->tim2 |= TIM2_BCD;
>
> /* TFT display, vert. comp. interrupt at the start of the back porch */
> fb->panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
> @@ -704,7 +731,7 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
> if (err)
> return err;
>
> - err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, &fb->panel->mode);
> + err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, fb->panel);
> if (err)
> return err;
>
>
^ permalink raw reply [flat|nested] 145+ messages in thread* [02/11] video: ARM CLCD: support DT signal inversion flags
@ 2016-02-17 18:10 ` Ray Jui
0 siblings, 0 replies; 145+ messages in thread
From: Ray Jui @ 2016-02-17 18:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
A somewhat related question, how do you see the CLKSEL bit in the TIM2
register will be supported in the future? There are some cases where the
CLKSEL bit needs to be set, and therefore the "CLCDCLK" instead of
"HCLK" reference clock source is selected.
Thanks!
Ray
On 2/4/2016 6:04 AM, Linus Walleij wrote:
> The device tree bindings from display-timing.txt allows us to
> specify if data enable, hsync, vsync or the pixed clock should be
> inverted on the way to the display. The driver does not currently
> handle this so add support for those flags as it is needed for
> the Versatile Sanyo LCD display.
>
> Note that the previous behaviour was to invert the pixel clock
> for all displays, so unless the pixel clock polarity is
> explicitly defined in the device tree (i.e. the timings node
> has the "pixelclk-active" property) we fall back to inverting
> the pixel clock. This needs some extra compatibility code.
>
> Since the timing flags have to be set up inside the struct
> clcd_panel, we need to refactor the code a bit to pass around
> the panel rather than just the mode.
>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> ---
> drivers/video/fbdev/amba-clcd.c | 41 ++++++++++++++++++++++++++++++++++-------
> 1 file changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
> index c5d1e9ca81ab..8903a42c4122 100644
> --- a/drivers/video/fbdev/amba-clcd.c
> +++ b/drivers/video/fbdev/amba-clcd.c
> @@ -567,10 +567,11 @@ static int clcdfb_register(struct clcd_fb *fb)
>
> #ifdef CONFIG_OF
> static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
> - struct fb_videomode *mode)
> + struct clcd_panel *clcd_panel)
> {
> int err;
> struct display_timing timing;
> + struct device_node *timnp;
> struct videomode video;
>
> err = of_get_display_timing(node, "panel-timing", &timing);
> @@ -579,10 +580,34 @@ static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
>
> videomode_from_timing(&timing, &video);
>
> - err = fb_videomode_from_videomode(&video, mode);
> + err = fb_videomode_from_videomode(&video, &clcd_panel->mode);
> if (err)
> return err;
>
> + /* Set up some inversion flags */
> + timnp = of_get_child_by_name(node, "panel-timing");
> + if (timnp && of_property_read_bool(timnp, "pixelclk-active")) {
> + if (timing.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> + clcd_panel->tim2 |= TIM2_IPC;
> + } else {
> + /*
> + * To preserve backwards compatibility, the IPC (inverted
> + * pixel clock) flag needs to be set on any display that
> + * doesn't explicitly specify that the pixel clock is
> + * active on the negative edge.
> + */
> + clcd_panel->tim2 |= TIM2_IPC;
> + }
> +
> + if (timing.flags & DISPLAY_FLAGS_HSYNC_LOW)
> + clcd_panel->tim2 |= TIM2_IHS;
> +
> + if (timing.flags & DISPLAY_FLAGS_VSYNC_LOW)
> + clcd_panel->tim2 |= TIM2_IVS;
> +
> + if (timing.flags & DISPLAY_FLAGS_DE_LOW)
> + clcd_panel->tim2 |= TIM2_IOE;
> +
> return 0;
> }
>
> @@ -615,10 +640,11 @@ static int clcdfb_of_get_backlight(struct device_node *endpoint,
> }
>
> static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
> - struct fb_videomode *mode)
> + struct clcd_panel *clcd_panel)
> {
> int err;
> struct device_node *panel;
> + struct fb_videomode *mode;
> char *name;
> int len;
>
> @@ -628,11 +654,12 @@ static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
>
> /* Only directly connected DPI panels supported for now */
> if (of_device_is_compatible(panel, "panel-dpi"))
> - err = clcdfb_of_get_dpi_panel_mode(panel, mode);
> + err = clcdfb_of_get_dpi_panel_mode(panel, clcd_panel);
> else
> err = -ENOENT;
> if (err)
> return err;
> + mode = &clcd_panel->mode;
>
> len = clcdfb_snprintf_mode(NULL, 0, mode);
> name = devm_kzalloc(dev, len + 1, GFP_KERNEL);
> @@ -663,8 +690,8 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
> };
> int i;
>
> - /* Bypass pixel clock divider, data output on the falling edge */
> - fb->panel->tim2 = TIM2_BCD | TIM2_IPC;
> + /* Bypass pixel clock divider */
> + fb->panel->tim2 |= TIM2_BCD;
>
> /* TFT display, vert. comp. interrupt at the start of the back porch */
> fb->panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
> @@ -704,7 +731,7 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
> if (err)
> return err;
>
> - err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, &fb->panel->mode);
> + err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, fb->panel);
> if (err)
> return err;
>
>
^ permalink raw reply [flat|nested] 145+ messages in thread* Re: [02/11] video: ARM CLCD: support DT signal inversion flags
2016-02-17 18:10 ` Ray Jui
@ 2016-02-19 8:46 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-19 8:46 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 17, 2016 at 7:10 PM, Ray Jui <ray.jui@broadcom.com> wrote:
> A somewhat related question, how do you see the CLKSEL bit in the TIM2
> register will be supported in the future? There are some cases where the
> CLKSEL bit needs to be set, and therefore the "CLCDCLK" instead of "HCLK"
> reference clock source is selected.
I think it's very simple:
The DT node usually looks like so:
display@10120000 {
compatible = "arm,pl110", "arm,primecell";
(...)
clocks = <&oscclk4>, <&pclk>;
clock-names = "clcd", "apb_pclk";
Just add a custom attribute pointing to the
reference clock in this array:
clcd-reference-clock = <0>;
If this is set to <1> "apb_pclk" (i.e. HCLK) is
the reference, and that bit in TIM2 gets set.
Do you have a system that needs this?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread* [02/11] video: ARM CLCD: support DT signal inversion flags
@ 2016-02-19 8:46 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-19 8:46 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 17, 2016 at 7:10 PM, Ray Jui <ray.jui@broadcom.com> wrote:
> A somewhat related question, how do you see the CLKSEL bit in the TIM2
> register will be supported in the future? There are some cases where the
> CLKSEL bit needs to be set, and therefore the "CLCDCLK" instead of "HCLK"
> reference clock source is selected.
I think it's very simple:
The DT node usually looks like so:
display at 10120000 {
compatible = "arm,pl110", "arm,primecell";
(...)
clocks = <&oscclk4>, <&pclk>;
clock-names = "clcd", "apb_pclk";
Just add a custom attribute pointing to the
reference clock in this array:
clcd-reference-clock = <0>;
If this is set to <1> "apb_pclk" (i.e. HCLK) is
the reference, and that bit in TIM2 gets set.
Do you have a system that needs this?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread* Re: [02/11] video: ARM CLCD: support DT signal inversion flags
2016-02-19 8:46 ` Linus Walleij
@ 2016-02-20 1:23 ` Ray Jui
-1 siblings, 0 replies; 145+ messages in thread
From: Ray Jui @ 2016-02-20 1:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
On 2/19/2016 12:46 AM, Linus Walleij wrote:
> On Wed, Feb 17, 2016 at 7:10 PM, Ray Jui <ray.jui@broadcom.com> wrote:
>
>> A somewhat related question, how do you see the CLKSEL bit in the TIM2
>> register will be supported in the future? There are some cases where the
>> CLKSEL bit needs to be set, and therefore the "CLCDCLK" instead of "HCLK"
>> reference clock source is selected.
>
> I think it's very simple:
>
> The DT node usually looks like so:
>
> display@10120000 {
> compatible = "arm,pl110", "arm,primecell";
> (...)
> clocks = <&oscclk4>, <&pclk>;
> clock-names = "clcd", "apb_pclk";
>
> Just add a custom attribute pointing to the
> reference clock in this array:
>
> clcd-reference-clock = <0>;
>
> If this is set to <1> "apb_pclk" (i.e. HCLK) is
> the reference, and that bit in TIM2 gets set.
This looks good!
>
> Do you have a system that needs this?
>
Yah, we have a system (Cygnus) that can either use the HCLK, or an
external clock generated from a PLL. To get certain pixel clock
frequencies (depending on the LCD panel we use), we need to use the
external clock source with the PLL configured to a particular VCO frequency.
We have not enabled full LCD/video support on that platform in the
mainline kernel, but we'll eventually get to it.
> Yours,
> Linus Walleij
>
Thanks,
Ray
^ permalink raw reply [flat|nested] 145+ messages in thread* [02/11] video: ARM CLCD: support DT signal inversion flags
@ 2016-02-20 1:23 ` Ray Jui
0 siblings, 0 replies; 145+ messages in thread
From: Ray Jui @ 2016-02-20 1:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
On 2/19/2016 12:46 AM, Linus Walleij wrote:
> On Wed, Feb 17, 2016 at 7:10 PM, Ray Jui <ray.jui@broadcom.com> wrote:
>
>> A somewhat related question, how do you see the CLKSEL bit in the TIM2
>> register will be supported in the future? There are some cases where the
>> CLKSEL bit needs to be set, and therefore the "CLCDCLK" instead of "HCLK"
>> reference clock source is selected.
>
> I think it's very simple:
>
> The DT node usually looks like so:
>
> display at 10120000 {
> compatible = "arm,pl110", "arm,primecell";
> (...)
> clocks = <&oscclk4>, <&pclk>;
> clock-names = "clcd", "apb_pclk";
>
> Just add a custom attribute pointing to the
> reference clock in this array:
>
> clcd-reference-clock = <0>;
>
> If this is set to <1> "apb_pclk" (i.e. HCLK) is
> the reference, and that bit in TIM2 gets set.
This looks good!
>
> Do you have a system that needs this?
>
Yah, we have a system (Cygnus) that can either use the HCLK, or an
external clock generated from a PLL. To get certain pixel clock
frequencies (depending on the LCD panel we use), we need to use the
external clock source with the PLL configured to a particular VCO frequency.
We have not enabled full LCD/video support on that platform in the
mainline kernel, but we'll eventually get to it.
> Yours,
> Linus Walleij
>
Thanks,
Ray
^ permalink raw reply [flat|nested] 145+ messages in thread* Re: [02/11] video: ARM CLCD: support DT signal inversion flags
2016-02-20 1:23 ` Ray Jui
@ 2016-02-20 11:46 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-20 11:46 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Feb 20, 2016 at 2:23 AM, Ray Jui <ray.jui@broadcom.com> wrote:
>> Do you have a system that needs this?
>
> Yah, we have a system (Cygnus) that can either use the HCLK, or an external
> clock generated from a PLL. To get certain pixel clock frequencies
> (depending on the LCD panel we use), we need to use the external clock
> source with the PLL configured to a particular VCO frequency.
>
> We have not enabled full LCD/video support on that platform in the mainline
> kernel, but we'll eventually get to it.
OK I hope to finish these patches soon so you have some nice stuff
to build upon. I guess it will need the same per-vendor plug-in that
I supplied for the ARMs and the Nomadik.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [02/11] video: ARM CLCD: support DT signal inversion flags
@ 2016-02-20 11:46 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-20 11:46 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Feb 20, 2016 at 2:23 AM, Ray Jui <ray.jui@broadcom.com> wrote:
>> Do you have a system that needs this?
>
> Yah, we have a system (Cygnus) that can either use the HCLK, or an external
> clock generated from a PLL. To get certain pixel clock frequencies
> (depending on the LCD panel we use), we need to use the external clock
> source with the PLL configured to a particular VCO frequency.
>
> We have not enabled full LCD/video support on that platform in the mainline
> kernel, but we'll eventually get to it.
OK I hope to finish these patches soon so you have some nice stuff
to build upon. I guess it will need the same per-vendor plug-in that
I supplied for the ARMs and the Nomadik.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 03/11] video: ARM CLCD: support pads connected in reverse order
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-04 14:04 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
There are CLCDs connected with the pads in BGR rather than RGB
order. It really doesn't matter since the CLCD has a flag and
a bit to switch the position of the RGB and BGR components.
This is needed to put something logical into the
arm,pl11x,tft-r0g0b0-pads property of the device tree on the
Nomadik which will then be <16 8 0>.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/video/fbdev/amba-clcd.c | 8 ++++++++
include/linux/amba/clcd.h | 31 ++++++++++++++++++++++++-------
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 8903a42c4122..9a631a8e2c04 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -681,6 +681,7 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
} panels[] = {
{ 0x110, 1, 7, 13, CLCD_CAP_5551 },
{ 0x110, 0, 8, 16, CLCD_CAP_888 },
+ { 0x110, 16, 8, 0, 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 |
@@ -708,6 +709,13 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
fb->panel->caps = panels[i].caps;
}
+ /*
+ * If we actually physically connected the R lines to B and
+ * vice versa
+ */
+ if (r0 != 0 && b0 = 0)
+ fb->panel->bgr_connection = true;
+
return fb->panel->caps ? 0 : -EINVAL;
}
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index e64c1ccebb76..c60f32e23a83 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -108,6 +108,12 @@ struct clcd_panel {
grayscale:1;
unsigned int connector;
struct backlight_device *backlight;
+ /*
+ * If the B/R lines are switched between the CLCD
+ * and the panel we need to know this and not try to
+ * compensate with the BGR bit in the control register.
+ */
+ bool bgr_connection;
};
struct clcd_regs {
@@ -234,16 +240,27 @@ static inline void clcdfb_decode(struct clcd_fb *fb, struct clcd_regs *regs)
if (var->grayscale)
val |= CNTL_LCDBW;
- if (fb->panel->caps && fb->board->caps &&
- var->bits_per_pixel >= 16) {
+ if (fb->panel->caps && fb->board->caps && var->bits_per_pixel >= 16) {
/*
* if board and panel supply capabilities, we can support
- * changing BGR/RGB depending on supplied parameters
+ * changing BGR/RGB depending on supplied parameters. Here
+ * we switch to what the framebuffer is providing if need
+ * be, so if the framebuffer is BGR but the display connection
+ * is RGB (first case) we switch it around. Vice versa mutatis
+ * mutandis if the framebuffer is RGB but the display connection
+ * is BGR, we flip it around.
*/
- if (var->red.offset = 0)
- val &= ~CNTL_BGR;
- else
- val |= CNTL_BGR;
+ if (!fb->panel->bgr_connection) {
+ if (var->red.offset = 0)
+ val &= ~CNTL_BGR;
+ else
+ val |= CNTL_BGR;
+ } else {
+ if (var->blue.offset = 0)
+ val &= ~CNTL_BGR;
+ else
+ val |= CNTL_BGR;
+ }
}
switch (var->bits_per_pixel) {
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread* [PATCH 03/11] video: ARM CLCD: support pads connected in reverse order
@ 2016-02-04 14:04 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
There are CLCDs connected with the pads in BGR rather than RGB
order. It really doesn't matter since the CLCD has a flag and
a bit to switch the position of the RGB and BGR components.
This is needed to put something logical into the
arm,pl11x,tft-r0g0b0-pads property of the device tree on the
Nomadik which will then be <16 8 0>.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/video/fbdev/amba-clcd.c | 8 ++++++++
include/linux/amba/clcd.h | 31 ++++++++++++++++++++++++-------
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 8903a42c4122..9a631a8e2c04 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -681,6 +681,7 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
} panels[] = {
{ 0x110, 1, 7, 13, CLCD_CAP_5551 },
{ 0x110, 0, 8, 16, CLCD_CAP_888 },
+ { 0x110, 16, 8, 0, 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 |
@@ -708,6 +709,13 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
fb->panel->caps = panels[i].caps;
}
+ /*
+ * If we actually physically connected the R lines to B and
+ * vice versa
+ */
+ if (r0 != 0 && b0 == 0)
+ fb->panel->bgr_connection = true;
+
return fb->panel->caps ? 0 : -EINVAL;
}
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index e64c1ccebb76..c60f32e23a83 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -108,6 +108,12 @@ struct clcd_panel {
grayscale:1;
unsigned int connector;
struct backlight_device *backlight;
+ /*
+ * If the B/R lines are switched between the CLCD
+ * and the panel we need to know this and not try to
+ * compensate with the BGR bit in the control register.
+ */
+ bool bgr_connection;
};
struct clcd_regs {
@@ -234,16 +240,27 @@ static inline void clcdfb_decode(struct clcd_fb *fb, struct clcd_regs *regs)
if (var->grayscale)
val |= CNTL_LCDBW;
- if (fb->panel->caps && fb->board->caps &&
- var->bits_per_pixel >= 16) {
+ if (fb->panel->caps && fb->board->caps && var->bits_per_pixel >= 16) {
/*
* if board and panel supply capabilities, we can support
- * changing BGR/RGB depending on supplied parameters
+ * changing BGR/RGB depending on supplied parameters. Here
+ * we switch to what the framebuffer is providing if need
+ * be, so if the framebuffer is BGR but the display connection
+ * is RGB (first case) we switch it around. Vice versa mutatis
+ * mutandis if the framebuffer is RGB but the display connection
+ * is BGR, we flip it around.
*/
- if (var->red.offset == 0)
- val &= ~CNTL_BGR;
- else
- val |= CNTL_BGR;
+ if (!fb->panel->bgr_connection) {
+ if (var->red.offset == 0)
+ val &= ~CNTL_BGR;
+ else
+ val |= CNTL_BGR;
+ } else {
+ if (var->blue.offset == 0)
+ val &= ~CNTL_BGR;
+ else
+ val |= CNTL_BGR;
+ }
}
switch (var->bits_per_pixel) {
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread
* [PATCH 04/11] video: ARM CLCD: support Nomadik variant
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-04 14:04 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
The Nomadik variant has a few special quirks that need to be respected
to make the driver work:
- The block need to be clocked during writing of the TIMn registers
or the bus will stall.
- Special bits in the control register select how many of the output
display lines get activated.
- Special bits in the control register select how to manage the
different 565 and 5551 modes.
- There is a packed 24bit graphics mode, i.e 888 pixels can be stored
in memory is three consecutive bytes, not evenly aligned to a 32bit
word.
This patch uses the vendor data pointer from the AMBA matching mechanism
to track the quirks for this variant, and adds two hooks that variants
can use to initialize boards and panels during start-up. These will
later be used to adopt a Nomadik board profile.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/video/fbdev/amba-clcd.c | 108 ++++++++++++++++++++++++++++++++++++----
include/linux/amba/clcd.h | 42 ++++++++++++++++
2 files changed, 140 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 9a631a8e2c04..77fb50e00670 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -227,6 +227,15 @@ clcdfb_set_bitfields(struct clcd_fb *fb, struct fb_var_screeninfo *var)
var->blue.length = 4;
}
break;
+ case 24:
+ if (fb->vendor->packed_24_bit_pixels) {
+ var->red.length = 8;
+ var->green.length = 8;
+ var->blue.length = 8;
+ } else {
+ ret = -EINVAL;
+ }
+ break;
case 32:
/* If we can't do 888, reject */
caps &= CLCD_CAP_888;
@@ -313,6 +322,12 @@ static int clcdfb_set_par(struct fb_info *info)
clcdfb_disable(fb);
+ /* Some variants must be clocked here */
+ if (fb->vendor->clock_timregs && !fb->clk_enabled) {
+ fb->clk_enabled = true;
+ clk_enable(fb->clk);
+ }
+
writel(regs.tim0, fb->regs + CLCD_TIM0);
writel(regs.tim1, fb->regs + CLCD_TIM1);
writel(regs.tim2, fb->regs + CLCD_TIM2);
@@ -716,12 +731,48 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
if (r0 != 0 && b0 = 0)
fb->panel->bgr_connection = true;
+ if (fb->panel->caps && fb->vendor->st_bitmux_control) {
+ /*
+ * Set up the special bits for the Nomadik control register
+ * (other platforms tend to do this through an external
+ * register).
+ */
+
+ /* Offset of the highest used color */
+ int maxoff = max3(r0, g0, b0);
+ /* Most significant bit out, highest used bit */
+ int msb = 0;
+
+ if (fb->panel->caps & CLCD_CAP_888) {
+ msb = maxoff + 8 - 1;
+ } else if (fb->panel->caps & CLCD_CAP_565) {
+ msb = maxoff + 5 - 1;
+ fb->panel->cntl |= CNTL_ST_1XBPP_565;
+ } else if (fb->panel->caps & CLCD_CAP_5551) {
+ msb = maxoff + 5 - 1;
+ fb->panel->cntl |= CNTL_ST_1XBPP_5551;
+ } else if (fb->panel->caps & CLCD_CAP_444) {
+ msb = maxoff + 4 - 1;
+ fb->panel->cntl |= CNTL_ST_1XBPP_444;
+ }
+
+ /* Send out as many bits as we need */
+ if (msb > 17)
+ fb->panel->cntl |= CNTL_ST_CDWID_24;
+ else if (msb > 15)
+ fb->panel->cntl |= CNTL_ST_CDWID_18;
+ else if (msb > 11)
+ fb->panel->cntl |= CNTL_ST_CDWID_16;
+ else
+ fb->panel->cntl |= CNTL_ST_CDWID_12;
+ }
+
return fb->panel->caps ? 0 : -EINVAL;
}
static int clcdfb_of_init_display(struct clcd_fb *fb)
{
- struct device_node *endpoint;
+ struct device_node *endpoint = NULL;
int err;
unsigned int bpp;
u32 max_bandwidth;
@@ -731,9 +782,21 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
if (!fb->panel)
return -ENOMEM;
- endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node, NULL);
- if (!endpoint)
- return -ENODEV;
+ if (fb->vendor->init_panel) {
+ err = fb->vendor->init_panel(fb, &endpoint);
+ if (err)
+ return err;
+ }
+ /*
+ * If the vendor-specific code did not choose an endpoint,
+ * take the first one.
+ */
+ if (!endpoint) {
+ endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node,
+ NULL);
+ if (!endpoint)
+ return -ENODEV;
+ }
err = clcdfb_of_get_backlight(endpoint, fb->panel);
if (err)
@@ -770,11 +833,11 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
if (of_property_read_u32_array(endpoint,
"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]);
+ tft_r0b0g0, ARRAY_SIZE(tft_r0b0g0)) != 0)
+ return -ENOENT;
- return -ENOENT;
+ return clcdfb_of_init_tft_panel(fb, tft_r0b0g0[0],
+ tft_r0b0g0[1], tft_r0b0g0[2]);
}
static int clcdfb_of_vram_setup(struct clcd_fb *fb)
@@ -895,6 +958,7 @@ static struct clcd_board *clcdfb_of_get_board(struct amba_device *dev)
static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
{
struct clcd_board *board = dev_get_platdata(&dev->dev);
+ struct clcd_vendor_data *vendor = id->data;
struct clcd_fb *fb;
int ret;
@@ -904,6 +968,12 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
if (!board)
return -EINVAL;
+ if (vendor->init_board) {
+ ret = vendor->init_board(dev, board);
+ if (ret)
+ return ret;
+ }
+
ret = dma_set_mask_and_coherent(&dev->dev, DMA_BIT_MASK(32));
if (ret)
goto out;
@@ -922,10 +992,11 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
}
fb->dev = dev;
+ fb->vendor = vendor;
fb->board = board;
- dev_info(&fb->dev->dev, "PL%03x rev%u at 0x%08llx\n",
- amba_part(dev), amba_rev(dev),
+ dev_info(&fb->dev->dev, "PL%03x designer %02x rev%u at 0x%08llx\n",
+ amba_part(dev), amba_manf(dev), amba_rev(dev),
(unsigned long long)dev->res.start);
ret = fb->board->setup(fb);
@@ -968,10 +1039,27 @@ static int clcdfb_remove(struct amba_device *dev)
return 0;
}
+static struct clcd_vendor_data vendor_arm = {
+ /* No special business */
+};
+
+static struct clcd_vendor_data vendor_nomadik = {
+ .clock_timregs = true,
+ .packed_24_bit_pixels = true,
+ .st_bitmux_control = true,
+};
+
static struct amba_id clcdfb_id_table[] = {
{
.id = 0x00041110,
.mask = 0x000ffffe,
+ .data = &vendor_arm,
+ },
+ /* ST Electronics Nomadik variant */
+ {
+ .id = 0x00180110,
+ .mask = 0x00fffffe,
+ .data = &vendor_nomadik,
},
{ 0, 0 },
};
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index c60f32e23a83..9d2e03fae84d 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -67,6 +67,17 @@
#define CNTL_LDMAFIFOTIME (1 << 15)
#define CNTL_WATERMARK (1 << 16)
+/* ST Microelectronics variant bits */
+#define CNTL_ST_1XBPP_444 0x0
+#define CNTL_ST_1XBPP_5551 (1 << 17)
+#define CNTL_ST_1XBPP_565 (1 << 18)
+#define CNTL_ST_CDWID_12 0x0
+#define CNTL_ST_CDWID_16 (1 << 19)
+#define CNTL_ST_CDWID_18 (1 << 20)
+#define CNTL_ST_CDWID_24 ((1 << 19)|(1 << 20))
+#define CNTL_ST_CEAEN (1 << 21)
+#define CNTL_ST_LCDBPP24_PACKED (6 << 1)
+
enum {
/* individual formats */
CLCD_CAP_RGB444 = (1 << 0),
@@ -179,11 +190,38 @@ struct clcd_board {
struct amba_device;
struct clk;
+/**
+ * struct clcd_vendor_data - holds hardware (IP-block) vendor-specific
+ * variant information
+ *
+ * @clock_timregs: the CLCD needs to be clocked when accessing the
+ * timer registers, or the hardware will hang.
+ * @packed_24_bit_pixels: this variant supports 24bit packed pixel data,
+ * so that RGB accesses 3 bytes at a time, not just on even 32bit
+ * boundaries, packing the pixel data in memory. ST Microelectronics
+ * have this.
+ * @st_bitmux_control: ST Microelectronics have implemented output
+ * bit line multiplexing into the CLCD control register. This indicates
+ * that we need to use this.
+ * @init_board: custom board init function for this variant
+ * @init_panel: custom panel init function for this variant
+ */
+struct clcd_vendor_data {
+ bool clock_timregs;
+ bool packed_24_bit_pixels;
+ bool st_bitmux_control;
+ int (*init_board)(struct amba_device *adev,
+ struct clcd_board *board);
+ int (*init_panel)(struct clcd_fb *fb,
+ struct device_node **panel);
+};
+
/* this data structure describes each frame buffer device we find */
struct clcd_fb {
struct fb_info fb;
struct amba_device *dev;
struct clk *clk;
+ struct clcd_vendor_data *vendor;
struct clcd_panel *panel;
struct clcd_board *board;
void *board_data;
@@ -290,6 +328,10 @@ static inline void clcdfb_decode(struct clcd_fb *fb, struct clcd_regs *regs)
else
val |= CNTL_LCDBPP16_444;
break;
+ case 24:
+ /* Modified variant supporting 24 bit packed pixels */
+ val |= CNTL_ST_LCDBPP24_PACKED;
+ break;
case 32:
val |= CNTL_LCDBPP24;
break;
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread* [PATCH 04/11] video: ARM CLCD: support Nomadik variant
@ 2016-02-04 14:04 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
The Nomadik variant has a few special quirks that need to be respected
to make the driver work:
- The block need to be clocked during writing of the TIMn registers
or the bus will stall.
- Special bits in the control register select how many of the output
display lines get activated.
- Special bits in the control register select how to manage the
different 565 and 5551 modes.
- There is a packed 24bit graphics mode, i.e 888 pixels can be stored
in memory is three consecutive bytes, not evenly aligned to a 32bit
word.
This patch uses the vendor data pointer from the AMBA matching mechanism
to track the quirks for this variant, and adds two hooks that variants
can use to initialize boards and panels during start-up. These will
later be used to adopt a Nomadik board profile.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/video/fbdev/amba-clcd.c | 108 ++++++++++++++++++++++++++++++++++++----
include/linux/amba/clcd.h | 42 ++++++++++++++++
2 files changed, 140 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 9a631a8e2c04..77fb50e00670 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -227,6 +227,15 @@ clcdfb_set_bitfields(struct clcd_fb *fb, struct fb_var_screeninfo *var)
var->blue.length = 4;
}
break;
+ case 24:
+ if (fb->vendor->packed_24_bit_pixels) {
+ var->red.length = 8;
+ var->green.length = 8;
+ var->blue.length = 8;
+ } else {
+ ret = -EINVAL;
+ }
+ break;
case 32:
/* If we can't do 888, reject */
caps &= CLCD_CAP_888;
@@ -313,6 +322,12 @@ static int clcdfb_set_par(struct fb_info *info)
clcdfb_disable(fb);
+ /* Some variants must be clocked here */
+ if (fb->vendor->clock_timregs && !fb->clk_enabled) {
+ fb->clk_enabled = true;
+ clk_enable(fb->clk);
+ }
+
writel(regs.tim0, fb->regs + CLCD_TIM0);
writel(regs.tim1, fb->regs + CLCD_TIM1);
writel(regs.tim2, fb->regs + CLCD_TIM2);
@@ -716,12 +731,48 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
if (r0 != 0 && b0 == 0)
fb->panel->bgr_connection = true;
+ if (fb->panel->caps && fb->vendor->st_bitmux_control) {
+ /*
+ * Set up the special bits for the Nomadik control register
+ * (other platforms tend to do this through an external
+ * register).
+ */
+
+ /* Offset of the highest used color */
+ int maxoff = max3(r0, g0, b0);
+ /* Most significant bit out, highest used bit */
+ int msb = 0;
+
+ if (fb->panel->caps & CLCD_CAP_888) {
+ msb = maxoff + 8 - 1;
+ } else if (fb->panel->caps & CLCD_CAP_565) {
+ msb = maxoff + 5 - 1;
+ fb->panel->cntl |= CNTL_ST_1XBPP_565;
+ } else if (fb->panel->caps & CLCD_CAP_5551) {
+ msb = maxoff + 5 - 1;
+ fb->panel->cntl |= CNTL_ST_1XBPP_5551;
+ } else if (fb->panel->caps & CLCD_CAP_444) {
+ msb = maxoff + 4 - 1;
+ fb->panel->cntl |= CNTL_ST_1XBPP_444;
+ }
+
+ /* Send out as many bits as we need */
+ if (msb > 17)
+ fb->panel->cntl |= CNTL_ST_CDWID_24;
+ else if (msb > 15)
+ fb->panel->cntl |= CNTL_ST_CDWID_18;
+ else if (msb > 11)
+ fb->panel->cntl |= CNTL_ST_CDWID_16;
+ else
+ fb->panel->cntl |= CNTL_ST_CDWID_12;
+ }
+
return fb->panel->caps ? 0 : -EINVAL;
}
static int clcdfb_of_init_display(struct clcd_fb *fb)
{
- struct device_node *endpoint;
+ struct device_node *endpoint = NULL;
int err;
unsigned int bpp;
u32 max_bandwidth;
@@ -731,9 +782,21 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
if (!fb->panel)
return -ENOMEM;
- endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node, NULL);
- if (!endpoint)
- return -ENODEV;
+ if (fb->vendor->init_panel) {
+ err = fb->vendor->init_panel(fb, &endpoint);
+ if (err)
+ return err;
+ }
+ /*
+ * If the vendor-specific code did not choose an endpoint,
+ * take the first one.
+ */
+ if (!endpoint) {
+ endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node,
+ NULL);
+ if (!endpoint)
+ return -ENODEV;
+ }
err = clcdfb_of_get_backlight(endpoint, fb->panel);
if (err)
@@ -770,11 +833,11 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
if (of_property_read_u32_array(endpoint,
"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]);
+ tft_r0b0g0, ARRAY_SIZE(tft_r0b0g0)) != 0)
+ return -ENOENT;
- return -ENOENT;
+ return clcdfb_of_init_tft_panel(fb, tft_r0b0g0[0],
+ tft_r0b0g0[1], tft_r0b0g0[2]);
}
static int clcdfb_of_vram_setup(struct clcd_fb *fb)
@@ -895,6 +958,7 @@ static struct clcd_board *clcdfb_of_get_board(struct amba_device *dev)
static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
{
struct clcd_board *board = dev_get_platdata(&dev->dev);
+ struct clcd_vendor_data *vendor = id->data;
struct clcd_fb *fb;
int ret;
@@ -904,6 +968,12 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
if (!board)
return -EINVAL;
+ if (vendor->init_board) {
+ ret = vendor->init_board(dev, board);
+ if (ret)
+ return ret;
+ }
+
ret = dma_set_mask_and_coherent(&dev->dev, DMA_BIT_MASK(32));
if (ret)
goto out;
@@ -922,10 +992,11 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
}
fb->dev = dev;
+ fb->vendor = vendor;
fb->board = board;
- dev_info(&fb->dev->dev, "PL%03x rev%u at 0x%08llx\n",
- amba_part(dev), amba_rev(dev),
+ dev_info(&fb->dev->dev, "PL%03x designer %02x rev%u at 0x%08llx\n",
+ amba_part(dev), amba_manf(dev), amba_rev(dev),
(unsigned long long)dev->res.start);
ret = fb->board->setup(fb);
@@ -968,10 +1039,27 @@ static int clcdfb_remove(struct amba_device *dev)
return 0;
}
+static struct clcd_vendor_data vendor_arm = {
+ /* No special business */
+};
+
+static struct clcd_vendor_data vendor_nomadik = {
+ .clock_timregs = true,
+ .packed_24_bit_pixels = true,
+ .st_bitmux_control = true,
+};
+
static struct amba_id clcdfb_id_table[] = {
{
.id = 0x00041110,
.mask = 0x000ffffe,
+ .data = &vendor_arm,
+ },
+ /* ST Electronics Nomadik variant */
+ {
+ .id = 0x00180110,
+ .mask = 0x00fffffe,
+ .data = &vendor_nomadik,
},
{ 0, 0 },
};
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index c60f32e23a83..9d2e03fae84d 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -67,6 +67,17 @@
#define CNTL_LDMAFIFOTIME (1 << 15)
#define CNTL_WATERMARK (1 << 16)
+/* ST Microelectronics variant bits */
+#define CNTL_ST_1XBPP_444 0x0
+#define CNTL_ST_1XBPP_5551 (1 << 17)
+#define CNTL_ST_1XBPP_565 (1 << 18)
+#define CNTL_ST_CDWID_12 0x0
+#define CNTL_ST_CDWID_16 (1 << 19)
+#define CNTL_ST_CDWID_18 (1 << 20)
+#define CNTL_ST_CDWID_24 ((1 << 19)|(1 << 20))
+#define CNTL_ST_CEAEN (1 << 21)
+#define CNTL_ST_LCDBPP24_PACKED (6 << 1)
+
enum {
/* individual formats */
CLCD_CAP_RGB444 = (1 << 0),
@@ -179,11 +190,38 @@ struct clcd_board {
struct amba_device;
struct clk;
+/**
+ * struct clcd_vendor_data - holds hardware (IP-block) vendor-specific
+ * variant information
+ *
+ * @clock_timregs: the CLCD needs to be clocked when accessing the
+ * timer registers, or the hardware will hang.
+ * @packed_24_bit_pixels: this variant supports 24bit packed pixel data,
+ * so that RGB accesses 3 bytes@a time, not just on even 32bit
+ * boundaries, packing the pixel data in memory. ST Microelectronics
+ * have this.
+ * @st_bitmux_control: ST Microelectronics have implemented output
+ * bit line multiplexing into the CLCD control register. This indicates
+ * that we need to use this.
+ * @init_board: custom board init function for this variant
+ * @init_panel: custom panel init function for this variant
+ */
+struct clcd_vendor_data {
+ bool clock_timregs;
+ bool packed_24_bit_pixels;
+ bool st_bitmux_control;
+ int (*init_board)(struct amba_device *adev,
+ struct clcd_board *board);
+ int (*init_panel)(struct clcd_fb *fb,
+ struct device_node **panel);
+};
+
/* this data structure describes each frame buffer device we find */
struct clcd_fb {
struct fb_info fb;
struct amba_device *dev;
struct clk *clk;
+ struct clcd_vendor_data *vendor;
struct clcd_panel *panel;
struct clcd_board *board;
void *board_data;
@@ -290,6 +328,10 @@ static inline void clcdfb_decode(struct clcd_fb *fb, struct clcd_regs *regs)
else
val |= CNTL_LCDBPP16_444;
break;
+ case 24:
+ /* Modified variant supporting 24 bit packed pixels */
+ val |= CNTL_ST_LCDBPP24_PACKED;
+ break;
case 32:
val |= CNTL_LCDBPP24;
break;
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread
* [PATCH 05/11] video: ARM CLCD: add special board and panel hooks for Nomadik
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-04 14:04 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In the .board_init() callback will set up a mux register in
the Nomadik system controller. It so happens that the platform
has two display output engines, and we have to poke a bit in
a special register to make sure the right engine is muxed in
as they are mutually exclusive.
The Nomadik CLCD variant is instantiated on a platform where
it is combined with a 800x480 TPO WVGA display. In the
.panel_init() hook we will detect this display from the
compatible string and set it up. We also add .enable() and
.disable() callbacks for it as the sleep state is software
controlled.
The display is connected with a special 3-wire serial bus
(this is sadly neither I2C or SPI) using three GPIO lines that
we bitbang to detect the display and enable/disable sleep
state.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/video/fbdev/Makefile | 1 +
drivers/video/fbdev/amba-clcd-nomadik.c | 263 ++++++++++++++++++++++++++++++++
drivers/video/fbdev/amba-clcd-nomadik.h | 24 +++
drivers/video/fbdev/amba-clcd.c | 6 +-
4 files changed, 293 insertions(+), 1 deletion(-)
create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.c
create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.h
diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index 65fb15075c8f..f0aec3aa213c 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_FB_ATMEL) += atmel_lcdfb.o
obj-$(CONFIG_FB_PVR2) += pvr2fb.o
obj-$(CONFIG_FB_VOODOO1) += sstfb.o
obj-$(CONFIG_FB_ARMCLCD) += amba-clcd.o
+obj-$(CONFIG_ARCH_NOMADIK) += amba-clcd-nomadik.o
obj-$(CONFIG_PLAT_VERSATILE_CLCD) += amba-clcd-versatile.o
obj-$(CONFIG_FB_GOLDFISH) += goldfishfb.o
obj-$(CONFIG_FB_68328) += 68328fb.o
diff --git a/drivers/video/fbdev/amba-clcd-nomadik.c b/drivers/video/fbdev/amba-clcd-nomadik.c
new file mode 100644
index 000000000000..bc3519d1b5c0
--- /dev/null
+++ b/drivers/video/fbdev/amba-clcd-nomadik.c
@@ -0,0 +1,263 @@
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/gpio/consumer.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/delay.h>
+#include <linux/bitops.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+
+#include "amba-clcd-nomadik.h"
+
+static struct gpio_desc *grestb;
+static struct gpio_desc *scen;
+static struct gpio_desc *scl;
+static struct gpio_desc *sda;
+
+static u8 tpg110_readwrite_reg(bool write, u8 address, u8 outval)
+{
+ int i;
+ u8 inval = 0;
+
+ /* Assert SCEN */
+ gpiod_set_value_cansleep(scen, 1);
+ ndelay(150);
+ /* Hammer out the address */
+ for (i = 5; i >= 0; i--) {
+ if (address & BIT(i))
+ gpiod_set_value_cansleep(sda, 1);
+ else
+ gpiod_set_value_cansleep(sda, 0);
+ ndelay(150);
+ /* Send an SCL pulse */
+ gpiod_set_value_cansleep(scl, 1);
+ ndelay(160);
+ gpiod_set_value_cansleep(scl, 0);
+ ndelay(160);
+ }
+
+ if (write) {
+ /* WRITE */
+ gpiod_set_value_cansleep(sda, 0);
+ } else {
+ /* READ */
+ gpiod_set_value_cansleep(sda, 1);
+ }
+ ndelay(150);
+ /* Send an SCL pulse */
+ gpiod_set_value_cansleep(scl, 1);
+ ndelay(160);
+ gpiod_set_value_cansleep(scl, 0);
+ ndelay(160);
+
+ if (!write)
+ /* HiZ turn-around cycle */
+ gpiod_direction_input(sda);
+ ndelay(150);
+ /* Send an SCL pulse */
+ gpiod_set_value_cansleep(scl, 1);
+ ndelay(160);
+ gpiod_set_value_cansleep(scl, 0);
+ ndelay(160);
+
+ /* Hammer in/out the data */
+ for (i = 7; i >= 0; i--) {
+ int value;
+
+ if (write) {
+ value = !!(outval & BIT(i));
+ gpiod_set_value_cansleep(sda, value);
+ } else {
+ value = gpiod_get_value(sda);
+ if (value)
+ inval |= BIT(i);
+ }
+ ndelay(150);
+ /* Send an SCL pulse */
+ gpiod_set_value_cansleep(scl, 1);
+ ndelay(160);
+ gpiod_set_value_cansleep(scl, 0);
+ ndelay(160);
+ }
+
+ gpiod_direction_output(sda, 0);
+ /* Deassert SCEN */
+ gpiod_set_value_cansleep(scen, 0);
+ /* Satisfies SCEN pulse width */
+ udelay(1);
+
+ return inval;
+}
+
+static u8 tpg110_read_reg(u8 address)
+{
+ return tpg110_readwrite_reg(false, address, 0);
+}
+
+static void tpg110_write_reg(u8 address, u8 outval)
+{
+ tpg110_readwrite_reg(true, address, outval);
+}
+
+static void tpg110_startup(struct device *dev)
+{
+ u8 val;
+
+ dev_info(dev, "TPG110 display enable\n");
+ /* De-assert the reset signal */
+ gpiod_set_value_cansleep(grestb, 0);
+ mdelay(1);
+ dev_info(dev, "de-asserted GRESTB\n");
+
+ /* Test display communication */
+ tpg110_write_reg(0x00, 0x55);
+ val = tpg110_read_reg(0x00);
+ if (val = 0x55)
+ dev_info(dev, "passed communication test\n");
+ val = tpg110_read_reg(0x01);
+ dev_info(dev, "TPG110 chip ID: %d version: %d\n",
+ val>>4, val&0x0f);
+
+ /* Show display resolution */
+ val = tpg110_read_reg(0x02);
+ val &= 7;
+ switch (val) {
+ case 0x0:
+ dev_info(dev, "IN 400x240 RGB -> OUT 800x480 RGB (dual scan)");
+ break;
+ case 0x1:
+ dev_info(dev, "IN 480x272 RGB -> OUT 800x480 RGB (dual scan)");
+ break;
+ case 0x4:
+ dev_info(dev, "480x640 RGB");
+ break;
+ case 0x5:
+ dev_info(dev, "480x272 RGB");
+ break;
+ case 0x6:
+ dev_info(dev, "640x480 RGB");
+ break;
+ case 0x7:
+ dev_info(dev, "800x480 RGB");
+ break;
+ default:
+ dev_info(dev, "ILLEGAL RESOLUTION");
+ break;
+ }
+
+ val = tpg110_read_reg(0x03);
+ dev_info(dev, "resolution is controlled by %s\n",
+ (val & BIT(7)) ? "software" : "hardware");
+}
+
+static void tpg110_enable(struct clcd_fb *fb)
+{
+ struct fb_var_screeninfo *var = &fb->fb.var;
+ struct device *dev = &fb->dev->dev;
+ static bool startup;
+ u8 val;
+
+ if (!startup) {
+ tpg110_startup(dev);
+ startup = true;
+ }
+
+ /* Take chip out of standby */
+ val = tpg110_read_reg(0x03);
+ val |= BIT(0);
+ tpg110_write_reg(0x03, val);
+}
+
+static void tpg110_disable(struct clcd_fb *fb)
+{
+ u8 val;
+
+ dev_info(&fb->dev->dev, "TPG110 display disable\n");
+ val = tpg110_read_reg(0x03);
+ /* Put into standby */
+ val &= ~BIT(0);
+ tpg110_write_reg(0x03, val);
+}
+
+static void tpg110_init(struct device *dev, struct device_node *np,
+ struct clcd_board *board)
+{
+ dev_info(dev, "TPG110 display init\n");
+
+ grestb = devm_get_gpiod_from_child(dev, "grestb", &np->fwnode);
+ if (IS_ERR(grestb)) {
+ dev_err(dev, "no GRESTB GPIO\n");
+ return;
+ }
+ /* This asserts the GRESTB signal, putting the display into reset */
+ gpiod_direction_output(grestb, 1);
+
+ scen = devm_get_gpiod_from_child(dev, "scen", &np->fwnode);
+ if (IS_ERR(scen)) {
+ dev_err(dev, "no SCEN GPIO\n");
+ return;
+ }
+ gpiod_direction_output(scen, 0);
+ scl = devm_get_gpiod_from_child(dev, "scl", &np->fwnode);
+ if (IS_ERR(scl)) {
+ dev_err(dev, "no SCL GPIO\n");
+ return;
+ }
+ gpiod_direction_output(scl, 0);
+ sda = devm_get_gpiod_from_child(dev, "sda", &np->fwnode);
+ if (IS_ERR(sda)) {
+ dev_err(dev, "no SDA GPIO\n");
+ return;
+ }
+ gpiod_direction_output(sda, 0);
+ board->enable = tpg110_enable;
+ board->disable = tpg110_disable;
+}
+
+int nomadik_clcd_init_panel(struct clcd_fb *fb,
+ struct device_node **endpoint)
+{
+ struct device_node *panel;
+
+ *endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node,
+ NULL);
+ if (!*endpoint)
+ return -ENODEV;
+
+ panel = of_graph_get_remote_port_parent(endpoint);
+ if (!panel)
+ return -ENODEV;
+
+ if (of_device_is_compatible(panel, "tpo,tpg110"))
+ tpg110_init(&fb->dev->dev, panel, fb->board);
+ else
+ dev_info(&fb->dev->dev, "unknown panel\n");
+
+ /* Unknown panel, fall through */
+ return 0;
+}
+
+#define PMU_CTRL_OFFSET 0x0000
+#define PMU_CTRL_LCDNDIF BIT(26)
+
+int nomadik_clcd_init_board(struct amba_device *adev,
+ struct clcd_board *board)
+{
+ struct regmap *pmu_regmap;
+
+ dev_info(&adev->dev, "Nomadik CLCD board init\n");
+ pmu_regmap + syscon_regmap_lookup_by_compatible("stericsson,nomadik-pmu");
+ if (IS_ERR(pmu_regmap)) {
+ dev_err(&adev->dev, "could not find PMU syscon regmap\n");
+ return PTR_ERR(pmu_regmap);
+ }
+ regmap_update_bits(pmu_regmap,
+ PMU_CTRL_OFFSET,
+ PMU_CTRL_LCDNDIF,
+ 0);
+ dev_info(&adev->dev, "set PMU mux to CLCD mode\n");
+
+ return 0;
+}
diff --git a/drivers/video/fbdev/amba-clcd-nomadik.h b/drivers/video/fbdev/amba-clcd-nomadik.h
new file mode 100644
index 000000000000..b34dbf3061bf
--- /dev/null
+++ b/drivers/video/fbdev/amba-clcd-nomadik.h
@@ -0,0 +1,24 @@
+#ifndef _AMBA_CLCD_NOMADIK_H
+#define _AMBA_CLCD_NOMADIK_H
+
+#include <linux/amba/bus.h>
+
+#ifdef CONFIG_ARCH_NOMADIK
+int nomadik_clcd_init_board(struct amba_device *adev,
+ struct clcd_board *board);
+int nomadik_clcd_init_panel(struct clcd_fb *fb,
+ struct device_node **endpoint);
+#else
+static inline int nomadik_clcd_init_board(struct amba_device *adev,
+ struct clcd_board *board)
+{
+ return 0;
+}
+static inline int nomadik_clcd_init_panel(struct clcd_fb *fb,
+ struct device_node **endpoint)
+{
+ return 0;
+}
+#endif
+
+#endif /* inclusion guard */
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 77fb50e00670..53c5ec31168d 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -37,6 +37,8 @@
#include <asm/sizes.h>
+#include "amba-clcd-nomadik.h"
+
#define to_clcd(info) container_of(info, struct clcd_fb, fb)
/* This is limited to 16 characters when displayed by X startup */
@@ -1003,7 +1005,7 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
if (ret)
goto free_fb;
- ret = clcdfb_register(fb);
+ ret = clcdfb_register(fb);
if (ret = 0) {
amba_set_drvdata(dev, fb);
goto out;
@@ -1047,6 +1049,8 @@ static struct clcd_vendor_data vendor_nomadik = {
.clock_timregs = true,
.packed_24_bit_pixels = true,
.st_bitmux_control = true,
+ .init_board = nomadik_clcd_init_board,
+ .init_panel = nomadik_clcd_init_panel,
};
static struct amba_id clcdfb_id_table[] = {
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread* [PATCH 05/11] video: ARM CLCD: add special board and panel hooks for Nomadik
@ 2016-02-04 14:04 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In the .board_init() callback will set up a mux register in
the Nomadik system controller. It so happens that the platform
has two display output engines, and we have to poke a bit in
a special register to make sure the right engine is muxed in
as they are mutually exclusive.
The Nomadik CLCD variant is instantiated on a platform where
it is combined with a 800x480 TPO WVGA display. In the
.panel_init() hook we will detect this display from the
compatible string and set it up. We also add .enable() and
.disable() callbacks for it as the sleep state is software
controlled.
The display is connected with a special 3-wire serial bus
(this is sadly neither I2C or SPI) using three GPIO lines that
we bitbang to detect the display and enable/disable sleep
state.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/video/fbdev/Makefile | 1 +
drivers/video/fbdev/amba-clcd-nomadik.c | 263 ++++++++++++++++++++++++++++++++
drivers/video/fbdev/amba-clcd-nomadik.h | 24 +++
drivers/video/fbdev/amba-clcd.c | 6 +-
4 files changed, 293 insertions(+), 1 deletion(-)
create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.c
create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.h
diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index 65fb15075c8f..f0aec3aa213c 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_FB_ATMEL) += atmel_lcdfb.o
obj-$(CONFIG_FB_PVR2) += pvr2fb.o
obj-$(CONFIG_FB_VOODOO1) += sstfb.o
obj-$(CONFIG_FB_ARMCLCD) += amba-clcd.o
+obj-$(CONFIG_ARCH_NOMADIK) += amba-clcd-nomadik.o
obj-$(CONFIG_PLAT_VERSATILE_CLCD) += amba-clcd-versatile.o
obj-$(CONFIG_FB_GOLDFISH) += goldfishfb.o
obj-$(CONFIG_FB_68328) += 68328fb.o
diff --git a/drivers/video/fbdev/amba-clcd-nomadik.c b/drivers/video/fbdev/amba-clcd-nomadik.c
new file mode 100644
index 000000000000..bc3519d1b5c0
--- /dev/null
+++ b/drivers/video/fbdev/amba-clcd-nomadik.c
@@ -0,0 +1,263 @@
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/gpio/consumer.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/delay.h>
+#include <linux/bitops.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+
+#include "amba-clcd-nomadik.h"
+
+static struct gpio_desc *grestb;
+static struct gpio_desc *scen;
+static struct gpio_desc *scl;
+static struct gpio_desc *sda;
+
+static u8 tpg110_readwrite_reg(bool write, u8 address, u8 outval)
+{
+ int i;
+ u8 inval = 0;
+
+ /* Assert SCEN */
+ gpiod_set_value_cansleep(scen, 1);
+ ndelay(150);
+ /* Hammer out the address */
+ for (i = 5; i >= 0; i--) {
+ if (address & BIT(i))
+ gpiod_set_value_cansleep(sda, 1);
+ else
+ gpiod_set_value_cansleep(sda, 0);
+ ndelay(150);
+ /* Send an SCL pulse */
+ gpiod_set_value_cansleep(scl, 1);
+ ndelay(160);
+ gpiod_set_value_cansleep(scl, 0);
+ ndelay(160);
+ }
+
+ if (write) {
+ /* WRITE */
+ gpiod_set_value_cansleep(sda, 0);
+ } else {
+ /* READ */
+ gpiod_set_value_cansleep(sda, 1);
+ }
+ ndelay(150);
+ /* Send an SCL pulse */
+ gpiod_set_value_cansleep(scl, 1);
+ ndelay(160);
+ gpiod_set_value_cansleep(scl, 0);
+ ndelay(160);
+
+ if (!write)
+ /* HiZ turn-around cycle */
+ gpiod_direction_input(sda);
+ ndelay(150);
+ /* Send an SCL pulse */
+ gpiod_set_value_cansleep(scl, 1);
+ ndelay(160);
+ gpiod_set_value_cansleep(scl, 0);
+ ndelay(160);
+
+ /* Hammer in/out the data */
+ for (i = 7; i >= 0; i--) {
+ int value;
+
+ if (write) {
+ value = !!(outval & BIT(i));
+ gpiod_set_value_cansleep(sda, value);
+ } else {
+ value = gpiod_get_value(sda);
+ if (value)
+ inval |= BIT(i);
+ }
+ ndelay(150);
+ /* Send an SCL pulse */
+ gpiod_set_value_cansleep(scl, 1);
+ ndelay(160);
+ gpiod_set_value_cansleep(scl, 0);
+ ndelay(160);
+ }
+
+ gpiod_direction_output(sda, 0);
+ /* Deassert SCEN */
+ gpiod_set_value_cansleep(scen, 0);
+ /* Satisfies SCEN pulse width */
+ udelay(1);
+
+ return inval;
+}
+
+static u8 tpg110_read_reg(u8 address)
+{
+ return tpg110_readwrite_reg(false, address, 0);
+}
+
+static void tpg110_write_reg(u8 address, u8 outval)
+{
+ tpg110_readwrite_reg(true, address, outval);
+}
+
+static void tpg110_startup(struct device *dev)
+{
+ u8 val;
+
+ dev_info(dev, "TPG110 display enable\n");
+ /* De-assert the reset signal */
+ gpiod_set_value_cansleep(grestb, 0);
+ mdelay(1);
+ dev_info(dev, "de-asserted GRESTB\n");
+
+ /* Test display communication */
+ tpg110_write_reg(0x00, 0x55);
+ val = tpg110_read_reg(0x00);
+ if (val == 0x55)
+ dev_info(dev, "passed communication test\n");
+ val = tpg110_read_reg(0x01);
+ dev_info(dev, "TPG110 chip ID: %d version: %d\n",
+ val>>4, val&0x0f);
+
+ /* Show display resolution */
+ val = tpg110_read_reg(0x02);
+ val &= 7;
+ switch (val) {
+ case 0x0:
+ dev_info(dev, "IN 400x240 RGB -> OUT 800x480 RGB (dual scan)");
+ break;
+ case 0x1:
+ dev_info(dev, "IN 480x272 RGB -> OUT 800x480 RGB (dual scan)");
+ break;
+ case 0x4:
+ dev_info(dev, "480x640 RGB");
+ break;
+ case 0x5:
+ dev_info(dev, "480x272 RGB");
+ break;
+ case 0x6:
+ dev_info(dev, "640x480 RGB");
+ break;
+ case 0x7:
+ dev_info(dev, "800x480 RGB");
+ break;
+ default:
+ dev_info(dev, "ILLEGAL RESOLUTION");
+ break;
+ }
+
+ val = tpg110_read_reg(0x03);
+ dev_info(dev, "resolution is controlled by %s\n",
+ (val & BIT(7)) ? "software" : "hardware");
+}
+
+static void tpg110_enable(struct clcd_fb *fb)
+{
+ struct fb_var_screeninfo *var = &fb->fb.var;
+ struct device *dev = &fb->dev->dev;
+ static bool startup;
+ u8 val;
+
+ if (!startup) {
+ tpg110_startup(dev);
+ startup = true;
+ }
+
+ /* Take chip out of standby */
+ val = tpg110_read_reg(0x03);
+ val |= BIT(0);
+ tpg110_write_reg(0x03, val);
+}
+
+static void tpg110_disable(struct clcd_fb *fb)
+{
+ u8 val;
+
+ dev_info(&fb->dev->dev, "TPG110 display disable\n");
+ val = tpg110_read_reg(0x03);
+ /* Put into standby */
+ val &= ~BIT(0);
+ tpg110_write_reg(0x03, val);
+}
+
+static void tpg110_init(struct device *dev, struct device_node *np,
+ struct clcd_board *board)
+{
+ dev_info(dev, "TPG110 display init\n");
+
+ grestb = devm_get_gpiod_from_child(dev, "grestb", &np->fwnode);
+ if (IS_ERR(grestb)) {
+ dev_err(dev, "no GRESTB GPIO\n");
+ return;
+ }
+ /* This asserts the GRESTB signal, putting the display into reset */
+ gpiod_direction_output(grestb, 1);
+
+ scen = devm_get_gpiod_from_child(dev, "scen", &np->fwnode);
+ if (IS_ERR(scen)) {
+ dev_err(dev, "no SCEN GPIO\n");
+ return;
+ }
+ gpiod_direction_output(scen, 0);
+ scl = devm_get_gpiod_from_child(dev, "scl", &np->fwnode);
+ if (IS_ERR(scl)) {
+ dev_err(dev, "no SCL GPIO\n");
+ return;
+ }
+ gpiod_direction_output(scl, 0);
+ sda = devm_get_gpiod_from_child(dev, "sda", &np->fwnode);
+ if (IS_ERR(sda)) {
+ dev_err(dev, "no SDA GPIO\n");
+ return;
+ }
+ gpiod_direction_output(sda, 0);
+ board->enable = tpg110_enable;
+ board->disable = tpg110_disable;
+}
+
+int nomadik_clcd_init_panel(struct clcd_fb *fb,
+ struct device_node **endpoint)
+{
+ struct device_node *panel;
+
+ *endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node,
+ NULL);
+ if (!*endpoint)
+ return -ENODEV;
+
+ panel = of_graph_get_remote_port_parent(endpoint);
+ if (!panel)
+ return -ENODEV;
+
+ if (of_device_is_compatible(panel, "tpo,tpg110"))
+ tpg110_init(&fb->dev->dev, panel, fb->board);
+ else
+ dev_info(&fb->dev->dev, "unknown panel\n");
+
+ /* Unknown panel, fall through */
+ return 0;
+}
+
+#define PMU_CTRL_OFFSET 0x0000
+#define PMU_CTRL_LCDNDIF BIT(26)
+
+int nomadik_clcd_init_board(struct amba_device *adev,
+ struct clcd_board *board)
+{
+ struct regmap *pmu_regmap;
+
+ dev_info(&adev->dev, "Nomadik CLCD board init\n");
+ pmu_regmap =
+ syscon_regmap_lookup_by_compatible("stericsson,nomadik-pmu");
+ if (IS_ERR(pmu_regmap)) {
+ dev_err(&adev->dev, "could not find PMU syscon regmap\n");
+ return PTR_ERR(pmu_regmap);
+ }
+ regmap_update_bits(pmu_regmap,
+ PMU_CTRL_OFFSET,
+ PMU_CTRL_LCDNDIF,
+ 0);
+ dev_info(&adev->dev, "set PMU mux to CLCD mode\n");
+
+ return 0;
+}
diff --git a/drivers/video/fbdev/amba-clcd-nomadik.h b/drivers/video/fbdev/amba-clcd-nomadik.h
new file mode 100644
index 000000000000..b34dbf3061bf
--- /dev/null
+++ b/drivers/video/fbdev/amba-clcd-nomadik.h
@@ -0,0 +1,24 @@
+#ifndef _AMBA_CLCD_NOMADIK_H
+#define _AMBA_CLCD_NOMADIK_H
+
+#include <linux/amba/bus.h>
+
+#ifdef CONFIG_ARCH_NOMADIK
+int nomadik_clcd_init_board(struct amba_device *adev,
+ struct clcd_board *board);
+int nomadik_clcd_init_panel(struct clcd_fb *fb,
+ struct device_node **endpoint);
+#else
+static inline int nomadik_clcd_init_board(struct amba_device *adev,
+ struct clcd_board *board)
+{
+ return 0;
+}
+static inline int nomadik_clcd_init_panel(struct clcd_fb *fb,
+ struct device_node **endpoint)
+{
+ return 0;
+}
+#endif
+
+#endif /* inclusion guard */
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 77fb50e00670..53c5ec31168d 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -37,6 +37,8 @@
#include <asm/sizes.h>
+#include "amba-clcd-nomadik.h"
+
#define to_clcd(info) container_of(info, struct clcd_fb, fb)
/* This is limited to 16 characters when displayed by X startup */
@@ -1003,7 +1005,7 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
if (ret)
goto free_fb;
- ret = clcdfb_register(fb);
+ ret = clcdfb_register(fb);
if (ret == 0) {
amba_set_drvdata(dev, fb);
goto out;
@@ -1047,6 +1049,8 @@ static struct clcd_vendor_data vendor_nomadik = {
.clock_timregs = true,
.packed_24_bit_pixels = true,
.st_bitmux_control = true,
+ .init_board = nomadik_clcd_init_board,
+ .init_panel = nomadik_clcd_init_panel,
};
static struct amba_id clcdfb_id_table[] = {
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread
* [PATCH 06/11] Documentation/DT: add blurb for IB2 syscon to Versatile
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-04 14:04 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
The ARM Versatile has an optional daughterboard, if this is
mounted, we need to be able to access its system controller.
Put in a documentation blurb for this.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Documentation/devicetree/bindings/arm/arm-boards | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
index 1a709970e7f7..2daeabc519de 100644
--- a/Documentation/devicetree/bindings/arm/arm-boards
+++ b/Documentation/devicetree/bindings/arm/arm-boards
@@ -93,6 +93,14 @@ Required nodes:
a core-module with regs and the compatible strings
"arm,core-module-versatile", "syscon"
+Optional nodes:
+
+- arm,versatile-ib2-syscon : if the Versatile has an IB2 interface
+ board mounted, this has a separate system controller that is
+ defined in this node.
+ Required properties:
+ compatible = "arm,versatile-ib2-syscon", "syscon"
+
ARM RealView Boards
-------------------
The RealView boards cover tailored evaluation boards that are used to explore
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread
* [PATCH 06/11] Documentation/DT: add blurb for IB2 syscon to Versatile
@ 2016-02-04 14:04 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
The ARM Versatile has an optional daughterboard, if this is
mounted, we need to be able to access its system controller.
Put in a documentation blurb for this.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Documentation/devicetree/bindings/arm/arm-boards | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
index 1a709970e7f7..2daeabc519de 100644
--- a/Documentation/devicetree/bindings/arm/arm-boards
+++ b/Documentation/devicetree/bindings/arm/arm-boards
@@ -93,6 +93,14 @@ Required nodes:
a core-module with regs and the compatible strings
"arm,core-module-versatile", "syscon"
+Optional nodes:
+
+- arm,versatile-ib2-syscon : if the Versatile has an IB2 interface
+ board mounted, this has a separate system controller that is
+ defined in this node.
+ Required properties:
+ compatible = "arm,versatile-ib2-syscon", "syscon"
+
ARM RealView Boards
-------------------
The RealView boards cover tailored evaluation boards that are used to explore
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread
* [PATCH 07/11] Documentation/DT: add Versatile display bindings
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-04 14:04 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
This adds bindings for the LCD displays that can be found connected
to the ARM Versatile reference design, interface boards IB1 and
IB2.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
.../devicetree/bindings/display/panel/epson,l2f50113t00.txt | 7 +++++++
.../devicetree/bindings/display/panel/sanyo,alr252rgt.txt | 7 +++++++
.../devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt | 7 +++++++
.../devicetree/bindings/display/panel/sharp,lq084v1dg21.txt | 7 +++++++
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
5 files changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt
diff --git a/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt b/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
new file mode 100644
index 000000000000..58eca804dbe8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
@@ -0,0 +1,7 @@
+Epson Mobile display
+
+Required properties:
+- compatible: should be "epson,l2f50113t00"
+
+This binding is compatible with the panel-dpi binding, which is specified
+in panel-dpi.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt b/Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
new file mode 100644
index 000000000000..d24562b34cd0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
@@ -0,0 +1,7 @@
+Sanyo Electric Co. 2.5" panel
+
+Required properties:
+- compatible: should be "sanyo,alr252rgt"
+
+This binding is compatible with the panel-dpi binding, which is specified
+in panel-dpi.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt b/Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
new file mode 100644
index 000000000000..c1582012d52e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
@@ -0,0 +1,7 @@
+Sanyo Electric Co. 3.8" panel
+
+Required properties:
+- compatible: should be "sanyo,tm38qv67a02a"
+
+This binding is compatible with the panel-dpi binding, which is specified
+in panel-dpi.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt b/Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt
new file mode 100644
index 000000000000..8318c2422740
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt
@@ -0,0 +1,7 @@
+Sharp 8.4" VGA color TFT
+
+Required properties:
+- compatible: should be "sharp,lq084v1dg21"
+
+This binding is compatible with the panel-dpi binding, which is specified
+in panel-dpi.txt in this directory.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 72e2c5a2b327..da5d8bf13818 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -198,6 +198,7 @@ ricoh Ricoh Co. Ltd.
rockchip Fuzhou Rockchip Electronics Co., Ltd
samsung Samsung Semiconductor
sandisk Sandisk Corporation
+sanyo Sanyo Electric Co., Ltd.
sbs Smart Battery System
schindler Schindler
seagate Seagate Technology PLC
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread
* [PATCH 07/11] Documentation/DT: add Versatile display bindings
@ 2016-02-04 14:04 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
This adds bindings for the LCD displays that can be found connected
to the ARM Versatile reference design, interface boards IB1 and
IB2.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
.../devicetree/bindings/display/panel/epson,l2f50113t00.txt | 7 +++++++
.../devicetree/bindings/display/panel/sanyo,alr252rgt.txt | 7 +++++++
.../devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt | 7 +++++++
.../devicetree/bindings/display/panel/sharp,lq084v1dg21.txt | 7 +++++++
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
5 files changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt
diff --git a/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt b/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
new file mode 100644
index 000000000000..58eca804dbe8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
@@ -0,0 +1,7 @@
+Epson Mobile display
+
+Required properties:
+- compatible: should be "epson,l2f50113t00"
+
+This binding is compatible with the panel-dpi binding, which is specified
+in panel-dpi.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt b/Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
new file mode 100644
index 000000000000..d24562b34cd0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
@@ -0,0 +1,7 @@
+Sanyo Electric Co. 2.5" panel
+
+Required properties:
+- compatible: should be "sanyo,alr252rgt"
+
+This binding is compatible with the panel-dpi binding, which is specified
+in panel-dpi.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt b/Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
new file mode 100644
index 000000000000..c1582012d52e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
@@ -0,0 +1,7 @@
+Sanyo Electric Co. 3.8" panel
+
+Required properties:
+- compatible: should be "sanyo,tm38qv67a02a"
+
+This binding is compatible with the panel-dpi binding, which is specified
+in panel-dpi.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt b/Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt
new file mode 100644
index 000000000000..8318c2422740
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt
@@ -0,0 +1,7 @@
+Sharp 8.4" VGA color TFT
+
+Required properties:
+- compatible: should be "sharp,lq084v1dg21"
+
+This binding is compatible with the panel-dpi binding, which is specified
+in panel-dpi.txt in this directory.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 72e2c5a2b327..da5d8bf13818 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -198,6 +198,7 @@ ricoh Ricoh Co. Ltd.
rockchip Fuzhou Rockchip Electronics Co., Ltd
samsung Samsung Semiconductor
sandisk Sandisk Corporation
+sanyo Sanyo Electric Co., Ltd.
sbs Smart Battery System
schindler Schindler
seagate Seagate Technology PLC
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread
* Re: [PATCH 07/11] Documentation/DT: add Versatile display bindings
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-17 9:11 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-17 9:11 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]
On 04/02/16 16:04, Linus Walleij wrote:
> This adds bindings for the LCD displays that can be found connected
> to the ARM Versatile reference design, interface boards IB1 and
> IB2.
>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> .../devicetree/bindings/display/panel/epson,l2f50113t00.txt | 7 +++++++
> .../devicetree/bindings/display/panel/sanyo,alr252rgt.txt | 7 +++++++
> .../devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt | 7 +++++++
> .../devicetree/bindings/display/panel/sharp,lq084v1dg21.txt | 7 +++++++
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 5 files changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
> create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
> create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
> create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt b/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
> new file mode 100644
> index 000000000000..58eca804dbe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
> @@ -0,0 +1,7 @@
> +Epson Mobile display
> +
> +Required properties:
> +- compatible: should be "epson,l2f50113t00"
> +
> +This binding is compatible with the panel-dpi binding, which is specified
> +in panel-dpi.txt in this directory.
Do we really want to add new binding doc files for all panels, even if
they just point to a more generic binding? We may end up with quite a
lot of these, each only saying "look at the panel-dpi.txt".
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 07/11] Documentation/DT: add Versatile display bindings
@ 2016-02-17 9:11 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-17 9:11 UTC (permalink / raw)
To: linux-arm-kernel
On 04/02/16 16:04, Linus Walleij wrote:
> This adds bindings for the LCD displays that can be found connected
> to the ARM Versatile reference design, interface boards IB1 and
> IB2.
>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> .../devicetree/bindings/display/panel/epson,l2f50113t00.txt | 7 +++++++
> .../devicetree/bindings/display/panel/sanyo,alr252rgt.txt | 7 +++++++
> .../devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt | 7 +++++++
> .../devicetree/bindings/display/panel/sharp,lq084v1dg21.txt | 7 +++++++
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 5 files changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
> create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
> create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
> create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt b/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
> new file mode 100644
> index 000000000000..58eca804dbe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
> @@ -0,0 +1,7 @@
> +Epson Mobile display
> +
> +Required properties:
> +- compatible: should be "epson,l2f50113t00"
> +
> +This binding is compatible with the panel-dpi binding, which is specified
> +in panel-dpi.txt in this directory.
Do we really want to add new binding doc files for all panels, even if
they just point to a more generic binding? We may end up with quite a
lot of these, each only saying "look at the panel-dpi.txt".
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/39cfbc9c/attachment-0001.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 07/11] Documentation/DT: add Versatile display bindings
2016-02-17 9:11 ` Tomi Valkeinen
@ 2016-02-18 20:48 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-18 20:48 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 17, 2016 at 10:11 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> +Required properties:
>> +- compatible: should be "epson,l2f50113t00"
>> +
>> +This binding is compatible with the panel-dpi binding, which is specified
>> +in panel-dpi.txt in this directory.
>
> Do we really want to add new binding doc files for all panels, even if
> they just point to a more generic binding? We may end up with quite a
> lot of these, each only saying "look at the panel-dpi.txt".
That's sort of what I'm asking too. But there was some other
file doing exactly this :(
What do you say about just putting a list of compatible panels
directly into panel-dpi.txt?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 07/11] Documentation/DT: add Versatile display bindings
@ 2016-02-18 20:48 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-18 20:48 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 17, 2016 at 10:11 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> +Required properties:
>> +- compatible: should be "epson,l2f50113t00"
>> +
>> +This binding is compatible with the panel-dpi binding, which is specified
>> +in panel-dpi.txt in this directory.
>
> Do we really want to add new binding doc files for all panels, even if
> they just point to a more generic binding? We may end up with quite a
> lot of these, each only saying "look at the panel-dpi.txt".
That's sort of what I'm asking too. But there was some other
file doing exactly this :(
What do you say about just putting a list of compatible panels
directly into panel-dpi.txt?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 08/11] video: ARM CLCD: add special panel hook for Versatiles
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-04 14:04 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
This adds a special panel init hook for the ARM reference designs
Integrator (IM-PD1), Versatile and RealView, so we can configure
a DPI panel from device tree and have it working without
boardfiles for these machines.
Basically this is the same code as from the board files, just
moved over to look up the syscon DT node and manipulate the
special CLCD register from their regmap.
Tested on RealView PB11MPcore.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/video/fbdev/Kconfig | 2 +
drivers/video/fbdev/amba-clcd-versatile.c | 406 ++++++++++++++++++++++++++++++
drivers/video/fbdev/amba-clcd-versatile.h | 17 ++
drivers/video/fbdev/amba-clcd.c | 4 +-
4 files changed, 428 insertions(+), 1 deletion(-)
create mode 100644 drivers/video/fbdev/amba-clcd-versatile.h
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 6dcd91237551..a3fdc4cd1837 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -307,6 +307,8 @@ config PLAT_VERSATILE_CLCD
def_bool ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS || ARCH_INTEGRATOR
depends on ARM
depends on FB_ARMCLCD && FB=y
+ select REGMAP
+ select MFD_SYSCON
config FB_ACORN
bool "Acorn VIDC support"
diff --git a/drivers/video/fbdev/amba-clcd-versatile.c b/drivers/video/fbdev/amba-clcd-versatile.c
index 7a8afcd4573e..5d125f77215d 100644
--- a/drivers/video/fbdev/amba-clcd-versatile.c
+++ b/drivers/video/fbdev/amba-clcd-versatile.c
@@ -3,6 +3,12 @@
#include <linux/amba/bus.h>
#include <linux/amba/clcd.h>
#include <linux/platform_data/video-clcd-versatile.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+#include <linux/bitops.h>
+#include "amba-clcd-versatile.h"
static struct clcd_panel vga = {
.mode = {
@@ -180,3 +186,403 @@ void versatile_clcd_remove_dma(struct clcd_fb *fb)
dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
fb->fb.screen_base, fb->fb.fix.smem_start);
}
+
+#ifdef CONFIG_OF
+
+static struct regmap *versatile_syscon_map;
+static struct regmap *versatile_ib2_map;
+
+/*
+ * We detect the different syscon types from the compatible strings.
+ */
+enum versatile_clcd {
+ INTEGRATOR_CLCD_CM,
+ VERSATILE_CLCD,
+ REALVIEW_CLCD_EB,
+ REALVIEW_CLCD_PB1176,
+ REALVIEW_CLCD_PB11MP,
+ REALVIEW_CLCD_PBA8,
+ REALVIEW_CLCD_PBX,
+};
+
+static const struct of_device_id versatile_clcd_of_match[] = {
+ {
+ .compatible = "arm,core-module-integrator",
+ .data = (void *)INTEGRATOR_CLCD_CM,
+ },
+ {
+ .compatible = "arm,versatile-sysreg",
+ .data = (void *)VERSATILE_CLCD,
+ },
+ {
+ .compatible = "arm,realview-eb-syscon",
+ .data = (void *)REALVIEW_CLCD_EB,
+ },
+ {
+ .compatible = "arm,realview-pb1176-syscon",
+ .data = (void *)REALVIEW_CLCD_PB1176,
+ },
+ {
+ .compatible = "arm,realview-pb11mp-syscon",
+ .data = (void *)REALVIEW_CLCD_PB11MP,
+ },
+ {
+ .compatible = "arm,realview-pba8-syscon",
+ .data = (void *)REALVIEW_CLCD_PBA8,
+ },
+ {
+ .compatible = "arm,realview-pbx-syscon",
+ .data = (void *)REALVIEW_CLCD_PBX,
+ },
+ {},
+};
+
+/*
+ * Core module CLCD control on the Integrator/CP, bits
+ * 8 thru 19 of the CM_CONTROL register controls a bunch
+ * of CLCD settings.
+ */
+#define INTEGRATOR_HDR_CTRL_OFFSET 0x0C
+#define INTEGRATOR_CLCD_LCDBIASEN BIT(8)
+#define INTEGRATOR_CLCD_LCDBIASUP BIT(9)
+#define INTEGRATOR_CLCD_LCDBIASDN BIT(10)
+/* Bits 11,12,13 controls the LCD type */
+#define INTEGRATOR_CLCD_LCDMUX_MASK (BIT(11)|BIT(12)|BIT(13))
+#define INTEGRATOR_CLCD_LCDMUX_LCD24 BIT(11)
+#define INTEGRATOR_CLCD_LCDMUX_VGA565 BIT(12)
+#define INTEGRATOR_CLCD_LCDMUX_SHARP (BIT(11)|BIT(12))
+#define INTEGRATOR_CLCD_LCDMUX_VGA555 BIT(13)
+#define INTEGRATOR_CLCD_LCDMUX_VGA24 (BIT(11)|BIT(12)|BIT(13))
+#define INTEGRATOR_CLCD_LCD0_EN BIT(14)
+#define INTEGRATOR_CLCD_LCD1_EN BIT(15)
+/* R/L flip on Sharp */
+#define INTEGRATOR_CLCD_LCD_STATIC1 BIT(16)
+/* U/D flip on Sharp */
+#define INTEGRATOR_CLCD_LCD_STATIC2 BIT(17)
+/* No connection on Sharp */
+#define INTEGRATOR_CLCD_LCD_STATIC BIT(18)
+/* 0 = 24bit VGA, 1 = 18bit VGA */
+#define INTEGRATOR_CLCD_LCD_N24BITEN BIT(19)
+
+#define INTEGRATOR_CLCD_MASK (INTEGRATOR_CLCD_LCDMUX_MASK | \
+ INTEGRATOR_CLCD_LCD0_EN | \
+ INTEGRATOR_CLCD_LCD1_EN | \
+ INTEGRATOR_CLCD_LCD_STATIC1 | \
+ INTEGRATOR_CLCD_LCD_STATIC2 | \
+ INTEGRATOR_CLCD_LCD_STATIC | \
+ INTEGRATOR_CLCD_LCD_N24BITEN)
+
+static void integrator_clcd_enable(struct clcd_fb *fb)
+{
+ struct fb_var_screeninfo *var = &fb->fb.var;
+ u32 val;
+
+ dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
+
+ val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
+ INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
+ if (var->bits_per_pixel <= 8 ||
+ (var->bits_per_pixel = 16 && var->green.length = 5))
+ /* Pseudocolor, RGB555, BGR555 */
+ val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
+ else if (fb->fb.var.bits_per_pixel <= 16)
+ /* truecolor RGB565 */
+ val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
+ else
+ val = 0; /* no idea for this, don't trust the docs */
+
+ regmap_update_bits(versatile_syscon_map,
+ INTEGRATOR_HDR_CTRL_OFFSET,
+ 0,
+ INTEGRATOR_CLCD_MASK);
+}
+
+/*
+ * This configuration register in the Versatile and RealView
+ * family is uniformly present but appears more and more
+ * unutilized starting with the RealView series.
+ */
+#define SYS_CLCD 0x50
+#define SYS_CLCD_MODE_MASK (BIT(0)|BIT(1))
+#define SYS_CLCD_MODE_888 0
+#define SYS_CLCD_MODE_5551 BIT(0)
+#define SYS_CLCD_MODE_565_R_LSB BIT(1)
+#define SYS_CLCD_MODE_565_B_LSB (BIT(0)|BIT(1))
+#define SYS_CLCD_CONNECTOR_MASK (BIT(2)|BIT(3)|BIT(4)|BIT(5))
+#define SYS_CLCD_NLCDIOON BIT(2)
+#define SYS_CLCD_VDDPOSSWITCH BIT(3)
+#define SYS_CLCD_PWR3V5SWITCH BIT(4)
+#define SYS_CLCD_VDDNEGSWITCH BIT(5)
+#define SYS_CLCD_TSNSS BIT(6) /* touchscreen enable */
+#define SYS_CLCD_SSPEXP BIT(7) /* SSP expansion enable */
+
+/* The Versatile can detect the connected panel type */
+#define SYS_CLCD_CLCDID_MASK (BIT(8)|BIT(9)|BIT(10)|BIT(11)|BIT(12))
+#define SYS_CLCD_ID_SANYO_3_8 (0x00 << 8)
+#define SYS_CLCD_ID_SHARP_8_4 (0x01 << 8)
+#define SYS_CLCD_ID_EPSON_2_2 (0x02 << 8)
+#define SYS_CLCD_ID_SANYO_2_5 (0x07 << 8)
+#define SYS_CLCD_ID_VGA (0x1f << 8)
+
+#define SYS_CLCD_TSNDAV BIT(13) /* data ready from TS */
+
+/* IB2 control register for the Versatile daughterboard */
+#define IB2_CTRL 0x00
+#define IB2_CTRL_LCD_SD BIT(1) /* 1 = shut down LCD */
+#define IB2_CTRL_LCD_BL_ON BIT(0)
+#define IB2_CTRL_LCD_MASK (BIT(0)|BIT(1))
+
+static void versatile_clcd_disable(struct clcd_fb *fb)
+{
+ dev_info(&fb->dev->dev, "disable Versatile CLCD connectors\n");
+ regmap_update_bits(versatile_syscon_map,
+ SYS_CLCD,
+ SYS_CLCD_CONNECTOR_MASK,
+ 0);
+
+ /* If we're on an IB2 daughterboard, turn off display */
+ if (versatile_ib2_map) {
+ dev_info(&fb->dev->dev, "disable IB2 display\n");
+ regmap_update_bits(versatile_ib2_map,
+ IB2_CTRL,
+ IB2_CTRL_LCD_MASK,
+ IB2_CTRL_LCD_SD);
+ }
+}
+
+static void versatile_clcd_enable(struct clcd_fb *fb)
+{
+ struct fb_var_screeninfo *var = &fb->fb.var;
+ u32 val = 0;
+
+ dev_info(&fb->dev->dev, "enable Versatile CLCD connectors\n");
+ switch (var->green.length) {
+ case 5:
+ val |= SYS_CLCD_MODE_5551;
+ break;
+ case 6:
+ if (var->red.offset = 0)
+ val |= SYS_CLCD_MODE_565_R_LSB;
+ else
+ val |= SYS_CLCD_MODE_565_B_LSB;
+ break;
+ case 8:
+ val |= SYS_CLCD_MODE_888;
+ break;
+ }
+
+ /* Set up the MUX */
+ regmap_update_bits(versatile_syscon_map,
+ SYS_CLCD,
+ SYS_CLCD_MODE_MASK,
+ val);
+
+ /* Then enable the display */
+ regmap_update_bits(versatile_syscon_map,
+ SYS_CLCD,
+ SYS_CLCD_CONNECTOR_MASK,
+ SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH);
+
+ /* If we're on an IB2 daughterboard, turn on display */
+ if (versatile_ib2_map) {
+ dev_info(&fb->dev->dev, "enable IB2 display\n");
+ regmap_update_bits(versatile_ib2_map,
+ IB2_CTRL,
+ IB2_CTRL_LCD_MASK,
+ IB2_CTRL_LCD_BL_ON);
+ }
+}
+
+static void versatile_clcd_decode(struct clcd_fb *fb, struct clcd_regs *regs)
+{
+ clcdfb_decode(fb, regs);
+
+ /* Always clear BGR for RGB565: we do the routing externally */
+ if (fb->fb.var.green.length = 6)
+ regs->cntl &= ~CNTL_BGR;
+}
+
+static void realview_clcd_disable(struct clcd_fb *fb)
+{
+ dev_info(&fb->dev->dev, "disable RealView CLCD connectors\n");
+ regmap_update_bits(versatile_syscon_map,
+ SYS_CLCD,
+ SYS_CLCD_CONNECTOR_MASK,
+ 0);
+}
+
+static void realview_clcd_enable(struct clcd_fb *fb)
+{
+ dev_info(&fb->dev->dev, "enable RealView CLCD connectors\n");
+ regmap_update_bits(versatile_syscon_map,
+ SYS_CLCD,
+ SYS_CLCD_CONNECTOR_MASK,
+ SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH);
+}
+
+struct versatile_panel {
+ u32 id;
+ char *compatible;
+ bool ib2;
+};
+
+static const struct versatile_panel versatile_panels[] = {
+ {
+ .id = SYS_CLCD_ID_VGA,
+ .compatible = "VGA",
+ },
+ {
+ .id = SYS_CLCD_ID_SANYO_3_8,
+ .compatible = "sanyo,tm38qv67a02a",
+ },
+ {
+ .id = SYS_CLCD_ID_SHARP_8_4,
+ .compatible = "sharp,lq084v1dg21",
+ },
+ {
+ .id = SYS_CLCD_ID_EPSON_2_2,
+ .compatible = "epson,l2f50113t00",
+ },
+ {
+ .id = SYS_CLCD_ID_SANYO_2_5,
+ .compatible = "sanyo,alr252rgt",
+ .ib2 = true,
+ },
+};
+
+static void versatile_panel_probe(struct device *dev,
+ struct device_node **endpoint)
+{
+ struct versatile_panel const *vpanel = NULL;
+ struct device_node *ep = NULL;
+ struct device_node *panel = NULL;
+ u32 val;
+ int ret;
+ int i;
+
+ /*
+ * The Versatile CLCD has a panel auto-detection mechanism.
+ * We use this and look for the compatible panel in the
+ * device tree.
+ */
+ ret = regmap_read(versatile_syscon_map, SYS_CLCD, &val);
+ if (ret) {
+ dev_err(dev, "cannot read CLCD syscon register\n");
+ return;
+ }
+ val &= SYS_CLCD_CLCDID_MASK;
+ dev_info(dev, "SYS_CLCD=%08x\n", val);
+
+ /* First find corresponding panel information */
+ for (i = 0; i < ARRAY_SIZE(versatile_panels); i++) {
+ vpanel = &versatile_panels[i];
+
+ if (val = vpanel->id) {
+ dev_err(dev, "autodetected panel \"%s\"\n",
+ vpanel->compatible);
+ break;
+ }
+ }
+ if (i = ARRAY_SIZE(versatile_panels)) {
+ dev_err(dev, "could not auto-detect panel\n");
+ return;
+ }
+
+ /* Then look for a compatible endpoint/panel */
+ for_each_endpoint_of_node(dev->of_node, ep) {
+ panel = of_graph_get_remote_port_parent(ep);
+ if (!panel) {
+ dev_err(dev, "could not locate remote port for panel\n");
+ return;
+ }
+
+ if (of_device_is_compatible(panel, vpanel->compatible))
+ break;
+ }
+ if (ep = NULL) {
+ dev_err(dev, "could not find a panel compatible with \"%s\"\n",
+ vpanel->compatible);
+ return;
+ }
+
+
+ /*
+ * If we have a Sanyo 2.5" port
+ * that we're running on an IB2 and proceed to look for the
+ * IB2 syscon regmap.
+ */
+ if (!vpanel->ib2) {
+ /* Tell the driver to use this panel */
+ *endpoint = ep;
+ return;
+ }
+
+ versatile_ib2_map = syscon_regmap_lookup_by_compatible(
+ "arm,versatile-ib2-syscon");
+ if (IS_ERR(versatile_ib2_map)) {
+ dev_err(dev, "could not locate IB2 control register\n");
+ versatile_ib2_map = NULL;
+ return;
+ }
+ *endpoint = ep;
+}
+
+int versatile_clcd_init_panel(struct clcd_fb *fb,
+ struct device_node **endpoint)
+{
+ const struct of_device_id *clcd_id;
+ enum versatile_clcd versatile_clcd_type;
+ struct device_node *np;
+ struct regmap *map;
+ struct device *dev = &fb->dev->dev;
+
+ np = of_find_matching_node_and_match(NULL, versatile_clcd_of_match,
+ &clcd_id);
+ if (!np) {
+ dev_err(dev, "no Versatile syscon node\n");
+ return -ENODEV;
+ }
+ versatile_clcd_type = (enum versatile_clcd)clcd_id->data;
+
+ map = syscon_node_to_regmap(np);
+ if (!map) {
+ dev_err(dev, "no Versatile syscon regmap\n");
+ return -ENODEV;
+ }
+
+ switch (versatile_clcd_type) {
+ case INTEGRATOR_CLCD_CM:
+ versatile_syscon_map = map;
+ fb->board->enable = integrator_clcd_enable;
+ /* Override the caps, we have only these */
+ fb->board->caps = CLCD_CAP_5551 | CLCD_CAP_RGB565 |
+ CLCD_CAP_888;
+ dev_info(dev, "set up callbacks for Integrator PL110\n");
+ break;
+ case VERSATILE_CLCD:
+ versatile_syscon_map = map;
+ fb->board->enable = versatile_clcd_enable;
+ fb->board->disable = versatile_clcd_disable;
+ fb->board->decode = versatile_clcd_decode;
+ versatile_panel_probe(dev, endpoint);
+ dev_info(dev, "set up callbacks for Versatile\n");
+ break;
+ case REALVIEW_CLCD_EB:
+ case REALVIEW_CLCD_PB1176:
+ case REALVIEW_CLCD_PB11MP:
+ case REALVIEW_CLCD_PBA8:
+ case REALVIEW_CLCD_PBX:
+ versatile_syscon_map = map;
+ fb->board->enable = realview_clcd_enable;
+ fb->board->disable = realview_clcd_disable;
+ dev_info(dev, "set up callbacks for RealView PL111\n");
+ break;
+ default:
+ dev_info(dev, "unknown Versatile system controller\n");
+ break;
+ }
+
+ return 0;
+}
+
+#endif
diff --git a/drivers/video/fbdev/amba-clcd-versatile.h b/drivers/video/fbdev/amba-clcd-versatile.h
new file mode 100644
index 000000000000..dc44557a2466
--- /dev/null
+++ b/drivers/video/fbdev/amba-clcd-versatile.h
@@ -0,0 +1,17 @@
+/*
+ * Special local versatile callbacks
+ */
+#include <linux/of.h>
+#include <linux/amba/bus.h>
+#include <linux/platform_data/video-clcd-versatile.h>
+
+#if defined(CONFIG_PLAT_VERSATILE_CLCD) && defined(CONFIG_OF)
+int versatile_clcd_init_panel(struct clcd_fb *fb,
+ struct device_node **endpoint);
+#else
+static inline int versatile_clcd_init_panel(struct clcd_fb *fb,
+ struct device_node **endpoint)
+{
+ return 0;
+}
+#endif
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 53c5ec31168d..e1897cb657f5 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -38,6 +38,7 @@
#include <asm/sizes.h>
#include "amba-clcd-nomadik.h"
+#include "amba-clcd-versatile.h"
#define to_clcd(info) container_of(info, struct clcd_fb, fb)
@@ -1042,7 +1043,8 @@ static int clcdfb_remove(struct amba_device *dev)
}
static struct clcd_vendor_data vendor_arm = {
- /* No special business */
+ /* Sets up the versatile board displays */
+ .init_panel = versatile_clcd_init_panel,
};
static struct clcd_vendor_data vendor_nomadik = {
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread* [PATCH 08/11] video: ARM CLCD: add special panel hook for Versatiles
@ 2016-02-04 14:04 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
This adds a special panel init hook for the ARM reference designs
Integrator (IM-PD1), Versatile and RealView, so we can configure
a DPI panel from device tree and have it working without
boardfiles for these machines.
Basically this is the same code as from the board files, just
moved over to look up the syscon DT node and manipulate the
special CLCD register from their regmap.
Tested on RealView PB11MPcore.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/video/fbdev/Kconfig | 2 +
drivers/video/fbdev/amba-clcd-versatile.c | 406 ++++++++++++++++++++++++++++++
drivers/video/fbdev/amba-clcd-versatile.h | 17 ++
drivers/video/fbdev/amba-clcd.c | 4 +-
4 files changed, 428 insertions(+), 1 deletion(-)
create mode 100644 drivers/video/fbdev/amba-clcd-versatile.h
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 6dcd91237551..a3fdc4cd1837 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -307,6 +307,8 @@ config PLAT_VERSATILE_CLCD
def_bool ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS || ARCH_INTEGRATOR
depends on ARM
depends on FB_ARMCLCD && FB=y
+ select REGMAP
+ select MFD_SYSCON
config FB_ACORN
bool "Acorn VIDC support"
diff --git a/drivers/video/fbdev/amba-clcd-versatile.c b/drivers/video/fbdev/amba-clcd-versatile.c
index 7a8afcd4573e..5d125f77215d 100644
--- a/drivers/video/fbdev/amba-clcd-versatile.c
+++ b/drivers/video/fbdev/amba-clcd-versatile.c
@@ -3,6 +3,12 @@
#include <linux/amba/bus.h>
#include <linux/amba/clcd.h>
#include <linux/platform_data/video-clcd-versatile.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+#include <linux/bitops.h>
+#include "amba-clcd-versatile.h"
static struct clcd_panel vga = {
.mode = {
@@ -180,3 +186,403 @@ void versatile_clcd_remove_dma(struct clcd_fb *fb)
dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
fb->fb.screen_base, fb->fb.fix.smem_start);
}
+
+#ifdef CONFIG_OF
+
+static struct regmap *versatile_syscon_map;
+static struct regmap *versatile_ib2_map;
+
+/*
+ * We detect the different syscon types from the compatible strings.
+ */
+enum versatile_clcd {
+ INTEGRATOR_CLCD_CM,
+ VERSATILE_CLCD,
+ REALVIEW_CLCD_EB,
+ REALVIEW_CLCD_PB1176,
+ REALVIEW_CLCD_PB11MP,
+ REALVIEW_CLCD_PBA8,
+ REALVIEW_CLCD_PBX,
+};
+
+static const struct of_device_id versatile_clcd_of_match[] = {
+ {
+ .compatible = "arm,core-module-integrator",
+ .data = (void *)INTEGRATOR_CLCD_CM,
+ },
+ {
+ .compatible = "arm,versatile-sysreg",
+ .data = (void *)VERSATILE_CLCD,
+ },
+ {
+ .compatible = "arm,realview-eb-syscon",
+ .data = (void *)REALVIEW_CLCD_EB,
+ },
+ {
+ .compatible = "arm,realview-pb1176-syscon",
+ .data = (void *)REALVIEW_CLCD_PB1176,
+ },
+ {
+ .compatible = "arm,realview-pb11mp-syscon",
+ .data = (void *)REALVIEW_CLCD_PB11MP,
+ },
+ {
+ .compatible = "arm,realview-pba8-syscon",
+ .data = (void *)REALVIEW_CLCD_PBA8,
+ },
+ {
+ .compatible = "arm,realview-pbx-syscon",
+ .data = (void *)REALVIEW_CLCD_PBX,
+ },
+ {},
+};
+
+/*
+ * Core module CLCD control on the Integrator/CP, bits
+ * 8 thru 19 of the CM_CONTROL register controls a bunch
+ * of CLCD settings.
+ */
+#define INTEGRATOR_HDR_CTRL_OFFSET 0x0C
+#define INTEGRATOR_CLCD_LCDBIASEN BIT(8)
+#define INTEGRATOR_CLCD_LCDBIASUP BIT(9)
+#define INTEGRATOR_CLCD_LCDBIASDN BIT(10)
+/* Bits 11,12,13 controls the LCD type */
+#define INTEGRATOR_CLCD_LCDMUX_MASK (BIT(11)|BIT(12)|BIT(13))
+#define INTEGRATOR_CLCD_LCDMUX_LCD24 BIT(11)
+#define INTEGRATOR_CLCD_LCDMUX_VGA565 BIT(12)
+#define INTEGRATOR_CLCD_LCDMUX_SHARP (BIT(11)|BIT(12))
+#define INTEGRATOR_CLCD_LCDMUX_VGA555 BIT(13)
+#define INTEGRATOR_CLCD_LCDMUX_VGA24 (BIT(11)|BIT(12)|BIT(13))
+#define INTEGRATOR_CLCD_LCD0_EN BIT(14)
+#define INTEGRATOR_CLCD_LCD1_EN BIT(15)
+/* R/L flip on Sharp */
+#define INTEGRATOR_CLCD_LCD_STATIC1 BIT(16)
+/* U/D flip on Sharp */
+#define INTEGRATOR_CLCD_LCD_STATIC2 BIT(17)
+/* No connection on Sharp */
+#define INTEGRATOR_CLCD_LCD_STATIC BIT(18)
+/* 0 = 24bit VGA, 1 = 18bit VGA */
+#define INTEGRATOR_CLCD_LCD_N24BITEN BIT(19)
+
+#define INTEGRATOR_CLCD_MASK (INTEGRATOR_CLCD_LCDMUX_MASK | \
+ INTEGRATOR_CLCD_LCD0_EN | \
+ INTEGRATOR_CLCD_LCD1_EN | \
+ INTEGRATOR_CLCD_LCD_STATIC1 | \
+ INTEGRATOR_CLCD_LCD_STATIC2 | \
+ INTEGRATOR_CLCD_LCD_STATIC | \
+ INTEGRATOR_CLCD_LCD_N24BITEN)
+
+static void integrator_clcd_enable(struct clcd_fb *fb)
+{
+ struct fb_var_screeninfo *var = &fb->fb.var;
+ u32 val;
+
+ dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
+
+ val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
+ INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
+ if (var->bits_per_pixel <= 8 ||
+ (var->bits_per_pixel == 16 && var->green.length == 5))
+ /* Pseudocolor, RGB555, BGR555 */
+ val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
+ else if (fb->fb.var.bits_per_pixel <= 16)
+ /* truecolor RGB565 */
+ val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
+ else
+ val = 0; /* no idea for this, don't trust the docs */
+
+ regmap_update_bits(versatile_syscon_map,
+ INTEGRATOR_HDR_CTRL_OFFSET,
+ 0,
+ INTEGRATOR_CLCD_MASK);
+}
+
+/*
+ * This configuration register in the Versatile and RealView
+ * family is uniformly present but appears more and more
+ * unutilized starting with the RealView series.
+ */
+#define SYS_CLCD 0x50
+#define SYS_CLCD_MODE_MASK (BIT(0)|BIT(1))
+#define SYS_CLCD_MODE_888 0
+#define SYS_CLCD_MODE_5551 BIT(0)
+#define SYS_CLCD_MODE_565_R_LSB BIT(1)
+#define SYS_CLCD_MODE_565_B_LSB (BIT(0)|BIT(1))
+#define SYS_CLCD_CONNECTOR_MASK (BIT(2)|BIT(3)|BIT(4)|BIT(5))
+#define SYS_CLCD_NLCDIOON BIT(2)
+#define SYS_CLCD_VDDPOSSWITCH BIT(3)
+#define SYS_CLCD_PWR3V5SWITCH BIT(4)
+#define SYS_CLCD_VDDNEGSWITCH BIT(5)
+#define SYS_CLCD_TSNSS BIT(6) /* touchscreen enable */
+#define SYS_CLCD_SSPEXP BIT(7) /* SSP expansion enable */
+
+/* The Versatile can detect the connected panel type */
+#define SYS_CLCD_CLCDID_MASK (BIT(8)|BIT(9)|BIT(10)|BIT(11)|BIT(12))
+#define SYS_CLCD_ID_SANYO_3_8 (0x00 << 8)
+#define SYS_CLCD_ID_SHARP_8_4 (0x01 << 8)
+#define SYS_CLCD_ID_EPSON_2_2 (0x02 << 8)
+#define SYS_CLCD_ID_SANYO_2_5 (0x07 << 8)
+#define SYS_CLCD_ID_VGA (0x1f << 8)
+
+#define SYS_CLCD_TSNDAV BIT(13) /* data ready from TS */
+
+/* IB2 control register for the Versatile daughterboard */
+#define IB2_CTRL 0x00
+#define IB2_CTRL_LCD_SD BIT(1) /* 1 = shut down LCD */
+#define IB2_CTRL_LCD_BL_ON BIT(0)
+#define IB2_CTRL_LCD_MASK (BIT(0)|BIT(1))
+
+static void versatile_clcd_disable(struct clcd_fb *fb)
+{
+ dev_info(&fb->dev->dev, "disable Versatile CLCD connectors\n");
+ regmap_update_bits(versatile_syscon_map,
+ SYS_CLCD,
+ SYS_CLCD_CONNECTOR_MASK,
+ 0);
+
+ /* If we're on an IB2 daughterboard, turn off display */
+ if (versatile_ib2_map) {
+ dev_info(&fb->dev->dev, "disable IB2 display\n");
+ regmap_update_bits(versatile_ib2_map,
+ IB2_CTRL,
+ IB2_CTRL_LCD_MASK,
+ IB2_CTRL_LCD_SD);
+ }
+}
+
+static void versatile_clcd_enable(struct clcd_fb *fb)
+{
+ struct fb_var_screeninfo *var = &fb->fb.var;
+ u32 val = 0;
+
+ dev_info(&fb->dev->dev, "enable Versatile CLCD connectors\n");
+ switch (var->green.length) {
+ case 5:
+ val |= SYS_CLCD_MODE_5551;
+ break;
+ case 6:
+ if (var->red.offset == 0)
+ val |= SYS_CLCD_MODE_565_R_LSB;
+ else
+ val |= SYS_CLCD_MODE_565_B_LSB;
+ break;
+ case 8:
+ val |= SYS_CLCD_MODE_888;
+ break;
+ }
+
+ /* Set up the MUX */
+ regmap_update_bits(versatile_syscon_map,
+ SYS_CLCD,
+ SYS_CLCD_MODE_MASK,
+ val);
+
+ /* Then enable the display */
+ regmap_update_bits(versatile_syscon_map,
+ SYS_CLCD,
+ SYS_CLCD_CONNECTOR_MASK,
+ SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH);
+
+ /* If we're on an IB2 daughterboard, turn on display */
+ if (versatile_ib2_map) {
+ dev_info(&fb->dev->dev, "enable IB2 display\n");
+ regmap_update_bits(versatile_ib2_map,
+ IB2_CTRL,
+ IB2_CTRL_LCD_MASK,
+ IB2_CTRL_LCD_BL_ON);
+ }
+}
+
+static void versatile_clcd_decode(struct clcd_fb *fb, struct clcd_regs *regs)
+{
+ clcdfb_decode(fb, regs);
+
+ /* Always clear BGR for RGB565: we do the routing externally */
+ if (fb->fb.var.green.length == 6)
+ regs->cntl &= ~CNTL_BGR;
+}
+
+static void realview_clcd_disable(struct clcd_fb *fb)
+{
+ dev_info(&fb->dev->dev, "disable RealView CLCD connectors\n");
+ regmap_update_bits(versatile_syscon_map,
+ SYS_CLCD,
+ SYS_CLCD_CONNECTOR_MASK,
+ 0);
+}
+
+static void realview_clcd_enable(struct clcd_fb *fb)
+{
+ dev_info(&fb->dev->dev, "enable RealView CLCD connectors\n");
+ regmap_update_bits(versatile_syscon_map,
+ SYS_CLCD,
+ SYS_CLCD_CONNECTOR_MASK,
+ SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH);
+}
+
+struct versatile_panel {
+ u32 id;
+ char *compatible;
+ bool ib2;
+};
+
+static const struct versatile_panel versatile_panels[] = {
+ {
+ .id = SYS_CLCD_ID_VGA,
+ .compatible = "VGA",
+ },
+ {
+ .id = SYS_CLCD_ID_SANYO_3_8,
+ .compatible = "sanyo,tm38qv67a02a",
+ },
+ {
+ .id = SYS_CLCD_ID_SHARP_8_4,
+ .compatible = "sharp,lq084v1dg21",
+ },
+ {
+ .id = SYS_CLCD_ID_EPSON_2_2,
+ .compatible = "epson,l2f50113t00",
+ },
+ {
+ .id = SYS_CLCD_ID_SANYO_2_5,
+ .compatible = "sanyo,alr252rgt",
+ .ib2 = true,
+ },
+};
+
+static void versatile_panel_probe(struct device *dev,
+ struct device_node **endpoint)
+{
+ struct versatile_panel const *vpanel = NULL;
+ struct device_node *ep = NULL;
+ struct device_node *panel = NULL;
+ u32 val;
+ int ret;
+ int i;
+
+ /*
+ * The Versatile CLCD has a panel auto-detection mechanism.
+ * We use this and look for the compatible panel in the
+ * device tree.
+ */
+ ret = regmap_read(versatile_syscon_map, SYS_CLCD, &val);
+ if (ret) {
+ dev_err(dev, "cannot read CLCD syscon register\n");
+ return;
+ }
+ val &= SYS_CLCD_CLCDID_MASK;
+ dev_info(dev, "SYS_CLCD=%08x\n", val);
+
+ /* First find corresponding panel information */
+ for (i = 0; i < ARRAY_SIZE(versatile_panels); i++) {
+ vpanel = &versatile_panels[i];
+
+ if (val == vpanel->id) {
+ dev_err(dev, "autodetected panel \"%s\"\n",
+ vpanel->compatible);
+ break;
+ }
+ }
+ if (i == ARRAY_SIZE(versatile_panels)) {
+ dev_err(dev, "could not auto-detect panel\n");
+ return;
+ }
+
+ /* Then look for a compatible endpoint/panel */
+ for_each_endpoint_of_node(dev->of_node, ep) {
+ panel = of_graph_get_remote_port_parent(ep);
+ if (!panel) {
+ dev_err(dev, "could not locate remote port for panel\n");
+ return;
+ }
+
+ if (of_device_is_compatible(panel, vpanel->compatible))
+ break;
+ }
+ if (ep == NULL) {
+ dev_err(dev, "could not find a panel compatible with \"%s\"\n",
+ vpanel->compatible);
+ return;
+ }
+
+
+ /*
+ * If we have a Sanyo 2.5" port
+ * that we're running on an IB2 and proceed to look for the
+ * IB2 syscon regmap.
+ */
+ if (!vpanel->ib2) {
+ /* Tell the driver to use this panel */
+ *endpoint = ep;
+ return;
+ }
+
+ versatile_ib2_map = syscon_regmap_lookup_by_compatible(
+ "arm,versatile-ib2-syscon");
+ if (IS_ERR(versatile_ib2_map)) {
+ dev_err(dev, "could not locate IB2 control register\n");
+ versatile_ib2_map = NULL;
+ return;
+ }
+ *endpoint = ep;
+}
+
+int versatile_clcd_init_panel(struct clcd_fb *fb,
+ struct device_node **endpoint)
+{
+ const struct of_device_id *clcd_id;
+ enum versatile_clcd versatile_clcd_type;
+ struct device_node *np;
+ struct regmap *map;
+ struct device *dev = &fb->dev->dev;
+
+ np = of_find_matching_node_and_match(NULL, versatile_clcd_of_match,
+ &clcd_id);
+ if (!np) {
+ dev_err(dev, "no Versatile syscon node\n");
+ return -ENODEV;
+ }
+ versatile_clcd_type = (enum versatile_clcd)clcd_id->data;
+
+ map = syscon_node_to_regmap(np);
+ if (!map) {
+ dev_err(dev, "no Versatile syscon regmap\n");
+ return -ENODEV;
+ }
+
+ switch (versatile_clcd_type) {
+ case INTEGRATOR_CLCD_CM:
+ versatile_syscon_map = map;
+ fb->board->enable = integrator_clcd_enable;
+ /* Override the caps, we have only these */
+ fb->board->caps = CLCD_CAP_5551 | CLCD_CAP_RGB565 |
+ CLCD_CAP_888;
+ dev_info(dev, "set up callbacks for Integrator PL110\n");
+ break;
+ case VERSATILE_CLCD:
+ versatile_syscon_map = map;
+ fb->board->enable = versatile_clcd_enable;
+ fb->board->disable = versatile_clcd_disable;
+ fb->board->decode = versatile_clcd_decode;
+ versatile_panel_probe(dev, endpoint);
+ dev_info(dev, "set up callbacks for Versatile\n");
+ break;
+ case REALVIEW_CLCD_EB:
+ case REALVIEW_CLCD_PB1176:
+ case REALVIEW_CLCD_PB11MP:
+ case REALVIEW_CLCD_PBA8:
+ case REALVIEW_CLCD_PBX:
+ versatile_syscon_map = map;
+ fb->board->enable = realview_clcd_enable;
+ fb->board->disable = realview_clcd_disable;
+ dev_info(dev, "set up callbacks for RealView PL111\n");
+ break;
+ default:
+ dev_info(dev, "unknown Versatile system controller\n");
+ break;
+ }
+
+ return 0;
+}
+
+#endif
diff --git a/drivers/video/fbdev/amba-clcd-versatile.h b/drivers/video/fbdev/amba-clcd-versatile.h
new file mode 100644
index 000000000000..dc44557a2466
--- /dev/null
+++ b/drivers/video/fbdev/amba-clcd-versatile.h
@@ -0,0 +1,17 @@
+/*
+ * Special local versatile callbacks
+ */
+#include <linux/of.h>
+#include <linux/amba/bus.h>
+#include <linux/platform_data/video-clcd-versatile.h>
+
+#if defined(CONFIG_PLAT_VERSATILE_CLCD) && defined(CONFIG_OF)
+int versatile_clcd_init_panel(struct clcd_fb *fb,
+ struct device_node **endpoint);
+#else
+static inline int versatile_clcd_init_panel(struct clcd_fb *fb,
+ struct device_node **endpoint)
+{
+ return 0;
+}
+#endif
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 53c5ec31168d..e1897cb657f5 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -38,6 +38,7 @@
#include <asm/sizes.h>
#include "amba-clcd-nomadik.h"
+#include "amba-clcd-versatile.h"
#define to_clcd(info) container_of(info, struct clcd_fb, fb)
@@ -1042,7 +1043,8 @@ static int clcdfb_remove(struct amba_device *dev)
}
static struct clcd_vendor_data vendor_arm = {
- /* No special business */
+ /* Sets up the versatile board displays */
+ .init_panel = versatile_clcd_init_panel,
};
static struct clcd_vendor_data vendor_nomadik = {
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread
* [PATCH 09/11] ARM: PB11MPCore: define a standard VGA panel
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-04 14:04 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
Let's supply a standard VGA panel by default on the PB11MPCore,
this will work with most monitors. If more screen real estate is
desired, users can update the DPI definition.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/arm-realview-pb11mp.dts | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/arm-realview-pb11mp.dts b/arch/arm/boot/dts/arm-realview-pb11mp.dts
index 3d9b1b0f4ffc..9e744c83f5ee 100644
--- a/arch/arm/boot/dts/arm-realview-pb11mp.dts
+++ b/arch/arm/boot/dts/arm-realview-pb11mp.dts
@@ -629,16 +629,17 @@
};
};
+ /* Standard 640x480 VGA timings */
panel-timing {
- 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>;
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <48>;
+ hfront-porch = <16>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <33>;
+ vfront-porch = <10>;
+ vsync-len = <2>;
};
};
};
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread* [PATCH 09/11] ARM: PB11MPCore: define a standard VGA panel
@ 2016-02-04 14:04 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
Let's supply a standard VGA panel by default on the PB11MPCore,
this will work with most monitors. If more screen real estate is
desired, users can update the DPI definition.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/arm-realview-pb11mp.dts | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/arm-realview-pb11mp.dts b/arch/arm/boot/dts/arm-realview-pb11mp.dts
index 3d9b1b0f4ffc..9e744c83f5ee 100644
--- a/arch/arm/boot/dts/arm-realview-pb11mp.dts
+++ b/arch/arm/boot/dts/arm-realview-pb11mp.dts
@@ -629,16 +629,17 @@
};
};
+ /* Standard 640x480 VGA timings */
panel-timing {
- 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>;
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <48>;
+ hfront-porch = <16>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <33>;
+ vfront-porch = <10>;
+ vsync-len = <2>;
};
};
};
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread
* [PATCH 10/11] ARM: PB1176: define a standard VGA panel
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-04 14:04 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
This defines the CLCD block in the PB1176 and adds a standard
640x480 VGA panel to the device tree.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/arm-realview-pb1176.dts | 40 +++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/arm-realview-pb1176.dts b/arch/arm/boot/dts/arm-realview-pb1176.dts
index d012ecf25127..af10d888545b 100644
--- a/arch/arm/boot/dts/arm-realview-pb1176.dts
+++ b/arch/arm/boot/dts/arm-realview-pb1176.dts
@@ -362,6 +362,46 @@
clocks = <&uartclk>, <&pclk>;
clock-names = "uartclk", "apb_pclk";
};
+
+ clcd@10112000 {
+ compatible = "arm,pl111", "arm,primecell";
+ reg = <0x10112000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupt-names = "combined";
+ interrupts = <0 47 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&oscclk0>, <&pclk>;
+ clock-names = "clcdclk", "apb_pclk";
+
+ port {
+ clcd_pads: endpoint {
+ remote-endpoint = <&clcd_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ };
+
+ panel {
+ compatible = "panel-dpi";
+
+ port {
+ clcd_panel: endpoint {
+ remote-endpoint = <&clcd_pads>;
+ };
+ };
+
+ /* Standard 640x480 VGA timings */
+ panel-timing {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <48>;
+ hfront-porch = <16>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <33>;
+ vfront-porch = <10>;
+ vsync-len = <2>;
+ };
+ };
+ };
};
/* These peripherals are inside the FPGA rather than the DevChip */
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread* [PATCH 10/11] ARM: PB1176: define a standard VGA panel
@ 2016-02-04 14:04 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
This defines the CLCD block in the PB1176 and adds a standard
640x480 VGA panel to the device tree.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/arm-realview-pb1176.dts | 40 +++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/arm-realview-pb1176.dts b/arch/arm/boot/dts/arm-realview-pb1176.dts
index d012ecf25127..af10d888545b 100644
--- a/arch/arm/boot/dts/arm-realview-pb1176.dts
+++ b/arch/arm/boot/dts/arm-realview-pb1176.dts
@@ -362,6 +362,46 @@
clocks = <&uartclk>, <&pclk>;
clock-names = "uartclk", "apb_pclk";
};
+
+ clcd at 10112000 {
+ compatible = "arm,pl111", "arm,primecell";
+ reg = <0x10112000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupt-names = "combined";
+ interrupts = <0 47 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&oscclk0>, <&pclk>;
+ clock-names = "clcdclk", "apb_pclk";
+
+ port {
+ clcd_pads: endpoint {
+ remote-endpoint = <&clcd_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ };
+
+ panel {
+ compatible = "panel-dpi";
+
+ port {
+ clcd_panel: endpoint {
+ remote-endpoint = <&clcd_pads>;
+ };
+ };
+
+ /* Standard 640x480 VGA timings */
+ panel-timing {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <48>;
+ hfront-porch = <16>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <33>;
+ vfront-porch = <10>;
+ vsync-len = <2>;
+ };
+ };
+ };
};
/* These peripherals are inside the FPGA rather than the DevChip */
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-04 14:04 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
This moves the versatile CLCD configuration to the device tree by:
- Deleting the board file set-up of CLCD displays and quirks,
instead relying on the driver to handle this. The driver will
attempt to auto-detect (like the board file did) and match to
a corresponding panel in the device tree.
- Defining all auto-detectable panels in the device tree for the
versatile-ab, defaulting the first one to VGA. The right
panel will be selected at panel initialization, and should
just work for the IB1 daughterboard panels, like EPSON.
- Creating a special superset DTS file for the IB2 daughterboard
(phone form-factor) equipped Versatile, overriding the default VGA
display with the Sanyo 2.5" portrait display definitions, so that
the IB2-equipped Versatile can be used with this. This follows
the pattern of how we define the Versatile PB as a superset of
Versatile AB.
Tested on Versatile AB with just VGA with the default device tree,
and with the IB2 daughterboard with the custom IB2 device tree.
Tested to shunt in XVGA by modifying the device tree and this works
too. Also tested on QEMU for Versatile in both VGA and Sanyo 2.5"
mode. I don't have the IB1 daughterboard and its add-on displays,
but it should work as long as the detection mechanism and device
tree parameters are sound.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/versatile-ab-ib2.dts | 20 ++++
arch/arm/boot/dts/versatile-ab.dts | 203 ++++++++++++++++++++++++++++++++-
arch/arm/mach-versatile/versatile_dt.c | 162 --------------------------
4 files changed, 220 insertions(+), 166 deletions(-)
create mode 100644 arch/arm/boot/dts/versatile-ab-ib2.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70e8b26..76baaa51080c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -743,6 +743,7 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
uniphier-proxstream2-vodka.dtb
dtb-$(CONFIG_ARCH_VERSATILE) += \
versatile-ab.dtb \
+ versatile-ab-ib2.dtb \
versatile-pb.dtb
dtb-$(CONFIG_ARCH_VEXPRESS) += \
vexpress-v2p-ca5s.dtb \
diff --git a/arch/arm/boot/dts/versatile-ab-ib2.dts b/arch/arm/boot/dts/versatile-ab-ib2.dts
new file mode 100644
index 000000000000..4b98b5382922
--- /dev/null
+++ b/arch/arm/boot/dts/versatile-ab-ib2.dts
@@ -0,0 +1,20 @@
+#include <versatile-ab.dts>
+
+/ {
+ model = "ARM Versatile AB + IB2 board";
+
+ /* Special IB2 control register */
+ ib2_syscon@27000000 {
+ compatible = "arm,versatile-ib2-syscon", "syscon", "simple-mfd";
+ reg = <0x27000000 0x4>;
+
+ led@00.4 {
+ compatible = "register-bit-led";
+ offset = <0x00>;
+ mask = <0x10>;
+ label = "versatile-ib2:0";
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts
index 6fd7efbead34..836511cf8046 100644
--- a/arch/arm/boot/dts/versatile-ab.dts
+++ b/arch/arm/boot/dts/versatile-ab.dts
@@ -29,6 +29,147 @@
clock-frequency = <24000000>;
};
+ vga_panel {
+ compatible = "VGA", "panel-dpi";
+ port {
+ clcd_vga_panel: endpoint {
+ remote-endpoint = <&clcd_vga_pads>;
+ };
+ };
+
+ /* Standard 640x480 VGA timings */
+ panel-timing {
+ clock-frequency = <25175000>;
+ pixelclk-active = <0>;
+ hactive = <640>;
+ hback-porch = <48>;
+ hfront-porch = <16>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <33>;
+ vfront-porch = <10>;
+ vsync-len = <2>;
+ };
+ };
+
+ xvga_panel {
+ compatible = "XVGA", "panel-dpi";
+ port {
+ clcd_xvga_panel: endpoint {
+ remote-endpoint = <&clcd_xvga_pads>;
+ };
+ };
+
+ /* Standard 1024x768 XVGA timings */
+ panel-timing {
+ clock-frequency = <63500127>;
+ pixelclk-active = <0>;
+ hactive = <1024>;
+ hback-porch = <152>;
+ hfront-porch = <48>;
+ hsync-len = <104>;
+ vactive = <768>;
+ vback-porch = <23>;
+ vfront-porch = <3>;
+ vsync-len = <4>;
+ };
+ };
+
+ sanyo38_panel {
+ compatible = "sanyo,tm38qv67a02a", "panel-dpi";
+ port {
+ clcd_sanyo38_panel: endpoint {
+ remote-endpoint = <&clcd_sanyo38_pads>;
+ };
+ };
+
+ panel-timing {
+ clock-frequency = <10000000>;
+ pixelclk-active = <1>;
+ hactive = <320>;
+ hback-porch = <6>;
+ hfront-porch = <6>;
+ hsync-len = <6>;
+ vactive = <240>;
+ vback-porch = <6>;
+ vfront-porch = <6>;
+ vsync-len = <0>;
+ };
+ };
+
+ sharp84_panel {
+ compatible = "sharp,lq084v1dg21", "panel-dpi";
+ port {
+ clcd_sharp84_panel: endpoint {
+ remote-endpoint = <&clcd_sharp84_pads>;
+ };
+ };
+
+ /* Standard 640x480 VGA timings */
+ panel-timing {
+ clock-frequency = <25175000>;
+ pixelclk-active = <0>;
+ hactive = <640>;
+ hback-porch = <48>;
+ hfront-porch = <16>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <33>;
+ vfront-porch = <10>;
+ vsync-len = <2>;
+ };
+ };
+
+ /*
+ * The IB2 has a Sanyo ALR252RGT QVGA panel mounted.
+ */
+ sanyo25_panel {
+ compatible = "sanyo,alr252rgt", "panel-dpi";
+ port {
+ clcd_sanyo25_panel: endpoint {
+ remote-endpoint = <&clcd_sanyo25_pads>;
+ };
+ };
+
+ panel-timing {
+ clock-frequency = <5440000>;
+ pixelclk-active = <0>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ hactive = <240>;
+ hback-porch = <20>;
+ hfront-porch = <10>;
+ hsync-len = <10>;
+ vactive = <320>;
+ vback-porch = <2>;
+ vfront-porch = <2>;
+ vsync-len = <2>;
+ };
+ };
+
+ epson_panel {
+ compatible = "epson,l2f50113t00", "panel-dpi";
+ port {
+ clcd_epson_panel: endpoint {
+ remote-endpoint = <&clcd_epson_pads>;
+ };
+ };
+
+ panel-timing {
+ clock-frequency = <16000000>;
+ pixelclk-active = <0>;
+ hactive = <176>;
+ hback-porch = <3>;
+ hfront-porch = <2>;
+ hsync-len = <3>;
+ vactive = <220>;
+ vback-porch = <1>;
+ vfront-porch = <0>;
+ vsync-len = <2>;
+ };
+ };
+
core-module@10000000 {
compatible = "arm,core-module-versatile", "syscon", "simple-mfd";
reg = <0x10000000 0x200>;
@@ -93,10 +234,20 @@
default-state = "off";
};
- /* OSC1 on AB, OSC4 on PB */
- osc1: cm_aux_osc@24M {
+ oscclk0: osc0@0c {
+ compatible = "arm,syscon-icst307";
#clock-cells = <0>;
- compatible = "arm,versatile-cm-auxosc";
+ lock-offset = <0x20>;
+ vco-offset = <0x0C>;
+ clocks = <&xtal24mhz>;
+ };
+
+ /* This is called OSC1 on AB, OSC4 on PB, call it OSC4 here */
+ oscclk4: osc4@1c {
+ compatible = "arm,syscon-icst307";
+ #clock-cells = <0>;
+ lock-offset = <0x20>;
+ vco-offset = <0x1C>;
clocks = <&xtal24mhz>;
};
@@ -227,8 +378,52 @@
compatible = "arm,pl110", "arm,primecell";
reg = <0x10120000 0x1000>;
interrupts = <16>;
- clocks = <&osc1>, <&pclk>;
+ clocks = <&oscclk4>, <&pclk>;
clock-names = "clcd", "apb_pclk";
+ /* 16bpp @ 25.175MHz = 50350000 bytes per second */
+ max-memory-bandwidth = <50350000>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ /*
+ * The CLCD connects to either of these panels.
+ * at run-time, board-specific code will
+ * detect and select the right one. If no
+ * panel is detected, the first one (VGA)
+ * will be used by default.
+ */
+ clcd_vga_pads: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&clcd_vga_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
+ };
+ clcd_xvga_pads: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&clcd_xvga_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
+ };
+ clcd_sanyo38_pads: endpoint@2 {
+ reg = <2>;
+ remote-endpoint = <&clcd_sanyo38_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ clcd_sharp84_pads: endpoint@3 {
+ reg = <3>;
+ remote-endpoint = <&clcd_sharp84_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ clcd_sanyo25_pads: endpoint@4 {
+ reg = <4>;
+ remote-endpoint = <&clcd_sanyo25_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ clcd_epson_pads: endpoint@5 {
+ reg = <5>;
+ remote-endpoint = <&clcd_epson_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ };
};
sctl@101e0000 {
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index c44871851255..ebe27945fea5 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -29,8 +29,6 @@
#include <linux/of_platform.h>
#include <linux/slab.h>
#include <linux/amba/bus.h>
-#include <linux/amba/clcd.h>
-#include <linux/platform_data/video-clcd-versatile.h>
#include <linux/amba/mmci.h>
#include <linux/mtd/physmap.h>
#include <asm/mach-types.h>
@@ -57,7 +55,6 @@
#define VERSATILE_SYS_PCICTL_OFFSET 0x44
#define VERSATILE_SYS_MCI_OFFSET 0x48
#define VERSATILE_SYS_FLASH_OFFSET 0x4C
-#define VERSATILE_SYS_CLCD_OFFSET 0x50
/*
* VERSATILE_SYS_FLASH
@@ -69,10 +66,7 @@
*/
#define VERSATILE_MMCI0_BASE 0x10005000 /* MMC interface */
#define VERSATILE_MMCI1_BASE 0x1000B000 /* MMC Interface */
-#define VERSATILE_CLCD_BASE 0x10120000 /* CLCD */
#define VERSATILE_SCTL_BASE 0x101E0000 /* System controller */
-#define VERSATILE_IB2_BASE 0x24000000 /* IB2 module */
-#define VERSATILE_IB2_CTL_BASE (VERSATILE_IB2_BASE + 0x03000000)
/*
* System controller bit assignment
@@ -86,7 +80,6 @@
#define VERSATILE_TIMER4_EnSel 21
static void __iomem *versatile_sys_base;
-static void __iomem *versatile_ib2_ctrl;
static void versatile_flash_set_vpp(struct platform_device *pdev, int on)
{
@@ -149,158 +142,6 @@ static struct mmci_platform_data mmc1_plat_data = {
};
/*
- * CLCD support.
- */
-#define SYS_CLCD_MODE_MASK (3 << 0)
-#define SYS_CLCD_MODE_888 (0 << 0)
-#define SYS_CLCD_MODE_5551 (1 << 0)
-#define SYS_CLCD_MODE_565_RLSB (2 << 0)
-#define SYS_CLCD_MODE_565_BLSB (3 << 0)
-#define SYS_CLCD_NLCDIOON (1 << 2)
-#define SYS_CLCD_VDDPOSSWITCH (1 << 3)
-#define SYS_CLCD_PWR3V5SWITCH (1 << 4)
-#define SYS_CLCD_ID_MASK (0x1f << 8)
-#define SYS_CLCD_ID_SANYO_3_8 (0x00 << 8)
-#define SYS_CLCD_ID_UNKNOWN_8_4 (0x01 << 8)
-#define SYS_CLCD_ID_EPSON_2_2 (0x02 << 8)
-#define SYS_CLCD_ID_SANYO_2_5 (0x07 << 8)
-#define SYS_CLCD_ID_VGA (0x1f << 8)
-
-static bool is_sanyo_2_5_lcd;
-
-/*
- * Disable all display connectors on the interface module.
- */
-static void versatile_clcd_disable(struct clcd_fb *fb)
-{
- void __iomem *sys_clcd = versatile_sys_base + VERSATILE_SYS_CLCD_OFFSET;
- u32 val;
-
- val = readl(sys_clcd);
- val &= ~SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
- writel(val, sys_clcd);
-
- /*
- * If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light off
- */
- if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
- unsigned long ctrl;
-
- ctrl = readl(versatile_ib2_ctrl);
- ctrl &= ~0x01;
- writel(ctrl, versatile_ib2_ctrl);
- }
-}
-
-/*
- * Enable the relevant connector on the interface module.
- */
-static void versatile_clcd_enable(struct clcd_fb *fb)
-{
- struct fb_var_screeninfo *var = &fb->fb.var;
- void __iomem *sys_clcd = versatile_sys_base + VERSATILE_SYS_CLCD_OFFSET;
- u32 val;
-
- val = readl(sys_clcd);
- val &= ~SYS_CLCD_MODE_MASK;
-
- switch (var->green.length) {
- case 5:
- val |= SYS_CLCD_MODE_5551;
- break;
- case 6:
- if (var->red.offset = 0)
- val |= SYS_CLCD_MODE_565_RLSB;
- else
- val |= SYS_CLCD_MODE_565_BLSB;
- break;
- case 8:
- val |= SYS_CLCD_MODE_888;
- break;
- }
-
- /*
- * Set the MUX
- */
- writel(val, sys_clcd);
-
- /*
- * And now enable the PSUs
- */
- val |= SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
- writel(val, sys_clcd);
-
- /*
- * If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light on
- */
- if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
- unsigned long ctrl;
-
- ctrl = readl(versatile_ib2_ctrl);
- ctrl |= 0x01;
- writel(ctrl, versatile_ib2_ctrl);
- }
-}
-
-/*
- * Detect which LCD panel is connected, and return the appropriate
- * clcd_panel structure. Note: we do not have any information on
- * the required timings for the 8.4in panel, so we presently assume
- * VGA timings.
- */
-static int versatile_clcd_setup(struct clcd_fb *fb)
-{
- void __iomem *sys_clcd = versatile_sys_base + VERSATILE_SYS_CLCD_OFFSET;
- const char *panel_name;
- u32 val;
-
- is_sanyo_2_5_lcd = false;
-
- val = readl(sys_clcd) & SYS_CLCD_ID_MASK;
- if (val = SYS_CLCD_ID_SANYO_3_8)
- panel_name = "Sanyo TM38QV67A02A";
- else if (val = SYS_CLCD_ID_SANYO_2_5) {
- panel_name = "Sanyo QVGA Portrait";
- is_sanyo_2_5_lcd = true;
- } else if (val = SYS_CLCD_ID_EPSON_2_2)
- panel_name = "Epson L2F50113T00";
- else if (val = SYS_CLCD_ID_VGA)
- panel_name = "VGA";
- else {
- printk(KERN_ERR "CLCD: unknown LCD panel ID 0x%08x, using VGA\n",
- val);
- panel_name = "VGA";
- }
-
- fb->panel = versatile_clcd_get_panel(panel_name);
- if (!fb->panel)
- return -EINVAL;
-
- return versatile_clcd_setup_dma(fb, SZ_1M);
-}
-
-static void versatile_clcd_decode(struct clcd_fb *fb, struct clcd_regs *regs)
-{
- clcdfb_decode(fb, regs);
-
- /* Always clear BGR for RGB565: we do the routing externally */
- if (fb->fb.var.green.length = 6)
- regs->cntl &= ~CNTL_BGR;
-}
-
-static struct clcd_board clcd_plat_data = {
- .name = "Versatile",
- .caps = CLCD_CAP_5551 | CLCD_CAP_565 | CLCD_CAP_888,
- .check = clcdfb_check,
- .decode = versatile_clcd_decode,
- .disable = versatile_clcd_disable,
- .enable = versatile_clcd_enable,
- .setup = versatile_clcd_setup,
- .mmap = versatile_clcd_mmap_dma,
- .remove = versatile_clcd_remove_dma,
-};
-
-/*
* Lookup table for attaching a specific name and platform_data pointer to
* devices as they get created by of_platform_populate(). Ideally this table
* would not exist, but the current clock implementation depends on some devices
@@ -309,7 +150,6 @@ static struct clcd_board clcd_plat_data = {
struct of_dev_auxdata versatile_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI0_BASE, "fpga:05", &mmc0_plat_data),
OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI1_BASE, "fpga:0b", &mmc1_plat_data),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_CLCD_BASE, "dev:20", &clcd_plat_data),
{}
};
@@ -400,8 +240,6 @@ static void __init versatile_dt_init(void)
versatile_sys_base = of_iomap(np, 0);
WARN_ON(!versatile_sys_base);
- versatile_ib2_ctrl = ioremap(VERSATILE_IB2_CTL_BASE, SZ_4K);
-
versatile_dt_pci_init();
platform_device_register(&versatile_flash_device);
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-04 14:04 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
This moves the versatile CLCD configuration to the device tree by:
- Deleting the board file set-up of CLCD displays and quirks,
instead relying on the driver to handle this. The driver will
attempt to auto-detect (like the board file did) and match to
a corresponding panel in the device tree.
- Defining all auto-detectable panels in the device tree for the
versatile-ab, defaulting the first one to VGA. The right
panel will be selected at panel initialization, and should
just work for the IB1 daughterboard panels, like EPSON.
- Creating a special superset DTS file for the IB2 daughterboard
(phone form-factor) equipped Versatile, overriding the default VGA
display with the Sanyo 2.5" portrait display definitions, so that
the IB2-equipped Versatile can be used with this. This follows
the pattern of how we define the Versatile PB as a superset of
Versatile AB.
Tested on Versatile AB with just VGA with the default device tree,
and with the IB2 daughterboard with the custom IB2 device tree.
Tested to shunt in XVGA by modifying the device tree and this works
too. Also tested on QEMU for Versatile in both VGA and Sanyo 2.5"
mode. I don't have the IB1 daughterboard and its add-on displays,
but it should work as long as the detection mechanism and device
tree parameters are sound.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/versatile-ab-ib2.dts | 20 ++++
arch/arm/boot/dts/versatile-ab.dts | 203 ++++++++++++++++++++++++++++++++-
arch/arm/mach-versatile/versatile_dt.c | 162 --------------------------
4 files changed, 220 insertions(+), 166 deletions(-)
create mode 100644 arch/arm/boot/dts/versatile-ab-ib2.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70e8b26..76baaa51080c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -743,6 +743,7 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
uniphier-proxstream2-vodka.dtb
dtb-$(CONFIG_ARCH_VERSATILE) += \
versatile-ab.dtb \
+ versatile-ab-ib2.dtb \
versatile-pb.dtb
dtb-$(CONFIG_ARCH_VEXPRESS) += \
vexpress-v2p-ca5s.dtb \
diff --git a/arch/arm/boot/dts/versatile-ab-ib2.dts b/arch/arm/boot/dts/versatile-ab-ib2.dts
new file mode 100644
index 000000000000..4b98b5382922
--- /dev/null
+++ b/arch/arm/boot/dts/versatile-ab-ib2.dts
@@ -0,0 +1,20 @@
+#include <versatile-ab.dts>
+
+/ {
+ model = "ARM Versatile AB + IB2 board";
+
+ /* Special IB2 control register */
+ ib2_syscon at 27000000 {
+ compatible = "arm,versatile-ib2-syscon", "syscon", "simple-mfd";
+ reg = <0x27000000 0x4>;
+
+ led at 00.4 {
+ compatible = "register-bit-led";
+ offset = <0x00>;
+ mask = <0x10>;
+ label = "versatile-ib2:0";
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts
index 6fd7efbead34..836511cf8046 100644
--- a/arch/arm/boot/dts/versatile-ab.dts
+++ b/arch/arm/boot/dts/versatile-ab.dts
@@ -29,6 +29,147 @@
clock-frequency = <24000000>;
};
+ vga_panel {
+ compatible = "VGA", "panel-dpi";
+ port {
+ clcd_vga_panel: endpoint {
+ remote-endpoint = <&clcd_vga_pads>;
+ };
+ };
+
+ /* Standard 640x480 VGA timings */
+ panel-timing {
+ clock-frequency = <25175000>;
+ pixelclk-active = <0>;
+ hactive = <640>;
+ hback-porch = <48>;
+ hfront-porch = <16>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <33>;
+ vfront-porch = <10>;
+ vsync-len = <2>;
+ };
+ };
+
+ xvga_panel {
+ compatible = "XVGA", "panel-dpi";
+ port {
+ clcd_xvga_panel: endpoint {
+ remote-endpoint = <&clcd_xvga_pads>;
+ };
+ };
+
+ /* Standard 1024x768 XVGA timings */
+ panel-timing {
+ clock-frequency = <63500127>;
+ pixelclk-active = <0>;
+ hactive = <1024>;
+ hback-porch = <152>;
+ hfront-porch = <48>;
+ hsync-len = <104>;
+ vactive = <768>;
+ vback-porch = <23>;
+ vfront-porch = <3>;
+ vsync-len = <4>;
+ };
+ };
+
+ sanyo38_panel {
+ compatible = "sanyo,tm38qv67a02a", "panel-dpi";
+ port {
+ clcd_sanyo38_panel: endpoint {
+ remote-endpoint = <&clcd_sanyo38_pads>;
+ };
+ };
+
+ panel-timing {
+ clock-frequency = <10000000>;
+ pixelclk-active = <1>;
+ hactive = <320>;
+ hback-porch = <6>;
+ hfront-porch = <6>;
+ hsync-len = <6>;
+ vactive = <240>;
+ vback-porch = <6>;
+ vfront-porch = <6>;
+ vsync-len = <0>;
+ };
+ };
+
+ sharp84_panel {
+ compatible = "sharp,lq084v1dg21", "panel-dpi";
+ port {
+ clcd_sharp84_panel: endpoint {
+ remote-endpoint = <&clcd_sharp84_pads>;
+ };
+ };
+
+ /* Standard 640x480 VGA timings */
+ panel-timing {
+ clock-frequency = <25175000>;
+ pixelclk-active = <0>;
+ hactive = <640>;
+ hback-porch = <48>;
+ hfront-porch = <16>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <33>;
+ vfront-porch = <10>;
+ vsync-len = <2>;
+ };
+ };
+
+ /*
+ * The IB2 has a Sanyo ALR252RGT QVGA panel mounted.
+ */
+ sanyo25_panel {
+ compatible = "sanyo,alr252rgt", "panel-dpi";
+ port {
+ clcd_sanyo25_panel: endpoint {
+ remote-endpoint = <&clcd_sanyo25_pads>;
+ };
+ };
+
+ panel-timing {
+ clock-frequency = <5440000>;
+ pixelclk-active = <0>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ hactive = <240>;
+ hback-porch = <20>;
+ hfront-porch = <10>;
+ hsync-len = <10>;
+ vactive = <320>;
+ vback-porch = <2>;
+ vfront-porch = <2>;
+ vsync-len = <2>;
+ };
+ };
+
+ epson_panel {
+ compatible = "epson,l2f50113t00", "panel-dpi";
+ port {
+ clcd_epson_panel: endpoint {
+ remote-endpoint = <&clcd_epson_pads>;
+ };
+ };
+
+ panel-timing {
+ clock-frequency = <16000000>;
+ pixelclk-active = <0>;
+ hactive = <176>;
+ hback-porch = <3>;
+ hfront-porch = <2>;
+ hsync-len = <3>;
+ vactive = <220>;
+ vback-porch = <1>;
+ vfront-porch = <0>;
+ vsync-len = <2>;
+ };
+ };
+
core-module at 10000000 {
compatible = "arm,core-module-versatile", "syscon", "simple-mfd";
reg = <0x10000000 0x200>;
@@ -93,10 +234,20 @@
default-state = "off";
};
- /* OSC1 on AB, OSC4 on PB */
- osc1: cm_aux_osc at 24M {
+ oscclk0: osc0 at 0c {
+ compatible = "arm,syscon-icst307";
#clock-cells = <0>;
- compatible = "arm,versatile-cm-auxosc";
+ lock-offset = <0x20>;
+ vco-offset = <0x0C>;
+ clocks = <&xtal24mhz>;
+ };
+
+ /* This is called OSC1 on AB, OSC4 on PB, call it OSC4 here */
+ oscclk4: osc4 at 1c {
+ compatible = "arm,syscon-icst307";
+ #clock-cells = <0>;
+ lock-offset = <0x20>;
+ vco-offset = <0x1C>;
clocks = <&xtal24mhz>;
};
@@ -227,8 +378,52 @@
compatible = "arm,pl110", "arm,primecell";
reg = <0x10120000 0x1000>;
interrupts = <16>;
- clocks = <&osc1>, <&pclk>;
+ clocks = <&oscclk4>, <&pclk>;
clock-names = "clcd", "apb_pclk";
+ /* 16bpp @ 25.175MHz = 50350000 bytes per second */
+ max-memory-bandwidth = <50350000>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ /*
+ * The CLCD connects to either of these panels.
+ * at run-time, board-specific code will
+ * detect and select the right one. If no
+ * panel is detected, the first one (VGA)
+ * will be used by default.
+ */
+ clcd_vga_pads: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&clcd_vga_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
+ };
+ clcd_xvga_pads: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint = <&clcd_xvga_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
+ };
+ clcd_sanyo38_pads: endpoint at 2 {
+ reg = <2>;
+ remote-endpoint = <&clcd_sanyo38_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ clcd_sharp84_pads: endpoint at 3 {
+ reg = <3>;
+ remote-endpoint = <&clcd_sharp84_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ clcd_sanyo25_pads: endpoint at 4 {
+ reg = <4>;
+ remote-endpoint = <&clcd_sanyo25_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ clcd_epson_pads: endpoint at 5 {
+ reg = <5>;
+ remote-endpoint = <&clcd_epson_panel>;
+ arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+ };
+ };
};
sctl at 101e0000 {
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index c44871851255..ebe27945fea5 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -29,8 +29,6 @@
#include <linux/of_platform.h>
#include <linux/slab.h>
#include <linux/amba/bus.h>
-#include <linux/amba/clcd.h>
-#include <linux/platform_data/video-clcd-versatile.h>
#include <linux/amba/mmci.h>
#include <linux/mtd/physmap.h>
#include <asm/mach-types.h>
@@ -57,7 +55,6 @@
#define VERSATILE_SYS_PCICTL_OFFSET 0x44
#define VERSATILE_SYS_MCI_OFFSET 0x48
#define VERSATILE_SYS_FLASH_OFFSET 0x4C
-#define VERSATILE_SYS_CLCD_OFFSET 0x50
/*
* VERSATILE_SYS_FLASH
@@ -69,10 +66,7 @@
*/
#define VERSATILE_MMCI0_BASE 0x10005000 /* MMC interface */
#define VERSATILE_MMCI1_BASE 0x1000B000 /* MMC Interface */
-#define VERSATILE_CLCD_BASE 0x10120000 /* CLCD */
#define VERSATILE_SCTL_BASE 0x101E0000 /* System controller */
-#define VERSATILE_IB2_BASE 0x24000000 /* IB2 module */
-#define VERSATILE_IB2_CTL_BASE (VERSATILE_IB2_BASE + 0x03000000)
/*
* System controller bit assignment
@@ -86,7 +80,6 @@
#define VERSATILE_TIMER4_EnSel 21
static void __iomem *versatile_sys_base;
-static void __iomem *versatile_ib2_ctrl;
static void versatile_flash_set_vpp(struct platform_device *pdev, int on)
{
@@ -149,158 +142,6 @@ static struct mmci_platform_data mmc1_plat_data = {
};
/*
- * CLCD support.
- */
-#define SYS_CLCD_MODE_MASK (3 << 0)
-#define SYS_CLCD_MODE_888 (0 << 0)
-#define SYS_CLCD_MODE_5551 (1 << 0)
-#define SYS_CLCD_MODE_565_RLSB (2 << 0)
-#define SYS_CLCD_MODE_565_BLSB (3 << 0)
-#define SYS_CLCD_NLCDIOON (1 << 2)
-#define SYS_CLCD_VDDPOSSWITCH (1 << 3)
-#define SYS_CLCD_PWR3V5SWITCH (1 << 4)
-#define SYS_CLCD_ID_MASK (0x1f << 8)
-#define SYS_CLCD_ID_SANYO_3_8 (0x00 << 8)
-#define SYS_CLCD_ID_UNKNOWN_8_4 (0x01 << 8)
-#define SYS_CLCD_ID_EPSON_2_2 (0x02 << 8)
-#define SYS_CLCD_ID_SANYO_2_5 (0x07 << 8)
-#define SYS_CLCD_ID_VGA (0x1f << 8)
-
-static bool is_sanyo_2_5_lcd;
-
-/*
- * Disable all display connectors on the interface module.
- */
-static void versatile_clcd_disable(struct clcd_fb *fb)
-{
- void __iomem *sys_clcd = versatile_sys_base + VERSATILE_SYS_CLCD_OFFSET;
- u32 val;
-
- val = readl(sys_clcd);
- val &= ~SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
- writel(val, sys_clcd);
-
- /*
- * If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light off
- */
- if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
- unsigned long ctrl;
-
- ctrl = readl(versatile_ib2_ctrl);
- ctrl &= ~0x01;
- writel(ctrl, versatile_ib2_ctrl);
- }
-}
-
-/*
- * Enable the relevant connector on the interface module.
- */
-static void versatile_clcd_enable(struct clcd_fb *fb)
-{
- struct fb_var_screeninfo *var = &fb->fb.var;
- void __iomem *sys_clcd = versatile_sys_base + VERSATILE_SYS_CLCD_OFFSET;
- u32 val;
-
- val = readl(sys_clcd);
- val &= ~SYS_CLCD_MODE_MASK;
-
- switch (var->green.length) {
- case 5:
- val |= SYS_CLCD_MODE_5551;
- break;
- case 6:
- if (var->red.offset == 0)
- val |= SYS_CLCD_MODE_565_RLSB;
- else
- val |= SYS_CLCD_MODE_565_BLSB;
- break;
- case 8:
- val |= SYS_CLCD_MODE_888;
- break;
- }
-
- /*
- * Set the MUX
- */
- writel(val, sys_clcd);
-
- /*
- * And now enable the PSUs
- */
- val |= SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
- writel(val, sys_clcd);
-
- /*
- * If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light on
- */
- if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
- unsigned long ctrl;
-
- ctrl = readl(versatile_ib2_ctrl);
- ctrl |= 0x01;
- writel(ctrl, versatile_ib2_ctrl);
- }
-}
-
-/*
- * Detect which LCD panel is connected, and return the appropriate
- * clcd_panel structure. Note: we do not have any information on
- * the required timings for the 8.4in panel, so we presently assume
- * VGA timings.
- */
-static int versatile_clcd_setup(struct clcd_fb *fb)
-{
- void __iomem *sys_clcd = versatile_sys_base + VERSATILE_SYS_CLCD_OFFSET;
- const char *panel_name;
- u32 val;
-
- is_sanyo_2_5_lcd = false;
-
- val = readl(sys_clcd) & SYS_CLCD_ID_MASK;
- if (val == SYS_CLCD_ID_SANYO_3_8)
- panel_name = "Sanyo TM38QV67A02A";
- else if (val == SYS_CLCD_ID_SANYO_2_5) {
- panel_name = "Sanyo QVGA Portrait";
- is_sanyo_2_5_lcd = true;
- } else if (val == SYS_CLCD_ID_EPSON_2_2)
- panel_name = "Epson L2F50113T00";
- else if (val == SYS_CLCD_ID_VGA)
- panel_name = "VGA";
- else {
- printk(KERN_ERR "CLCD: unknown LCD panel ID 0x%08x, using VGA\n",
- val);
- panel_name = "VGA";
- }
-
- fb->panel = versatile_clcd_get_panel(panel_name);
- if (!fb->panel)
- return -EINVAL;
-
- return versatile_clcd_setup_dma(fb, SZ_1M);
-}
-
-static void versatile_clcd_decode(struct clcd_fb *fb, struct clcd_regs *regs)
-{
- clcdfb_decode(fb, regs);
-
- /* Always clear BGR for RGB565: we do the routing externally */
- if (fb->fb.var.green.length == 6)
- regs->cntl &= ~CNTL_BGR;
-}
-
-static struct clcd_board clcd_plat_data = {
- .name = "Versatile",
- .caps = CLCD_CAP_5551 | CLCD_CAP_565 | CLCD_CAP_888,
- .check = clcdfb_check,
- .decode = versatile_clcd_decode,
- .disable = versatile_clcd_disable,
- .enable = versatile_clcd_enable,
- .setup = versatile_clcd_setup,
- .mmap = versatile_clcd_mmap_dma,
- .remove = versatile_clcd_remove_dma,
-};
-
-/*
* Lookup table for attaching a specific name and platform_data pointer to
* devices as they get created by of_platform_populate(). Ideally this table
* would not exist, but the current clock implementation depends on some devices
@@ -309,7 +150,6 @@ static struct clcd_board clcd_plat_data = {
struct of_dev_auxdata versatile_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI0_BASE, "fpga:05", &mmc0_plat_data),
OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI1_BASE, "fpga:0b", &mmc1_plat_data),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_CLCD_BASE, "dev:20", &clcd_plat_data),
{}
};
@@ -400,8 +240,6 @@ static void __init versatile_dt_init(void)
versatile_sys_base = of_iomap(np, 0);
WARN_ON(!versatile_sys_base);
- versatile_ib2_ctrl = ioremap(VERSATILE_IB2_CTL_BASE, SZ_4K);
-
versatile_dt_pci_init();
platform_device_register(&versatile_flash_device);
--
2.4.3
^ permalink raw reply related [flat|nested] 145+ messages in thread* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-17 9:09 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-17 9:09 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]
On 04/02/16 16:04, Linus Walleij wrote:
> This moves the versatile CLCD configuration to the device tree by:
>
> - Deleting the board file set-up of CLCD displays and quirks,
> instead relying on the driver to handle this. The driver will
> attempt to auto-detect (like the board file did) and match to
> a corresponding panel in the device tree.
>
> - Defining all auto-detectable panels in the device tree for the
> versatile-ab, defaulting the first one to VGA. The right
> panel will be selected at panel initialization, and should
> just work for the IB1 daughterboard panels, like EPSON.
>
> - Creating a special superset DTS file for the IB2 daughterboard
> (phone form-factor) equipped Versatile, overriding the default VGA
> display with the Sanyo 2.5" portrait display definitions, so that
> the IB2-equipped Versatile can be used with this. This follows
> the pattern of how we define the Versatile PB as a superset of
> Versatile AB.
>
> Tested on Versatile AB with just VGA with the default device tree,
> and with the IB2 daughterboard with the custom IB2 device tree.
> Tested to shunt in XVGA by modifying the device tree and this works
> too. Also tested on QEMU for Versatile in both VGA and Sanyo 2.5"
> mode. I don't have the IB1 daughterboard and its add-on displays,
> but it should work as long as the detection mechanism and device
> tree parameters are sound.
Well... I don't like this very much. The .dts should contain
descriptions for hardware that is connected. Have you looked at DT
overlays? I think they would be a much better match for this.
What's the SYS_CLCD register? An EEPROM or such, programmed when the
board is manufactured? Is the panel meant to be switchable by the user,
possibly to a panel that's not "standard"?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-17 9:09 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-17 9:09 UTC (permalink / raw)
To: linux-arm-kernel
On 04/02/16 16:04, Linus Walleij wrote:
> This moves the versatile CLCD configuration to the device tree by:
>
> - Deleting the board file set-up of CLCD displays and quirks,
> instead relying on the driver to handle this. The driver will
> attempt to auto-detect (like the board file did) and match to
> a corresponding panel in the device tree.
>
> - Defining all auto-detectable panels in the device tree for the
> versatile-ab, defaulting the first one to VGA. The right
> panel will be selected at panel initialization, and should
> just work for the IB1 daughterboard panels, like EPSON.
>
> - Creating a special superset DTS file for the IB2 daughterboard
> (phone form-factor) equipped Versatile, overriding the default VGA
> display with the Sanyo 2.5" portrait display definitions, so that
> the IB2-equipped Versatile can be used with this. This follows
> the pattern of how we define the Versatile PB as a superset of
> Versatile AB.
>
> Tested on Versatile AB with just VGA with the default device tree,
> and with the IB2 daughterboard with the custom IB2 device tree.
> Tested to shunt in XVGA by modifying the device tree and this works
> too. Also tested on QEMU for Versatile in both VGA and Sanyo 2.5"
> mode. I don't have the IB1 daughterboard and its add-on displays,
> but it should work as long as the detection mechanism and device
> tree parameters are sound.
Well... I don't like this very much. The .dts should contain
descriptions for hardware that is connected. Have you looked at DT
overlays? I think they would be a much better match for this.
What's the SYS_CLCD register? An EEPROM or such, programmed when the
board is manufactured? Is the panel meant to be switchable by the user,
possibly to a panel that's not "standard"?
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/1978c9c1/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-17 9:09 ` Tomi Valkeinen
@ 2016-02-17 9:41 ` Russell King - ARM Linux
-1 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-17 9:41 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 17, 2016 at 11:09:46AM +0200, Tomi Valkeinen wrote:
> What's the SYS_CLCD register? An EEPROM or such, programmed when the
> board is manufactured? Is the panel meant to be switchable by the user,
> possibly to a panel that's not "standard"?
If you read this bit of the patch, which describes the bits in the
register, it gives some clues:
-#define SYS_CLCD_MODE_MASK (3 << 0)
-#define SYS_CLCD_MODE_888 (0 << 0)
-#define SYS_CLCD_MODE_5551 (1 << 0)
-#define SYS_CLCD_MODE_565_RLSB (2 << 0)
-#define SYS_CLCD_MODE_565_BLSB (3 << 0)
-#define SYS_CLCD_NLCDIOON (1 << 2)
-#define SYS_CLCD_VDDPOSSWITCH (1 << 3)
-#define SYS_CLCD_PWR3V5SWITCH (1 << 4)
-#define SYS_CLCD_ID_MASK (0x1f << 8)
-#define SYS_CLCD_ID_SANYO_3_8 (0x00 << 8)
-#define SYS_CLCD_ID_UNKNOWN_8_4 (0x01 << 8)
-#define SYS_CLCD_ID_EPSON_2_2 (0x02 << 8)
-#define SYS_CLCD_ID_SANYO_2_5 (0x07 << 8)
-#define SYS_CLCD_ID_VGA (0x1f << 8)
The LCD panels plug-in to the board, and they have a 5-bit hard-wired
ID, which is signalled through five ID lines into the FPGA.
The register is also writable, which is used to control power supplies
to the LCD and an external MUX which changes the RGB format outside of
the capabilities of the CLCD itself.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-17 9:41 ` Russell King - ARM Linux
0 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-17 9:41 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 17, 2016 at 11:09:46AM +0200, Tomi Valkeinen wrote:
> What's the SYS_CLCD register? An EEPROM or such, programmed when the
> board is manufactured? Is the panel meant to be switchable by the user,
> possibly to a panel that's not "standard"?
If you read this bit of the patch, which describes the bits in the
register, it gives some clues:
-#define SYS_CLCD_MODE_MASK (3 << 0)
-#define SYS_CLCD_MODE_888 (0 << 0)
-#define SYS_CLCD_MODE_5551 (1 << 0)
-#define SYS_CLCD_MODE_565_RLSB (2 << 0)
-#define SYS_CLCD_MODE_565_BLSB (3 << 0)
-#define SYS_CLCD_NLCDIOON (1 << 2)
-#define SYS_CLCD_VDDPOSSWITCH (1 << 3)
-#define SYS_CLCD_PWR3V5SWITCH (1 << 4)
-#define SYS_CLCD_ID_MASK (0x1f << 8)
-#define SYS_CLCD_ID_SANYO_3_8 (0x00 << 8)
-#define SYS_CLCD_ID_UNKNOWN_8_4 (0x01 << 8)
-#define SYS_CLCD_ID_EPSON_2_2 (0x02 << 8)
-#define SYS_CLCD_ID_SANYO_2_5 (0x07 << 8)
-#define SYS_CLCD_ID_VGA (0x1f << 8)
The LCD panels plug-in to the board, and they have a 5-bit hard-wired
ID, which is signalled through five ID lines into the FPGA.
The register is also writable, which is used to control power supplies
to the LCD and an external MUX which changes the RGB format outside of
the capabilities of the CLCD itself.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently@9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-17 9:09 ` Tomi Valkeinen
@ 2016-02-17 16:17 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-17 16:17 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 17, 2016 at 10:09 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> Tested on Versatile AB with just VGA with the default device tree,
>> and with the IB2 daughterboard with the custom IB2 device tree.
>> Tested to shunt in XVGA by modifying the device tree and this works
>> too. Also tested on QEMU for Versatile in both VGA and Sanyo 2.5"
>> mode. I don't have the IB1 daughterboard and its add-on displays,
>> but it should work as long as the detection mechanism and device
>> tree parameters are sound.
>
> Well... I don't like this very much. The .dts should contain
> descriptions for hardware that is connected. Have you looked at DT
> overlays? I think they would be a much better match for this.
I'll look into it. I don't know how good those are. They must be overlaid
at runtime and anyways exist somewhere in memory so they can be
overlaid in there.
> What's the SYS_CLCD register? An EEPROM or such, programmed when the
> board is manufactured? Is the panel meant to be switchable by the user,
> possibly to a panel that's not "standard"?
As Russell points out: it's a register that contains a number saying what
panel is connected.
So it is plug-n-play and I want to preserve this in the patch.
The alternative is to make one DTS per display type connected, but that is
loosing all the nice plug'n'play :(
But if an overlay can do the same, I'm game for it.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-17 16:17 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-17 16:17 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 17, 2016 at 10:09 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> Tested on Versatile AB with just VGA with the default device tree,
>> and with the IB2 daughterboard with the custom IB2 device tree.
>> Tested to shunt in XVGA by modifying the device tree and this works
>> too. Also tested on QEMU for Versatile in both VGA and Sanyo 2.5"
>> mode. I don't have the IB1 daughterboard and its add-on displays,
>> but it should work as long as the detection mechanism and device
>> tree parameters are sound.
>
> Well... I don't like this very much. The .dts should contain
> descriptions for hardware that is connected. Have you looked at DT
> overlays? I think they would be a much better match for this.
I'll look into it. I don't know how good those are. They must be overlaid
at runtime and anyways exist somewhere in memory so they can be
overlaid in there.
> What's the SYS_CLCD register? An EEPROM or such, programmed when the
> board is manufactured? Is the panel meant to be switchable by the user,
> possibly to a panel that's not "standard"?
As Russell points out: it's a register that contains a number saying what
panel is connected.
So it is plug-n-play and I want to preserve this in the patch.
The alternative is to make one DTS per display type connected, but that is
loosing all the nice plug'n'play :(
But if an overlay can do the same, I'm game for it.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-17 16:17 ` Linus Walleij
@ 2016-02-17 21:32 ` Russell King - ARM Linux
-1 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-17 21:32 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 17, 2016 at 05:17:33PM +0100, Linus Walleij wrote:
> As Russell points out: it's a register that contains a number saying what
> panel is connected.
>
> So it is plug-n-play and I want to preserve this in the patch.
>
> The alternative is to make one DTS per display type connected, but that is
> loosing all the nice plug'n'play :(
That's totally insane: we're talking about what's plugged in through
an external connector. It's not an "internal" device connector.
These displays are external separate boxes to the board.
We don't have separate DT files just because we plugged in a USB device
to a board., or a SDIO card, or an external HDD.
> But if an overlay can do the same, I'm game for it.
That's rather eww, because that means you need to either build the
overlay into the kernel (which IIRC then ties the base DT file to
that exact kernel) or it needs to sit in userland, which means no
LCD display until userland is up and running. It doesn't sound very
satisfactory, IMHO.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-17 21:32 ` Russell King - ARM Linux
0 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-17 21:32 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 17, 2016 at 05:17:33PM +0100, Linus Walleij wrote:
> As Russell points out: it's a register that contains a number saying what
> panel is connected.
>
> So it is plug-n-play and I want to preserve this in the patch.
>
> The alternative is to make one DTS per display type connected, but that is
> loosing all the nice plug'n'play :(
That's totally insane: we're talking about what's plugged in through
an external connector. It's not an "internal" device connector.
These displays are external separate boxes to the board.
We don't have separate DT files just because we plugged in a USB device
to a board., or a SDIO card, or an external HDD.
> But if an overlay can do the same, I'm game for it.
That's rather eww, because that means you need to either build the
overlay into the kernel (which IIRC then ties the base DT file to
that exact kernel) or it needs to sit in userland, which means no
LCD display until userland is up and running. It doesn't sound very
satisfactory, IMHO.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-17 21:32 ` Russell King - ARM Linux
@ 2016-02-18 11:52 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-18 11:52 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]
On 17/02/16 23:32, Russell King - ARM Linux wrote:
> On Wed, Feb 17, 2016 at 05:17:33PM +0100, Linus Walleij wrote:
>> As Russell points out: it's a register that contains a number saying what
>> panel is connected.
>>
>> So it is plug-n-play and I want to preserve this in the patch.
>>
>> The alternative is to make one DTS per display type connected, but that is
>> loosing all the nice plug'n'play :(
>
> That's totally insane: we're talking about what's plugged in through
> an external connector. It's not an "internal" device connector.
> These displays are external separate boxes to the board.
>
> We don't have separate DT files just because we plugged in a USB device
> to a board., or a SDIO card, or an external HDD.
That's because USB, SDIO, HDD are all standard piece of HW, and any
probing can be done via the bus.
For panels we need DT fragments. The question is where these fragments
are and, possibly, who who loads them.
>> But if an overlay can do the same, I'm game for it.
>
> That's rather eww, because that means you need to either build the
> overlay into the kernel (which IIRC then ties the base DT file to
> that exact kernel) or it needs to sit in userland, which means no
> LCD display until userland is up and running. It doesn't sound very
> satisfactory, IMHO.
I don't think there are any satisfactory solutions to this.
For me the eww'est option is what this patch does, adding lots of panels
to the .dts, even if the panels are not connected, and having a board
specific fbdev driver. On the other hand, it's easy solution.
One a bit more general question here is: who should know the details of
the board? Is it the bootloader, kernel or userspace? I think the aim
has been to make the kernel drivers generic, not board specific. If so,
it hints either towards the bootloader or userspace. If userspace, the
panels will only be enabled later, when userspace is up.
In my opinion the best option would be to use DT overlays, but so that
the bootloader would supply them, or construct the dtb. But afaik that's
not possible at the moment. And perhaps I think that's the best option
only because I don't work with the bootloaders =).
So, I don't like this, but I don't have a good suggestion how to do it
better with the infrastructure in place at the moment.
We (TI) are struggling with the same problem at the moment (we don't
even have detection capability in all cases), and so far I've refused to
start adding board specific hacks to the display drivers. So I'm very
interested to find a good solution to this too.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-18 11:52 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-18 11:52 UTC (permalink / raw)
To: linux-arm-kernel
On 17/02/16 23:32, Russell King - ARM Linux wrote:
> On Wed, Feb 17, 2016 at 05:17:33PM +0100, Linus Walleij wrote:
>> As Russell points out: it's a register that contains a number saying what
>> panel is connected.
>>
>> So it is plug-n-play and I want to preserve this in the patch.
>>
>> The alternative is to make one DTS per display type connected, but that is
>> loosing all the nice plug'n'play :(
>
> That's totally insane: we're talking about what's plugged in through
> an external connector. It's not an "internal" device connector.
> These displays are external separate boxes to the board.
>
> We don't have separate DT files just because we plugged in a USB device
> to a board., or a SDIO card, or an external HDD.
That's because USB, SDIO, HDD are all standard piece of HW, and any
probing can be done via the bus.
For panels we need DT fragments. The question is where these fragments
are and, possibly, who who loads them.
>> But if an overlay can do the same, I'm game for it.
>
> That's rather eww, because that means you need to either build the
> overlay into the kernel (which IIRC then ties the base DT file to
> that exact kernel) or it needs to sit in userland, which means no
> LCD display until userland is up and running. It doesn't sound very
> satisfactory, IMHO.
I don't think there are any satisfactory solutions to this.
For me the eww'est option is what this patch does, adding lots of panels
to the .dts, even if the panels are not connected, and having a board
specific fbdev driver. On the other hand, it's easy solution.
One a bit more general question here is: who should know the details of
the board? Is it the bootloader, kernel or userspace? I think the aim
has been to make the kernel drivers generic, not board specific. If so,
it hints either towards the bootloader or userspace. If userspace, the
panels will only be enabled later, when userspace is up.
In my opinion the best option would be to use DT overlays, but so that
the bootloader would supply them, or construct the dtb. But afaik that's
not possible at the moment. And perhaps I think that's the best option
only because I don't work with the bootloaders =).
So, I don't like this, but I don't have a good suggestion how to do it
better with the infrastructure in place at the moment.
We (TI) are struggling with the same problem at the moment (we don't
even have detection capability in all cases), and so far I've refused to
start adding board specific hacks to the display drivers. So I'm very
interested to find a good solution to this too.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160218/768efc8c/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-18 11:52 ` Tomi Valkeinen
@ 2016-02-18 13:12 ` Russell King - ARM Linux
-1 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-18 13:12 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 18, 2016 at 01:52:32PM +0200, Tomi Valkeinen wrote:
> In my opinion the best option would be to use DT overlays, but so that
> the bootloader would supply them, or construct the dtb. But afaik that's
> not possible at the moment. And perhaps I think that's the best option
> only because I don't work with the bootloaders =).
>
> So, I don't like this, but I don't have a good suggestion how to do it
> better with the infrastructure in place at the moment.
The danger of that position is that we end up with nothing happening,
and the problem remaining unresolved, which then pushes people into
maintaining patches out of mainline just to have a working setup -
which then pushes people to vendor trees.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-18 13:12 ` Russell King - ARM Linux
0 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-18 13:12 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 18, 2016 at 01:52:32PM +0200, Tomi Valkeinen wrote:
> In my opinion the best option would be to use DT overlays, but so that
> the bootloader would supply them, or construct the dtb. But afaik that's
> not possible at the moment. And perhaps I think that's the best option
> only because I don't work with the bootloaders =).
>
> So, I don't like this, but I don't have a good suggestion how to do it
> better with the infrastructure in place at the moment.
The danger of that position is that we end up with nothing happening,
and the problem remaining unresolved, which then pushes people into
maintaining patches out of mainline just to have a working setup -
which then pushes people to vendor trees.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-18 13:12 ` Russell King - ARM Linux
@ 2016-02-18 13:37 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-18 13:37 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]
On 18/02/16 15:12, Russell King - ARM Linux wrote:
> On Thu, Feb 18, 2016 at 01:52:32PM +0200, Tomi Valkeinen wrote:
>> In my opinion the best option would be to use DT overlays, but so that
>> the bootloader would supply them, or construct the dtb. But afaik that's
>> not possible at the moment. And perhaps I think that's the best option
>> only because I don't work with the bootloaders =).
>>
>> So, I don't like this, but I don't have a good suggestion how to do it
>> better with the infrastructure in place at the moment.
>
> The danger of that position is that we end up with nothing happening,
> and the problem remaining unresolved, which then pushes people into
> maintaining patches out of mainline just to have a working setup -
> which then pushes people to vendor trees.
I agree.
I didn't express my position clearly: I'm ok with the approach, if we
don't come up with anything better.
But if we go with this approach, it must be understood that it may cause
problems later. It's not the most maintainable approach.
I'd also like to have an ack from the DT maintainers, as I think this is
somewhat of an abuse of the DT.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-18 13:37 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-18 13:37 UTC (permalink / raw)
To: linux-arm-kernel
On 18/02/16 15:12, Russell King - ARM Linux wrote:
> On Thu, Feb 18, 2016 at 01:52:32PM +0200, Tomi Valkeinen wrote:
>> In my opinion the best option would be to use DT overlays, but so that
>> the bootloader would supply them, or construct the dtb. But afaik that's
>> not possible at the moment. And perhaps I think that's the best option
>> only because I don't work with the bootloaders =).
>>
>> So, I don't like this, but I don't have a good suggestion how to do it
>> better with the infrastructure in place at the moment.
>
> The danger of that position is that we end up with nothing happening,
> and the problem remaining unresolved, which then pushes people into
> maintaining patches out of mainline just to have a working setup -
> which then pushes people to vendor trees.
I agree.
I didn't express my position clearly: I'm ok with the approach, if we
don't come up with anything better.
But if we go with this approach, it must be understood that it may cause
problems later. It's not the most maintainable approach.
I'd also like to have an ack from the DT maintainers, as I think this is
somewhat of an abuse of the DT.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160218/d9a76271/attachment-0001.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-18 13:37 ` Tomi Valkeinen
@ 2016-02-18 20:31 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-18 20:31 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 18, 2016 at 2:37 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 18/02/16 15:12, Russell King - ARM Linux wrote:
>> On Thu, Feb 18, 2016 at 01:52:32PM +0200, Tomi Valkeinen wrote:
>>> In my opinion the best option would be to use DT overlays, but so that
>>> the bootloader would supply them, or construct the dtb. But afaik that's
>>> not possible at the moment. And perhaps I think that's the best option
>>> only because I don't work with the bootloaders =).
>>>
>>> So, I don't like this, but I don't have a good suggestion how to do it
>>> better with the infrastructure in place at the moment.
>>
>> The danger of that position is that we end up with nothing happening,
>> and the problem remaining unresolved, which then pushes people into
>> maintaining patches out of mainline just to have a working setup -
>> which then pushes people to vendor trees.
>
> I agree.
>
> I didn't express my position clearly: I'm ok with the approach, if we
> don't come up with anything better.
I'm checking to see if I can use the overlay primitives directly from
the kernel.
It seems possible, basically to have a panel defined in the device tree
for VGA as default, and then augment it depending on what we detect.
Meaning I start to overwrite clock-frequency, pixelclk-active, hactive etc.
It basically means we go back to having a database in the kernel.
I would then even overwrite the .compatible string from the kernel.
It may be more elegant than this solution though?
> But if we go with this approach, it must be understood that it may cause
> problems later. It's not the most maintainable approach.
>
> I'd also like to have an ack from the DT maintainers, as I think this is
> somewhat of an abuse of the DT.
What I am doing in this patch is sort of a "Schrödinger's cat approach",
I basically say that the cat is both dead and alive until we open the
box, i.e. all displays are connected until we figure out which one it
actually is.
Basically the approach taken could even handle the case of switching
a display at runtime. Though I don't think the hardware would like that.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-18 20:31 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-18 20:31 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 18, 2016 at 2:37 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 18/02/16 15:12, Russell King - ARM Linux wrote:
>> On Thu, Feb 18, 2016 at 01:52:32PM +0200, Tomi Valkeinen wrote:
>>> In my opinion the best option would be to use DT overlays, but so that
>>> the bootloader would supply them, or construct the dtb. But afaik that's
>>> not possible at the moment. And perhaps I think that's the best option
>>> only because I don't work with the bootloaders =).
>>>
>>> So, I don't like this, but I don't have a good suggestion how to do it
>>> better with the infrastructure in place at the moment.
>>
>> The danger of that position is that we end up with nothing happening,
>> and the problem remaining unresolved, which then pushes people into
>> maintaining patches out of mainline just to have a working setup -
>> which then pushes people to vendor trees.
>
> I agree.
>
> I didn't express my position clearly: I'm ok with the approach, if we
> don't come up with anything better.
I'm checking to see if I can use the overlay primitives directly from
the kernel.
It seems possible, basically to have a panel defined in the device tree
for VGA as default, and then augment it depending on what we detect.
Meaning I start to overwrite clock-frequency, pixelclk-active, hactive etc.
It basically means we go back to having a database in the kernel.
I would then even overwrite the .compatible string from the kernel.
It may be more elegant than this solution though?
> But if we go with this approach, it must be understood that it may cause
> problems later. It's not the most maintainable approach.
>
> I'd also like to have an ack from the DT maintainers, as I think this is
> somewhat of an abuse of the DT.
What I am doing in this patch is sort of a "Schr?dinger's cat approach",
I basically say that the cat is both dead and alive until we open the
box, i.e. all displays are connected until we figure out which one it
actually is.
Basically the approach taken could even handle the case of switching
a display at runtime. Though I don't think the hardware would like that.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
[parent not found: <56C5B080.9090007-l0cyMroinI0@public.gmane.org>]
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-18 11:52 ` Tomi Valkeinen
(?)
@ 2016-02-21 22:39 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-21 22:39 UTC (permalink / raw)
To: Tomi Valkeinen, Russell King - ARM Linux, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
Jean-Christophe Plagniol-Villard, Pawel Moll,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann
On Thu, Feb 18, 2016 at 12:52 PM, Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org> wrote:
> For panels we need DT fragments. The question is where these fragments
> are and, possibly, who who loads them.
I hacked something up that augments the device tree from the kernel,
given you have a node with all the props you want to augment, tell me
what you think of this and whether I should continue in this direction...
also the DT people need to be involved:
#include "../../drivers/of/of_private.h"
/* Obviously make the property duplication function public instead,
it's a test */
struct versatile_panel {
u32 id;
char *compatible;
u32 clock_frequency;
u32 pixelclk_active;
u32 hsync_active;
u32 vsync_active;
u32 de_active;
u32 hactive;
u32 hback_porch;
u32 hfront_porch;
u32 hsync_len;
u32 vactive;
u32 vback_porch;
u32 vfront_porch;
u32 vsync_len;
bool ib2;
};
static const struct versatile_panel versatile_panels[] = {
{
.id = SYS_CLCD_ID_VGA,
.compatible = "VGA",
.clock_frequency = 25175000,
.pixelclk_active = 0,
.hsync_active = 1,
.vsync_active = 1,
.de_active = 1,
.hactive = 640,
.hback_porch = 48,
.hfront_porch = 16,
.hsync_len = 96,
.vactive = 480,
.vback_porch = 33,
.vfront_porch = 10,
.vsync_len = 2,
},
{
.id = SYS_CLCD_ID_SANYO_3_8,
.compatible = "sanyo,tm38qv67a02a",
.clock_frequency = 10000000,
.pixelclk_active = 1,
.hsync_active = 1,
.vsync_active = 1,
.de_active = 1,
.hactive = 320,
.hback_porch = 6,
.hfront_porch = 6,
.hsync_len = 6,
.vactive = 240,
.vback_porch = 6,
.vfront_porch = 6,
.vsync_len = 0,
},
{
.id = SYS_CLCD_ID_SHARP_8_4,
.compatible = "sharp,lq084v1dg21",
.clock_frequency = 25175000,
.pixelclk_active = 0,
.hsync_active = 1,
.vsync_active = 1,
.de_active = 1,
.hactive = 640,
.hback_porch = 48,
.hfront_porch = 16,
.hsync_len = 96,
.vactive = 480,
.vback_porch = 33,
.vfront_porch = 10,
.vsync_len = 2,
},
{
.id = SYS_CLCD_ID_EPSON_2_2,
.compatible = "epson,l2f50113t00",
.clock_frequency = 16000000,
.pixelclk_active = 0,
.hsync_active = 1,
.vsync_active = 1,
.de_active = 1,
.hactive = 176,
.hback_porch = 3,
.hfront_porch = 2,
.hsync_len = 3,
.vactive = 220,
.vback_porch = 1,
.vfront_porch = 0,
.vsync_len = 2,
},
{
.id = SYS_CLCD_ID_SANYO_2_5,
.compatible = "sanyo,alr252rgt",
.ib2 = true,
.clock_frequency = 5440000,
.pixelclk_active = 0,
.hsync_active = 0,
.vsync_active = 0,
.de_active = 1,
.hactive = 240,
.hback_porch = 20,
.hfront_porch = 10,
.hsync_len = 10,
.vactive = 320,
.vback_porch = 2,
.vfront_porch = 2,
.vsync_len = 2,
},
};
static void update_timings_prop(struct device *dev,
struct of_changeset *cset,
struct device_node *timings,
const char *propname,
u32 val)
{
struct property *prop, *new;
__be32 *dt_val;
prop = of_find_property(timings, propname, NULL);
if (!prop) {
dev_err(dev, "could not find property \"%s\" - skipping\n",
propname);
return;
}
new = __of_prop_dup(prop, GFP_KERNEL);
if (!new) {
dev_err(dev, "could not copy property \"%s\" - skipping\n",
propname);
return;
}
dt_val = new->value;
*dt_val = cpu_to_be32(val);
of_changeset_update_property(cset, timings, new);
}
static int versatile_overwrite_of_panel(struct device *dev,
struct device_node *panel,
const struct versatile_panel *vpanel)
{
struct of_changeset cset;
struct device_node *timings;
int ret;
dev_info(dev, "CLCD: overwriting device tree\n");
of_changeset_init(&cset);
/* Find the timings node */
timings = of_get_child_by_name(panel, "panel-timing");
if (!timings) {
dev_err(dev, "could not find panel timing node\n");
goto err_destroy_cs;
}
update_timings_prop(dev, &cset, timings, "clock-frequency",
vpanel->clock_frequency);
update_timings_prop(dev, &cset, timings, "pixelclk-active",
vpanel->pixelclk_active);
update_timings_prop(dev, &cset, timings, "hsync-active",
vpanel->hsync_active);
update_timings_prop(dev, &cset, timings, "vsync-active",
vpanel->vsync_active);
update_timings_prop(dev, &cset, timings, "de-active",
vpanel->de_active);
update_timings_prop(dev, &cset, timings, "hactive",
vpanel->hactive);
update_timings_prop(dev, &cset, timings, "hback-porch",
vpanel->hback_porch);
update_timings_prop(dev, &cset, timings, "hsync-len",
vpanel->hsync_len);
update_timings_prop(dev, &cset, timings, "vactive",
vpanel->vactive);
update_timings_prop(dev, &cset, timings, "vback-porch",
vpanel->vback_porch);
update_timings_prop(dev, &cset, timings, "vfront-porch",
vpanel->vfront_porch);
update_timings_prop(dev, &cset, timings, "vsync-len",
vpanel->hsync_len);
ret = of_changeset_apply(&cset);
if (ret) {
dev_err(dev, "could not apply device tree changeset\n");
goto err_destroy_cs;
}
return ret;
err_destroy_cs:
of_changeset_destroy(&cset);
return ret;
}
static void versatile_panel_probe(struct device *dev,
struct device_node *endpoint)
{
struct versatile_panel const *vpanel = NULL;
struct device_node *panel = NULL;
u32 val;
int ret;
int i;
/*
* The Versatile CLCD has a panel auto-detection mechanism.
* We use this and look for the compatible panel in the
* device tree.
*/
ret = regmap_read(versatile_syscon_map, SYS_CLCD, &val);
if (ret) {
dev_err(dev, "cannot read CLCD syscon register\n");
return;
}
val &= SYS_CLCD_CLCDID_MASK;
dev_info(dev, "SYS_CLCD=%08x\n", val);
/* First find corresponding panel information */
for (i = 0; i < ARRAY_SIZE(versatile_panels); i++) {
vpanel = &versatile_panels[i];
if (val == vpanel->id) {
dev_err(dev, "autodetected panel \"%s\"\n",
vpanel->compatible);
break;
}
}
if (i == ARRAY_SIZE(versatile_panels)) {
dev_err(dev, "could not auto-detect panel\n");
return;
}
/* This is the default panel node in the device tree */
panel = of_graph_get_remote_port_parent(endpoint);
if (!panel) {
dev_err(dev, "could not locate remote port for panel\n");
return;
}
/*
* So now we dynamically update the display properties of the
* panel in accordance to what was detected..
*/
ret = versatile_overwrite_of_panel(dev, panel, vpanel);
if (ret) {
dev_err(dev, "cannot overwrite devicetree panel\n");
return;
}
/*
* If we have a Sanyo 2.5" port
* that we're running on an IB2 and proceed to look for the
* IB2 syscon regmap.
*/
if (!vpanel->ib2)
return;
versatile_ib2_map = syscon_regmap_lookup_by_compatible(
"arm,versatile-ib2-syscon");
if (IS_ERR(versatile_ib2_map)) {
dev_err(dev, "could not locate IB2 control register\n");
versatile_ib2_map = NULL;
return;
}
}
This actually works. But would need some public device tree
property augmentation API instead of the hacks. Should I pursue
it?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 145+ messages in thread* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-21 22:39 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-21 22:39 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 18, 2016 at 12:52 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> For panels we need DT fragments. The question is where these fragments
> are and, possibly, who who loads them.
I hacked something up that augments the device tree from the kernel,
given you have a node with all the props you want to augment, tell me
what you think of this and whether I should continue in this direction...
also the DT people need to be involved:
#include "../../drivers/of/of_private.h"
/* Obviously make the property duplication function public instead,
it's a test */
struct versatile_panel {
u32 id;
char *compatible;
u32 clock_frequency;
u32 pixelclk_active;
u32 hsync_active;
u32 vsync_active;
u32 de_active;
u32 hactive;
u32 hback_porch;
u32 hfront_porch;
u32 hsync_len;
u32 vactive;
u32 vback_porch;
u32 vfront_porch;
u32 vsync_len;
bool ib2;
};
static const struct versatile_panel versatile_panels[] = {
{
.id = SYS_CLCD_ID_VGA,
.compatible = "VGA",
.clock_frequency = 25175000,
.pixelclk_active = 0,
.hsync_active = 1,
.vsync_active = 1,
.de_active = 1,
.hactive = 640,
.hback_porch = 48,
.hfront_porch = 16,
.hsync_len = 96,
.vactive = 480,
.vback_porch = 33,
.vfront_porch = 10,
.vsync_len = 2,
},
{
.id = SYS_CLCD_ID_SANYO_3_8,
.compatible = "sanyo,tm38qv67a02a",
.clock_frequency = 10000000,
.pixelclk_active = 1,
.hsync_active = 1,
.vsync_active = 1,
.de_active = 1,
.hactive = 320,
.hback_porch = 6,
.hfront_porch = 6,
.hsync_len = 6,
.vactive = 240,
.vback_porch = 6,
.vfront_porch = 6,
.vsync_len = 0,
},
{
.id = SYS_CLCD_ID_SHARP_8_4,
.compatible = "sharp,lq084v1dg21",
.clock_frequency = 25175000,
.pixelclk_active = 0,
.hsync_active = 1,
.vsync_active = 1,
.de_active = 1,
.hactive = 640,
.hback_porch = 48,
.hfront_porch = 16,
.hsync_len = 96,
.vactive = 480,
.vback_porch = 33,
.vfront_porch = 10,
.vsync_len = 2,
},
{
.id = SYS_CLCD_ID_EPSON_2_2,
.compatible = "epson,l2f50113t00",
.clock_frequency = 16000000,
.pixelclk_active = 0,
.hsync_active = 1,
.vsync_active = 1,
.de_active = 1,
.hactive = 176,
.hback_porch = 3,
.hfront_porch = 2,
.hsync_len = 3,
.vactive = 220,
.vback_porch = 1,
.vfront_porch = 0,
.vsync_len = 2,
},
{
.id = SYS_CLCD_ID_SANYO_2_5,
.compatible = "sanyo,alr252rgt",
.ib2 = true,
.clock_frequency = 5440000,
.pixelclk_active = 0,
.hsync_active = 0,
.vsync_active = 0,
.de_active = 1,
.hactive = 240,
.hback_porch = 20,
.hfront_porch = 10,
.hsync_len = 10,
.vactive = 320,
.vback_porch = 2,
.vfront_porch = 2,
.vsync_len = 2,
},
};
static void update_timings_prop(struct device *dev,
struct of_changeset *cset,
struct device_node *timings,
const char *propname,
u32 val)
{
struct property *prop, *new;
__be32 *dt_val;
prop = of_find_property(timings, propname, NULL);
if (!prop) {
dev_err(dev, "could not find property \"%s\" - skipping\n",
propname);
return;
}
new = __of_prop_dup(prop, GFP_KERNEL);
if (!new) {
dev_err(dev, "could not copy property \"%s\" - skipping\n",
propname);
return;
}
dt_val = new->value;
*dt_val = cpu_to_be32(val);
of_changeset_update_property(cset, timings, new);
}
static int versatile_overwrite_of_panel(struct device *dev,
struct device_node *panel,
const struct versatile_panel *vpanel)
{
struct of_changeset cset;
struct device_node *timings;
int ret;
dev_info(dev, "CLCD: overwriting device tree\n");
of_changeset_init(&cset);
/* Find the timings node */
timings = of_get_child_by_name(panel, "panel-timing");
if (!timings) {
dev_err(dev, "could not find panel timing node\n");
goto err_destroy_cs;
}
update_timings_prop(dev, &cset, timings, "clock-frequency",
vpanel->clock_frequency);
update_timings_prop(dev, &cset, timings, "pixelclk-active",
vpanel->pixelclk_active);
update_timings_prop(dev, &cset, timings, "hsync-active",
vpanel->hsync_active);
update_timings_prop(dev, &cset, timings, "vsync-active",
vpanel->vsync_active);
update_timings_prop(dev, &cset, timings, "de-active",
vpanel->de_active);
update_timings_prop(dev, &cset, timings, "hactive",
vpanel->hactive);
update_timings_prop(dev, &cset, timings, "hback-porch",
vpanel->hback_porch);
update_timings_prop(dev, &cset, timings, "hsync-len",
vpanel->hsync_len);
update_timings_prop(dev, &cset, timings, "vactive",
vpanel->vactive);
update_timings_prop(dev, &cset, timings, "vback-porch",
vpanel->vback_porch);
update_timings_prop(dev, &cset, timings, "vfront-porch",
vpanel->vfront_porch);
update_timings_prop(dev, &cset, timings, "vsync-len",
vpanel->hsync_len);
ret = of_changeset_apply(&cset);
if (ret) {
dev_err(dev, "could not apply device tree changeset\n");
goto err_destroy_cs;
}
return ret;
err_destroy_cs:
of_changeset_destroy(&cset);
return ret;
}
static void versatile_panel_probe(struct device *dev,
struct device_node *endpoint)
{
struct versatile_panel const *vpanel = NULL;
struct device_node *panel = NULL;
u32 val;
int ret;
int i;
/*
* The Versatile CLCD has a panel auto-detection mechanism.
* We use this and look for the compatible panel in the
* device tree.
*/
ret = regmap_read(versatile_syscon_map, SYS_CLCD, &val);
if (ret) {
dev_err(dev, "cannot read CLCD syscon register\n");
return;
}
val &= SYS_CLCD_CLCDID_MASK;
dev_info(dev, "SYS_CLCD=%08x\n", val);
/* First find corresponding panel information */
for (i = 0; i < ARRAY_SIZE(versatile_panels); i++) {
vpanel = &versatile_panels[i];
if (val == vpanel->id) {
dev_err(dev, "autodetected panel \"%s\"\n",
vpanel->compatible);
break;
}
}
if (i == ARRAY_SIZE(versatile_panels)) {
dev_err(dev, "could not auto-detect panel\n");
return;
}
/* This is the default panel node in the device tree */
panel = of_graph_get_remote_port_parent(endpoint);
if (!panel) {
dev_err(dev, "could not locate remote port for panel\n");
return;
}
/*
* So now we dynamically update the display properties of the
* panel in accordance to what was detected..
*/
ret = versatile_overwrite_of_panel(dev, panel, vpanel);
if (ret) {
dev_err(dev, "cannot overwrite devicetree panel\n");
return;
}
/*
* If we have a Sanyo 2.5" port
* that we're running on an IB2 and proceed to look for the
* IB2 syscon regmap.
*/
if (!vpanel->ib2)
return;
versatile_ib2_map = syscon_regmap_lookup_by_compatible(
"arm,versatile-ib2-syscon");
if (IS_ERR(versatile_ib2_map)) {
dev_err(dev, "could not locate IB2 control register\n");
versatile_ib2_map = NULL;
return;
}
}
This actually works. But would need some public device tree
property augmentation API instead of the hacks. Should I pursue
it?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-21 22:39 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-21 22:39 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 18, 2016 at 12:52 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> For panels we need DT fragments. The question is where these fragments
> are and, possibly, who who loads them.
I hacked something up that augments the device tree from the kernel,
given you have a node with all the props you want to augment, tell me
what you think of this and whether I should continue in this direction...
also the DT people need to be involved:
#include "../../drivers/of/of_private.h"
/* Obviously make the property duplication function public instead,
it's a test */
struct versatile_panel {
u32 id;
char *compatible;
u32 clock_frequency;
u32 pixelclk_active;
u32 hsync_active;
u32 vsync_active;
u32 de_active;
u32 hactive;
u32 hback_porch;
u32 hfront_porch;
u32 hsync_len;
u32 vactive;
u32 vback_porch;
u32 vfront_porch;
u32 vsync_len;
bool ib2;
};
static const struct versatile_panel versatile_panels[] = {
{
.id = SYS_CLCD_ID_VGA,
.compatible = "VGA",
.clock_frequency = 25175000,
.pixelclk_active = 0,
.hsync_active = 1,
.vsync_active = 1,
.de_active = 1,
.hactive = 640,
.hback_porch = 48,
.hfront_porch = 16,
.hsync_len = 96,
.vactive = 480,
.vback_porch = 33,
.vfront_porch = 10,
.vsync_len = 2,
},
{
.id = SYS_CLCD_ID_SANYO_3_8,
.compatible = "sanyo,tm38qv67a02a",
.clock_frequency = 10000000,
.pixelclk_active = 1,
.hsync_active = 1,
.vsync_active = 1,
.de_active = 1,
.hactive = 320,
.hback_porch = 6,
.hfront_porch = 6,
.hsync_len = 6,
.vactive = 240,
.vback_porch = 6,
.vfront_porch = 6,
.vsync_len = 0,
},
{
.id = SYS_CLCD_ID_SHARP_8_4,
.compatible = "sharp,lq084v1dg21",
.clock_frequency = 25175000,
.pixelclk_active = 0,
.hsync_active = 1,
.vsync_active = 1,
.de_active = 1,
.hactive = 640,
.hback_porch = 48,
.hfront_porch = 16,
.hsync_len = 96,
.vactive = 480,
.vback_porch = 33,
.vfront_porch = 10,
.vsync_len = 2,
},
{
.id = SYS_CLCD_ID_EPSON_2_2,
.compatible = "epson,l2f50113t00",
.clock_frequency = 16000000,
.pixelclk_active = 0,
.hsync_active = 1,
.vsync_active = 1,
.de_active = 1,
.hactive = 176,
.hback_porch = 3,
.hfront_porch = 2,
.hsync_len = 3,
.vactive = 220,
.vback_porch = 1,
.vfront_porch = 0,
.vsync_len = 2,
},
{
.id = SYS_CLCD_ID_SANYO_2_5,
.compatible = "sanyo,alr252rgt",
.ib2 = true,
.clock_frequency = 5440000,
.pixelclk_active = 0,
.hsync_active = 0,
.vsync_active = 0,
.de_active = 1,
.hactive = 240,
.hback_porch = 20,
.hfront_porch = 10,
.hsync_len = 10,
.vactive = 320,
.vback_porch = 2,
.vfront_porch = 2,
.vsync_len = 2,
},
};
static void update_timings_prop(struct device *dev,
struct of_changeset *cset,
struct device_node *timings,
const char *propname,
u32 val)
{
struct property *prop, *new;
__be32 *dt_val;
prop = of_find_property(timings, propname, NULL);
if (!prop) {
dev_err(dev, "could not find property \"%s\" - skipping\n",
propname);
return;
}
new = __of_prop_dup(prop, GFP_KERNEL);
if (!new) {
dev_err(dev, "could not copy property \"%s\" - skipping\n",
propname);
return;
}
dt_val = new->value;
*dt_val = cpu_to_be32(val);
of_changeset_update_property(cset, timings, new);
}
static int versatile_overwrite_of_panel(struct device *dev,
struct device_node *panel,
const struct versatile_panel *vpanel)
{
struct of_changeset cset;
struct device_node *timings;
int ret;
dev_info(dev, "CLCD: overwriting device tree\n");
of_changeset_init(&cset);
/* Find the timings node */
timings = of_get_child_by_name(panel, "panel-timing");
if (!timings) {
dev_err(dev, "could not find panel timing node\n");
goto err_destroy_cs;
}
update_timings_prop(dev, &cset, timings, "clock-frequency",
vpanel->clock_frequency);
update_timings_prop(dev, &cset, timings, "pixelclk-active",
vpanel->pixelclk_active);
update_timings_prop(dev, &cset, timings, "hsync-active",
vpanel->hsync_active);
update_timings_prop(dev, &cset, timings, "vsync-active",
vpanel->vsync_active);
update_timings_prop(dev, &cset, timings, "de-active",
vpanel->de_active);
update_timings_prop(dev, &cset, timings, "hactive",
vpanel->hactive);
update_timings_prop(dev, &cset, timings, "hback-porch",
vpanel->hback_porch);
update_timings_prop(dev, &cset, timings, "hsync-len",
vpanel->hsync_len);
update_timings_prop(dev, &cset, timings, "vactive",
vpanel->vactive);
update_timings_prop(dev, &cset, timings, "vback-porch",
vpanel->vback_porch);
update_timings_prop(dev, &cset, timings, "vfront-porch",
vpanel->vfront_porch);
update_timings_prop(dev, &cset, timings, "vsync-len",
vpanel->hsync_len);
ret = of_changeset_apply(&cset);
if (ret) {
dev_err(dev, "could not apply device tree changeset\n");
goto err_destroy_cs;
}
return ret;
err_destroy_cs:
of_changeset_destroy(&cset);
return ret;
}
static void versatile_panel_probe(struct device *dev,
struct device_node *endpoint)
{
struct versatile_panel const *vpanel = NULL;
struct device_node *panel = NULL;
u32 val;
int ret;
int i;
/*
* The Versatile CLCD has a panel auto-detection mechanism.
* We use this and look for the compatible panel in the
* device tree.
*/
ret = regmap_read(versatile_syscon_map, SYS_CLCD, &val);
if (ret) {
dev_err(dev, "cannot read CLCD syscon register\n");
return;
}
val &= SYS_CLCD_CLCDID_MASK;
dev_info(dev, "SYS_CLCD=%08x\n", val);
/* First find corresponding panel information */
for (i = 0; i < ARRAY_SIZE(versatile_panels); i++) {
vpanel = &versatile_panels[i];
if (val = vpanel->id) {
dev_err(dev, "autodetected panel \"%s\"\n",
vpanel->compatible);
break;
}
}
if (i = ARRAY_SIZE(versatile_panels)) {
dev_err(dev, "could not auto-detect panel\n");
return;
}
/* This is the default panel node in the device tree */
panel = of_graph_get_remote_port_parent(endpoint);
if (!panel) {
dev_err(dev, "could not locate remote port for panel\n");
return;
}
/*
* So now we dynamically update the display properties of the
* panel in accordance to what was detected..
*/
ret = versatile_overwrite_of_panel(dev, panel, vpanel);
if (ret) {
dev_err(dev, "cannot overwrite devicetree panel\n");
return;
}
/*
* If we have a Sanyo 2.5" port
* that we're running on an IB2 and proceed to look for the
* IB2 syscon regmap.
*/
if (!vpanel->ib2)
return;
versatile_ib2_map = syscon_regmap_lookup_by_compatible(
"arm,versatile-ib2-syscon");
if (IS_ERR(versatile_ib2_map)) {
dev_err(dev, "could not locate IB2 control register\n");
versatile_ib2_map = NULL;
return;
}
}
This actually works. But would need some public device tree
property augmentation API instead of the hacks. Should I pursue
it?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread[parent not found: <CACRpkdaXFUCR5=5mS28_4Dx_LfzqV13zwT=vVeJwuOzm_rGRBQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-21 22:39 ` Linus Walleij
(?)
@ 2016-02-22 15:41 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-22 15:41 UTC (permalink / raw)
To: Linus Walleij, Russell King - ARM Linux, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
Jean-Christophe Plagniol-Villard, Pawel Moll,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann
[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]
On 22/02/16 00:39, Linus Walleij wrote:
> On Thu, Feb 18, 2016 at 12:52 PM, Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org> wrote:
>
>> For panels we need DT fragments. The question is where these fragments
>> are and, possibly, who who loads them.
>
> I hacked something up that augments the device tree from the kernel,
> given you have a node with all the props you want to augment, tell me
> what you think of this and whether I should continue in this direction...
> also the DT people need to be involved:
What you have there is almost like a legacy board file, isn't it? It's
just passing DT data forward, instead of device platform data. In fact,
if the driver in question supports platform data too, you could as well
generate platform data for it (but I'm not saying that's a better option).
After thinking this a bit and discussing it with Laurent P., generally
speaking I still think that the only sane option is that the bootloader
does any detection needed and provides the kernel a .dtb that contains
the HW that is connected. No board specific drivers are needed on the
kernel side.
In some cases userspace loaded DT overlays may be fine, if the userspace
can do the detection and the device in question is not somehow critical
to operation. But I think displays are critical, and afaik in Versatile
case the userspace can't even do the detection (?).
The third option is to have board specific display handling code and the
display HW data in the kernel, as you've done in the patches.
But, of course, which option should be used for which board is not
always clear...
What bootloader is used on Versatile? If it's some proprietary loader
which can't be changed, then the bootloader option is out, and I guess
it points to the third option, i.e. either the version in this patch or
the earlier version. If it's u-boot, I would suggest going for the
bootloader option.
Afaik u-boot doesn't support combining DT fragments yet. But (also
afaik) the u-boot maintainer is ok with the idea. And I know there are
others (for example TI) interested in the same functionality.
Now, adding that support might take some time, and in the meantime it'd
be good to get the HW working with kernel with a temporary solution. To
do that, my suggestion is basically "any solution which requires no
(temporary) changes to .dts".
While I don't like too much the solution in the patch here, it's all
inside kernel code and can be dropped easily, right? If we would merge
the the multi-endpoint solution you had in the earlier patch, you would
have to support that .dts in the future too.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-22 15:41 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-22 15:41 UTC (permalink / raw)
To: linux-arm-kernel
On 22/02/16 00:39, Linus Walleij wrote:
> On Thu, Feb 18, 2016 at 12:52 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> For panels we need DT fragments. The question is where these fragments
>> are and, possibly, who who loads them.
>
> I hacked something up that augments the device tree from the kernel,
> given you have a node with all the props you want to augment, tell me
> what you think of this and whether I should continue in this direction...
> also the DT people need to be involved:
What you have there is almost like a legacy board file, isn't it? It's
just passing DT data forward, instead of device platform data. In fact,
if the driver in question supports platform data too, you could as well
generate platform data for it (but I'm not saying that's a better option).
After thinking this a bit and discussing it with Laurent P., generally
speaking I still think that the only sane option is that the bootloader
does any detection needed and provides the kernel a .dtb that contains
the HW that is connected. No board specific drivers are needed on the
kernel side.
In some cases userspace loaded DT overlays may be fine, if the userspace
can do the detection and the device in question is not somehow critical
to operation. But I think displays are critical, and afaik in Versatile
case the userspace can't even do the detection (?).
The third option is to have board specific display handling code and the
display HW data in the kernel, as you've done in the patches.
But, of course, which option should be used for which board is not
always clear...
What bootloader is used on Versatile? If it's some proprietary loader
which can't be changed, then the bootloader option is out, and I guess
it points to the third option, i.e. either the version in this patch or
the earlier version. If it's u-boot, I would suggest going for the
bootloader option.
Afaik u-boot doesn't support combining DT fragments yet. But (also
afaik) the u-boot maintainer is ok with the idea. And I know there are
others (for example TI) interested in the same functionality.
Now, adding that support might take some time, and in the meantime it'd
be good to get the HW working with kernel with a temporary solution. To
do that, my suggestion is basically "any solution which requires no
(temporary) changes to .dts".
While I don't like too much the solution in the patch here, it's all
inside kernel code and can be dropped easily, right? If we would merge
the the multi-endpoint solution you had in the earlier patch, you would
have to support that .dts in the future too.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160222/75449315/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-22 15:41 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-22 15:41 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]
On 22/02/16 00:39, Linus Walleij wrote:
> On Thu, Feb 18, 2016 at 12:52 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> For panels we need DT fragments. The question is where these fragments
>> are and, possibly, who who loads them.
>
> I hacked something up that augments the device tree from the kernel,
> given you have a node with all the props you want to augment, tell me
> what you think of this and whether I should continue in this direction...
> also the DT people need to be involved:
What you have there is almost like a legacy board file, isn't it? It's
just passing DT data forward, instead of device platform data. In fact,
if the driver in question supports platform data too, you could as well
generate platform data for it (but I'm not saying that's a better option).
After thinking this a bit and discussing it with Laurent P., generally
speaking I still think that the only sane option is that the bootloader
does any detection needed and provides the kernel a .dtb that contains
the HW that is connected. No board specific drivers are needed on the
kernel side.
In some cases userspace loaded DT overlays may be fine, if the userspace
can do the detection and the device in question is not somehow critical
to operation. But I think displays are critical, and afaik in Versatile
case the userspace can't even do the detection (?).
The third option is to have board specific display handling code and the
display HW data in the kernel, as you've done in the patches.
But, of course, which option should be used for which board is not
always clear...
What bootloader is used on Versatile? If it's some proprietary loader
which can't be changed, then the bootloader option is out, and I guess
it points to the third option, i.e. either the version in this patch or
the earlier version. If it's u-boot, I would suggest going for the
bootloader option.
Afaik u-boot doesn't support combining DT fragments yet. But (also
afaik) the u-boot maintainer is ok with the idea. And I know there are
others (for example TI) interested in the same functionality.
Now, adding that support might take some time, and in the meantime it'd
be good to get the HW working with kernel with a temporary solution. To
do that, my suggestion is basically "any solution which requires no
(temporary) changes to .dts".
While I don't like too much the solution in the patch here, it's all
inside kernel code and can be dropped easily, right? If we would merge
the the multi-endpoint solution you had in the earlier patch, you would
have to support that .dts in the future too.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
[parent not found: <56CB2C31.5040703-l0cyMroinI0@public.gmane.org>]
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-22 15:41 ` Tomi Valkeinen
(?)
@ 2016-02-22 15:54 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-22 15:54 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Russell King - ARM Linux, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
Jean-Christophe Plagniol-Villard, Pawel Moll,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann
On Mon, Feb 22, 2016 at 4:41 PM, Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org> wrote:
> After thinking this a bit and discussing it with Laurent P., generally
> speaking I still think that the only sane option is that the bootloader
> does any detection needed and provides the kernel a .dtb that contains
> the HW that is connected. No board specific drivers are needed on the
> kernel side.
>
> In some cases userspace loaded DT overlays may be fine, if the userspace
> can do the detection and the device in question is not somehow critical
> to operation. But I think displays are critical, and afaik in Versatile
> case the userspace can't even do the detection (?).
>
> The third option is to have board specific display handling code and the
> display HW data in the kernel, as you've done in the patches.
Yeah correct...
> But, of course, which option should be used for which board is not
> always clear...
>
> What bootloader is used on Versatile?
It's U-boot indeed. Not that I've tried to compile or use it, I got it
as binary from ARM.
> If it's some proprietary loader
> which can't be changed, then the bootloader option is out, and I guess
> it points to the third option, i.e. either the version in this patch or
> the earlier version. If it's u-boot, I would suggest going for the
> bootloader option.
>
> Afaik u-boot doesn't support combining DT fragments yet. But (also
> afaik) the u-boot maintainer is ok with the idea. And I know there are
> others (for example TI) interested in the same functionality.
Hm OK.... so the bootloader need to be better at augmenting device
trees than the kernel. Well... The problem is that there are a bunch
of deployed systems out there and they all need to have their boot loader
updated then, which may be OK since it's ARM development boards
but I don't know.
> Now, adding that support might take some time, and in the meantime it'd
> be good to get the HW working with kernel with a temporary solution. To
> do that, my suggestion is basically "any solution which requires no
> (temporary) changes to .dts".
>
> While I don't like too much the solution in the patch here, it's all
> inside kernel code and can be dropped easily, right? If we would merge
> the the multi-endpoint solution you had in the earlier patch, you would
> have to support that .dts in the future too.
To go with this solution I need to extend the drivers/of library to be
able to update properties properly instead of this hack, and that is
non-reversible if we start to use it.
It is not really an overlay because the DT stuff is dynamically
augmented by the kernel, not taken from somewhere else.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-22 15:54 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-22 15:54 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Feb 22, 2016 at 4:41 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> After thinking this a bit and discussing it with Laurent P., generally
> speaking I still think that the only sane option is that the bootloader
> does any detection needed and provides the kernel a .dtb that contains
> the HW that is connected. No board specific drivers are needed on the
> kernel side.
>
> In some cases userspace loaded DT overlays may be fine, if the userspace
> can do the detection and the device in question is not somehow critical
> to operation. But I think displays are critical, and afaik in Versatile
> case the userspace can't even do the detection (?).
>
> The third option is to have board specific display handling code and the
> display HW data in the kernel, as you've done in the patches.
Yeah correct...
> But, of course, which option should be used for which board is not
> always clear...
>
> What bootloader is used on Versatile?
It's U-boot indeed. Not that I've tried to compile or use it, I got it
as binary from ARM.
> If it's some proprietary loader
> which can't be changed, then the bootloader option is out, and I guess
> it points to the third option, i.e. either the version in this patch or
> the earlier version. If it's u-boot, I would suggest going for the
> bootloader option.
>
> Afaik u-boot doesn't support combining DT fragments yet. But (also
> afaik) the u-boot maintainer is ok with the idea. And I know there are
> others (for example TI) interested in the same functionality.
Hm OK.... so the bootloader need to be better at augmenting device
trees than the kernel. Well... The problem is that there are a bunch
of deployed systems out there and they all need to have their boot loader
updated then, which may be OK since it's ARM development boards
but I don't know.
> Now, adding that support might take some time, and in the meantime it'd
> be good to get the HW working with kernel with a temporary solution. To
> do that, my suggestion is basically "any solution which requires no
> (temporary) changes to .dts".
>
> While I don't like too much the solution in the patch here, it's all
> inside kernel code and can be dropped easily, right? If we would merge
> the the multi-endpoint solution you had in the earlier patch, you would
> have to support that .dts in the future too.
To go with this solution I need to extend the drivers/of library to be
able to update properties properly instead of this hack, and that is
non-reversible if we start to use it.
It is not really an overlay because the DT stuff is dynamically
augmented by the kernel, not taken from somewhere else.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-22 15:54 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-22 15:54 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Feb 22, 2016 at 4:41 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> After thinking this a bit and discussing it with Laurent P., generally
> speaking I still think that the only sane option is that the bootloader
> does any detection needed and provides the kernel a .dtb that contains
> the HW that is connected. No board specific drivers are needed on the
> kernel side.
>
> In some cases userspace loaded DT overlays may be fine, if the userspace
> can do the detection and the device in question is not somehow critical
> to operation. But I think displays are critical, and afaik in Versatile
> case the userspace can't even do the detection (?).
>
> The third option is to have board specific display handling code and the
> display HW data in the kernel, as you've done in the patches.
Yeah correct...
> But, of course, which option should be used for which board is not
> always clear...
>
> What bootloader is used on Versatile?
It's U-boot indeed. Not that I've tried to compile or use it, I got it
as binary from ARM.
> If it's some proprietary loader
> which can't be changed, then the bootloader option is out, and I guess
> it points to the third option, i.e. either the version in this patch or
> the earlier version. If it's u-boot, I would suggest going for the
> bootloader option.
>
> Afaik u-boot doesn't support combining DT fragments yet. But (also
> afaik) the u-boot maintainer is ok with the idea. And I know there are
> others (for example TI) interested in the same functionality.
Hm OK.... so the bootloader need to be better at augmenting device
trees than the kernel. Well... The problem is that there are a bunch
of deployed systems out there and they all need to have their boot loader
updated then, which may be OK since it's ARM development boards
but I don't know.
> Now, adding that support might take some time, and in the meantime it'd
> be good to get the HW working with kernel with a temporary solution. To
> do that, my suggestion is basically "any solution which requires no
> (temporary) changes to .dts".
>
> While I don't like too much the solution in the patch here, it's all
> inside kernel code and can be dropped easily, right? If we would merge
> the the multi-endpoint solution you had in the earlier patch, you would
> have to support that .dts in the future too.
To go with this solution I need to extend the drivers/of library to be
able to update properties properly instead of this hack, and that is
non-reversible if we start to use it.
It is not really an overlay because the DT stuff is dynamically
augmented by the kernel, not taken from somewhere else.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-23 9:08 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-23 9:08 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> This moves the versatile CLCD configuration to the device tree by:
As this Schrödinger's cat approach seems controversial, as well
as the alternative to manipulate the DT in memory at run-time,
I will respin the series without the full Versatile support, adding
plug-in for the other ARM boards and and half-baked support
for the Versatile supporting just VGA (like the other reference
designs from ARM).
The pluggable displays prove yet again to be a problem to the
world, sigh.
I will think of a better solution, if any, for this for v4.6, but will
put forward something that handles the Nomadik and all the
other ARM reference designs for now.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 9:08 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-23 9:08 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> This moves the versatile CLCD configuration to the device tree by:
As this Schr?dinger's cat approach seems controversial, as well
as the alternative to manipulate the DT in memory at run-time,
I will respin the series without the full Versatile support, adding
plug-in for the other ARM boards and and half-baked support
for the Versatile supporting just VGA (like the other reference
designs from ARM).
The pluggable displays prove yet again to be a problem to the
world, sigh.
I will think of a better solution, if any, for this for v4.6, but will
put forward something that handles the Nomadik and all the
other ARM reference designs for now.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 9:08 ` Linus Walleij
@ 2016-02-23 9:34 ` Arnd Bergmann
-1 siblings, 0 replies; 145+ messages in thread
From: Arnd Bergmann @ 2016-02-23 9:34 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 23 February 2016 10:08:05 Linus Walleij wrote:
> I will think of a better solution, if any, for this for v4.6, but will
> put forward something that handles the Nomadik and all the
> other ARM reference designs for now.
>
How about still describing all known panels in the DT marked 'status="disabled"',
but then having a minimal piece of board specific code that just enables
whichever one gets detected at boot time?
Arnd
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 9:34 ` Arnd Bergmann
0 siblings, 0 replies; 145+ messages in thread
From: Arnd Bergmann @ 2016-02-23 9:34 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 23 February 2016 10:08:05 Linus Walleij wrote:
> I will think of a better solution, if any, for this for v4.6, but will
> put forward something that handles the Nomadik and all the
> other ARM reference designs for now.
>
How about still describing all known panels in the DT marked 'status="disabled"',
but then having a minimal piece of board specific code that just enables
whichever one gets detected at boot time?
Arnd
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 9:34 ` Arnd Bergmann
@ 2016-02-23 10:10 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-23 10:10 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 10:34 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 23 February 2016 10:08:05 Linus Walleij wrote:
>> I will think of a better solution, if any, for this for v4.6, but will
>> put forward something that handles the Nomadik and all the
>> other ARM reference designs for now.
>>
>
> How about still describing all known panels in the DT marked 'status="disabled"',
> but then having a minimal piece of board specific code that just enables
> whichever one gets detected at boot time?
Close but no cigar :D
It means that all panels (enabled and all disabled) have to have the same
endpoint in the of_graph.
I tried it:
panel@0 {
compatible = "panel-dpi";
port {
clcd_panel: endpoint {
remote-endpoint = <&clcd_pads>;
};
};
(...)
panel@1 {
compatible = "panel-dpi";
port {
clcd_panel: endpoint {
remote-endpoint = <&clcd_pads>;
};
};
(...)
display@10120000 {
(...)
port {
(...)
clcd_pads: endpoint@0 {
reg = <0>;
remote-endpoint = <&clcd_panel>;
arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
};
};
Building the device tree:
ERROR (duplicate_label): ERROR (duplicate_label): Duplicate label
'clcd_panel' on /panel@1/port/endpoint and /panel@0/port/endpoint
Duplicate label 'clcd_panel' on /panel@1/port/endpoint and
/panel@0/port/endpoint
So the dtc does not allow duplicate node labels for the phandle
even if the node it resides in is disabled. Tough luck...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 10:10 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-23 10:10 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 10:34 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 23 February 2016 10:08:05 Linus Walleij wrote:
>> I will think of a better solution, if any, for this for v4.6, but will
>> put forward something that handles the Nomadik and all the
>> other ARM reference designs for now.
>>
>
> How about still describing all known panels in the DT marked 'status="disabled"',
> but then having a minimal piece of board specific code that just enables
> whichever one gets detected at boot time?
Close but no cigar :D
It means that all panels (enabled and all disabled) have to have the same
endpoint in the of_graph.
I tried it:
panel at 0 {
compatible = "panel-dpi";
port {
clcd_panel: endpoint {
remote-endpoint = <&clcd_pads>;
};
};
(...)
panel at 1 {
compatible = "panel-dpi";
port {
clcd_panel: endpoint {
remote-endpoint = <&clcd_pads>;
};
};
(...)
display at 10120000 {
(...)
port {
(...)
clcd_pads: endpoint at 0 {
reg = <0>;
remote-endpoint = <&clcd_panel>;
arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
};
};
Building the device tree:
ERROR (duplicate_label): ERROR (duplicate_label): Duplicate label
'clcd_panel' on /panel at 1/port/endpoint and /panel at 0/port/endpoint
Duplicate label 'clcd_panel' on /panel at 1/port/endpoint and
/panel at 0/port/endpoint
So the dtc does not allow duplicate node labels for the phandle
even if the node it resides in is disabled. Tough luck...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 10:10 ` Linus Walleij
@ 2016-02-23 11:22 ` Arnd Bergmann
-1 siblings, 0 replies; 145+ messages in thread
From: Arnd Bergmann @ 2016-02-23 11:22 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 23 February 2016 11:10:33 Linus Walleij wrote:
>
> ERROR (duplicate_label): ERROR (duplicate_label): Duplicate label
> 'clcd_panel' on /panel@1/port/endpoint and /panel@0/port/endpoint
> Duplicate label 'clcd_panel' on /panel@1/port/endpoint and
> /panel@0/port/endpoint
>
> So the dtc does not allow duplicate node labels for the phandle
> even if the node it resides in is disabled. Tough luck...
Ah, too bad. I guess we could still do it by also setting the
remote-endpoint property to node->phandle, but then it's
not as simple any more.
Arnd
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 11:22 ` Arnd Bergmann
0 siblings, 0 replies; 145+ messages in thread
From: Arnd Bergmann @ 2016-02-23 11:22 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 23 February 2016 11:10:33 Linus Walleij wrote:
>
> ERROR (duplicate_label): ERROR (duplicate_label): Duplicate label
> 'clcd_panel' on /panel at 1/port/endpoint and /panel at 0/port/endpoint
> Duplicate label 'clcd_panel' on /panel at 1/port/endpoint and
> /panel at 0/port/endpoint
>
> So the dtc does not allow duplicate node labels for the phandle
> even if the node it resides in is disabled. Tough luck...
Ah, too bad. I guess we could still do it by also setting the
remote-endpoint property to node->phandle, but then it's
not as simple any more.
Arnd
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 11:22 ` Arnd Bergmann
@ 2016-02-23 13:00 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-23 13:00 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]
On 23/02/16 13:22, Arnd Bergmann wrote:
> On Tuesday 23 February 2016 11:10:33 Linus Walleij wrote:
>>
>> ERROR (duplicate_label): ERROR (duplicate_label): Duplicate label
>> 'clcd_panel' on /panel@1/port/endpoint and /panel@0/port/endpoint
>> Duplicate label 'clcd_panel' on /panel@1/port/endpoint and
>> /panel@0/port/endpoint
>>
>> So the dtc does not allow duplicate node labels for the phandle
>> even if the node it resides in is disabled. Tough luck...
>
> Ah, too bad. I guess we could still do it by also setting the
> remote-endpoint property to node->phandle, but then it's
> not as simple any more.
I think it could be done with all panels in an endpoint of their own, as
it is currently in this patch. All the panels would be disabled by
default, and one of them gets enabled at some early boot phase. The
fbdev driver would then iterate the endpoints and pick the first panel
that's enabled.
That would be almost the same as what's already in this patch, except
(if I'm not mistaken) the detection part could be in platform code, and
the fbdev driver itself would know nothing about board specific
detection or board specific panel lists.
So maybe that would be a bit cleaner. Still ugly, I think =). I really
don't like having possible-panels in the Schrödinger's DT data
(http://www.angryflower.com/387.html).
That said, maybe this is the best way to deal with Versatile, without
requiring any change to the bootloader or the boot mechanism.
What is the current status of Versatile? Have we had working display
with Versatile when booting with device tree? Or has the display been
supported only with legacy boot?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 13:00 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-23 13:00 UTC (permalink / raw)
To: linux-arm-kernel
On 23/02/16 13:22, Arnd Bergmann wrote:
> On Tuesday 23 February 2016 11:10:33 Linus Walleij wrote:
>>
>> ERROR (duplicate_label): ERROR (duplicate_label): Duplicate label
>> 'clcd_panel' on /panel at 1/port/endpoint and /panel at 0/port/endpoint
>> Duplicate label 'clcd_panel' on /panel at 1/port/endpoint and
>> /panel at 0/port/endpoint
>>
>> So the dtc does not allow duplicate node labels for the phandle
>> even if the node it resides in is disabled. Tough luck...
>
> Ah, too bad. I guess we could still do it by also setting the
> remote-endpoint property to node->phandle, but then it's
> not as simple any more.
I think it could be done with all panels in an endpoint of their own, as
it is currently in this patch. All the panels would be disabled by
default, and one of them gets enabled at some early boot phase. The
fbdev driver would then iterate the endpoints and pick the first panel
that's enabled.
That would be almost the same as what's already in this patch, except
(if I'm not mistaken) the detection part could be in platform code, and
the fbdev driver itself would know nothing about board specific
detection or board specific panel lists.
So maybe that would be a bit cleaner. Still ugly, I think =). I really
don't like having possible-panels in the Schr?dinger's DT data
(http://www.angryflower.com/387.html).
That said, maybe this is the best way to deal with Versatile, without
requiring any change to the bootloader or the boot mechanism.
What is the current status of Versatile? Have we had working display
with Versatile when booting with device tree? Or has the display been
supported only with legacy boot?
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/39c3ae95/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 13:00 ` Tomi Valkeinen
@ 2016-02-23 13:16 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-23 13:16 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 2:00 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> That would be almost the same as what's already in this patch, except
> (if I'm not mistaken) the detection part could be in platform code, and
> the fbdev driver itself would know nothing about board specific
> detection or board specific panel lists.
In this patch set the board/platform-specific plugins are separated
out adding the opaque .board_init() and .panel_init() to the driver.
The platform-specific code is in completely separate files this way,
and the CLCD driver itself just handles various versions of that
IP block.
> So maybe that would be a bit cleaner. Still ugly, I think =). I really
> don't like having possible-panels in the Schrödinger's DT data
> (http://www.angryflower.com/387.html).
OK I will focus my work on the DT-augment code instead.
> That said, maybe this is the best way to deal with Versatile, without
> requiring any change to the bootloader or the boot mechanism.
Depends on if the OF core maintainers will accept my patches to
dynamically alter DT properties at runtime. If I can't do that then
I have to go back to the Schrödinger patch.
> What is the current status of Versatile? Have we had working display
> with Versatile when booting with device tree? Or has the display been
> supported only with legacy boot?
Versatile is DT only as of kernel v4.5. The DT boot uses AUXDATA
which is the Frankenstein solution, bolting on a boardfile piece
to the DT boot and ignoring the existing panel bindings, and of
course standing in the way of cleaning things up.
IMO Schrödinger > Frankenstein.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 13:16 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-23 13:16 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 2:00 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> That would be almost the same as what's already in this patch, except
> (if I'm not mistaken) the detection part could be in platform code, and
> the fbdev driver itself would know nothing about board specific
> detection or board specific panel lists.
In this patch set the board/platform-specific plugins are separated
out adding the opaque .board_init() and .panel_init() to the driver.
The platform-specific code is in completely separate files this way,
and the CLCD driver itself just handles various versions of that
IP block.
> So maybe that would be a bit cleaner. Still ugly, I think =). I really
> don't like having possible-panels in the Schr?dinger's DT data
> (http://www.angryflower.com/387.html).
OK I will focus my work on the DT-augment code instead.
> That said, maybe this is the best way to deal with Versatile, without
> requiring any change to the bootloader or the boot mechanism.
Depends on if the OF core maintainers will accept my patches to
dynamically alter DT properties at runtime. If I can't do that then
I have to go back to the Schr?dinger patch.
> What is the current status of Versatile? Have we had working display
> with Versatile when booting with device tree? Or has the display been
> supported only with legacy boot?
Versatile is DT only as of kernel v4.5. The DT boot uses AUXDATA
which is the Frankenstein solution, bolting on a boardfile piece
to the DT boot and ignoring the existing panel bindings, and of
course standing in the way of cleaning things up.
IMO Schr?dinger > Frankenstein.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 13:16 ` Linus Walleij
@ 2016-02-23 13:38 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-23 13:38 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 3124 bytes --]
On 23/02/16 15:16, Linus Walleij wrote:
> On Tue, Feb 23, 2016 at 2:00 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> That would be almost the same as what's already in this patch, except
>> (if I'm not mistaken) the detection part could be in platform code, and
>> the fbdev driver itself would know nothing about board specific
>> detection or board specific panel lists.
>
> In this patch set the board/platform-specific plugins are separated
> out adding the opaque .board_init() and .panel_init() to the driver.
> The platform-specific code is in completely separate files this way,
> and the CLCD driver itself just handles various versions of that
> IP block.
I see. Yes, it's in separate files but still part of the fbdev driver.
One thing to mention is that I'm looking at this maybe from a slightly
different perspective.
TI makes SoCs which may be used on a lot of different boards from
different vendors. I will not allow any solution on TI display subsystem
that would contain any board specific data, as that would quickly expand
to an unmaintainable mess. All the display data has to come from the
bootloader.
Maybe Versatile is different. If CLCD is only used on that board, or a
small family of boards, from one vendor, I guess it is maintainable to
have board specific driver parts for CLCD. But if CLCD can be used by
many vendors in many different boards, I'd steer clear of board specific
driver code.
>> So maybe that would be a bit cleaner. Still ugly, I think =). I really
>> don't like having possible-panels in the Schrödinger's DT data
>> (http://www.angryflower.com/387.html).
>
> OK I will focus my work on the DT-augment code instead.
Yeah, I don't know if that will fly either, so I think it's better to
see if these discussion go somewhere first.
>> That said, maybe this is the best way to deal with Versatile, without
>> requiring any change to the bootloader or the boot mechanism.
>
> Depends on if the OF core maintainers will accept my patches to
> dynamically alter DT properties at runtime. If I can't do that then
> I have to go back to the Schrödinger patch.
>
>> What is the current status of Versatile? Have we had working display
>> with Versatile when booting with device tree? Or has the display been
>> supported only with legacy boot?
>
> Versatile is DT only as of kernel v4.5. The DT boot uses AUXDATA
> which is the Frankenstein solution, bolting on a boardfile piece
> to the DT boot and ignoring the existing panel bindings, and of
> course standing in the way of cleaning things up.
Ok. I feel everyone is trying to push the ugly part out of their domain.
I want the board specific hacks out of fbdev. Bootloader people don't
want it there. arch/arm/ people don't want it there. =)
So what you're saying is that Versatile boots now with DT, and supports
display without any panel info in the DT data? If so, it means that when
you add panel data to the .dts, the old .dts will not support display
anymore, except if you leave all the current boardfile stuff there.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 13:38 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-23 13:38 UTC (permalink / raw)
To: linux-arm-kernel
On 23/02/16 15:16, Linus Walleij wrote:
> On Tue, Feb 23, 2016 at 2:00 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> That would be almost the same as what's already in this patch, except
>> (if I'm not mistaken) the detection part could be in platform code, and
>> the fbdev driver itself would know nothing about board specific
>> detection or board specific panel lists.
>
> In this patch set the board/platform-specific plugins are separated
> out adding the opaque .board_init() and .panel_init() to the driver.
> The platform-specific code is in completely separate files this way,
> and the CLCD driver itself just handles various versions of that
> IP block.
I see. Yes, it's in separate files but still part of the fbdev driver.
One thing to mention is that I'm looking at this maybe from a slightly
different perspective.
TI makes SoCs which may be used on a lot of different boards from
different vendors. I will not allow any solution on TI display subsystem
that would contain any board specific data, as that would quickly expand
to an unmaintainable mess. All the display data has to come from the
bootloader.
Maybe Versatile is different. If CLCD is only used on that board, or a
small family of boards, from one vendor, I guess it is maintainable to
have board specific driver parts for CLCD. But if CLCD can be used by
many vendors in many different boards, I'd steer clear of board specific
driver code.
>> So maybe that would be a bit cleaner. Still ugly, I think =). I really
>> don't like having possible-panels in the Schr?dinger's DT data
>> (http://www.angryflower.com/387.html).
>
> OK I will focus my work on the DT-augment code instead.
Yeah, I don't know if that will fly either, so I think it's better to
see if these discussion go somewhere first.
>> That said, maybe this is the best way to deal with Versatile, without
>> requiring any change to the bootloader or the boot mechanism.
>
> Depends on if the OF core maintainers will accept my patches to
> dynamically alter DT properties at runtime. If I can't do that then
> I have to go back to the Schr?dinger patch.
>
>> What is the current status of Versatile? Have we had working display
>> with Versatile when booting with device tree? Or has the display been
>> supported only with legacy boot?
>
> Versatile is DT only as of kernel v4.5. The DT boot uses AUXDATA
> which is the Frankenstein solution, bolting on a boardfile piece
> to the DT boot and ignoring the existing panel bindings, and of
> course standing in the way of cleaning things up.
Ok. I feel everyone is trying to push the ugly part out of their domain.
I want the board specific hacks out of fbdev. Bootloader people don't
want it there. arch/arm/ people don't want it there. =)
So what you're saying is that Versatile boots now with DT, and supports
display without any panel info in the DT data? If so, it means that when
you add panel data to the .dts, the old .dts will not support display
anymore, except if you leave all the current boardfile stuff there.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/9c052c07/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 13:38 ` Tomi Valkeinen
@ 2016-02-24 10:53 ` Russell King - ARM Linux
-1 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-24 10:53 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 03:38:12PM +0200, Tomi Valkeinen wrote:
> Ok. I feel everyone is trying to push the ugly part out of their domain.
> I want the board specific hacks out of fbdev. Bootloader people don't
> want it there. arch/arm/ people don't want it there. =)
I think that is really really unfair. No one is trying to push ugly
bits out of their domain - this is being driven by Linus, who is
trying to convert Versatile to DT. There is no other agenda here.
Remember, I was the one who wrote the CLCD driver, and it was written
to support the boards at the time using the best methods at the time.
Things change, people's ideas of what's acceptable change. What was
acceptable when classes of boards were separate is no longer acceptable
with single zImage.
The board specific parts of CLCD were in arch/arm for a very long time,
but that gets in the way of single zImage, and the solution adopted by
the newly interested parties has been to move them to drivers/video
to keep things working.
That's how we're here: there isn't a conspiracy as you seem to be
thinking.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-24 10:53 ` Russell King - ARM Linux
0 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-24 10:53 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 03:38:12PM +0200, Tomi Valkeinen wrote:
> Ok. I feel everyone is trying to push the ugly part out of their domain.
> I want the board specific hacks out of fbdev. Bootloader people don't
> want it there. arch/arm/ people don't want it there. =)
I think that is really really unfair. No one is trying to push ugly
bits out of their domain - this is being driven by Linus, who is
trying to convert Versatile to DT. There is no other agenda here.
Remember, I was the one who wrote the CLCD driver, and it was written
to support the boards at the time using the best methods at the time.
Things change, people's ideas of what's acceptable change. What was
acceptable when classes of boards were separate is no longer acceptable
with single zImage.
The board specific parts of CLCD were in arch/arm for a very long time,
but that gets in the way of single zImage, and the solution adopted by
the newly interested parties has been to move them to drivers/video
to keep things working.
That's how we're here: there isn't a conspiracy as you seem to be
thinking.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-24 10:53 ` Russell King - ARM Linux
@ 2016-02-24 11:35 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-24 11:35 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]
On 24/02/16 12:53, Russell King - ARM Linux wrote:
> On Tue, Feb 23, 2016 at 03:38:12PM +0200, Tomi Valkeinen wrote:
>> Ok. I feel everyone is trying to push the ugly part out of their domain.
>> I want the board specific hacks out of fbdev. Bootloader people don't
>> want it there. arch/arm/ people don't want it there. =)
>
> I think that is really really unfair. No one is trying to push ugly
> bits out of their domain - this is being driven by Linus, who is
> trying to convert Versatile to DT. There is no other agenda here.
>
> Remember, I was the one who wrote the CLCD driver, and it was written
> to support the boards at the time using the best methods at the time.
> Things change, people's ideas of what's acceptable change. What was
> acceptable when classes of boards were separate is no longer acceptable
> with single zImage.
That's fine. I've done the same. The point here is where should we aim
for with today's kernel? What's the good solution for the future boards?
> The board specific parts of CLCD were in arch/arm for a very long time,
> but that gets in the way of single zImage, and the solution adopted by
> the newly interested parties has been to move them to drivers/video
> to keep things working.
And I'm fine with having board specific parts in drivers/video when
needed. That's the only option when we really need a driver for the
board specific parts, i.e. we need to do something with the board
specific HW at runtime.
But that's not really the case with Versatile. Correct me if I'm wrong,
but there's just one panel connected to the board at a time and the
panel cannot be changed at runtime. We need to do the board specific
panel probing once at boot time, but other than that, there's no
difference to a single on-board panel.
To me it sounds that the cleanest solution to this is that the
bootloader does the detection (it's a trivial detection, isn't it? no
complex busses need to be used?), and just passes the kernel the correct
HW setup with DT.
Again, I understand there are lots of board out there without bootloader
doing that, so we may not get there with Versatile. But if someone comes
with patches for a new board, I'd like to have a good suggestion how to
handle similar cases the best way.
> That's how we're here: there isn't a conspiracy as you seem to be
> thinking.
I wasn't exactly serious there, as the smiley tried to imply...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-24 11:35 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-24 11:35 UTC (permalink / raw)
To: linux-arm-kernel
On 24/02/16 12:53, Russell King - ARM Linux wrote:
> On Tue, Feb 23, 2016 at 03:38:12PM +0200, Tomi Valkeinen wrote:
>> Ok. I feel everyone is trying to push the ugly part out of their domain.
>> I want the board specific hacks out of fbdev. Bootloader people don't
>> want it there. arch/arm/ people don't want it there. =)
>
> I think that is really really unfair. No one is trying to push ugly
> bits out of their domain - this is being driven by Linus, who is
> trying to convert Versatile to DT. There is no other agenda here.
>
> Remember, I was the one who wrote the CLCD driver, and it was written
> to support the boards at the time using the best methods at the time.
> Things change, people's ideas of what's acceptable change. What was
> acceptable when classes of boards were separate is no longer acceptable
> with single zImage.
That's fine. I've done the same. The point here is where should we aim
for with today's kernel? What's the good solution for the future boards?
> The board specific parts of CLCD were in arch/arm for a very long time,
> but that gets in the way of single zImage, and the solution adopted by
> the newly interested parties has been to move them to drivers/video
> to keep things working.
And I'm fine with having board specific parts in drivers/video when
needed. That's the only option when we really need a driver for the
board specific parts, i.e. we need to do something with the board
specific HW at runtime.
But that's not really the case with Versatile. Correct me if I'm wrong,
but there's just one panel connected to the board at a time and the
panel cannot be changed at runtime. We need to do the board specific
panel probing once at boot time, but other than that, there's no
difference to a single on-board panel.
To me it sounds that the cleanest solution to this is that the
bootloader does the detection (it's a trivial detection, isn't it? no
complex busses need to be used?), and just passes the kernel the correct
HW setup with DT.
Again, I understand there are lots of board out there without bootloader
doing that, so we may not get there with Versatile. But if someone comes
with patches for a new board, I'd like to have a good suggestion how to
handle similar cases the best way.
> That's how we're here: there isn't a conspiracy as you seem to be
> thinking.
I wasn't exactly serious there, as the smiley tried to imply...
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/6b6f3241/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 13:38 ` Tomi Valkeinen
@ 2016-02-25 14:04 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-25 14:04 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 2:38 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Maybe Versatile is different. If CLCD is only used on that board, or a
> small family of boards, from one vendor, I guess it is maintainable to
> have board specific driver parts for CLCD. But if CLCD can be used by
> many vendors in many different boards, I'd steer clear of board specific
> driver code.
OK I think at this point we would say that CLCD is a legacy driver.
It is a PrimceCell (IP block) made by ARM Ltd for their reference
designs, and intended for demonstration purposes. It is used in
these:
arch/arm/mach-integrator/
arch/arm/mach-versatile/
arch/arm/mach-realview/
arch/arm/mach-vexpress/
At the last iteration of their reference designs, ARM invented a
new display driver called HDLCD, which you can find in
drivers/gpu/drm/arm in linux-next. Thus the CLCD is now legacy.
As part of signing a deal with ARM to synthesize their silicon,
vendors get copies of the IP blocks to jumpstart design work.
Sometimes they will design their own display controller, sometimes
they will take the ARM CLCD and synthesize it right off
and not innovate around it at all. That is why CLCD also
appears in:
arch/arm/configs/axm55xx_defconfig
arch/arm/configs/lpc18xx_defconfig
arch/arm/boot/dts/lpc18xx.dtsi
arch/arm/configs/lpc32xx_defconfig
arch/arm/boot/dts/lpc32xx.dtsi
arch/arm/configs/netx_defconfig
arch/arm/configs/spear3xx_defconfig
Sometimes the vendors will tweak the CLCD. St Microelectronics
did the latter, and that is why I add support for that variant as
well.
HOWEVER: the ARM Versatile is the *only* platform I have
seen of these that have plug'n'play for the display.
*All* the others
will be very happy with *ONE* display defined as panel in the
device tree, and off they go. Usually VGA. And that will look
much like arch/arm/boot/dts/vexpress-v2m.dtsi already look
like today, using "panel-dpi" to define their displays.
They and their displays may need some board-specific or SoC
specific tweaks though, just like the Nomadik. The Vexpress is
happy to be able to go without, because I guess it is hard-coded
to just use the DVI output, so no path for the signal needs to be
set up.
I add support for doing this for the Integrator and RealView in
the patch set, by grabbing a handle to the system controller
where they have a few "misc registers". However if you look at
it:
static void integrator_clcd_enable(struct clcd_fb *fb)
{
struct fb_var_screeninfo *var = &fb->fb.var;
u32 val;
dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
if (var->bits_per_pixel <= 8 ||
(var->bits_per_pixel = 16 && var->green.length = 5))
/* Pseudocolor, RGB555, BGR555 */
val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
else if (fb->fb.var.bits_per_pixel <= 16)
/* truecolor RGB565 */
val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
else
val = 0; /* no idea for this, don't trust the docs */
regmap_update_bits(versatile_syscon_map,
INTEGRATOR_HDR_CTRL_OFFSET,
0,
INTEGRATOR_CLCD_MASK);
}
This is stuff that is so closely tied in to the fbdev driver that even
if it is SoC-specific (and reside in arch/arm/mach-integrator etc
today) it would be hard to argument that it should not be part
of the fbdev driver: what it does is connect the lines out of the
CLCD block to the physical VGA encode chip in different ways
depending on how the pixels were set up.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-25 14:04 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-25 14:04 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 2:38 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Maybe Versatile is different. If CLCD is only used on that board, or a
> small family of boards, from one vendor, I guess it is maintainable to
> have board specific driver parts for CLCD. But if CLCD can be used by
> many vendors in many different boards, I'd steer clear of board specific
> driver code.
OK I think at this point we would say that CLCD is a legacy driver.
It is a PrimceCell (IP block) made by ARM Ltd for their reference
designs, and intended for demonstration purposes. It is used in
these:
arch/arm/mach-integrator/
arch/arm/mach-versatile/
arch/arm/mach-realview/
arch/arm/mach-vexpress/
At the last iteration of their reference designs, ARM invented a
new display driver called HDLCD, which you can find in
drivers/gpu/drm/arm in linux-next. Thus the CLCD is now legacy.
As part of signing a deal with ARM to synthesize their silicon,
vendors get copies of the IP blocks to jumpstart design work.
Sometimes they will design their own display controller, sometimes
they will take the ARM CLCD and synthesize it right off
and not innovate around it at all. That is why CLCD also
appears in:
arch/arm/configs/axm55xx_defconfig
arch/arm/configs/lpc18xx_defconfig
arch/arm/boot/dts/lpc18xx.dtsi
arch/arm/configs/lpc32xx_defconfig
arch/arm/boot/dts/lpc32xx.dtsi
arch/arm/configs/netx_defconfig
arch/arm/configs/spear3xx_defconfig
Sometimes the vendors will tweak the CLCD. St Microelectronics
did the latter, and that is why I add support for that variant as
well.
HOWEVER: the ARM Versatile is the *only* platform I have
seen of these that have plug'n'play for the display.
*All* the others
will be very happy with *ONE* display defined as panel in the
device tree, and off they go. Usually VGA. And that will look
much like arch/arm/boot/dts/vexpress-v2m.dtsi already look
like today, using "panel-dpi" to define their displays.
They and their displays may need some board-specific or SoC
specific tweaks though, just like the Nomadik. The Vexpress is
happy to be able to go without, because I guess it is hard-coded
to just use the DVI output, so no path for the signal needs to be
set up.
I add support for doing this for the Integrator and RealView in
the patch set, by grabbing a handle to the system controller
where they have a few "misc registers". However if you look at
it:
static void integrator_clcd_enable(struct clcd_fb *fb)
{
struct fb_var_screeninfo *var = &fb->fb.var;
u32 val;
dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
if (var->bits_per_pixel <= 8 ||
(var->bits_per_pixel == 16 && var->green.length == 5))
/* Pseudocolor, RGB555, BGR555 */
val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
else if (fb->fb.var.bits_per_pixel <= 16)
/* truecolor RGB565 */
val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
else
val = 0; /* no idea for this, don't trust the docs */
regmap_update_bits(versatile_syscon_map,
INTEGRATOR_HDR_CTRL_OFFSET,
0,
INTEGRATOR_CLCD_MASK);
}
This is stuff that is so closely tied in to the fbdev driver that even
if it is SoC-specific (and reside in arch/arm/mach-integrator etc
today) it would be hard to argument that it should not be part
of the fbdev driver: what it does is connect the lines out of the
CLCD block to the physical VGA encode chip in different ways
depending on how the pixels were set up.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-25 14:04 ` Linus Walleij
@ 2016-02-25 16:08 ` Arnd Bergmann
-1 siblings, 0 replies; 145+ messages in thread
From: Arnd Bergmann @ 2016-02-25 16:08 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 25 February 2016 15:04:52 Linus Walleij wrote:
>
> I add support for doing this for the Integrator and RealView in
> the patch set, by grabbing a handle to the system controller
> where they have a few "misc registers". However if you look at
> it:
>
> static void integrator_clcd_enable(struct clcd_fb *fb)
> {
> struct fb_var_screeninfo *var = &fb->fb.var;
> u32 val;
>
> dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
>
> val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
> INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
> if (var->bits_per_pixel <= 8 ||
> (var->bits_per_pixel = 16 && var->green.length = 5))
> /* Pseudocolor, RGB555, BGR555 */
> val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
> else if (fb->fb.var.bits_per_pixel <= 16)
> /* truecolor RGB565 */
> val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
> else
> val = 0; /* no idea for this, don't trust the docs */
>
> regmap_update_bits(versatile_syscon_map,
> INTEGRATOR_HDR_CTRL_OFFSET,
> 0,
> INTEGRATOR_CLCD_MASK);
> }
>
> This is stuff that is so closely tied in to the fbdev driver that even
> if it is SoC-specific (and reside in arch/arm/mach-integrator etc
> today) it would be hard to argument that it should not be part
> of the fbdev driver: what it does is connect the lines out of the
> CLCD block to the physical VGA encode chip in different ways
> depending on how the pixels were set up.
I think the nicest approach here would be to make this a layered
driver, where you have a separate platform_driver instance
that contains all the versatile specific add-ons, and this calls
into the common driver that handles everything that is not specific
to versatile.
It may not be worth investing much into a rework to get there
though, so simply putting it all into one module sounds like
a reasonable compromise.
Arnd
^ permalink raw reply [flat|nested] 145+ messages in thread* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-25 16:08 ` Arnd Bergmann
0 siblings, 0 replies; 145+ messages in thread
From: Arnd Bergmann @ 2016-02-25 16:08 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 25 February 2016 15:04:52 Linus Walleij wrote:
>
> I add support for doing this for the Integrator and RealView in
> the patch set, by grabbing a handle to the system controller
> where they have a few "misc registers". However if you look at
> it:
>
> static void integrator_clcd_enable(struct clcd_fb *fb)
> {
> struct fb_var_screeninfo *var = &fb->fb.var;
> u32 val;
>
> dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
>
> val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
> INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
> if (var->bits_per_pixel <= 8 ||
> (var->bits_per_pixel == 16 && var->green.length == 5))
> /* Pseudocolor, RGB555, BGR555 */
> val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
> else if (fb->fb.var.bits_per_pixel <= 16)
> /* truecolor RGB565 */
> val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
> else
> val = 0; /* no idea for this, don't trust the docs */
>
> regmap_update_bits(versatile_syscon_map,
> INTEGRATOR_HDR_CTRL_OFFSET,
> 0,
> INTEGRATOR_CLCD_MASK);
> }
>
> This is stuff that is so closely tied in to the fbdev driver that even
> if it is SoC-specific (and reside in arch/arm/mach-integrator etc
> today) it would be hard to argument that it should not be part
> of the fbdev driver: what it does is connect the lines out of the
> CLCD block to the physical VGA encode chip in different ways
> depending on how the pixels were set up.
I think the nicest approach here would be to make this a layered
driver, where you have a separate platform_driver instance
that contains all the versatile specific add-ons, and this calls
into the common driver that handles everything that is not specific
to versatile.
It may not be worth investing much into a rework to get there
though, so simply putting it all into one module sounds like
a reasonable compromise.
Arnd
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-25 14:04 ` Linus Walleij
@ 2016-02-25 16:22 ` Russell King - ARM Linux
-1 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-25 16:22 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 25, 2016 at 03:04:52PM +0100, Linus Walleij wrote:
> HOWEVER: the ARM Versatile is the *only* platform I have
> seen of these that have plug'n'play for the display.
And Realview, at least Realview EB, which is the same format board as
Versatile and carries the same LCD connector.
> *All* the others
> will be very happy with *ONE* display defined as panel in the
> device tree, and off they go. Usually VGA. And that will look
> much like arch/arm/boot/dts/vexpress-v2m.dtsi already look
> like today, using "panel-dpi" to define their displays.
Versatile Express only has a DVI connector.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-25 16:22 ` Russell King - ARM Linux
0 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-25 16:22 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 25, 2016 at 03:04:52PM +0100, Linus Walleij wrote:
> HOWEVER: the ARM Versatile is the *only* platform I have
> seen of these that have plug'n'play for the display.
And Realview, at least Realview EB, which is the same format board as
Versatile and carries the same LCD connector.
> *All* the others
> will be very happy with *ONE* display defined as panel in the
> device tree, and off they go. Usually VGA. And that will look
> much like arch/arm/boot/dts/vexpress-v2m.dtsi already look
> like today, using "panel-dpi" to define their displays.
Versatile Express only has a DVI connector.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-25 14:04 ` Linus Walleij
@ 2016-02-25 16:45 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-25 16:45 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 3393 bytes --]
On 25/02/16 16:04, Linus Walleij wrote:
> On Tue, Feb 23, 2016 at 2:38 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> Maybe Versatile is different. If CLCD is only used on that board, or a
>> small family of boards, from one vendor, I guess it is maintainable to
>> have board specific driver parts for CLCD. But if CLCD can be used by
>> many vendors in many different boards, I'd steer clear of board specific
>> driver code.
>
> OK I think at this point we would say that CLCD is a legacy driver.
Ok.
My biggest fear with this is the maintenance nightmare that comes if an
IP or panel is used in multiple SoCs and future designs. We have the
same display subsystem and panel drivers used from OMAP2 forward, and
it's been a constant struggle, so I've come to appreciate the effort to
split things up as much as possible, so that when the time comes when
the HW guys have decided to change a piece here or there, it's easier to
cope with.
Anyway, if it's likely that we're not seeing new CLCD boards, I think
it's fine if we don't go to any great lengths to clean things up there.
Let's just get it working.
> HOWEVER: the ARM Versatile is the *only* platform I have
> seen of these that have plug'n'play for the display.
Ok. And presumably no new boards will use that plug'n'play display, so
we can just consider it specific to versatile.
> *All* the others
> will be very happy with *ONE* display defined as panel in the
> device tree, and off they go. Usually VGA. And that will look
You keep mentioning VGA. So is there are VGA output? Or do you just mean
MIPI DPI panels, which happen to take the same video timings as VGA?
> I add support for doing this for the Integrator and RealView in
> the patch set, by grabbing a handle to the system controller
> where they have a few "misc registers". However if you look at
> it:
>
> static void integrator_clcd_enable(struct clcd_fb *fb)
> {
> struct fb_var_screeninfo *var = &fb->fb.var;
> u32 val;
>
> dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
>
> val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
> INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
> if (var->bits_per_pixel <= 8 ||
> (var->bits_per_pixel == 16 && var->green.length == 5))
> /* Pseudocolor, RGB555, BGR555 */
> val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
> else if (fb->fb.var.bits_per_pixel <= 16)
> /* truecolor RGB565 */
> val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
> else
> val = 0; /* no idea for this, don't trust the docs */
>
> regmap_update_bits(versatile_syscon_map,
> INTEGRATOR_HDR_CTRL_OFFSET,
> 0,
> INTEGRATOR_CLCD_MASK);
> }
>
> This is stuff that is so closely tied in to the fbdev driver that even
> if it is SoC-specific (and reside in arch/arm/mach-integrator etc
> today) it would be hard to argument that it should not be part
> of the fbdev driver: what it does is connect the lines out of the
> CLCD block to the physical VGA encode chip in different ways
> depending on how the pixels were set up.
Hmm so is there an external VGA encoder on the board?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-25 16:45 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-25 16:45 UTC (permalink / raw)
To: linux-arm-kernel
On 25/02/16 16:04, Linus Walleij wrote:
> On Tue, Feb 23, 2016 at 2:38 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> Maybe Versatile is different. If CLCD is only used on that board, or a
>> small family of boards, from one vendor, I guess it is maintainable to
>> have board specific driver parts for CLCD. But if CLCD can be used by
>> many vendors in many different boards, I'd steer clear of board specific
>> driver code.
>
> OK I think at this point we would say that CLCD is a legacy driver.
Ok.
My biggest fear with this is the maintenance nightmare that comes if an
IP or panel is used in multiple SoCs and future designs. We have the
same display subsystem and panel drivers used from OMAP2 forward, and
it's been a constant struggle, so I've come to appreciate the effort to
split things up as much as possible, so that when the time comes when
the HW guys have decided to change a piece here or there, it's easier to
cope with.
Anyway, if it's likely that we're not seeing new CLCD boards, I think
it's fine if we don't go to any great lengths to clean things up there.
Let's just get it working.
> HOWEVER: the ARM Versatile is the *only* platform I have
> seen of these that have plug'n'play for the display.
Ok. And presumably no new boards will use that plug'n'play display, so
we can just consider it specific to versatile.
> *All* the others
> will be very happy with *ONE* display defined as panel in the
> device tree, and off they go. Usually VGA. And that will look
You keep mentioning VGA. So is there are VGA output? Or do you just mean
MIPI DPI panels, which happen to take the same video timings as VGA?
> I add support for doing this for the Integrator and RealView in
> the patch set, by grabbing a handle to the system controller
> where they have a few "misc registers". However if you look at
> it:
>
> static void integrator_clcd_enable(struct clcd_fb *fb)
> {
> struct fb_var_screeninfo *var = &fb->fb.var;
> u32 val;
>
> dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
>
> val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
> INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
> if (var->bits_per_pixel <= 8 ||
> (var->bits_per_pixel == 16 && var->green.length == 5))
> /* Pseudocolor, RGB555, BGR555 */
> val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
> else if (fb->fb.var.bits_per_pixel <= 16)
> /* truecolor RGB565 */
> val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
> else
> val = 0; /* no idea for this, don't trust the docs */
>
> regmap_update_bits(versatile_syscon_map,
> INTEGRATOR_HDR_CTRL_OFFSET,
> 0,
> INTEGRATOR_CLCD_MASK);
> }
>
> This is stuff that is so closely tied in to the fbdev driver that even
> if it is SoC-specific (and reside in arch/arm/mach-integrator etc
> today) it would be hard to argument that it should not be part
> of the fbdev driver: what it does is connect the lines out of the
> CLCD block to the physical VGA encode chip in different ways
> depending on how the pixels were set up.
Hmm so is there an external VGA encoder on the board?
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/bd6de85d/attachment-0001.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-25 16:45 ` Tomi Valkeinen
@ 2016-02-25 16:57 ` Russell King - ARM Linux
-1 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-25 16:57 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 25, 2016 at 06:45:37PM +0200, Tomi Valkeinen wrote:
> > *All* the others
> > will be very happy with *ONE* display defined as panel in the
> > device tree, and off they go. Usually VGA. And that will look
>
> You keep mentioning VGA. So is there are VGA output? Or do you just mean
> MIPI DPI panels, which happen to take the same video timings as VGA?
There is a 15-pin VGA connector too. No DDC though.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-25 16:57 ` Russell King - ARM Linux
0 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-25 16:57 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 25, 2016 at 06:45:37PM +0200, Tomi Valkeinen wrote:
> > *All* the others
> > will be very happy with *ONE* display defined as panel in the
> > device tree, and off they go. Usually VGA. And that will look
>
> You keep mentioning VGA. So is there are VGA output? Or do you just mean
> MIPI DPI panels, which happen to take the same video timings as VGA?
There is a 15-pin VGA connector too. No DDC though.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-25 16:45 ` Tomi Valkeinen
@ 2016-02-25 19:30 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-25 19:30 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 25, 2016 at 5:45 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 25/02/16 16:04, Linus Walleij wrote:
>> *All* the others
>> will be very happy with *ONE* display defined as panel in the
>> device tree, and off they go. Usually VGA. And that will look
>
> You keep mentioning VGA. So is there are VGA output? Or do you just mean
> MIPI DPI panels, which happen to take the same video timings as VGA?
Russell beat me to it, yes there is an external VGA encoder.
It needs some bits set up through the "misc registers" system
controller as indicated. From the CLCD hardware point of view
it's no different than any other panel. So the DTS fragment looks
like so:
panel {
compatible = "panel-dpi";
port {
clcd_panel: endpoint {
remote-endpoint = <&clcd_pads>;
};
};
/* Standard 640x480 VGA timings */
panel-timing {
clock-frequency = <25175000>;
hactive = <640>;
hback-porch = <48>;
hfront-porch = <16>;
hsync-len = <96>;
vactive = <480>;
vback-porch = <33>;
vfront-porch = <10>;
vsync-len = <2>;
};
};
This is reported as the default display type if no LCD panel
is connected.
If a LCD panel is also connected, it take precedence.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-25 19:30 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-25 19:30 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 25, 2016 at 5:45 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 25/02/16 16:04, Linus Walleij wrote:
>> *All* the others
>> will be very happy with *ONE* display defined as panel in the
>> device tree, and off they go. Usually VGA. And that will look
>
> You keep mentioning VGA. So is there are VGA output? Or do you just mean
> MIPI DPI panels, which happen to take the same video timings as VGA?
Russell beat me to it, yes there is an external VGA encoder.
It needs some bits set up through the "misc registers" system
controller as indicated. From the CLCD hardware point of view
it's no different than any other panel. So the DTS fragment looks
like so:
panel {
compatible = "panel-dpi";
port {
clcd_panel: endpoint {
remote-endpoint = <&clcd_pads>;
};
};
/* Standard 640x480 VGA timings */
panel-timing {
clock-frequency = <25175000>;
hactive = <640>;
hback-porch = <48>;
hfront-porch = <16>;
hsync-len = <96>;
vactive = <480>;
vback-porch = <33>;
vfront-porch = <10>;
vsync-len = <2>;
};
};
This is reported as the default display type if no LCD panel
is connected.
If a LCD panel is also connected, it take precedence.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-25 19:30 ` Linus Walleij
@ 2016-02-26 10:47 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-26 10:47 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 2417 bytes --]
On 25/02/16 21:30, Linus Walleij wrote:
> On Thu, Feb 25, 2016 at 5:45 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 25/02/16 16:04, Linus Walleij wrote:
>
>>> *All* the others
>>> will be very happy with *ONE* display defined as panel in the
>>> device tree, and off they go. Usually VGA. And that will look
>>
>> You keep mentioning VGA. So is there are VGA output? Or do you just mean
>> MIPI DPI panels, which happen to take the same video timings as VGA?
>
> Russell beat me to it, yes there is an external VGA encoder.
> It needs some bits set up through the "misc registers" system
> controller as indicated. From the CLCD hardware point of view
> it's no different than any other panel. So the DTS fragment looks
> like so:
>
> panel {
> compatible = "panel-dpi";
>
> port {
> clcd_panel: endpoint {
> remote-endpoint = <&clcd_pads>;
> };
> };
>
> /* Standard 640x480 VGA timings */
> panel-timing {
> clock-frequency = <25175000>;
> hactive = <640>;
> hback-porch = <48>;
> hfront-porch = <16>;
> hsync-len = <96>;
> vactive = <480>;
> vback-porch = <33>;
> vfront-porch = <10>;
> vsync-len = <2>;
> };
> };
>
>
> This is reported as the default display type if no LCD panel
> is connected.
>
> If a LCD panel is also connected, it take precedence.
Ok. Well... It's all wrong, but I don't know how much time we want to
spend on fixing that.
Although one thing to consider is that if there is ever going to be a
DRM driver for CLCD, it would be good to have the device tree parts
correctly representing the hardware, so that the DRM driver could be
implemented in a cleaner, more generic way.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-26 10:47 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-26 10:47 UTC (permalink / raw)
To: linux-arm-kernel
On 25/02/16 21:30, Linus Walleij wrote:
> On Thu, Feb 25, 2016 at 5:45 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 25/02/16 16:04, Linus Walleij wrote:
>
>>> *All* the others
>>> will be very happy with *ONE* display defined as panel in the
>>> device tree, and off they go. Usually VGA. And that will look
>>
>> You keep mentioning VGA. So is there are VGA output? Or do you just mean
>> MIPI DPI panels, which happen to take the same video timings as VGA?
>
> Russell beat me to it, yes there is an external VGA encoder.
> It needs some bits set up through the "misc registers" system
> controller as indicated. From the CLCD hardware point of view
> it's no different than any other panel. So the DTS fragment looks
> like so:
>
> panel {
> compatible = "panel-dpi";
>
> port {
> clcd_panel: endpoint {
> remote-endpoint = <&clcd_pads>;
> };
> };
>
> /* Standard 640x480 VGA timings */
> panel-timing {
> clock-frequency = <25175000>;
> hactive = <640>;
> hback-porch = <48>;
> hfront-porch = <16>;
> hsync-len = <96>;
> vactive = <480>;
> vback-porch = <33>;
> vfront-porch = <10>;
> vsync-len = <2>;
> };
> };
>
>
> This is reported as the default display type if no LCD panel
> is connected.
>
> If a LCD panel is also connected, it take precedence.
Ok. Well... It's all wrong, but I don't know how much time we want to
spend on fixing that.
Although one thing to consider is that if there is ever going to be a
DRM driver for CLCD, it would be good to have the device tree parts
correctly representing the hardware, so that the DRM driver could be
implemented in a cleaner, more generic way.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/2d0bbf63/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-26 10:47 ` Tomi Valkeinen
@ 2016-03-05 16:57 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-03-05 16:57 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 26, 2016 at 5:47 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Although one thing to consider is that if there is ever going to be a
> DRM driver for CLCD, it would be good to have the device tree parts
> correctly representing the hardware, so that the DRM driver could be
> implemented in a cleaner, more generic way.
OK so for the next kernel cycle I can work on that.
The non-controversial patch set is essentially just using the DT bindings
that are already in the kernel and in widespread use. See:
commit d10715be03bd8bad59ddc50236cb140c3bd73c7b
"video: ARM CLCD: Add DT support"
They follow the example set by
commit 478a4f81af4936c683a03488e15b087e28cb4f0d
"ARM: vexpress: Add CLCD Device Tree properties"
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-03-05 16:57 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-03-05 16:57 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 26, 2016 at 5:47 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Although one thing to consider is that if there is ever going to be a
> DRM driver for CLCD, it would be good to have the device tree parts
> correctly representing the hardware, so that the DRM driver could be
> implemented in a cleaner, more generic way.
OK so for the next kernel cycle I can work on that.
The non-controversial patch set is essentially just using the DT bindings
that are already in the kernel and in widespread use. See:
commit d10715be03bd8bad59ddc50236cb140c3bd73c7b
"video: ARM CLCD: Add DT support"
They follow the example set by
commit 478a4f81af4936c683a03488e15b087e28cb4f0d
"ARM: vexpress: Add CLCD Device Tree properties"
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-03-05 16:57 ` Linus Walleij
@ 2016-03-07 7:36 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-03-07 7:36 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1111 bytes --]
On 05/03/16 18:57, Linus Walleij wrote:
> On Fri, Feb 26, 2016 at 5:47 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> Although one thing to consider is that if there is ever going to be a
>> DRM driver for CLCD, it would be good to have the device tree parts
>> correctly representing the hardware, so that the DRM driver could be
>> implemented in a cleaner, more generic way.
>
> OK so for the next kernel cycle I can work on that.
>
> The non-controversial patch set is essentially just using the DT bindings
Yes, I think the non-controversial series is fine. Will you be sending a
v2 of that series?
> that are already in the kernel and in widespread use. See:
> commit d10715be03bd8bad59ddc50236cb140c3bd73c7b
> "video: ARM CLCD: Add DT support"
>
> They follow the example set by
> commit 478a4f81af4936c683a03488e15b087e28cb4f0d
> "ARM: vexpress: Add CLCD Device Tree properties"
This one not actually correct, as the panel node is inside the clcd
node. The child parent relationship should represent a control bus. But
that's a different topic...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-03-07 7:36 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-03-07 7:36 UTC (permalink / raw)
To: linux-arm-kernel
On 05/03/16 18:57, Linus Walleij wrote:
> On Fri, Feb 26, 2016 at 5:47 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> Although one thing to consider is that if there is ever going to be a
>> DRM driver for CLCD, it would be good to have the device tree parts
>> correctly representing the hardware, so that the DRM driver could be
>> implemented in a cleaner, more generic way.
>
> OK so for the next kernel cycle I can work on that.
>
> The non-controversial patch set is essentially just using the DT bindings
Yes, I think the non-controversial series is fine. Will you be sending a
v2 of that series?
> that are already in the kernel and in widespread use. See:
> commit d10715be03bd8bad59ddc50236cb140c3bd73c7b
> "video: ARM CLCD: Add DT support"
>
> They follow the example set by
> commit 478a4f81af4936c683a03488e15b087e28cb4f0d
> "ARM: vexpress: Add CLCD Device Tree properties"
This one not actually correct, as the panel node is inside the clcd
node. The child parent relationship should represent a control bus. But
that's a different topic...
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160307/363b6742/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-25 16:45 ` Tomi Valkeinen
@ 2016-02-25 19:32 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-25 19:32 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 25, 2016 at 5:45 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Anyway, if it's likely that we're not seeing new CLCD boards, I think
> it's fine if we don't go to any great lengths to clean things up there.
> Let's just get it working.
Do you think you could merge the other patch set I made, that doesn't
even deal with this plug-n-play-panel issue?
I have rebased the two approaches to autodetection on top of that.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-25 19:32 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-25 19:32 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 25, 2016 at 5:45 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Anyway, if it's likely that we're not seeing new CLCD boards, I think
> it's fine if we don't go to any great lengths to clean things up there.
> Let's just get it working.
Do you think you could merge the other patch set I made, that doesn't
even deal with this plug-n-play-panel issue?
I have rebased the two approaches to autodetection on top of that.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 9:08 ` Linus Walleij
@ 2016-02-23 9:58 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-23 9:58 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]
(cc'ing a few more people as this is going into generic direction)
On 23/02/16 11:08, Linus Walleij wrote:
> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>> This moves the versatile CLCD configuration to the device tree by:
>
> As this Schrödinger's cat approach seems controversial, as well
> as the alternative to manipulate the DT in memory at run-time,
> I will respin the series without the full Versatile support, adding
> plug-in for the other ARM boards and and half-baked support
> for the Versatile supporting just VGA (like the other reference
> designs from ARM).
>
> The pluggable displays prove yet again to be a problem to the
> world, sigh.
>
> I will think of a better solution, if any, for this for v4.6, but will
> put forward something that handles the Nomadik and all the
> other ARM reference designs for now.
I had a chat with Tom Rini and Pantelis Antoniou yesterday.
Panto is about to send a new series for DT overlay management soon. I
haven't had time to test that yet, but what it would give us is that you
could build DT overlay binaries as "firmware" into the kernel image, and
thus the panel DT data would be there even before rootfs is mounted. The
DT overlays can be loaded from the rootfs or initramfs too, if it's not
critical to get the display up early.
I'm not quite sure how it works if, as in versatile display case, there
are multiple DT overlays of which one has to be enabled. I hope there's
support to choose which one to use via kernel cmdline or similar.
I would personally like it much more if the bootloader would either
compose a final dtb from DT fragments and pass it to the kernel, or
alternatively the bootloader would pass the base dtb image and a bunch
of DT overlays to the kernel, and the kernel would deal with the DT
overlays.
In any case, I think the firmware solution is a good step forward, and
will probably work fine for many users. Then again, I haven't tested it
yet so I don't know the details, and it's not in the mainline.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 9:58 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-23 9:58 UTC (permalink / raw)
To: linux-arm-kernel
(cc'ing a few more people as this is going into generic direction)
On 23/02/16 11:08, Linus Walleij wrote:
> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>> This moves the versatile CLCD configuration to the device tree by:
>
> As this Schr?dinger's cat approach seems controversial, as well
> as the alternative to manipulate the DT in memory at run-time,
> I will respin the series without the full Versatile support, adding
> plug-in for the other ARM boards and and half-baked support
> for the Versatile supporting just VGA (like the other reference
> designs from ARM).
>
> The pluggable displays prove yet again to be a problem to the
> world, sigh.
>
> I will think of a better solution, if any, for this for v4.6, but will
> put forward something that handles the Nomadik and all the
> other ARM reference designs for now.
I had a chat with Tom Rini and Pantelis Antoniou yesterday.
Panto is about to send a new series for DT overlay management soon. I
haven't had time to test that yet, but what it would give us is that you
could build DT overlay binaries as "firmware" into the kernel image, and
thus the panel DT data would be there even before rootfs is mounted. The
DT overlays can be loaded from the rootfs or initramfs too, if it's not
critical to get the display up early.
I'm not quite sure how it works if, as in versatile display case, there
are multiple DT overlays of which one has to be enabled. I hope there's
support to choose which one to use via kernel cmdline or similar.
I would personally like it much more if the bootloader would either
compose a final dtb from DT fragments and pass it to the kernel, or
alternatively the bootloader would pass the base dtb image and a bunch
of DT overlays to the kernel, and the kernel would deal with the DT
overlays.
In any case, I think the firmware solution is a good step forward, and
will probably work fine for many users. Then again, I haven't tested it
yet so I don't know the details, and it's not in the mainline.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/79e69ace/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 9:58 ` Tomi Valkeinen
@ 2016-02-23 10:32 ` Adam Ford
-1 siblings, 0 replies; 145+ messages in thread
From: Adam Ford @ 2016-02-23 10:32 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 3:58 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> (cc'ing a few more people as this is going into generic direction)
>
> On 23/02/16 11:08, Linus Walleij wrote:
>> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>>> This moves the versatile CLCD configuration to the device tree by:
>>
>> As this Schrödinger's cat approach seems controversial, as well
>> as the alternative to manipulate the DT in memory at run-time,
>> I will respin the series without the full Versatile support, adding
>> plug-in for the other ARM boards and and half-baked support
>> for the Versatile supporting just VGA (like the other reference
>> designs from ARM).
>>
>> The pluggable displays prove yet again to be a problem to the
>> world, sigh.
>>
>> I will think of a better solution, if any, for this for v4.6, but will
>> put forward something that handles the Nomadik and all the
>> other ARM reference designs for now.
>
> I had a chat with Tom Rini and Pantelis Antoniou yesterday.
>
> Panto is about to send a new series for DT overlay management soon. I
> haven't had time to test that yet, but what it would give us is that you
> could build DT overlay binaries as "firmware" into the kernel image, and
> thus the panel DT data would be there even before rootfs is mounted. The
> DT overlays can be loaded from the rootfs or initramfs too, if it's not
> critical to get the display up early.
>
> I'm not quite sure how it works if, as in versatile display case, there
> are multiple DT overlays of which one has to be enabled. I hope there's
> support to choose which one to use via kernel cmdline or similar.
>
> I would personally like it much more if the bootloader would either
> compose a final dtb from DT fragments and pass it to the kernel, or
> alternatively the bootloader would pass the base dtb image and a bunch
> of DT overlays to the kernel, and the kernel would deal with the DT
> overlays.
>
If there was a nice way to merge the device trees, I would love to
create device tree 'modules' that could be loaded at will and merged
just before the time of boot. I could see this being useful beyond
just plugable displays.
> In any case, I think the firmware solution is a good step forward, and
> will probably work fine for many users. Then again, I haven't tested it
> yet so I don't know the details, and it's not in the mainline.
>
I am willing to test it, but I'll need the patch and some instructions
from Panto.
> Tomi
>
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 10:32 ` Adam Ford
0 siblings, 0 replies; 145+ messages in thread
From: Adam Ford @ 2016-02-23 10:32 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 3:58 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> (cc'ing a few more people as this is going into generic direction)
>
> On 23/02/16 11:08, Linus Walleij wrote:
>> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>>> This moves the versatile CLCD configuration to the device tree by:
>>
>> As this Schr?dinger's cat approach seems controversial, as well
>> as the alternative to manipulate the DT in memory at run-time,
>> I will respin the series without the full Versatile support, adding
>> plug-in for the other ARM boards and and half-baked support
>> for the Versatile supporting just VGA (like the other reference
>> designs from ARM).
>>
>> The pluggable displays prove yet again to be a problem to the
>> world, sigh.
>>
>> I will think of a better solution, if any, for this for v4.6, but will
>> put forward something that handles the Nomadik and all the
>> other ARM reference designs for now.
>
> I had a chat with Tom Rini and Pantelis Antoniou yesterday.
>
> Panto is about to send a new series for DT overlay management soon. I
> haven't had time to test that yet, but what it would give us is that you
> could build DT overlay binaries as "firmware" into the kernel image, and
> thus the panel DT data would be there even before rootfs is mounted. The
> DT overlays can be loaded from the rootfs or initramfs too, if it's not
> critical to get the display up early.
>
> I'm not quite sure how it works if, as in versatile display case, there
> are multiple DT overlays of which one has to be enabled. I hope there's
> support to choose which one to use via kernel cmdline or similar.
>
> I would personally like it much more if the bootloader would either
> compose a final dtb from DT fragments and pass it to the kernel, or
> alternatively the bootloader would pass the base dtb image and a bunch
> of DT overlays to the kernel, and the kernel would deal with the DT
> overlays.
>
If there was a nice way to merge the device trees, I would love to
create device tree 'modules' that could be loaded at will and merged
just before the time of boot. I could see this being useful beyond
just plugable displays.
> In any case, I think the firmware solution is a good step forward, and
> will probably work fine for many users. Then again, I haven't tested it
> yet so I don't know the details, and it's not in the mainline.
>
I am willing to test it, but I'll need the patch and some instructions
from Panto.
> Tomi
>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 10:32 ` Adam Ford
@ 2016-02-23 10:59 ` Pantelis Antoniou
-1 siblings, 0 replies; 145+ messages in thread
From: Pantelis Antoniou @ 2016-02-23 10:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi Adam,
> On Feb 23, 2016, at 12:32 , Adam Ford <aford173@gmail.com> wrote:
>
> On Tue, Feb 23, 2016 at 3:58 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> (cc'ing a few more people as this is going into generic direction)
>>
>> On 23/02/16 11:08, Linus Walleij wrote:
>>> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>>
>>>> This moves the versatile CLCD configuration to the device tree by:
>>>
>>> As this Schrödinger's cat approach seems controversial, as well
>>> as the alternative to manipulate the DT in memory at run-time,
>>> I will respin the series without the full Versatile support, adding
>>> plug-in for the other ARM boards and and half-baked support
>>> for the Versatile supporting just VGA (like the other reference
>>> designs from ARM).
>>>
>>> The pluggable displays prove yet again to be a problem to the
>>> world, sigh.
>>>
>>> I will think of a better solution, if any, for this for v4.6, but will
>>> put forward something that handles the Nomadik and all the
>>> other ARM reference designs for now.
>>
>> I had a chat with Tom Rini and Pantelis Antoniou yesterday.
>>
>> Panto is about to send a new series for DT overlay management soon. I
>> haven't had time to test that yet, but what it would give us is that you
>> could build DT overlay binaries as "firmware" into the kernel image, and
>> thus the panel DT data would be there even before rootfs is mounted. The
>> DT overlays can be loaded from the rootfs or initramfs too, if it's not
>> critical to get the display up early.
>>
>> I'm not quite sure how it works if, as in versatile display case, there
>> are multiple DT overlays of which one has to be enabled. I hope there's
>> support to choose which one to use via kernel cmdline or similar.
>>
>> I would personally like it much more if the bootloader would either
>> compose a final dtb from DT fragments and pass it to the kernel, or
>> alternatively the bootloader would pass the base dtb image and a bunch
>> of DT overlays to the kernel, and the kernel would deal with the DT
>> overlays.
>>
> If there was a nice way to merge the device trees, I would love to
> create device tree 'modules' that could be loaded at will and merged
> just before the time of boot. I could see this being useful beyond
> just plugable displays.
>
Looks like you would be happy by having a way to boot using a device tree
blob + a number of device tree overlay blobs to be applied in sequence.
You could append the dtbo’s to the device tree blob (where-ever that may be)
and it should work.
The good thing about this scheme is that it’s independent of the bootloader.
An advanced bootloader (like u-boot) with DT smarts can create the appended
DT blob itself, while a dumb one can just be given the appended blob as
it was created outside of the device.
>> In any case, I think the firmware solution is a good step forward, and
>> will probably work fine for many users. Then again, I haven't tested it
>> yet so I don't know the details, and it's not in the mainline.
>>
> I am willing to test it, but I'll need the patch and some instructions
> from Panto.
>
The appended device tree blob thing does not exist yet, but it’s not such a big
problem to add. I’d give it a shot this week.
The standard device tree overlays are in my overlay branch at
https://github.com/pantoniou/linux-beagle-track-mainline/tree/bbb-overlays
The capemgr has options for parsing a kernel command line to apply an overlay:
https://github.com/pantoniou/linux-beagle-track-mainline/blob/bbb-overlays/drivers/misc/bone_capemgr.c
The command line options are enable_partno & disable_partno where you supply
the part numbers of the capes you want enabled/disabled at boot.
The capemgr is complicated due to the eeprom detection and the horrible kludges done with the
variants (beaglebone white/beaglebone black), but I think you can figure out what’s going
on with the command line options.
>> Tomi
>>
Regards
— Pantelis
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 10:59 ` Pantelis Antoniou
0 siblings, 0 replies; 145+ messages in thread
From: Pantelis Antoniou @ 2016-02-23 10:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi Adam,
> On Feb 23, 2016, at 12:32 , Adam Ford <aford173@gmail.com> wrote:
>
> On Tue, Feb 23, 2016 at 3:58 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> (cc'ing a few more people as this is going into generic direction)
>>
>> On 23/02/16 11:08, Linus Walleij wrote:
>>> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>>
>>>> This moves the versatile CLCD configuration to the device tree by:
>>>
>>> As this Schr?dinger's cat approach seems controversial, as well
>>> as the alternative to manipulate the DT in memory at run-time,
>>> I will respin the series without the full Versatile support, adding
>>> plug-in for the other ARM boards and and half-baked support
>>> for the Versatile supporting just VGA (like the other reference
>>> designs from ARM).
>>>
>>> The pluggable displays prove yet again to be a problem to the
>>> world, sigh.
>>>
>>> I will think of a better solution, if any, for this for v4.6, but will
>>> put forward something that handles the Nomadik and all the
>>> other ARM reference designs for now.
>>
>> I had a chat with Tom Rini and Pantelis Antoniou yesterday.
>>
>> Panto is about to send a new series for DT overlay management soon. I
>> haven't had time to test that yet, but what it would give us is that you
>> could build DT overlay binaries as "firmware" into the kernel image, and
>> thus the panel DT data would be there even before rootfs is mounted. The
>> DT overlays can be loaded from the rootfs or initramfs too, if it's not
>> critical to get the display up early.
>>
>> I'm not quite sure how it works if, as in versatile display case, there
>> are multiple DT overlays of which one has to be enabled. I hope there's
>> support to choose which one to use via kernel cmdline or similar.
>>
>> I would personally like it much more if the bootloader would either
>> compose a final dtb from DT fragments and pass it to the kernel, or
>> alternatively the bootloader would pass the base dtb image and a bunch
>> of DT overlays to the kernel, and the kernel would deal with the DT
>> overlays.
>>
> If there was a nice way to merge the device trees, I would love to
> create device tree 'modules' that could be loaded at will and merged
> just before the time of boot. I could see this being useful beyond
> just plugable displays.
>
Looks like you would be happy by having a way to boot using a device tree
blob + a number of device tree overlay blobs to be applied in sequence.
You could append the dtbo?s to the device tree blob (where-ever that may be)
and it should work.
The good thing about this scheme is that it?s independent of the bootloader.
An advanced bootloader (like u-boot) with DT smarts can create the appended
DT blob itself, while a dumb one can just be given the appended blob as
it was created outside of the device.
>> In any case, I think the firmware solution is a good step forward, and
>> will probably work fine for many users. Then again, I haven't tested it
>> yet so I don't know the details, and it's not in the mainline.
>>
> I am willing to test it, but I'll need the patch and some instructions
> from Panto.
>
The appended device tree blob thing does not exist yet, but it?s not such a big
problem to add. I?d give it a shot this week.
The standard device tree overlays are in my overlay branch at
https://github.com/pantoniou/linux-beagle-track-mainline/tree/bbb-overlays
The capemgr has options for parsing a kernel command line to apply an overlay:
https://github.com/pantoniou/linux-beagle-track-mainline/blob/bbb-overlays/drivers/misc/bone_capemgr.c
The command line options are enable_partno & disable_partno where you supply
the part numbers of the capes you want enabled/disabled at boot.
The capemgr is complicated due to the eeprom detection and the horrible kludges done with the
variants (beaglebone white/beaglebone black), but I think you can figure out what?s going
on with the command line options.
>> Tomi
>>
Regards
? Pantelis
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 9:58 ` Tomi Valkeinen
@ 2016-02-23 11:56 ` Peter Maydell
-1 siblings, 0 replies; 145+ messages in thread
From: Peter Maydell @ 2016-02-23 11:56 UTC (permalink / raw)
To: linux-arm-kernel
On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> I'm not quite sure how it works if, as in versatile display case, there
> are multiple DT overlays of which one has to be enabled. I hope there's
> support to choose which one to use via kernel cmdline or similar.
>
> I would personally like it much more if the bootloader would either
> compose a final dtb from DT fragments and pass it to the kernel, or
> alternatively the bootloader would pass the base dtb image and a bunch
> of DT overlays to the kernel, and the kernel would deal with the DT
> overlays.
Speaking as somebody who's written the "bootloader" code that's
used for what I guess are the majority of versatile kernel boots,
i.e. the one in QEMU, I think that requiring the bootloader to do this
would be a significant worsening from the current state.
Right now the bootloader doesn't need to do much at all with device
trees, except pass the kernel the DT that the user gave us, which
is just the kernel's own data structures in a separate file for
convenience. You need to do some very minor tweaks to the /chosen
node, but these can be handled the same way for any board and aren't
hardware specific. There's no need to worry about dt fragments
either for the bootloader or for the user. Imposing a new requirement
for the bootloader to have to probe hardware which it otherwise
has no need to even care about, and then edit and update the DT
in a board-specific manner, or have board-specific DT fragments,
seems like a totally unnecessary imposition on both bootloader
authors and end-users, and of course it would break booting newer
kernels on the great mass of already existing boot loaders and
QEMU installs.
The kernel is in a position to probe the display hardware and determine
what is there, and do the right thing, and that's exactly what it
does today. The kernel should continue to do this.
The advantage of DT is that it allows moving information about
non-probeable hardware that was previously hardwired in the kernel
C sources into a separate data structure, but the versatile displays
are not non-probeable. I can see no benefit at all from hardwiring into
the dt something which the kernel has previously been successfully
dynamically getting right without any bootloader intervention -- it just
makes the kernel less flexible and less user-friendly.
thanks
-- PMM
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 11:56 ` Peter Maydell
0 siblings, 0 replies; 145+ messages in thread
From: Peter Maydell @ 2016-02-23 11:56 UTC (permalink / raw)
To: linux-arm-kernel
On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> I'm not quite sure how it works if, as in versatile display case, there
> are multiple DT overlays of which one has to be enabled. I hope there's
> support to choose which one to use via kernel cmdline or similar.
>
> I would personally like it much more if the bootloader would either
> compose a final dtb from DT fragments and pass it to the kernel, or
> alternatively the bootloader would pass the base dtb image and a bunch
> of DT overlays to the kernel, and the kernel would deal with the DT
> overlays.
Speaking as somebody who's written the "bootloader" code that's
used for what I guess are the majority of versatile kernel boots,
i.e. the one in QEMU, I think that requiring the bootloader to do this
would be a significant worsening from the current state.
Right now the bootloader doesn't need to do much at all with device
trees, except pass the kernel the DT that the user gave us, which
is just the kernel's own data structures in a separate file for
convenience. You need to do some very minor tweaks to the /chosen
node, but these can be handled the same way for any board and aren't
hardware specific. There's no need to worry about dt fragments
either for the bootloader or for the user. Imposing a new requirement
for the bootloader to have to probe hardware which it otherwise
has no need to even care about, and then edit and update the DT
in a board-specific manner, or have board-specific DT fragments,
seems like a totally unnecessary imposition on both bootloader
authors and end-users, and of course it would break booting newer
kernels on the great mass of already existing boot loaders and
QEMU installs.
The kernel is in a position to probe the display hardware and determine
what is there, and do the right thing, and that's exactly what it
does today. The kernel should continue to do this.
The advantage of DT is that it allows moving information about
non-probeable hardware that was previously hardwired in the kernel
C sources into a separate data structure, but the versatile displays
are not non-probeable. I can see no benefit at all from hardwiring into
the dt something which the kernel has previously been successfully
dynamically getting right without any bootloader intervention -- it just
makes the kernel less flexible and less user-friendly.
thanks
-- PMM
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 11:56 ` Peter Maydell
@ 2016-02-23 12:01 ` Russell King - ARM Linux
-1 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-23 12:01 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 11:56:34AM +0000, Peter Maydell wrote:
> On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > I'm not quite sure how it works if, as in versatile display case, there
> > are multiple DT overlays of which one has to be enabled. I hope there's
> > support to choose which one to use via kernel cmdline or similar.
> >
> > I would personally like it much more if the bootloader would either
> > compose a final dtb from DT fragments and pass it to the kernel, or
> > alternatively the bootloader would pass the base dtb image and a bunch
> > of DT overlays to the kernel, and the kernel would deal with the DT
> > overlays.
>
> Speaking as somebody who's written the "bootloader" code that's
> used for what I guess are the majority of versatile kernel boots,
> i.e. the one in QEMU, I think that requiring the bootloader to do this
> would be a significant worsening from the current state.
>
> Right now the bootloader doesn't need to do much at all with device
> trees, except pass the kernel the DT that the user gave us, which
> is just the kernel's own data structures in a separate file for
> convenience. You need to do some very minor tweaks to the /chosen
> node, but these can be handled the same way for any board and aren't
> hardware specific. There's no need to worry about dt fragments
> either for the bootloader or for the user. Imposing a new requirement
> for the bootloader to have to probe hardware which it otherwise
> has no need to even care about, and then edit and update the DT
> in a board-specific manner, or have board-specific DT fragments,
> seems like a totally unnecessary imposition on both bootloader
> authors and end-users, and of course it would break booting newer
> kernels on the great mass of already existing boot loaders and
> QEMU installs.
>
> The kernel is in a position to probe the display hardware and determine
> what is there, and do the right thing, and that's exactly what it
> does today. The kernel should continue to do this.
> The advantage of DT is that it allows moving information about
> non-probeable hardware that was previously hardwired in the kernel
> C sources into a separate data structure, but the versatile displays
> are not non-probeable. I can see no benefit at all from hardwiring into
> the dt something which the kernel has previously been successfully
> dynamically getting right without any bootloader intervention -- it just
> makes the kernel less flexible and less user-friendly.
+1.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 12:01 ` Russell King - ARM Linux
0 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-23 12:01 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 11:56:34AM +0000, Peter Maydell wrote:
> On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > I'm not quite sure how it works if, as in versatile display case, there
> > are multiple DT overlays of which one has to be enabled. I hope there's
> > support to choose which one to use via kernel cmdline or similar.
> >
> > I would personally like it much more if the bootloader would either
> > compose a final dtb from DT fragments and pass it to the kernel, or
> > alternatively the bootloader would pass the base dtb image and a bunch
> > of DT overlays to the kernel, and the kernel would deal with the DT
> > overlays.
>
> Speaking as somebody who's written the "bootloader" code that's
> used for what I guess are the majority of versatile kernel boots,
> i.e. the one in QEMU, I think that requiring the bootloader to do this
> would be a significant worsening from the current state.
>
> Right now the bootloader doesn't need to do much at all with device
> trees, except pass the kernel the DT that the user gave us, which
> is just the kernel's own data structures in a separate file for
> convenience. You need to do some very minor tweaks to the /chosen
> node, but these can be handled the same way for any board and aren't
> hardware specific. There's no need to worry about dt fragments
> either for the bootloader or for the user. Imposing a new requirement
> for the bootloader to have to probe hardware which it otherwise
> has no need to even care about, and then edit and update the DT
> in a board-specific manner, or have board-specific DT fragments,
> seems like a totally unnecessary imposition on both bootloader
> authors and end-users, and of course it would break booting newer
> kernels on the great mass of already existing boot loaders and
> QEMU installs.
>
> The kernel is in a position to probe the display hardware and determine
> what is there, and do the right thing, and that's exactly what it
> does today. The kernel should continue to do this.
> The advantage of DT is that it allows moving information about
> non-probeable hardware that was previously hardwired in the kernel
> C sources into a separate data structure, but the versatile displays
> are not non-probeable. I can see no benefit at all from hardwiring into
> the dt something which the kernel has previously been successfully
> dynamically getting right without any bootloader intervention -- it just
> makes the kernel less flexible and less user-friendly.
+1.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 12:01 ` Russell King - ARM Linux
@ 2016-02-23 13:45 ` Tom Rini
-1 siblings, 0 replies; 145+ messages in thread
From: Tom Rini @ 2016-02-23 13:45 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2759 bytes --]
On Tue, Feb 23, 2016 at 12:01:01PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 23, 2016 at 11:56:34AM +0000, Peter Maydell wrote:
> > On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > > I'm not quite sure how it works if, as in versatile display case, there
> > > are multiple DT overlays of which one has to be enabled. I hope there's
> > > support to choose which one to use via kernel cmdline or similar.
> > >
> > > I would personally like it much more if the bootloader would either
> > > compose a final dtb from DT fragments and pass it to the kernel, or
> > > alternatively the bootloader would pass the base dtb image and a bunch
> > > of DT overlays to the kernel, and the kernel would deal with the DT
> > > overlays.
> >
> > Speaking as somebody who's written the "bootloader" code that's
> > used for what I guess are the majority of versatile kernel boots,
> > i.e. the one in QEMU, I think that requiring the bootloader to do this
> > would be a significant worsening from the current state.
> >
> > Right now the bootloader doesn't need to do much at all with device
> > trees, except pass the kernel the DT that the user gave us, which
> > is just the kernel's own data structures in a separate file for
> > convenience. You need to do some very minor tweaks to the /chosen
> > node, but these can be handled the same way for any board and aren't
> > hardware specific. There's no need to worry about dt fragments
> > either for the bootloader or for the user. Imposing a new requirement
> > for the bootloader to have to probe hardware which it otherwise
> > has no need to even care about, and then edit and update the DT
> > in a board-specific manner, or have board-specific DT fragments,
> > seems like a totally unnecessary imposition on both bootloader
> > authors and end-users, and of course it would break booting newer
> > kernels on the great mass of already existing boot loaders and
> > QEMU installs.
> >
> > The kernel is in a position to probe the display hardware and determine
> > what is there, and do the right thing, and that's exactly what it
> > does today. The kernel should continue to do this.
> > The advantage of DT is that it allows moving information about
> > non-probeable hardware that was previously hardwired in the kernel
> > C sources into a separate data structure, but the versatile displays
> > are not non-probeable. I can see no benefit at all from hardwiring into
> > the dt something which the kernel has previously been successfully
> > dynamically getting right without any bootloader intervention -- it just
> > makes the kernel less flexible and less user-friendly.
>
> +1.
+1 from me too.
--
Tom
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 13:45 ` Tom Rini
0 siblings, 0 replies; 145+ messages in thread
From: Tom Rini @ 2016-02-23 13:45 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 12:01:01PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 23, 2016 at 11:56:34AM +0000, Peter Maydell wrote:
> > On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > > I'm not quite sure how it works if, as in versatile display case, there
> > > are multiple DT overlays of which one has to be enabled. I hope there's
> > > support to choose which one to use via kernel cmdline or similar.
> > >
> > > I would personally like it much more if the bootloader would either
> > > compose a final dtb from DT fragments and pass it to the kernel, or
> > > alternatively the bootloader would pass the base dtb image and a bunch
> > > of DT overlays to the kernel, and the kernel would deal with the DT
> > > overlays.
> >
> > Speaking as somebody who's written the "bootloader" code that's
> > used for what I guess are the majority of versatile kernel boots,
> > i.e. the one in QEMU, I think that requiring the bootloader to do this
> > would be a significant worsening from the current state.
> >
> > Right now the bootloader doesn't need to do much at all with device
> > trees, except pass the kernel the DT that the user gave us, which
> > is just the kernel's own data structures in a separate file for
> > convenience. You need to do some very minor tweaks to the /chosen
> > node, but these can be handled the same way for any board and aren't
> > hardware specific. There's no need to worry about dt fragments
> > either for the bootloader or for the user. Imposing a new requirement
> > for the bootloader to have to probe hardware which it otherwise
> > has no need to even care about, and then edit and update the DT
> > in a board-specific manner, or have board-specific DT fragments,
> > seems like a totally unnecessary imposition on both bootloader
> > authors and end-users, and of course it would break booting newer
> > kernels on the great mass of already existing boot loaders and
> > QEMU installs.
> >
> > The kernel is in a position to probe the display hardware and determine
> > what is there, and do the right thing, and that's exactly what it
> > does today. The kernel should continue to do this.
> > The advantage of DT is that it allows moving information about
> > non-probeable hardware that was previously hardwired in the kernel
> > C sources into a separate data structure, but the versatile displays
> > are not non-probeable. I can see no benefit at all from hardwiring into
> > the dt something which the kernel has previously been successfully
> > dynamically getting right without any bootloader intervention -- it just
> > makes the kernel less flexible and less user-friendly.
>
> +1.
+1 from me too.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/bfdb2434/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 11:56 ` Peter Maydell
@ 2016-02-23 12:45 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-23 12:45 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 4243 bytes --]
On 23/02/16 13:56, Peter Maydell wrote:
> On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> I'm not quite sure how it works if, as in versatile display case, there
>> are multiple DT overlays of which one has to be enabled. I hope there's
>> support to choose which one to use via kernel cmdline or similar.
>>
>> I would personally like it much more if the bootloader would either
>> compose a final dtb from DT fragments and pass it to the kernel, or
>> alternatively the bootloader would pass the base dtb image and a bunch
>> of DT overlays to the kernel, and the kernel would deal with the DT
>> overlays.
>
> Speaking as somebody who's written the "bootloader" code that's
> used for what I guess are the majority of versatile kernel boots,
> i.e. the one in QEMU, I think that requiring the bootloader to do this
> would be a significant worsening from the current state.
>
> Right now the bootloader doesn't need to do much at all with device
> trees, except pass the kernel the DT that the user gave us, which
> is just the kernel's own data structures in a separate file for
> convenience. You need to do some very minor tweaks to the /chosen
> node, but these can be handled the same way for any board and aren't
> hardware specific. There's no need to worry about dt fragments
> either for the bootloader or for the user. Imposing a new requirement
> for the bootloader to have to probe hardware which it otherwise
> has no need to even care about, and then edit and update the DT
> in a board-specific manner, or have board-specific DT fragments,
> seems like a totally unnecessary imposition on both bootloader
> authors and end-users, and of course it would break booting newer
> kernels on the great mass of already existing boot loaders and
> QEMU installs.
I'm looking for a good generic solution for going forward that can be
used on new boards, for both non-probeable and probeable displays.
When we have that solution, we can see if and how the solution could be
used for current boards. I'm sure that for some boards we need to
support whatever legacy methods are out there already.
> The kernel is in a position to probe the display hardware and determine
> what is there, and do the right thing, and that's exactly what it
> does today. The kernel should continue to do this.
> The advantage of DT is that it allows moving information about
> non-probeable hardware that was previously hardwired in the kernel
> C sources into a separate data structure, but the versatile displays
> are not non-probeable. I can see no benefit at all from hardwiring into
> the dt something which the kernel has previously been successfully
> dynamically getting right without any bootloader intervention -- it just
> makes the kernel less flexible and less user-friendly.
My opinion is that the bootloader should be responsible for telling the
kernel what hardware there is on the board. For busses like PCI we have
proper probing mechanism with global unique identifiers for the devices,
and nothing is needed from the bootloader.
In the Versatile case the panels are kind of probeable, but not in the
same sense as PCI: all that can be probed on Versatile is a board
specific ID, which in itself doesn't tell what kind of panel there is.
In addition to the ID we need board specific tables listing the details
of the panels.
So, true, there's probing going on, but it's all board specific,
requiring a board specific driver to support it in the kernel. And I
think that makes the bootloader much better place for supporting it.
But, again, for legacy reasons that may not be possible.
Now, _if_ the Versatile panels were hotpluggable, and it would be a
normal use case to switch the panels at runtime and having the kernel
automatically switch to the correct video mode, we would obviously need
a kernel driver for it. But afaik that's not the case.
I think one of the core questions here is: do we want to start adding
board specific drivers to the kernel, instead of dealing with it in the
bootloader when possible? My understanding is that we've been trying to
reduce board specific code from the kernel.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 12:45 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-23 12:45 UTC (permalink / raw)
To: linux-arm-kernel
On 23/02/16 13:56, Peter Maydell wrote:
> On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> I'm not quite sure how it works if, as in versatile display case, there
>> are multiple DT overlays of which one has to be enabled. I hope there's
>> support to choose which one to use via kernel cmdline or similar.
>>
>> I would personally like it much more if the bootloader would either
>> compose a final dtb from DT fragments and pass it to the kernel, or
>> alternatively the bootloader would pass the base dtb image and a bunch
>> of DT overlays to the kernel, and the kernel would deal with the DT
>> overlays.
>
> Speaking as somebody who's written the "bootloader" code that's
> used for what I guess are the majority of versatile kernel boots,
> i.e. the one in QEMU, I think that requiring the bootloader to do this
> would be a significant worsening from the current state.
>
> Right now the bootloader doesn't need to do much at all with device
> trees, except pass the kernel the DT that the user gave us, which
> is just the kernel's own data structures in a separate file for
> convenience. You need to do some very minor tweaks to the /chosen
> node, but these can be handled the same way for any board and aren't
> hardware specific. There's no need to worry about dt fragments
> either for the bootloader or for the user. Imposing a new requirement
> for the bootloader to have to probe hardware which it otherwise
> has no need to even care about, and then edit and update the DT
> in a board-specific manner, or have board-specific DT fragments,
> seems like a totally unnecessary imposition on both bootloader
> authors and end-users, and of course it would break booting newer
> kernels on the great mass of already existing boot loaders and
> QEMU installs.
I'm looking for a good generic solution for going forward that can be
used on new boards, for both non-probeable and probeable displays.
When we have that solution, we can see if and how the solution could be
used for current boards. I'm sure that for some boards we need to
support whatever legacy methods are out there already.
> The kernel is in a position to probe the display hardware and determine
> what is there, and do the right thing, and that's exactly what it
> does today. The kernel should continue to do this.
> The advantage of DT is that it allows moving information about
> non-probeable hardware that was previously hardwired in the kernel
> C sources into a separate data structure, but the versatile displays
> are not non-probeable. I can see no benefit at all from hardwiring into
> the dt something which the kernel has previously been successfully
> dynamically getting right without any bootloader intervention -- it just
> makes the kernel less flexible and less user-friendly.
My opinion is that the bootloader should be responsible for telling the
kernel what hardware there is on the board. For busses like PCI we have
proper probing mechanism with global unique identifiers for the devices,
and nothing is needed from the bootloader.
In the Versatile case the panels are kind of probeable, but not in the
same sense as PCI: all that can be probed on Versatile is a board
specific ID, which in itself doesn't tell what kind of panel there is.
In addition to the ID we need board specific tables listing the details
of the panels.
So, true, there's probing going on, but it's all board specific,
requiring a board specific driver to support it in the kernel. And I
think that makes the bootloader much better place for supporting it.
But, again, for legacy reasons that may not be possible.
Now, _if_ the Versatile panels were hotpluggable, and it would be a
normal use case to switch the panels at runtime and having the kernel
automatically switch to the correct video mode, we would obviously need
a kernel driver for it. But afaik that's not the case.
I think one of the core questions here is: do we want to start adding
board specific drivers to the kernel, instead of dealing with it in the
bootloader when possible? My understanding is that we've been trying to
reduce board specific code from the kernel.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/3b325e20/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 12:45 ` Tomi Valkeinen
@ 2016-02-23 13:49 ` Peter Maydell
-1 siblings, 0 replies; 145+ messages in thread
From: Peter Maydell @ 2016-02-23 13:49 UTC (permalink / raw)
To: linux-arm-kernel
On 23 February 2016 at 12:45, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> So, true, there's probing going on, but it's all board specific,
> requiring a board specific driver to support it in the kernel. And I
> think that makes the bootloader much better place for supporting it.
This doesn't seem to me like a reason to put the requirement
in the bootloader. A huge part of the purpose of the kernel
is to support the hardware (whether that's completely generic
and probeable, like PCI, or generic but not probeable, or
completely specific to a particular board). The kernel has to
support the hardware, and just because it happens to be board
specific hardware rather than generic hardware doesn't seem to
me to imply that the kernel gets to drop part of its core purpose.
> I think one of the core questions here is: do we want to start adding
> board specific drivers to the kernel, instead of dealing with it in the
> bootloader when possible? My understanding is that we've been trying to
> reduce board specific code from the kernel.
I think there's a difference between "reduce board specific code
in the kernel by replacing it with the combination of generic
or parameterisable code in the kernel plus a kernel data structure
(DT) that supplies the parameterisation needed", and "reduce
board specific code in the kernel by forcing the bootloader to
do the kernel's job for it".
thanks
-- PMM
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 13:49 ` Peter Maydell
0 siblings, 0 replies; 145+ messages in thread
From: Peter Maydell @ 2016-02-23 13:49 UTC (permalink / raw)
To: linux-arm-kernel
On 23 February 2016 at 12:45, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> So, true, there's probing going on, but it's all board specific,
> requiring a board specific driver to support it in the kernel. And I
> think that makes the bootloader much better place for supporting it.
This doesn't seem to me like a reason to put the requirement
in the bootloader. A huge part of the purpose of the kernel
is to support the hardware (whether that's completely generic
and probeable, like PCI, or generic but not probeable, or
completely specific to a particular board). The kernel has to
support the hardware, and just because it happens to be board
specific hardware rather than generic hardware doesn't seem to
me to imply that the kernel gets to drop part of its core purpose.
> I think one of the core questions here is: do we want to start adding
> board specific drivers to the kernel, instead of dealing with it in the
> bootloader when possible? My understanding is that we've been trying to
> reduce board specific code from the kernel.
I think there's a difference between "reduce board specific code
in the kernel by replacing it with the combination of generic
or parameterisable code in the kernel plus a kernel data structure
(DT) that supplies the parameterisation needed", and "reduce
board specific code in the kernel by forcing the bootloader to
do the kernel's job for it".
thanks
-- PMM
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 13:49 ` Peter Maydell
@ 2016-02-24 12:06 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-24 12:06 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]
On 23/02/16 15:49, Peter Maydell wrote:
> On 23 February 2016 at 12:45, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> So, true, there's probing going on, but it's all board specific,
>> requiring a board specific driver to support it in the kernel. And I
>> think that makes the bootloader much better place for supporting it.
>
> This doesn't seem to me like a reason to put the requirement
> in the bootloader. A huge part of the purpose of the kernel
> is to support the hardware (whether that's completely generic
> and probeable, like PCI, or generic but not probeable, or
> completely specific to a particular board). The kernel has to
> support the hardware, and just because it happens to be board
> specific hardware rather than generic hardware doesn't seem to
> me to imply that the kernel gets to drop part of its core purpose.
The thing here is, the kernel doesn't have to support the hardware (the
probing method). The kernel _has_ to support the display controller and
the panels, but the probing could as well be done in the bootloader. It
would work fine, and it would be a cleaner solution that what's being
proposed so far.
>> I think one of the core questions here is: do we want to start adding
>> board specific drivers to the kernel, instead of dealing with it in the
>> bootloader when possible? My understanding is that we've been trying to
>> reduce board specific code from the kernel.
>
> I think there's a difference between "reduce board specific code
> in the kernel by replacing it with the combination of generic
> or parameterisable code in the kernel plus a kernel data structure
> (DT) that supplies the parameterisation needed", and "reduce
> board specific code in the kernel by forcing the bootloader to
> do the kernel's job for it".
Perhaps my phone background affects here, but I see the vendor provided
bootloader as the place for board specific custom solutions, and then
the kernel doesn't have to deal with those if at all possible.
With an open source generic bootloader like u-boot that doesn't exactly
hold, though, as the custom solutions will still pile up in a common
project.
Anyway, as discussed in the thread, I'm fine with having a kernel driver
for this, as the display boards for Versatile are an external device.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-24 12:06 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-24 12:06 UTC (permalink / raw)
To: linux-arm-kernel
On 23/02/16 15:49, Peter Maydell wrote:
> On 23 February 2016 at 12:45, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> So, true, there's probing going on, but it's all board specific,
>> requiring a board specific driver to support it in the kernel. And I
>> think that makes the bootloader much better place for supporting it.
>
> This doesn't seem to me like a reason to put the requirement
> in the bootloader. A huge part of the purpose of the kernel
> is to support the hardware (whether that's completely generic
> and probeable, like PCI, or generic but not probeable, or
> completely specific to a particular board). The kernel has to
> support the hardware, and just because it happens to be board
> specific hardware rather than generic hardware doesn't seem to
> me to imply that the kernel gets to drop part of its core purpose.
The thing here is, the kernel doesn't have to support the hardware (the
probing method). The kernel _has_ to support the display controller and
the panels, but the probing could as well be done in the bootloader. It
would work fine, and it would be a cleaner solution that what's being
proposed so far.
>> I think one of the core questions here is: do we want to start adding
>> board specific drivers to the kernel, instead of dealing with it in the
>> bootloader when possible? My understanding is that we've been trying to
>> reduce board specific code from the kernel.
>
> I think there's a difference between "reduce board specific code
> in the kernel by replacing it with the combination of generic
> or parameterisable code in the kernel plus a kernel data structure
> (DT) that supplies the parameterisation needed", and "reduce
> board specific code in the kernel by forcing the bootloader to
> do the kernel's job for it".
Perhaps my phone background affects here, but I see the vendor provided
bootloader as the place for board specific custom solutions, and then
the kernel doesn't have to deal with those if at all possible.
With an open source generic bootloader like u-boot that doesn't exactly
hold, though, as the custom solutions will still pile up in a common
project.
Anyway, as discussed in the thread, I'm fine with having a kernel driver
for this, as the display boards for Versatile are an external device.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/b8465d20/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 12:45 ` Tomi Valkeinen
@ 2016-02-24 10:46 ` Russell King - ARM Linux
-1 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-24 10:46 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 02:45:30PM +0200, Tomi Valkeinen wrote:
> My opinion is that the bootloader should be responsible for telling the
> kernel what hardware there is on the board. For busses like PCI we have
> proper probing mechanism with global unique identifiers for the devices,
> and nothing is needed from the bootloader.
Exactly, but that is _NOT_ the case here, because we're not talking
about an on-board display.
> In the Versatile case the panels are kind of probeable, but not in the
> same sense as PCI: all that can be probed on Versatile is a board
> specific ID, which in itself doesn't tell what kind of panel there is.
> In addition to the ID we need board specific tables listing the details
> of the panels.
That argument does not stack up. Just because you've plugged in a
network device does not mean that the kernel can drive it: the kernel
needs a device specific driver, which is determined by looking at the
IDs. There is no standard network driver PCI interface.
> I think one of the core questions here is: do we want to start adding
> board specific drivers to the kernel, instead of dealing with it in the
> bootloader when possible? My understanding is that we've been trying to
> reduce board specific code from the kernel.
That's not really the question, because that question assumes that it
isn't already present, which is not true. The code is already present.
The question is how to deal with this from the DT perspective.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-24 10:46 ` Russell King - ARM Linux
0 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-24 10:46 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 02:45:30PM +0200, Tomi Valkeinen wrote:
> My opinion is that the bootloader should be responsible for telling the
> kernel what hardware there is on the board. For busses like PCI we have
> proper probing mechanism with global unique identifiers for the devices,
> and nothing is needed from the bootloader.
Exactly, but that is _NOT_ the case here, because we're not talking
about an on-board display.
> In the Versatile case the panels are kind of probeable, but not in the
> same sense as PCI: all that can be probed on Versatile is a board
> specific ID, which in itself doesn't tell what kind of panel there is.
> In addition to the ID we need board specific tables listing the details
> of the panels.
That argument does not stack up. Just because you've plugged in a
network device does not mean that the kernel can drive it: the kernel
needs a device specific driver, which is determined by looking at the
IDs. There is no standard network driver PCI interface.
> I think one of the core questions here is: do we want to start adding
> board specific drivers to the kernel, instead of dealing with it in the
> bootloader when possible? My understanding is that we've been trying to
> reduce board specific code from the kernel.
That's not really the question, because that question assumes that it
isn't already present, which is not true. The code is already present.
The question is how to deal with this from the DT perspective.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-24 10:46 ` Russell King - ARM Linux
@ 2016-02-24 11:21 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-24 11:21 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2902 bytes --]
On 24/02/16 12:46, Russell King - ARM Linux wrote:
> On Tue, Feb 23, 2016 at 02:45:30PM +0200, Tomi Valkeinen wrote:
>> My opinion is that the bootloader should be responsible for telling the
>> kernel what hardware there is on the board. For busses like PCI we have
>> proper probing mechanism with global unique identifiers for the devices,
>> and nothing is needed from the bootloader.
>
> Exactly, but that is _NOT_ the case here, because we're not talking
> about an on-board display.
Ok, what is it then? I'm not familiar with the boards in question.
When does a display become an on-board display? All the panels I have
can be disconnected quite easily, but I still consider them as on-board
displays.
>> In the Versatile case the panels are kind of probeable, but not in the
>> same sense as PCI: all that can be probed on Versatile is a board
>> specific ID, which in itself doesn't tell what kind of panel there is.
>> In addition to the ID we need board specific tables listing the details
>> of the panels.
>
> That argument does not stack up. Just because you've plugged in a
> network device does not mean that the kernel can drive it: the kernel
> needs a device specific driver, which is determined by looking at the
> IDs. There is no standard network driver PCI interface.
Yes, but you can connect the network device to any board with a PCI bus
and it works. Here, if I'm not mistaken, the displays are built for this
single board, making them board specific.
So sure, someone could build boards with the same connector, allowing
you to connect the same displays. If that's the case, then CLCD should
be taken out of this picture, as the board could have something else
than CLCD as the display controller.
>> I think one of the core questions here is: do we want to start adding
>> board specific drivers to the kernel, instead of dealing with it in the
>> bootloader when possible? My understanding is that we've been trying to
>> reduce board specific code from the kernel.
>
> That's not really the question, because that question assumes that it
> isn't already present, which is not true. The code is already present.
> The question is how to deal with this from the DT perspective.
Yes. As I commented in this (or the other thread), I'm looking for a
proper generic solution which can be recommended for all new boards.
When we know what that is, we can see if and how that could fit into
Versatile's case. Versatile is not the only board with the exact same
problem.
I wouldn't be at all surprised if the final solution is to just go with
Linus' current patches for Versatile, as everything else would break
compatibility or be overly complex.
But I cannot accept that as a general solution for all similar cases
going forward, especially when moving to DRM world, that's just bad SW
design.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-24 11:21 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-24 11:21 UTC (permalink / raw)
To: linux-arm-kernel
On 24/02/16 12:46, Russell King - ARM Linux wrote:
> On Tue, Feb 23, 2016 at 02:45:30PM +0200, Tomi Valkeinen wrote:
>> My opinion is that the bootloader should be responsible for telling the
>> kernel what hardware there is on the board. For busses like PCI we have
>> proper probing mechanism with global unique identifiers for the devices,
>> and nothing is needed from the bootloader.
>
> Exactly, but that is _NOT_ the case here, because we're not talking
> about an on-board display.
Ok, what is it then? I'm not familiar with the boards in question.
When does a display become an on-board display? All the panels I have
can be disconnected quite easily, but I still consider them as on-board
displays.
>> In the Versatile case the panels are kind of probeable, but not in the
>> same sense as PCI: all that can be probed on Versatile is a board
>> specific ID, which in itself doesn't tell what kind of panel there is.
>> In addition to the ID we need board specific tables listing the details
>> of the panels.
>
> That argument does not stack up. Just because you've plugged in a
> network device does not mean that the kernel can drive it: the kernel
> needs a device specific driver, which is determined by looking at the
> IDs. There is no standard network driver PCI interface.
Yes, but you can connect the network device to any board with a PCI bus
and it works. Here, if I'm not mistaken, the displays are built for this
single board, making them board specific.
So sure, someone could build boards with the same connector, allowing
you to connect the same displays. If that's the case, then CLCD should
be taken out of this picture, as the board could have something else
than CLCD as the display controller.
>> I think one of the core questions here is: do we want to start adding
>> board specific drivers to the kernel, instead of dealing with it in the
>> bootloader when possible? My understanding is that we've been trying to
>> reduce board specific code from the kernel.
>
> That's not really the question, because that question assumes that it
> isn't already present, which is not true. The code is already present.
> The question is how to deal with this from the DT perspective.
Yes. As I commented in this (or the other thread), I'm looking for a
proper generic solution which can be recommended for all new boards.
When we know what that is, we can see if and how that could fit into
Versatile's case. Versatile is not the only board with the exact same
problem.
I wouldn't be at all surprised if the final solution is to just go with
Linus' current patches for Versatile, as everything else would break
compatibility or be overly complex.
But I cannot accept that as a general solution for all similar cases
going forward, especially when moving to DRM world, that's just bad SW
design.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/9d13a40f/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-24 11:21 ` Tomi Valkeinen
@ 2016-02-24 11:35 ` Russell King - ARM Linux
-1 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-24 11:35 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 24, 2016 at 01:21:51PM +0200, Tomi Valkeinen wrote:
> On 24/02/16 12:46, Russell King - ARM Linux wrote:
> > On Tue, Feb 23, 2016 at 02:45:30PM +0200, Tomi Valkeinen wrote:
> >> My opinion is that the bootloader should be responsible for telling the
> >> kernel what hardware there is on the board. For busses like PCI we have
> >> proper probing mechanism with global unique identifiers for the devices,
> >> and nothing is needed from the bootloader.
> >
> > Exactly, but that is _NOT_ the case here, because we're not talking
> > about an on-board display.
>
> Ok, what is it then? I'm not familiar with the boards in question.
>
> When does a display become an on-board display? All the panels I have
> can be disconnected quite easily, but I still consider them as on-board
> displays.
The difference to me is quite clear.
If the connector is a flexi-strip or LVDS connector designed to be
connected directly to a panel, it is not designed as a user connector,
and the display can be regarded as part of the board: the connector
probably isn't rated for a large number of mating cycles.
If the connector is a board-edge external-unit connector, then the
panel is not part of the board.
In the case of Versatile, it's the latter: the connector is situated
at the board edge, next to the serial port connectors, and is designed
to connect to an external box housing the display.
> > That argument does not stack up. Just because you've plugged in a
> > network device does not mean that the kernel can drive it: the kernel
> > needs a device specific driver, which is determined by looking at the
> > IDs. There is no standard network driver PCI interface.
>
> Yes, but you can connect the network device to any board with a PCI bus
> and it works. Here, if I'm not mistaken, the displays are built for this
> single board, making them board specific.
It only works because Linux has a rich array of network drivers supporting
all that hardware, and the appropriate network driver is bound depending
on the hardware ID of the card. If a new PCI network device comes out,
it'll more likely than not require an update to a network driver to make
it work.
The displays are not built for "this single board" but for a family of
boards: not only Versatile PB/AB, but also the Realview family of boards
too.
> But I cannot accept that as a general solution for all similar cases
> going forward, especially when moving to DRM world, that's just bad SW
> design.
I think that's a matter of personal opinion, perspective and situation.
What is good design today is not necessary good design yesterday or
tomorrow. I thought we already ascertained that earlier in this
discussion. :)
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-24 11:35 ` Russell King - ARM Linux
0 siblings, 0 replies; 145+ messages in thread
From: Russell King - ARM Linux @ 2016-02-24 11:35 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 24, 2016 at 01:21:51PM +0200, Tomi Valkeinen wrote:
> On 24/02/16 12:46, Russell King - ARM Linux wrote:
> > On Tue, Feb 23, 2016 at 02:45:30PM +0200, Tomi Valkeinen wrote:
> >> My opinion is that the bootloader should be responsible for telling the
> >> kernel what hardware there is on the board. For busses like PCI we have
> >> proper probing mechanism with global unique identifiers for the devices,
> >> and nothing is needed from the bootloader.
> >
> > Exactly, but that is _NOT_ the case here, because we're not talking
> > about an on-board display.
>
> Ok, what is it then? I'm not familiar with the boards in question.
>
> When does a display become an on-board display? All the panels I have
> can be disconnected quite easily, but I still consider them as on-board
> displays.
The difference to me is quite clear.
If the connector is a flexi-strip or LVDS connector designed to be
connected directly to a panel, it is not designed as a user connector,
and the display can be regarded as part of the board: the connector
probably isn't rated for a large number of mating cycles.
If the connector is a board-edge external-unit connector, then the
panel is not part of the board.
In the case of Versatile, it's the latter: the connector is situated
at the board edge, next to the serial port connectors, and is designed
to connect to an external box housing the display.
> > That argument does not stack up. Just because you've plugged in a
> > network device does not mean that the kernel can drive it: the kernel
> > needs a device specific driver, which is determined by looking at the
> > IDs. There is no standard network driver PCI interface.
>
> Yes, but you can connect the network device to any board with a PCI bus
> and it works. Here, if I'm not mistaken, the displays are built for this
> single board, making them board specific.
It only works because Linux has a rich array of network drivers supporting
all that hardware, and the appropriate network driver is bound depending
on the hardware ID of the card. If a new PCI network device comes out,
it'll more likely than not require an update to a network driver to make
it work.
The displays are not built for "this single board" but for a family of
boards: not only Versatile PB/AB, but also the Realview family of boards
too.
> But I cannot accept that as a general solution for all similar cases
> going forward, especially when moving to DRM world, that's just bad SW
> design.
I think that's a matter of personal opinion, perspective and situation.
What is good design today is not necessary good design yesterday or
tomorrow. I thought we already ascertained that earlier in this
discussion. :)
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-24 11:35 ` Russell King - ARM Linux
@ 2016-02-24 11:47 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-24 11:47 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]
On 24/02/16 13:35, Russell King - ARM Linux wrote:
> If the connector is a flexi-strip or LVDS connector designed to be
> connected directly to a panel, it is not designed as a user connector,
> and the display can be regarded as part of the board: the connector
> probably isn't rated for a large number of mating cycles.
>
> If the connector is a board-edge external-unit connector, then the
> panel is not part of the board.
Ok, I see. I presumed the display-board was attached directly to the
mainboard. Of course, we could still argue about the difference, with
the exact same pins used with an external connector and with an on-board
connector, but lets not go there.
I agree in this case the panels are external devices =).
However, I would still be interested in opinions how to implement the
exact same case, but for boards where the panels were considered
on-board panels.
> The displays are not built for "this single board" but for a family of
> boards: not only Versatile PB/AB, but also the Realview family of boards
> too.
Alright.
So, if this is to be done correctly, we need to disconnect the display
board code from the CLCD code, as they really have nothing to do with
each other.
Perhaps a panel driver which covers the display boards used here, which
does the probing and contains the video timings for the panels in question?
One could then use that panel driver with other display controllers too.
Although the probing part is perhaps difficult to make generic, but that
board specific code should still be part of the panel-board driver, not
CLCD driver.
>> But I cannot accept that as a general solution for all similar cases
>> going forward, especially when moving to DRM world, that's just bad SW
>> design.
>
> I think that's a matter of personal opinion, perspective and situation.
> What is good design today is not necessary good design yesterday or
> tomorrow. I thought we already ascertained that earlier in this
> discussion. :)
Well, I was mostly referring to combining separate devices into single
driver. CLCD and the external displays, in this case. Then again,
"complexity" is part of the SW design, and splitting the devices drivers
into independent pieces often increases complexity, so...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-24 11:47 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-24 11:47 UTC (permalink / raw)
To: linux-arm-kernel
On 24/02/16 13:35, Russell King - ARM Linux wrote:
> If the connector is a flexi-strip or LVDS connector designed to be
> connected directly to a panel, it is not designed as a user connector,
> and the display can be regarded as part of the board: the connector
> probably isn't rated for a large number of mating cycles.
>
> If the connector is a board-edge external-unit connector, then the
> panel is not part of the board.
Ok, I see. I presumed the display-board was attached directly to the
mainboard. Of course, we could still argue about the difference, with
the exact same pins used with an external connector and with an on-board
connector, but lets not go there.
I agree in this case the panels are external devices =).
However, I would still be interested in opinions how to implement the
exact same case, but for boards where the panels were considered
on-board panels.
> The displays are not built for "this single board" but for a family of
> boards: not only Versatile PB/AB, but also the Realview family of boards
> too.
Alright.
So, if this is to be done correctly, we need to disconnect the display
board code from the CLCD code, as they really have nothing to do with
each other.
Perhaps a panel driver which covers the display boards used here, which
does the probing and contains the video timings for the panels in question?
One could then use that panel driver with other display controllers too.
Although the probing part is perhaps difficult to make generic, but that
board specific code should still be part of the panel-board driver, not
CLCD driver.
>> But I cannot accept that as a general solution for all similar cases
>> going forward, especially when moving to DRM world, that's just bad SW
>> design.
>
> I think that's a matter of personal opinion, perspective and situation.
> What is good design today is not necessary good design yesterday or
> tomorrow. I thought we already ascertained that earlier in this
> discussion. :)
Well, I was mostly referring to combining separate devices into single
driver. CLCD and the external displays, in this case. Then again,
"complexity" is part of the SW design, and splitting the devices drivers
into independent pieces often increases complexity, so...
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/2f80fff6/attachment-0001.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-24 11:21 ` Tomi Valkeinen
@ 2016-02-24 12:13 ` Pantelis Antoniou
-1 siblings, 0 replies; 145+ messages in thread
From: Pantelis Antoniou @ 2016-02-24 12:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomi,
> On Feb 24, 2016, at 13:21 , Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
[snip]
>>
>> That argument does not stack up. Just because you've plugged in a
>> network device does not mean that the kernel can drive it: the kernel
>> needs a device specific driver, which is determined by looking at the
>> IDs. There is no standard network driver PCI interface.
>
> Yes, but you can connect the network device to any board with a PCI bus
> and it works. Here, if I'm not mistaken, the displays are built for this
> single board, making them board specific.
>
> So sure, someone could build boards with the same connector, allowing
> you to connect the same displays. If that's the case, then CLCD should
> be taken out of this picture, as the board could have something else
> than CLCD as the display controller.
>
>>> I think one of the core questions here is: do we want to start adding
>>> board specific drivers to the kernel, instead of dealing with it in the
>>> bootloader when possible? My understanding is that we've been trying to
>>> reduce board specific code from the kernel.
>>
>> That's not really the question, because that question assumes that it
>> isn't already present, which is not true. The code is already present.
>> The question is how to deal with this from the DT perspective.
>
> Yes. As I commented in this (or the other thread), I'm looking for a
> proper generic solution which can be recommended for all new boards.
> When we know what that is, we can see if and how that could fit into
> Versatile's case. Versatile is not the only board with the exact same
> problem.
>
> I wouldn't be at all surprised if the final solution is to just go with
> Linus' current patches for Versatile, as everything else would break
> compatibility or be overly complex.
>
> But I cannot accept that as a general solution for all similar cases
> going forward, especially when moving to DRM world, that's just bad SW
> design.
>
IMHO DT+overlays handle all your cases just fine.
As far as I see these are the cases which we need to handle:
1) The expansion board in question has some means of identification, whether it’s an
EEPROM or a GPIO keying combination etc. In that case it is the kernel’s job to match this
id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware().
2) The expansion board in question has no means of identification. In that case the bootloader’s
job is to provide user-configured means to the kernel to use the expansion board.
We talked about two basic schemes.
2.1) The kernel command line contains information about the extra overlays to apply upon booting.
Something like “applyoverlays=foo.dtbo,bar.dtbo” is sufficient. The problem with this approach is that
if the firmware files must be present in the initrd/rootfs/builtin-kernel-image. For some this is a
problem.
2.2) The base DTB provided to the kernel from the bootloader is augmented with extra DTBOs that describe
the extra hardware. The concatenation is as simple as performing a ‘$ cat base.dtb foo.dtbo bar.dtbo’, which
can be done either by the bootloader or offline. At the moment this is not being done, but it’s easy enough
to add it and other people expressed interest for it.
Am I missing something here?
> Tomi
>
Regards
— Pantelis
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-24 12:13 ` Pantelis Antoniou
0 siblings, 0 replies; 145+ messages in thread
From: Pantelis Antoniou @ 2016-02-24 12:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomi,
> On Feb 24, 2016, at 13:21 , Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
[snip]
>>
>> That argument does not stack up. Just because you've plugged in a
>> network device does not mean that the kernel can drive it: the kernel
>> needs a device specific driver, which is determined by looking at the
>> IDs. There is no standard network driver PCI interface.
>
> Yes, but you can connect the network device to any board with a PCI bus
> and it works. Here, if I'm not mistaken, the displays are built for this
> single board, making them board specific.
>
> So sure, someone could build boards with the same connector, allowing
> you to connect the same displays. If that's the case, then CLCD should
> be taken out of this picture, as the board could have something else
> than CLCD as the display controller.
>
>>> I think one of the core questions here is: do we want to start adding
>>> board specific drivers to the kernel, instead of dealing with it in the
>>> bootloader when possible? My understanding is that we've been trying to
>>> reduce board specific code from the kernel.
>>
>> That's not really the question, because that question assumes that it
>> isn't already present, which is not true. The code is already present.
>> The question is how to deal with this from the DT perspective.
>
> Yes. As I commented in this (or the other thread), I'm looking for a
> proper generic solution which can be recommended for all new boards.
> When we know what that is, we can see if and how that could fit into
> Versatile's case. Versatile is not the only board with the exact same
> problem.
>
> I wouldn't be at all surprised if the final solution is to just go with
> Linus' current patches for Versatile, as everything else would break
> compatibility or be overly complex.
>
> But I cannot accept that as a general solution for all similar cases
> going forward, especially when moving to DRM world, that's just bad SW
> design.
>
IMHO DT+overlays handle all your cases just fine.
As far as I see these are the cases which we need to handle:
1) The expansion board in question has some means of identification, whether it?s an
EEPROM or a GPIO keying combination etc. In that case it is the kernel?s job to match this
id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware().
2) The expansion board in question has no means of identification. In that case the bootloader?s
job is to provide user-configured means to the kernel to use the expansion board.
We talked about two basic schemes.
2.1) The kernel command line contains information about the extra overlays to apply upon booting.
Something like ?applyoverlays=foo.dtbo,bar.dtbo? is sufficient. The problem with this approach is that
if the firmware files must be present in the initrd/rootfs/builtin-kernel-image. For some this is a
problem.
2.2) The base DTB provided to the kernel from the bootloader is augmented with extra DTBOs that describe
the extra hardware. The concatenation is as simple as performing a ?$ cat base.dtb foo.dtbo bar.dtbo?, which
can be done either by the bootloader or offline. At the moment this is not being done, but it?s easy enough
to add it and other people expressed interest for it.
Am I missing something here?
> Tomi
>
Regards
? Pantelis
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-24 12:13 ` Pantelis Antoniou
@ 2016-02-25 13:43 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-25 13:43 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 24, 2016 at 1:13 PM, Pantelis Antoniou
<pantelis.antoniou@konsulko.com> wrote:
> IMHO DT+overlays handle all your cases just fine.
>
> As far as I see these are the cases which we need to handle:
>
> 1) The expansion board in question has some means of identification, whether it’s an
> EEPROM or a GPIO keying combination etc. In that case it is the kernel’s job to match this
> id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware().
Since the dawn of time the x86 people used that console to display
the early boot crawl and collect crash data. What you're suggesting
is that we can't get the console up until after the filesystems and mounts
are up so the kernel can read firmware files.
This kills of early boot graphics and getting crash logs on the fbdev
console until that has happened.
It also means there is no way to get the console up without the right
firmware files in the filesystem. I think that is really crap compared
to what we have today where the display will always come up, and
basically a regression.
I understand the stance with respect to things like add-on hardware
like a Bluetooth board or WLAN or whatnot. But the fbdev console
is just too basic, like a serial port IMO.
Sure in the ARM world we usually have a serial console, but this is
seriously breaking current practice.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-25 13:43 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-25 13:43 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 24, 2016 at 1:13 PM, Pantelis Antoniou
<pantelis.antoniou@konsulko.com> wrote:
> IMHO DT+overlays handle all your cases just fine.
>
> As far as I see these are the cases which we need to handle:
>
> 1) The expansion board in question has some means of identification, whether it?s an
> EEPROM or a GPIO keying combination etc. In that case it is the kernel?s job to match this
> id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware().
Since the dawn of time the x86 people used that console to display
the early boot crawl and collect crash data. What you're suggesting
is that we can't get the console up until after the filesystems and mounts
are up so the kernel can read firmware files.
This kills of early boot graphics and getting crash logs on the fbdev
console until that has happened.
It also means there is no way to get the console up without the right
firmware files in the filesystem. I think that is really crap compared
to what we have today where the display will always come up, and
basically a regression.
I understand the stance with respect to things like add-on hardware
like a Bluetooth board or WLAN or whatnot. But the fbdev console
is just too basic, like a serial port IMO.
Sure in the ARM world we usually have a serial console, but this is
seriously breaking current practice.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-25 13:43 ` Linus Walleij
@ 2016-02-25 13:56 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-25 13:56 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1058 bytes --]
On 25/02/16 15:43, Linus Walleij wrote:
> On Wed, Feb 24, 2016 at 1:13 PM, Pantelis Antoniou
> <pantelis.antoniou@konsulko.com> wrote:
>
>> IMHO DT+overlays handle all your cases just fine.
>>
>> As far as I see these are the cases which we need to handle:
>>
>> 1) The expansion board in question has some means of identification, whether it’s an
>> EEPROM or a GPIO keying combination etc. In that case it is the kernel’s job to match this
>> id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware().
>
> Since the dawn of time the x86 people used that console to display
> the early boot crawl and collect crash data. What you're suggesting
> is that we can't get the console up until after the filesystems and mounts
> are up so the kernel can read firmware files.
You can build firmware images into the kernel image. No, I don't like
that either.
The 2.2) option in Pantelis' mail can be used for 1) too, although then
the bootloader needs to know which dtbos to add.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-25 13:56 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-25 13:56 UTC (permalink / raw)
To: linux-arm-kernel
On 25/02/16 15:43, Linus Walleij wrote:
> On Wed, Feb 24, 2016 at 1:13 PM, Pantelis Antoniou
> <pantelis.antoniou@konsulko.com> wrote:
>
>> IMHO DT+overlays handle all your cases just fine.
>>
>> As far as I see these are the cases which we need to handle:
>>
>> 1) The expansion board in question has some means of identification, whether it?s an
>> EEPROM or a GPIO keying combination etc. In that case it is the kernel?s job to match this
>> id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware().
>
> Since the dawn of time the x86 people used that console to display
> the early boot crawl and collect crash data. What you're suggesting
> is that we can't get the console up until after the filesystems and mounts
> are up so the kernel can read firmware files.
You can build firmware images into the kernel image. No, I don't like
that either.
The 2.2) option in Pantelis' mail can be used for 1) too, although then
the bootloader needs to know which dtbos to add.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/35dfa506/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-25 13:43 ` Linus Walleij
@ 2016-02-25 14:35 ` Pantelis Antoniou
-1 siblings, 0 replies; 145+ messages in thread
From: Pantelis Antoniou @ 2016-02-25 14:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
> On Feb 25, 2016, at 15:43 , Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Wed, Feb 24, 2016 at 1:13 PM, Pantelis Antoniou
> <pantelis.antoniou@konsulko.com> wrote:
>
>> IMHO DT+overlays handle all your cases just fine.
>>
>> As far as I see these are the cases which we need to handle:
>>
>> 1) The expansion board in question has some means of identification, whether it’s an
>> EEPROM or a GPIO keying combination etc. In that case it is the kernel’s job to match this
>> id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware().
>
> Since the dawn of time the x86 people used that console to display
> the early boot crawl and collect crash data. What you're suggesting
> is that we can't get the console up until after the filesystems and mounts
> are up so the kernel can read firmware files.
>
> This kills of early boot graphics and getting crash logs on the fbdev
> console until that has happened.
>
> It also means there is no way to get the console up without the right
> firmware files in the filesystem. I think that is really crap compared
> to what we have today where the display will always come up, and
> basically a regression.
>
> I understand the stance with respect to things like add-on hardware
> like a Bluetooth board or WLAN or whatnot. But the fbdev console
> is just too basic, like a serial port IMO.
>
> Sure in the ARM world we usually have a serial console, but this is
> seriously breaking current practice.
>
As Tomi mentioned firmware files can be located in the kernel image; there is no
requirement to be in a filesystem, and that application can be performed really
early, before even early init.
The comparison with x86 is not absolutely valid, since on x86 you know that
the video hardware is going to be present, always.
This is not so in ARM world, especially in the case we’re talking about, an add-on board.
> Yours,
> Linus Walleij
Regards
— Pantelis
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-25 14:35 ` Pantelis Antoniou
0 siblings, 0 replies; 145+ messages in thread
From: Pantelis Antoniou @ 2016-02-25 14:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
> On Feb 25, 2016, at 15:43 , Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Wed, Feb 24, 2016 at 1:13 PM, Pantelis Antoniou
> <pantelis.antoniou@konsulko.com> wrote:
>
>> IMHO DT+overlays handle all your cases just fine.
>>
>> As far as I see these are the cases which we need to handle:
>>
>> 1) The expansion board in question has some means of identification, whether it?s an
>> EEPROM or a GPIO keying combination etc. In that case it is the kernel?s job to match this
>> id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware().
>
> Since the dawn of time the x86 people used that console to display
> the early boot crawl and collect crash data. What you're suggesting
> is that we can't get the console up until after the filesystems and mounts
> are up so the kernel can read firmware files.
>
> This kills of early boot graphics and getting crash logs on the fbdev
> console until that has happened.
>
> It also means there is no way to get the console up without the right
> firmware files in the filesystem. I think that is really crap compared
> to what we have today where the display will always come up, and
> basically a regression.
>
> I understand the stance with respect to things like add-on hardware
> like a Bluetooth board or WLAN or whatnot. But the fbdev console
> is just too basic, like a serial port IMO.
>
> Sure in the ARM world we usually have a serial console, but this is
> seriously breaking current practice.
>
As Tomi mentioned firmware files can be located in the kernel image; there is no
requirement to be in a filesystem, and that application can be performed really
early, before even early init.
The comparison with x86 is not absolutely valid, since on x86 you know that
the video hardware is going to be present, always.
This is not so in ARM world, especially in the case we?re talking about, an add-on board.
> Yours,
> Linus Walleij
Regards
? Pantelis
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-25 14:35 ` Pantelis Antoniou
@ 2016-02-25 15:36 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-25 15:36 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 25, 2016 at 3:35 PM, Pantelis Antoniou
<pantelis.antoniou@konsulko.com> wrote:
>> On Feb 25, 2016, at 15:43 , Linus Walleij <linus.walleij@linaro.org> wrote:
>> It also means there is no way to get the console up without the right
>> firmware files in the filesystem. I think that is really crap compared
>> to what we have today where the display will always come up, and
>> basically a regression.
>>
>> I understand the stance with respect to things like add-on hardware
>> like a Bluetooth board or WLAN or whatnot. But the fbdev console
>> is just too basic, like a serial port IMO.
>>
>> Sure in the ARM world we usually have a serial console, but this is
>> seriously breaking current practice.
>
> As Tomi mentioned firmware files can be located in the kernel image; there is no
> requirement to be in a filesystem, and that application can be performed really
> early, before even early init.
Are you thinking about exploiting an appended DT with
CONFIG_ARM_APPENDED_DTB or something else?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-25 15:36 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-25 15:36 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 25, 2016 at 3:35 PM, Pantelis Antoniou
<pantelis.antoniou@konsulko.com> wrote:
>> On Feb 25, 2016, at 15:43 , Linus Walleij <linus.walleij@linaro.org> wrote:
>> It also means there is no way to get the console up without the right
>> firmware files in the filesystem. I think that is really crap compared
>> to what we have today where the display will always come up, and
>> basically a regression.
>>
>> I understand the stance with respect to things like add-on hardware
>> like a Bluetooth board or WLAN or whatnot. But the fbdev console
>> is just too basic, like a serial port IMO.
>>
>> Sure in the ARM world we usually have a serial console, but this is
>> seriously breaking current practice.
>
> As Tomi mentioned firmware files can be located in the kernel image; there is no
> requirement to be in a filesystem, and that application can be performed really
> early, before even early init.
Are you thinking about exploiting an appended DT with
CONFIG_ARM_APPENDED_DTB or something else?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-25 15:36 ` Linus Walleij
@ 2016-02-25 15:40 ` Pantelis Antoniou
-1 siblings, 0 replies; 145+ messages in thread
From: Pantelis Antoniou @ 2016-02-25 15:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
> On Feb 25, 2016, at 17:36 , Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Thu, Feb 25, 2016 at 3:35 PM, Pantelis Antoniou
> <pantelis.antoniou@konsulko.com> wrote:
>>> On Feb 25, 2016, at 15:43 , Linus Walleij <linus.walleij@linaro.org> wrote:
>
>>> It also means there is no way to get the console up without the right
>>> firmware files in the filesystem. I think that is really crap compared
>>> to what we have today where the display will always come up, and
>>> basically a regression.
>>>
>>> I understand the stance with respect to things like add-on hardware
>>> like a Bluetooth board or WLAN or whatnot. But the fbdev console
>>> is just too basic, like a serial port IMO.
>>>
>>> Sure in the ARM world we usually have a serial console, but this is
>>> seriously breaking current practice.
>>
>> As Tomi mentioned firmware files can be located in the kernel image; there is no
>> requirement to be in a filesystem, and that application can be performed really
>> early, before even early init.
>
> Are you thinking about exploiting an appended DT with
> CONFIG_ARM_APPENDED_DTB or something else?
>
It’s not much of a problem to scan for extra blobs appended to the booting blob.
If found, you just apply them and that’s it.
The concatenation operation can either be made off-line on the host, or by the bootloader
if it’s capable of doing so.
If the bootloader is not smart enough to do it, just put the concatenated dtb in place
of the original.
> Yours,
> Linus Walleij
Regards
— Pantelis
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-25 15:40 ` Pantelis Antoniou
0 siblings, 0 replies; 145+ messages in thread
From: Pantelis Antoniou @ 2016-02-25 15:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
> On Feb 25, 2016, at 17:36 , Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Thu, Feb 25, 2016 at 3:35 PM, Pantelis Antoniou
> <pantelis.antoniou@konsulko.com> wrote:
>>> On Feb 25, 2016, at 15:43 , Linus Walleij <linus.walleij@linaro.org> wrote:
>
>>> It also means there is no way to get the console up without the right
>>> firmware files in the filesystem. I think that is really crap compared
>>> to what we have today where the display will always come up, and
>>> basically a regression.
>>>
>>> I understand the stance with respect to things like add-on hardware
>>> like a Bluetooth board or WLAN or whatnot. But the fbdev console
>>> is just too basic, like a serial port IMO.
>>>
>>> Sure in the ARM world we usually have a serial console, but this is
>>> seriously breaking current practice.
>>
>> As Tomi mentioned firmware files can be located in the kernel image; there is no
>> requirement to be in a filesystem, and that application can be performed really
>> early, before even early init.
>
> Are you thinking about exploiting an appended DT with
> CONFIG_ARM_APPENDED_DTB or something else?
>
It?s not much of a problem to scan for extra blobs appended to the booting blob.
If found, you just apply them and that?s it.
The concatenation operation can either be made off-line on the host, or by the bootloader
if it?s capable of doing so.
If the bootloader is not smart enough to do it, just put the concatenated dtb in place
of the original.
> Yours,
> Linus Walleij
Regards
? Pantelis
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
2016-02-23 11:56 ` Peter Maydell
@ 2016-02-23 13:08 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-23 13:08 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 12:56 PM, Peter Maydell
<peter.maydell@linaro.org> wrote:
> On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> I'm not quite sure how it works if, as in versatile display case, there
>> are multiple DT overlays of which one has to be enabled. I hope there's
>> support to choose which one to use via kernel cmdline or similar.
>>
>> I would personally like it much more if the bootloader would either
>> compose a final dtb from DT fragments and pass it to the kernel, or
>> alternatively the bootloader would pass the base dtb image and a bunch
>> of DT overlays to the kernel, and the kernel would deal with the DT
>> overlays.
>
> Speaking as somebody who's written the "bootloader" code that's
> used for what I guess are the majority of versatile kernel boots,
> i.e. the one in QEMU, I think that requiring the bootloader to do this
> would be a significant worsening from the current state.
>
> Right now the bootloader doesn't need to do much at all with device
> trees, except pass the kernel the DT that the user gave us, which
> is just the kernel's own data structures in a separate file for
> convenience. You need to do some very minor tweaks to the /chosen
> node, but these can be handled the same way for any board and aren't
> hardware specific. There's no need to worry about dt fragments
> either for the bootloader or for the user. Imposing a new requirement
> for the bootloader to have to probe hardware which it otherwise
> has no need to even care about, and then edit and update the DT
> in a board-specific manner, or have board-specific DT fragments,
> seems like a totally unnecessary imposition on both bootloader
> authors and end-users, and of course it would break booting newer
> kernels on the great mass of already existing boot loaders and
> QEMU installs.
>
> The kernel is in a position to probe the display hardware and determine
> what is there, and do the right thing, and that's exactly what it
> does today. The kernel should continue to do this.
> The advantage of DT is that it allows moving information about
> non-probeable hardware that was previously hardwired in the kernel
> C sources into a separate data structure, but the versatile displays
> are not non-probeable. I can see no benefit at all from hardwiring into
> the dt something which the kernel has previously been successfully
> dynamically getting right without any bootloader intervention -- it just
> makes the kernel less flexible and less user-friendly.
I agree with Peter and Russell on this, as you could guess.
Today the kernel knows about all the hardware and it
JustWorks(TM) and that is so neat.
I'm still trying to appeal to the subsystem maintainer as well.
Pretty tough deal.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
@ 2016-02-23 13:08 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-23 13:08 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 12:56 PM, Peter Maydell
<peter.maydell@linaro.org> wrote:
> On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> I'm not quite sure how it works if, as in versatile display case, there
>> are multiple DT overlays of which one has to be enabled. I hope there's
>> support to choose which one to use via kernel cmdline or similar.
>>
>> I would personally like it much more if the bootloader would either
>> compose a final dtb from DT fragments and pass it to the kernel, or
>> alternatively the bootloader would pass the base dtb image and a bunch
>> of DT overlays to the kernel, and the kernel would deal with the DT
>> overlays.
>
> Speaking as somebody who's written the "bootloader" code that's
> used for what I guess are the majority of versatile kernel boots,
> i.e. the one in QEMU, I think that requiring the bootloader to do this
> would be a significant worsening from the current state.
>
> Right now the bootloader doesn't need to do much at all with device
> trees, except pass the kernel the DT that the user gave us, which
> is just the kernel's own data structures in a separate file for
> convenience. You need to do some very minor tweaks to the /chosen
> node, but these can be handled the same way for any board and aren't
> hardware specific. There's no need to worry about dt fragments
> either for the bootloader or for the user. Imposing a new requirement
> for the bootloader to have to probe hardware which it otherwise
> has no need to even care about, and then edit and update the DT
> in a board-specific manner, or have board-specific DT fragments,
> seems like a totally unnecessary imposition on both bootloader
> authors and end-users, and of course it would break booting newer
> kernels on the great mass of already existing boot loaders and
> QEMU installs.
>
> The kernel is in a position to probe the display hardware and determine
> what is there, and do the right thing, and that's exactly what it
> does today. The kernel should continue to do this.
> The advantage of DT is that it allows moving information about
> non-probeable hardware that was previously hardwired in the kernel
> C sources into a separate data structure, but the versatile displays
> are not non-probeable. I can see no benefit at all from hardwiring into
> the dt something which the kernel has previously been successfully
> dynamically getting right without any bootloader intervention -- it just
> makes the kernel less flexible and less user-friendly.
I agree with Peter and Russell on this, as you could guess.
Today the kernel knows about all the hardware and it
JustWorks(TM) and that is so neat.
I'm still trying to appeal to the subsystem maintainer as well.
Pretty tough deal.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 00/11] CLCD Nomadik+Versatile support
2016-02-04 14:04 ` Linus Walleij
@ 2016-02-15 23:34 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-15 23:34 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> Eventually I would like to have patches 1 thru 8 (those with
> patches to CLCD or the DT bindings) applied through the FBDEV
> subsystem,
If there are no comments, would the fbdev people consider
patches 1 thru 8?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 00/11] CLCD Nomadik+Versatile support
@ 2016-02-15 23:34 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-15 23:34 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> Eventually I would like to have patches 1 thru 8 (those with
> patches to CLCD or the DT bindings) applied through the FBDEV
> subsystem,
If there are no comments, would the fbdev people consider
patches 1 thru 8?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 00/11] CLCD Nomadik+Versatile support
2016-02-15 23:34 ` Linus Walleij
@ 2016-02-16 13:29 ` Tomi Valkeinen
-1 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-16 13:29 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 513 bytes --]
On 16/02/16 01:34, Linus Walleij wrote:
> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>> Eventually I would like to have patches 1 thru 8 (those with
>> patches to CLCD or the DT bindings) applied through the FBDEV
>> subsystem,
>
> If there are no comments, would the fbdev people consider
> patches 1 thru 8?
Hmm... Is there a v2 for the 05 patch? I see one in my mailbox, but it's
not sent as a reply to this thread, making it a bit unclear.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 00/11] CLCD Nomadik+Versatile support
@ 2016-02-16 13:29 ` Tomi Valkeinen
0 siblings, 0 replies; 145+ messages in thread
From: Tomi Valkeinen @ 2016-02-16 13:29 UTC (permalink / raw)
To: linux-arm-kernel
On 16/02/16 01:34, Linus Walleij wrote:
> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>> Eventually I would like to have patches 1 thru 8 (those with
>> patches to CLCD or the DT bindings) applied through the FBDEV
>> subsystem,
>
> If there are no comments, would the fbdev people consider
> patches 1 thru 8?
Hmm... Is there a v2 for the 05 patch? I see one in my mailbox, but it's
not sent as a reply to this thread, making it a bit unclear.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/d39da03d/attachment.sig>
^ permalink raw reply [flat|nested] 145+ messages in thread
* Re: [PATCH 00/11] CLCD Nomadik+Versatile support
2016-02-16 13:29 ` Tomi Valkeinen
@ 2016-02-16 22:30 ` Linus Walleij
-1 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-16 22:30 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 16, 2016 at 2:29 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 16/02/16 01:34, Linus Walleij wrote:
>> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>>> Eventually I would like to have patches 1 thru 8 (those with
>>> patches to CLCD or the DT bindings) applied through the FBDEV
>>> subsystem,
>>
>> If there are no comments, would the fbdev people consider
>> patches 1 thru 8?
>
> Hmm... Is there a v2 for the 05 patch? I see one in my mailbox, but it's
> not sent as a reply to this thread, making it a bit unclear.
Yeah there is a v2, I sent that separately as I didn't have any other
patch to follow up on.
I never figured out how to use in-reply-to sorry... maybe I should
learn it :/
If you prefer I can resent the whole 1 thru 8 series, or does it work
like this too?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread
* [PATCH 00/11] CLCD Nomadik+Versatile support
@ 2016-02-16 22:30 ` Linus Walleij
0 siblings, 0 replies; 145+ messages in thread
From: Linus Walleij @ 2016-02-16 22:30 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 16, 2016 at 2:29 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 16/02/16 01:34, Linus Walleij wrote:
>> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>>> Eventually I would like to have patches 1 thru 8 (those with
>>> patches to CLCD or the DT bindings) applied through the FBDEV
>>> subsystem,
>>
>> If there are no comments, would the fbdev people consider
>> patches 1 thru 8?
>
> Hmm... Is there a v2 for the 05 patch? I see one in my mailbox, but it's
> not sent as a reply to this thread, making it a bit unclear.
Yeah there is a v2, I sent that separately as I didn't have any other
patch to follow up on.
I never figured out how to use in-reply-to sorry... maybe I should
learn it :/
If you prefer I can resent the whole 1 thru 8 series, or does it work
like this too?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 145+ messages in thread