* [PATCH 10/26] OMAPDSS: add of helpers
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
In-Reply-To: <1386160133-24026-1-git-send-email-tomi.valkeinen@ti.com>
Add helpers to get ports and endpoints from DT data.
While all the functions in dss-of.c might be useful for panel drivers if
they need to parse full port/endpoint data, at the moment we only need a
few of them outside dss-of.c, so only those functions are exported.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/Makefile | 2 +-
drivers/video/omap2/dss/dss-of.c | 160 +++++++++++++++++++++++++++++++++++++++
include/video/omapdss.h | 6 ++
3 files changed, 167 insertions(+), 1 deletion(-)
create mode 100644 drivers/video/omap2/dss/dss-of.c
diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index d3aa91bdd6a8..8aec8bda27cc 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -1,7 +1,7 @@
obj-$(CONFIG_OMAP2_DSS) += omapdss.o
# Core DSS files
omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
- output.o
+ output.o dss-of.o
# DSS compat layer files
omapdss-y += manager.o manager-sysfs.o overlay.o overlay-sysfs.o apply.o \
dispc-compat.o display-sysfs.o
diff --git a/drivers/video/omap2/dss/dss-of.c b/drivers/video/omap2/dss/dss-of.c
new file mode 100644
index 000000000000..9aa61d4bdb3d
--- /dev/null
+++ b/drivers/video/omap2/dss/dss-of.c
@@ -0,0 +1,160 @@
+/*
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/seq_file.h>
+
+#include <video/omapdss.h>
+
+#include "dss.h"
+#include "dss_features.h"
+
+static struct device_node *
+omapdss_of_get_next_port(const struct device_node *parent,
+ struct device_node *prev)
+{
+ struct device_node *port = NULL;
+
+ if (!parent)
+ return NULL;
+
+ if (!prev) {
+ struct device_node *ports;
+ /*
+ * It's the first call, we have to find a port subnode
+ * within this node or within an optional 'ports' node.
+ */
+ ports = of_get_child_by_name(parent, "ports");
+ if (ports)
+ parent = ports;
+
+ port = of_get_child_by_name(parent, "port");
+
+ /* release the 'ports' node */
+ of_node_put(ports);
+ } else {
+ struct device_node *ports;
+
+ ports = of_get_parent(prev);
+ if (!ports)
+ return NULL;
+
+ do {
+ port = of_get_next_child(ports, prev);
+ if (!port) {
+ of_node_put(ports);
+ return NULL;
+ }
+ prev = port;
+ } while (of_node_cmp(port->name, "port") != 0);
+ }
+
+ return port;
+}
+
+static struct device_node *
+omapdss_of_get_next_endpoint(const struct device_node *parent,
+ struct device_node *prev)
+{
+ struct device_node *ep = NULL;
+
+ if (!parent)
+ return NULL;
+
+ do {
+ ep = of_get_next_child(parent, prev);
+ if (!ep)
+ return NULL;
+ prev = ep;
+ } while (of_node_cmp(ep->name, "endpoint") != 0);
+
+ return ep;
+}
+
+static struct device_node *
+omapdss_of_get_remote_device_node(const struct device_node *node)
+{
+ struct device_node *np;
+ int i;
+
+ np = of_parse_phandle(node, "remote-endpoint", 0);
+
+ if (!np)
+ return NULL;
+
+ np = of_get_next_parent(np);
+
+ for (i = 0; i < 3 && np; ++i) {
+ struct property *prop;
+
+ prop = of_find_property(np, "compatible", NULL);
+
+ if (prop)
+ return np;
+
+ np = of_get_next_parent(np);
+ }
+
+ return NULL;
+}
+
+struct device_node *
+omapdss_of_get_first_endpoint(const struct device_node *parent)
+{
+ struct device_node *port;
+ struct device_node *ep;
+
+ port = omapdss_of_get_next_port(parent, NULL);
+ if (port) {
+ ep = omapdss_of_get_next_endpoint(port, NULL);
+ of_node_put(port);
+ } else {
+ ep = omapdss_of_get_next_endpoint(parent, NULL);
+ }
+
+ return ep;
+}
+EXPORT_SYMBOL_GPL(omapdss_of_get_first_endpoint);
+
+struct omap_dss_device *
+omapdss_of_find_source_for_first_ep(struct device_node *node)
+{
+ struct device_node *ep;
+ struct device_node *src_node;
+ struct omap_dss_device *src;
+
+ ep = omapdss_of_get_first_endpoint(node);
+ if (!ep)
+ return ERR_PTR(-EINVAL);
+
+ src_node = omapdss_of_get_remote_device_node(ep);
+
+ of_node_put(ep);
+
+ if (!src_node)
+ return ERR_PTR(-EINVAL);
+
+ src = omap_dss_find_output_by_node(src_node);
+
+ of_node_put(src_node);
+
+ if (!src)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ return src;
+}
+EXPORT_SYMBOL_GPL(omapdss_of_find_source_for_first_ep);
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 3d7c51a6f9ff..c510591df1b8 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -1019,4 +1019,10 @@ static inline bool omapdss_device_is_enabled(struct omap_dss_device *dssdev)
return dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
}
+struct device_node *
+omapdss_of_get_first_endpoint(const struct device_node *parent);
+
+struct omap_dss_device *
+omapdss_of_find_source_for_first_ep(struct device_node *node);
+
#endif
--
1.8.3.2
^ permalink raw reply related
* [PATCH 09/26] OMAPFB: search for default display with DT alias
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
In-Reply-To: <1386160133-24026-1-git-send-email-tomi.valkeinen@ti.com>
Improve the search for the default display in two ways:
* compare the given display name to the display's alias
* if no display name is given, look for "display0" DT alias
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 8bfe973e55ec..961c5c251f63 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2413,7 +2413,10 @@ omapfb_find_default_display(struct omapfb2_device *fbdev)
const char *def_name;
int i;
- /* search with the display name from the user or the board file */
+ /*
+ * Search with the display name from the user or the board file,
+ * comparing to display names and aliases
+ */
def_name = omapdss_get_default_display_name();
@@ -2425,12 +2428,30 @@ omapfb_find_default_display(struct omapfb2_device *fbdev)
if (dssdev->name && strcmp(def_name, dssdev->name) = 0)
return dssdev;
+
+ if (strcmp(def_name, dssdev->alias) = 0)
+ return dssdev;
}
/* def_name given but not found */
return NULL;
}
+ /* then look for DT alias display0 */
+ for (i = 0; i < fbdev->num_displays; ++i) {
+ struct omap_dss_device *dssdev;
+ int id;
+
+ dssdev = fbdev->displays[i].dssdev;
+
+ if (dssdev->dev->of_node = NULL)
+ continue;
+
+ id = of_alias_get_id(dssdev->dev->of_node, "display");
+ if (id = 0)
+ return dssdev;
+ }
+
/* return the first display we have in the list */
return fbdev->displays[0].dssdev;
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 08/26] OMAPFB: clean up default display search
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
In-Reply-To: <1386160133-24026-1-git-send-email-tomi.valkeinen@ti.com>
Separate the code for finding the default display into a function for
clarity and to make it easier to extend it in the future.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 46 ++++++++++++++++++++------------
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 27d6905683f3..8bfe973e55ec 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2407,6 +2407,34 @@ static int omapfb_init_connections(struct omapfb2_device *fbdev,
return 0;
}
+static struct omap_dss_device *
+omapfb_find_default_display(struct omapfb2_device *fbdev)
+{
+ const char *def_name;
+ int i;
+
+ /* search with the display name from the user or the board file */
+
+ def_name = omapdss_get_default_display_name();
+
+ if (def_name) {
+ for (i = 0; i < fbdev->num_displays; ++i) {
+ struct omap_dss_device *dssdev;
+
+ dssdev = fbdev->displays[i].dssdev;
+
+ if (dssdev->name && strcmp(def_name, dssdev->name) = 0)
+ return dssdev;
+ }
+
+ /* def_name given but not found */
+ return NULL;
+ }
+
+ /* return the first display we have in the list */
+ return fbdev->displays[0].dssdev;
+}
+
static int omapfb_probe(struct platform_device *pdev)
{
struct omapfb2_device *fbdev = NULL;
@@ -2484,23 +2512,7 @@ static int omapfb_probe(struct platform_device *pdev)
for (i = 0; i < fbdev->num_managers; i++)
fbdev->managers[i] = omap_dss_get_overlay_manager(i);
- def_display = NULL;
-
- for (i = 0; i < fbdev->num_displays; ++i) {
- struct omap_dss_device *dssdev;
- const char *def_name;
-
- def_name = omapdss_get_default_display_name();
-
- dssdev = fbdev->displays[i].dssdev;
-
- if (def_name = NULL ||
- (dssdev->name && strcmp(def_name, dssdev->name) = 0)) {
- def_display = dssdev;
- break;
- }
- }
-
+ def_display = omapfb_find_default_display(fbdev);
if (def_display = NULL) {
dev_err(fbdev->dev, "failed to find default display\n");
r = -EPROBE_DEFER;
--
1.8.3.2
^ permalink raw reply related
* [PATCH 07/26] OMAPDSS: get dssdev->alias from DT alias
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
In-Reply-To: <1386160133-24026-1-git-send-email-tomi.valkeinen@ti.com>
We currently create a "displayX" style alias name for all displays,
using a number that is incremented for each registered display. With the
new DSS device model there is no clear order in which the displays are
registered, and thus the numbering is somewhat random.
This patch improves the behavior for DT case so that if the displays
have been assigned DT aliases, those aliases will be used as DSS
aliases.
This means that "display0" is always the one specified in the DT alias,
and thus display0 can be used as default display in case the user didn't
specify a default display.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/display.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c
index a946cf7ed00f..2f689a5fc45b 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -26,6 +26,7 @@
#include <linux/module.h>
#include <linux/jiffies.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
#include <video/omapdss.h>
#include "dss.h"
@@ -133,9 +134,24 @@ static int disp_num_counter;
int omapdss_register_display(struct omap_dss_device *dssdev)
{
struct omap_dss_driver *drv = dssdev->driver;
+ int id;
- snprintf(dssdev->alias, sizeof(dssdev->alias),
- "display%d", disp_num_counter++);
+ /*
+ * Note: this presumes all the displays are either using DT or non-DT,
+ * which normally should be the case. This also presumes that all
+ * displays either have an DT alias, or none has.
+ */
+
+ if (dssdev->dev->of_node) {
+ id = of_alias_get_id(dssdev->dev->of_node, "display");
+
+ if (id < 0)
+ id = disp_num_counter++;
+ } else {
+ id = disp_num_counter++;
+ }
+
+ snprintf(dssdev->alias, sizeof(dssdev->alias), "display%d", id);
if (dssdev->name = NULL)
dssdev->name = dssdev->alias;
--
1.8.3.2
^ permalink raw reply related
* [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
In-Reply-To: <1386160133-24026-1-git-send-email-tomi.valkeinen@ti.com>
To avoid the need for a "nickname" property for each display, change
the display registration so that the display's alias (i.e. "display0"
etc) will be used for the dssdev->name if the display driver didn't
provide a name.
This means that when booting with board files, we will have more
descriptive names for displays, like "lcd1", "hdmi". With DT we'll only
have "display0", etc. But as there are no "nicknames" for things like
serials ports either, I hope we will do fine with this approach.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c
index 669a81fdf58e..a946cf7ed00f 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -137,6 +137,9 @@ int omapdss_register_display(struct omap_dss_device *dssdev)
snprintf(dssdev->alias, sizeof(dssdev->alias),
"display%d", disp_num_counter++);
+ if (dssdev->name = NULL)
+ dssdev->name = dssdev->alias;
+
if (drv && drv->get_resolution = NULL)
drv->get_resolution = omapdss_default_get_resolution;
if (drv && drv->get_recommended_bpp = NULL)
--
1.8.3.2
^ permalink raw reply related
* [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
In-Reply-To: <1386160133-24026-1-git-send-email-tomi.valkeinen@ti.com>
omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-generic.c | 2 ++
arch/arm/mach-omap2/common.h | 2 ++
arch/arm/mach-omap2/display.c | 62 +++++++++++++++++++++++++++++++++++++
3 files changed, 66 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 19f1652e94cf..0e06771d7bee 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -36,6 +36,8 @@ static struct of_device_id omap_dt_match_table[] __initdata = {
static void __init omap_generic_init(void)
{
pdata_quirks_init(omap_dt_match_table);
+
+ omapdss_init_of();
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index f7644febee81..48e9cd34cae0 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -308,5 +308,7 @@ extern int omap_dss_reset(struct omap_hwmod *);
/* SoC specific clock initializer */
extern int (*omap_clk_init)(void);
+int __init omapdss_init_of(void);
+
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index a4e536b11ec9..3279afc5f0b5 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -23,6 +23,8 @@
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
#include <video/omapdss.h>
#include "omap_hwmod.h"
@@ -592,3 +594,63 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
+
+int __init omapdss_init_of(void)
+{
+ int r;
+ enum omapdss_version ver;
+
+ static struct omap_dss_board_info board_data = {
+ .dsi_enable_pads = omap_dsi_enable_pads,
+ .dsi_disable_pads = omap_dsi_disable_pads,
+ .get_context_loss_count = omap_pm_get_dev_context_loss_count,
+ .set_min_bus_tput = omap_dss_set_min_bus_tput,
+ };
+
+ ver = omap_display_get_version();
+
+ if (ver = OMAPDSS_VER_UNKNOWN) {
+ pr_err("DSS not supported on this SoC\n");
+ return -ENODEV;
+ }
+
+ board_data.version = ver;
+
+ omap_display_device.dev.platform_data = &board_data;
+
+ r = platform_device_register(&omap_display_device);
+ if (r < 0) {
+ pr_err("Unable to register omapdss device\n");
+ return r;
+ }
+
+ /* create DRM device */
+ r = omap_init_drm();
+ if (r < 0) {
+ pr_err("Unable to register omapdrm device\n");
+ return r;
+ }
+
+ /* create vrfb device */
+ r = omap_init_vrfb();
+ if (r < 0) {
+ pr_err("Unable to register omapvrfb device\n");
+ return r;
+ }
+
+ /* create FB device */
+ r = omap_init_fb();
+ if (r < 0) {
+ pr_err("Unable to register omapfb device\n");
+ return r;
+ }
+
+ /* create V4L2 display device */
+ r = omap_init_vout();
+ if (r < 0) {
+ pr_err("Unable to register omap_vout device\n");
+ return r;
+ }
+
+ return 0;
+}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 04/26] OMAPDSS: remove DT hacks for regulators
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
In-Reply-To: <1386160133-24026-1-git-send-email-tomi.valkeinen@ti.com>
For booting Panda and 4430SDP with DT, while DSS did not support DT, we
had to had small hacks in the omapdss driver to get the regulators. With
DT now supported in DSS, we can remove those hacks.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 5 -----
drivers/video/omap2/dss/hdmi4.c | 4 ----
2 files changed, 9 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 1cd3e47fd43f..18b5e84165bb 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1124,11 +1124,6 @@ static int dsi_regulator_init(struct platform_device *dsidev)
return 0;
vdds_dsi = devm_regulator_get(&dsi->pdev->dev, "vdds_dsi");
-
- /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
- if (IS_ERR(vdds_dsi))
- vdds_dsi = devm_regulator_get(&dsi->pdev->dev, "VCXIO");
-
if (IS_ERR(vdds_dsi)) {
DSSERR("can't get VDDS_DSI regulator\n");
return PTR_ERR(vdds_dsi);
diff --git a/drivers/video/omap2/dss/hdmi4.c b/drivers/video/omap2/dss/hdmi4.c
index e14009614338..16e598787522 100644
--- a/drivers/video/omap2/dss/hdmi4.c
+++ b/drivers/video/omap2/dss/hdmi4.c
@@ -90,10 +90,6 @@ static int hdmi_init_regulator(void)
reg = devm_regulator_get(&hdmi.pdev->dev, "vdda_hdmi_dac");
- /* DT HACK: try VDAC to make omapdss work for o4 sdp/panda */
- if (IS_ERR(reg))
- reg = devm_regulator_get(&hdmi.pdev->dev, "VDAC");
-
if (IS_ERR(reg)) {
DSSERR("can't get VDDA_HDMI_DAC regulator\n");
return PTR_ERR(reg);
--
1.8.3.2
^ permalink raw reply related
* [PATCH 03/26] ARM: OMAP: remove DSS DT hack
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
In-Reply-To: <1386160133-24026-1-git-send-email-tomi.valkeinen@ti.com>
As a temporary solution to enable DSS for selected boards when booting
with DT, a hack was added to board-generic.c in
63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable
DSS for panda & sdp boards).
We're now adding proper DT support, so the hack can be removed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/dss-common.c | 259 -------------------------------------
arch/arm/mach-omap2/dss-common.h | 13 --
arch/arm/mach-omap2/pdata-quirks.c | 4 -
4 files changed, 1 insertion(+), 277 deletions(-)
delete mode 100644 arch/arm/mach-omap2/dss-common.c
delete mode 100644 arch/arm/mach-omap2/dss-common.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 1f25f3e99c05..5b6456d1d266 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -296,4 +296,4 @@ endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
-obj-y += common-board-devices.o twl-common.o dss-common.o
+obj-y += common-board-devices.o twl-common.o
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
deleted file mode 100644
index 365bfd3d9c68..000000000000
--- a/arch/arm/mach-omap2/dss-common.c
+++ /dev/null
@@ -1,259 +0,0 @@
-/*
- * Copyright (C) 2012 Texas Instruments, Inc..
- * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-/*
- * NOTE: this is a transitional file to help with DT adaptation.
- * This file will be removed when DSS supports DT.
- */
-
-#include <linux/kernel.h>
-#include <linux/gpio.h>
-#include <linux/platform_device.h>
-
-#include <video/omapdss.h>
-#include <video/omap-panel-data.h>
-
-#include "soc.h"
-#include "dss-common.h"
-#include "mux.h"
-
-#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
-#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
-#define HDMI_GPIO_HPD 63 /* Hotplug detect */
-
-#define PANDA_DVI_TFP410_POWER_DOWN_GPIO 0
-
-/* DVI Connector */
-static struct connector_dvi_platform_data omap4_panda_dvi_connector_pdata = {
- .name = "dvi",
- .source = "tfp410.0",
- .i2c_bus_num = 2,
-};
-
-static struct platform_device omap4_panda_dvi_connector_device = {
- .name = "connector-dvi",
- .id = 0,
- .dev.platform_data = &omap4_panda_dvi_connector_pdata,
-};
-
-/* TFP410 DPI-to-DVI chip */
-static struct encoder_tfp410_platform_data omap4_panda_tfp410_pdata = {
- .name = "tfp410.0",
- .source = "dpi.0",
- .data_lines = 24,
- .power_down_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
-};
-
-static struct platform_device omap4_panda_tfp410_device = {
- .name = "tfp410",
- .id = 0,
- .dev.platform_data = &omap4_panda_tfp410_pdata,
-};
-
-/* HDMI Connector */
-static struct connector_hdmi_platform_data omap4_panda_hdmi_connector_pdata = {
- .name = "hdmi",
- .source = "tpd12s015.0",
-};
-
-static struct platform_device omap4_panda_hdmi_connector_device = {
- .name = "connector-hdmi",
- .id = 0,
- .dev.platform_data = &omap4_panda_hdmi_connector_pdata,
-};
-
-/* TPD12S015 HDMI ESD protection & level shifter chip */
-static struct encoder_tpd12s015_platform_data omap4_panda_tpd_pdata = {
- .name = "tpd12s015.0",
- .source = "hdmi.0",
-
- .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
- .ls_oe_gpio = HDMI_GPIO_LS_OE,
- .hpd_gpio = HDMI_GPIO_HPD,
-};
-
-static struct platform_device omap4_panda_tpd_device = {
- .name = "tpd12s015",
- .id = 0,
- .dev.platform_data = &omap4_panda_tpd_pdata,
-};
-
-static struct omap_dss_board_info omap4_panda_dss_data = {
- .default_display_name = "dvi",
-};
-
-void __init omap4_panda_display_init_of(void)
-{
- omap_display_init(&omap4_panda_dss_data);
-
- platform_device_register(&omap4_panda_tfp410_device);
- platform_device_register(&omap4_panda_dvi_connector_device);
-
- platform_device_register(&omap4_panda_tpd_device);
- platform_device_register(&omap4_panda_hdmi_connector_device);
-}
-
-
-/* OMAP4 Blaze display data */
-
-#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
-#define DLP_POWER_ON_GPIO 40
-
-static struct panel_dsicm_platform_data dsi1_panel = {
- .name = "lcd",
- .source = "dsi.0",
- .reset_gpio = 102,
- .use_ext_te = false,
- .ext_te_gpio = 101,
- .pin_config = {
- .num_pins = 6,
- .pins = { 0, 1, 2, 3, 4, 5 },
- },
-};
-
-static struct platform_device sdp4430_lcd_device = {
- .name = "panel-dsi-cm",
- .id = 0,
- .dev.platform_data = &dsi1_panel,
-};
-
-static struct panel_dsicm_platform_data dsi2_panel = {
- .name = "lcd2",
- .source = "dsi.1",
- .reset_gpio = 104,
- .use_ext_te = false,
- .ext_te_gpio = 103,
- .pin_config = {
- .num_pins = 6,
- .pins = { 0, 1, 2, 3, 4, 5 },
- },
-};
-
-static struct platform_device sdp4430_lcd2_device = {
- .name = "panel-dsi-cm",
- .id = 1,
- .dev.platform_data = &dsi2_panel,
-};
-
-/* HDMI Connector */
-static struct connector_hdmi_platform_data sdp4430_hdmi_connector_pdata = {
- .name = "hdmi",
- .source = "tpd12s015.0",
-};
-
-static struct platform_device sdp4430_hdmi_connector_device = {
- .name = "connector-hdmi",
- .id = 0,
- .dev.platform_data = &sdp4430_hdmi_connector_pdata,
-};
-
-/* TPD12S015 HDMI ESD protection & level shifter chip */
-static struct encoder_tpd12s015_platform_data sdp4430_tpd_pdata = {
- .name = "tpd12s015.0",
- .source = "hdmi.0",
-
- .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
- .ls_oe_gpio = HDMI_GPIO_LS_OE,
- .hpd_gpio = HDMI_GPIO_HPD,
-};
-
-static struct platform_device sdp4430_tpd_device = {
- .name = "tpd12s015",
- .id = 0,
- .dev.platform_data = &sdp4430_tpd_pdata,
-};
-
-
-static struct omap_dss_board_info sdp4430_dss_data = {
- .default_display_name = "lcd",
-};
-
-/*
- * we select LCD2 by default (instead of Pico DLP) by setting DISPLAY_SEL_GPIO.
- * Setting DLP_POWER_ON gpio enables the VDLP_2V5 VDLP_1V8 and VDLP_1V0 rails
- * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
- * selected by default
- */
-void __init omap_4430sdp_display_init_of(void)
-{
- int r;
-
- r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
- "display_sel");
- if (r)
- pr_err("%s: Could not get display_sel GPIO\n", __func__);
-
- r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
- "DLP POWER ON");
- if (r)
- pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
-
- omap_display_init(&sdp4430_dss_data);
-
- platform_device_register(&sdp4430_lcd_device);
- platform_device_register(&sdp4430_lcd2_device);
-
- platform_device_register(&sdp4430_tpd_device);
- platform_device_register(&sdp4430_hdmi_connector_device);
-}
-
-
-/* OMAP3 IGEPv2 data */
-
-#define IGEP2_DVI_TFP410_POWER_DOWN_GPIO 170
-
-/* DVI Connector */
-static struct connector_dvi_platform_data omap3_igep2_dvi_connector_pdata = {
- .name = "dvi",
- .source = "tfp410.0",
- .i2c_bus_num = 3,
-};
-
-static struct platform_device omap3_igep2_dvi_connector_device = {
- .name = "connector-dvi",
- .id = 0,
- .dev.platform_data = &omap3_igep2_dvi_connector_pdata,
-};
-
-/* TFP410 DPI-to-DVI chip */
-static struct encoder_tfp410_platform_data omap3_igep2_tfp410_pdata = {
- .name = "tfp410.0",
- .source = "dpi.0",
- .data_lines = 24,
- .power_down_gpio = IGEP2_DVI_TFP410_POWER_DOWN_GPIO,
-};
-
-static struct platform_device omap3_igep2_tfp410_device = {
- .name = "tfp410",
- .id = 0,
- .dev.platform_data = &omap3_igep2_tfp410_pdata,
-};
-
-static struct omap_dss_board_info igep2_dss_data = {
- .default_display_name = "dvi",
-};
-
-void __init omap3_igep2_display_init_of(void)
-{
- omap_display_init(&igep2_dss_data);
-
- platform_device_register(&omap3_igep2_tfp410_device);
- platform_device_register(&omap3_igep2_dvi_connector_device);
-}
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
deleted file mode 100644
index a9becf0d5be8..000000000000
--- a/arch/arm/mach-omap2/dss-common.h
+++ /dev/null
@@ -1,13 +0,0 @@
-#ifndef __OMAP_DSS_COMMON__
-#define __OMAP_DSS_COMMON__
-
-/*
- * NOTE: this is a transitional file to help with DT adaptation.
- * This file will be removed when DSS supports DT.
- */
-
-void __init omap4_panda_display_init_of(void);
-void __init omap_4430sdp_display_init_of(void);
-void __init omap3_igep2_display_init_of(void);
-
-#endif
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 10c71450cf63..ff5b48eca778 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -18,7 +18,6 @@
#include "common.h"
#include "common-board-devices.h"
-#include "dss-common.h"
#include "control.h"
struct pdata_init {
@@ -80,7 +79,6 @@ static void __init hsmmc2_internal_input_clk(void)
static void __init omap3_igep0020_legacy_init(void)
{
- omap3_igep2_display_init_of();
}
static void __init omap3_evm_legacy_init(void)
@@ -97,14 +95,12 @@ static void __init omap3_zoom_legacy_init(void)
#ifdef CONFIG_ARCH_OMAP4
static void __init omap4_sdp_legacy_init(void)
{
- omap_4430sdp_display_init_of();
legacy_init_wl12xx(WL12XX_REFCLOCK_26,
WL12XX_TCXOCLOCK_26, 53);
}
static void __init omap4_panda_legacy_init(void)
{
- omap4_panda_display_init_of();
legacy_init_ehci_clk("auxclk3_ck");
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 02/26] OMAPDSS: DSI: fix fifosize
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
In-Reply-To: <1386160133-24026-1-git-send-email-tomi.valkeinen@ti.com>
DSI has separate TX and RX fifos. However, the current code only has one
field where the fifo size is stored, and the code for both TX and RX
config write to the same field. This has not caused issues, as we've
been using the same fifo sizes.
Fix this bug by creating separate fields for TX and RX fifo sizes.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 6056b27cf73c..1cd3e47fd43f 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -297,7 +297,8 @@ struct dsi_data {
struct {
enum dsi_vc_source source;
struct omap_dss_device *dssdev;
- enum fifo_size fifo_size;
+ enum fifo_size tx_fifo_size;
+ enum fifo_size rx_fifo_size;
int vc_id;
} vc[4];
@@ -2427,14 +2428,14 @@ static void dsi_config_tx_fifo(struct platform_device *dsidev,
int add = 0;
int i;
- dsi->vc[0].fifo_size = size1;
- dsi->vc[1].fifo_size = size2;
- dsi->vc[2].fifo_size = size3;
- dsi->vc[3].fifo_size = size4;
+ dsi->vc[0].tx_fifo_size = size1;
+ dsi->vc[1].tx_fifo_size = size2;
+ dsi->vc[2].tx_fifo_size = size3;
+ dsi->vc[3].tx_fifo_size = size4;
for (i = 0; i < 4; i++) {
u8 v;
- int size = dsi->vc[i].fifo_size;
+ int size = dsi->vc[i].tx_fifo_size;
if (add + size > 4) {
DSSERR("Illegal FIFO configuration\n");
@@ -2460,14 +2461,14 @@ static void dsi_config_rx_fifo(struct platform_device *dsidev,
int add = 0;
int i;
- dsi->vc[0].fifo_size = size1;
- dsi->vc[1].fifo_size = size2;
- dsi->vc[2].fifo_size = size3;
- dsi->vc[3].fifo_size = size4;
+ dsi->vc[0].rx_fifo_size = size1;
+ dsi->vc[1].rx_fifo_size = size2;
+ dsi->vc[2].rx_fifo_size = size3;
+ dsi->vc[3].rx_fifo_size = size4;
for (i = 0; i < 4; i++) {
u8 v;
- int size = dsi->vc[i].fifo_size;
+ int size = dsi->vc[i].rx_fifo_size;
if (add + size > 4) {
DSSERR("Illegal FIFO configuration\n");
@@ -2920,7 +2921,7 @@ static int dsi_vc_send_long(struct platform_device *dsidev, int channel,
DSSDBG("dsi_vc_send_long, %d bytes\n", len);
/* len + header */
- if (dsi->vc[channel].fifo_size * 32 * 4 < len + 4) {
+ if (dsi->vc[channel].tx_fifo_size * 32 * 4 < len + 4) {
DSSERR("unable to send long packet: packet too long.\n");
return -EINVAL;
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 01/26] OMAPDSS: rename display-sysfs 'name' entry
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
In-Reply-To: <1386160133-24026-1-git-send-email-tomi.valkeinen@ti.com>
omapdss in compat mode creates some sysfs files into the device's sysfs
directory, including a 'name' file. This works fine for
platform_devices, but breaks with i2c or spi devices, as those already
have a 'name' file.
Fix this by renaming the omapdss's 'name' file to 'display_name'.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/display-sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/display-sysfs.c b/drivers/video/omap2/dss/display-sysfs.c
index 21d7f77df702..f7b5f9561041 100644
--- a/drivers/video/omap2/dss/display-sysfs.c
+++ b/drivers/video/omap2/dss/display-sysfs.c
@@ -277,7 +277,7 @@ static ssize_t display_wss_store(struct device *dev,
return size;
}
-static DEVICE_ATTR(name, S_IRUGO, display_name_show, NULL);
+static DEVICE_ATTR(display_name, S_IRUGO, display_name_show, NULL);
static DEVICE_ATTR(enabled, S_IRUGO|S_IWUSR,
display_enabled_show, display_enabled_store);
static DEVICE_ATTR(tear_elim, S_IRUGO|S_IWUSR,
@@ -292,7 +292,7 @@ static DEVICE_ATTR(wss, S_IRUGO|S_IWUSR,
display_wss_show, display_wss_store);
static const struct attribute *display_sysfs_attrs[] = {
- &dev_attr_name.attr,
+ &dev_attr_display_name.attr,
&dev_attr_enabled.attr,
&dev_attr_tear_elim.attr,
&dev_attr_timings.attr,
--
1.8.3.2
^ permalink raw reply related
* [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen,
Laurent Pinchart, Stefan Roese, Sebastian Reichel, Robert Nelson,
Dr . H . Nikolaus Schaller, Marek Belisko
Hi,
Here's a new version for DT support to OMAP Display Subsystem. See
http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the
previous version, which contains thoughts about the related problems.
The major change in this version is the use of V4L2 and CDF style port/endpoint
style in the DT data. However, note that even if the DT data contains proper
port & endpoint data, the drivers only use the first endpoint. This is to
simplify the patches, as adding full support for the ports and endpoints to the
drivers will be a big task. This approach still works with more or less all the
boards, as the only cases where the simpler model is an issue are the boards
with multiple display devices connected to a single output.
Laurent, I'd appreciate if you could have a look at the .dts changes, to see if
there's anything that's clearly not CDF compatible.
The patches can also be found from:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
A few notes:
- The DT data are added separately in the end of .dts files for clarity. In the
final version I will move them to appropriate places in the .dts files.
- No binding documentation. I will add them for the next version, if there are
no major changes needed. Hopefully the bindings are quite self-explanatory
for people with understanding of the hardware in question.
- The connectors' compatible strings are "ti,xxx". As there's nothing TI
specific there, I think I will rename them to be without "ti".
Tomi
Tomi Valkeinen (26):
OMAPDSS: rename display-sysfs 'name' entry
OMAPDSS: DSI: fix fifosize
ARM: OMAP: remove DSS DT hack
OMAPDSS: remove DT hacks for regulators
ARM: OMAP2+: add omapdss_init_of()
OMAPDSS: if dssdev->name=NULL, use alias
OMAPDSS: get dssdev->alias from DT alias
OMAPFB: clean up default display search
OMAPFB: search for default display with DT alias
OMAPDSS: add of helpers
OMAPDSS: Add DT support to DSS, DISPC, DPI, HDMI, VENC
OMAPDSS: Add DT support to DSI
ARM: omap3.dtsi: add omapdss information
ARM: omap4.dtsi: add omapdss information
ARM: omap4-panda.dts: add display information
ARM: omap4-sdp.dts: add display information
ARM: omap3-tobi.dts: add lcd (TEST)
ARM: omap3-beagle.dts: add display information
ARM: omap3-beagle-xm.dts: add display information
OMAPDSS: panel-dsi-cm: Add DT support
OMAPDSS: encoder-tfp410: Add DT support
OMAPDSS: connector-dvi: Add DT support
OMAPDSS: encoder-tpd12s015: Add DT support
OMAPDSS: hdmi-connector: Add DT support
OMAPDSS: panel-dpi: Add DT support
OMAPDSS: connector-analog-tv: Add DT support
arch/arm/boot/dts/omap3-beagle-xm.dts | 67 ++++++
arch/arm/boot/dts/omap3-beagle.dts | 67 ++++++
arch/arm/boot/dts/omap3-tobi.dts | 40 ++++
arch/arm/boot/dts/omap3.dtsi | 43 ++++
arch/arm/boot/dts/omap4-panda-common.dtsi | 102 ++++++++
arch/arm/boot/dts/omap4-sdp.dts | 91 ++++++++
arch/arm/boot/dts/omap4.dtsi | 58 +++++
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/board-generic.c | 2 +
arch/arm/mach-omap2/common.h | 2 +
arch/arm/mach-omap2/display.c | 62 +++++
arch/arm/mach-omap2/dss-common.c | 259 ---------------------
arch/arm/mach-omap2/dss-common.h | 13 --
arch/arm/mach-omap2/pdata-quirks.c | 4 -
.../video/omap2/displays-new/connector-analog-tv.c | 66 +++++-
drivers/video/omap2/displays-new/connector-dvi.c | 43 ++++
drivers/video/omap2/displays-new/connector-hdmi.c | 30 +++
drivers/video/omap2/displays-new/encoder-tfp410.c | 43 +++-
.../video/omap2/displays-new/encoder-tpd12s015.c | 56 +++++
drivers/video/omap2/displays-new/panel-dpi.c | 64 ++++-
drivers/video/omap2/displays-new/panel-dsi-cm.c | 65 +++++-
drivers/video/omap2/dss/Makefile | 2 +-
drivers/video/omap2/dss/dispc.c | 7 +
drivers/video/omap2/dss/display-sysfs.c | 4 +-
drivers/video/omap2/dss/display.c | 23 +-
drivers/video/omap2/dss/dpi.c | 50 ++++
drivers/video/omap2/dss/dsi.c | 166 +++++++++++--
drivers/video/omap2/dss/dss-of.c | 160 +++++++++++++
drivers/video/omap2/dss/dss.c | 10 +
drivers/video/omap2/dss/hdmi4.c | 10 +-
drivers/video/omap2/dss/venc.c | 34 +++
drivers/video/omap2/omapfb/omapfb-main.c | 67 ++++--
include/video/omapdss.h | 6 +
33 files changed, 1390 insertions(+), 328 deletions(-)
delete mode 100644 arch/arm/mach-omap2/dss-common.c
delete mode 100644 arch/arm/mach-omap2/dss-common.h
create mode 100644 drivers/video/omap2/dss/dss-of.c
--
1.8.3.2
^ permalink raw reply
* Re: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
From: Ian Campbell @ 2013-12-04 11:23 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Konrad Rzeszutek Wilk, xen-devel, linux-kernel, boris.ostrovsky,
david.vrabel, leosilva, ashley, peterhuewe, mail, tpmdd, tpmdd,
dmitry.torokhov, bhelgaas, plagnioj, tomi.valkeinen, tpmdd-devel,
linux-input, netdev, linux-pci, linux-fbdev
In-Reply-To: <alpine.DEB.2.02.1312041116230.7093@kaball.uk.xensource.com>
On Wed, 2013-12-04 at 11:18 +0000, Stefano Stabellini wrote:
> On Wed, 4 Dec 2013, Ian Campbell wrote:
> > On Wed, 2013-12-04 at 11:05 +0000, Stefano Stabellini wrote:
> > > On Wed, 4 Dec 2013, Ian Campbell wrote:
> > > > On Wed, 2013-12-04 at 10:51 +0000, Stefano Stabellini wrote:
> > > > > On Wed, 4 Dec 2013, Ian Campbell wrote:
> > > > > > > +bool xen_has_pv_devices(void)
> > > > > > > +{
> > > > > > > + if (!xen_domain())
> > > > > > > + return false;
> > > > > > > +
> > > > > > > + if (xen_hvm_domain()) {
> > > > > > > + /* User requested no unplug, so no PV drivers. */
> > > > > > > + if (xen_emul_unplug & XEN_UNPLUG_NEVER)
> > > > > > > + return false;
> > > > > >
> > > > > > I think you need
> > > > > > if (xen_emul_unpug & XEN_UNPLUG_UNNECESSARY)
> > > > > > return true;
> > > > > > don't you?
> > > > >
> > > > > XEN_UNPLUG_UNNECESSARY was introduced to enable the platform PCI device
> > > > > even if it didn't respond properly to the unplug protocol.
> > > > > The corresponding parameter is called "unnecessary" because if you pass
> > > > > it to the kernel you mean that it is unnecessary to unplug the emulated
> > > > > devices but you can use the pv devices anyway.
> > > > >
> > > > > So no, we shouldn't check for XEN_UNPLUG_UNNECESSARY here.
> > > >
> > > > Oh, we will eventually fall through to the return true, so it does
> > > > actually work out OK.
> > > >
> > > > I'd still be in favour of handling each option explicitly, for clarity.
> > > > Which means checking for XEN_UNPLUG_UNNECESSARY.
> > >
> > > I think is wrong to check for any xen_emul_unpug options in this function.
> > > The xen_emul_unpug options should be used to set the right value of
> > > xen_platform_pci_unplug. (See my other reply.)
> >
> > Whichever one we check we should still be checking explicitly for the
> > "unnecessary" case, for clarity if nothing else.
>
> Sure, that is OK for me.
> In that case should we check for the full list of possible options?
We probably should. That probably means an extra
xen_has_pv_{disk,nic}_devices() which is the existing one plus the
specific checks?
>
> ide-disks -- unplug primary master IDE devices
> aux-ide-disks -- unplug non-primary-master IDE devices
> nics -- unplug network devices
> all -- unplug all emulated devices (NICs and IDE disks)
> unnecessary -- unplugging emulated devices is
> unnecessary even if the host did not respond to
> the unplug protocol
> never -- do not unplug even if version check succeeds
^ permalink raw reply
* Re: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
From: Stefano Stabellini @ 2013-12-04 11:18 UTC (permalink / raw)
To: Ian Campbell
Cc: Stefano Stabellini, Konrad Rzeszutek Wilk, xen-devel,
linux-kernel, boris.ostrovsky, david.vrabel, leosilva, ashley,
peterhuewe, mail, tpmdd, tpmdd, dmitry.torokhov, bhelgaas,
plagnioj, tomi.valkeinen, tpmdd-devel, linux-input, netdev,
linux-pci, linux-fbdev
In-Reply-To: <1386155291.17466.19.camel@kazak.uk.xensource.com>
On Wed, 4 Dec 2013, Ian Campbell wrote:
> On Wed, 2013-12-04 at 11:05 +0000, Stefano Stabellini wrote:
> > On Wed, 4 Dec 2013, Ian Campbell wrote:
> > > On Wed, 2013-12-04 at 10:51 +0000, Stefano Stabellini wrote:
> > > > On Wed, 4 Dec 2013, Ian Campbell wrote:
> > > > > > +bool xen_has_pv_devices(void)
> > > > > > +{
> > > > > > + if (!xen_domain())
> > > > > > + return false;
> > > > > > +
> > > > > > + if (xen_hvm_domain()) {
> > > > > > + /* User requested no unplug, so no PV drivers. */
> > > > > > + if (xen_emul_unplug & XEN_UNPLUG_NEVER)
> > > > > > + return false;
> > > > >
> > > > > I think you need
> > > > > if (xen_emul_unpug & XEN_UNPLUG_UNNECESSARY)
> > > > > return true;
> > > > > don't you?
> > > >
> > > > XEN_UNPLUG_UNNECESSARY was introduced to enable the platform PCI device
> > > > even if it didn't respond properly to the unplug protocol.
> > > > The corresponding parameter is called "unnecessary" because if you pass
> > > > it to the kernel you mean that it is unnecessary to unplug the emulated
> > > > devices but you can use the pv devices anyway.
> > > >
> > > > So no, we shouldn't check for XEN_UNPLUG_UNNECESSARY here.
> > >
> > > Oh, we will eventually fall through to the return true, so it does
> > > actually work out OK.
> > >
> > > I'd still be in favour of handling each option explicitly, for clarity.
> > > Which means checking for XEN_UNPLUG_UNNECESSARY.
> >
> > I think is wrong to check for any xen_emul_unpug options in this function.
> > The xen_emul_unpug options should be used to set the right value of
> > xen_platform_pci_unplug. (See my other reply.)
>
> Whichever one we check we should still be checking explicitly for the
> "unnecessary" case, for clarity if nothing else.
Sure, that is OK for me.
In that case should we check for the full list of possible options?
ide-disks -- unplug primary master IDE devices
aux-ide-disks -- unplug non-primary-master IDE devices
nics -- unplug network devices
all -- unplug all emulated devices (NICs and IDE disks)
unnecessary -- unplugging emulated devices is
unnecessary even if the host did not respond to
the unplug protocol
never -- do not unplug even if version check succeeds
^ permalink raw reply
* Re: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
From: Ian Campbell @ 2013-12-04 11:08 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Konrad Rzeszutek Wilk, xen-devel, linux-kernel, boris.ostrovsky,
david.vrabel, leosilva, ashley, peterhuewe, mail, tpmdd, tpmdd,
dmitry.torokhov, bhelgaas, plagnioj, tomi.valkeinen, tpmdd-devel,
linux-input, netdev, linux-pci, linux-fbdev
In-Reply-To: <alpine.DEB.2.02.1312041104110.7093@kaball.uk.xensource.com>
On Wed, 2013-12-04 at 11:05 +0000, Stefano Stabellini wrote:
> On Wed, 4 Dec 2013, Ian Campbell wrote:
> > On Wed, 2013-12-04 at 10:51 +0000, Stefano Stabellini wrote:
> > > On Wed, 4 Dec 2013, Ian Campbell wrote:
> > > > > +bool xen_has_pv_devices(void)
> > > > > +{
> > > > > + if (!xen_domain())
> > > > > + return false;
> > > > > +
> > > > > + if (xen_hvm_domain()) {
> > > > > + /* User requested no unplug, so no PV drivers. */
> > > > > + if (xen_emul_unplug & XEN_UNPLUG_NEVER)
> > > > > + return false;
> > > >
> > > > I think you need
> > > > if (xen_emul_unpug & XEN_UNPLUG_UNNECESSARY)
> > > > return true;
> > > > don't you?
> > >
> > > XEN_UNPLUG_UNNECESSARY was introduced to enable the platform PCI device
> > > even if it didn't respond properly to the unplug protocol.
> > > The corresponding parameter is called "unnecessary" because if you pass
> > > it to the kernel you mean that it is unnecessary to unplug the emulated
> > > devices but you can use the pv devices anyway.
> > >
> > > So no, we shouldn't check for XEN_UNPLUG_UNNECESSARY here.
> >
> > Oh, we will eventually fall through to the return true, so it does
> > actually work out OK.
> >
> > I'd still be in favour of handling each option explicitly, for clarity.
> > Which means checking for XEN_UNPLUG_UNNECESSARY.
>
> I think is wrong to check for any xen_emul_unpug options in this function.
> The xen_emul_unpug options should be used to set the right value of
> xen_platform_pci_unplug. (See my other reply.)
Whichever one we check we should still be checking explicitly for the
"unnecessary" case, for clarity if nothing else.
TBH I think the split between xen_emul_unplug and
xen_platform_pci_unplug is a bit artificial. There should be one value
which is static to platform-pci-unplug.c and accessor functions should
be provided for other code to use. Open coding all those accesses to
xen_platform_pci_unplug in every driver is just too error prone.
Ian.
^ permalink raw reply
* Re: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
From: Stefano Stabellini @ 2013-12-04 11:05 UTC (permalink / raw)
To: Ian Campbell
Cc: Stefano Stabellini, Konrad Rzeszutek Wilk, xen-devel,
linux-kernel, boris.ostrovsky, david.vrabel, leosilva, ashley,
peterhuewe, mail, tpmdd, tpmdd, dmitry.torokhov, bhelgaas,
plagnioj, tomi.valkeinen, tpmdd-devel, linux-input, netdev,
linux-pci, linux-fbdev
In-Reply-To: <1386154783.17466.14.camel@kazak.uk.xensource.com>
On Wed, 4 Dec 2013, Ian Campbell wrote:
> On Wed, 2013-12-04 at 10:51 +0000, Stefano Stabellini wrote:
> > On Wed, 4 Dec 2013, Ian Campbell wrote:
> > > > +bool xen_has_pv_devices(void)
> > > > +{
> > > > + if (!xen_domain())
> > > > + return false;
> > > > +
> > > > + if (xen_hvm_domain()) {
> > > > + /* User requested no unplug, so no PV drivers. */
> > > > + if (xen_emul_unplug & XEN_UNPLUG_NEVER)
> > > > + return false;
> > >
> > > I think you need
> > > if (xen_emul_unpug & XEN_UNPLUG_UNNECESSARY)
> > > return true;
> > > don't you?
> >
> > XEN_UNPLUG_UNNECESSARY was introduced to enable the platform PCI device
> > even if it didn't respond properly to the unplug protocol.
> > The corresponding parameter is called "unnecessary" because if you pass
> > it to the kernel you mean that it is unnecessary to unplug the emulated
> > devices but you can use the pv devices anyway.
> >
> > So no, we shouldn't check for XEN_UNPLUG_UNNECESSARY here.
>
> Oh, we will eventually fall through to the return true, so it does
> actually work out OK.
>
> I'd still be in favour of handling each option explicitly, for clarity.
> Which means checking for XEN_UNPLUG_UNNECESSARY.
I think is wrong to check for any xen_emul_unpug options in this function.
The xen_emul_unpug options should be used to set the right value of
xen_platform_pci_unplug. (See my other reply.)
> > > > + /* And user has xen_platform_pci=0 set in guest config as
> > > > + * driver did not modify the value. */
> > > > + if (!xen_platform_pci_unplug)
> > > > + return false;
>
> I assume this check doesn't trigger if unnecessary has been specified?
right
^ permalink raw reply
* Re: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
From: Ian Campbell @ 2013-12-04 10:59 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Konrad Rzeszutek Wilk, xen-devel, linux-kernel, boris.ostrovsky,
david.vrabel, leosilva, ashley, peterhuewe, mail, tpmdd, tpmdd,
dmitry.torokhov, bhelgaas, plagnioj, tomi.valkeinen, tpmdd-devel,
linux-input, netdev, linux-pci, linux-fbdev
In-Reply-To: <alpine.DEB.2.02.1312041049310.7093@kaball.uk.xensource.com>
On Wed, 2013-12-04 at 10:51 +0000, Stefano Stabellini wrote:
> On Wed, 4 Dec 2013, Ian Campbell wrote:
> > > +bool xen_has_pv_devices(void)
> > > +{
> > > + if (!xen_domain())
> > > + return false;
> > > +
> > > + if (xen_hvm_domain()) {
> > > + /* User requested no unplug, so no PV drivers. */
> > > + if (xen_emul_unplug & XEN_UNPLUG_NEVER)
> > > + return false;
> >
> > I think you need
> > if (xen_emul_unpug & XEN_UNPLUG_UNNECESSARY)
> > return true;
> > don't you?
>
> XEN_UNPLUG_UNNECESSARY was introduced to enable the platform PCI device
> even if it didn't respond properly to the unplug protocol.
> The corresponding parameter is called "unnecessary" because if you pass
> it to the kernel you mean that it is unnecessary to unplug the emulated
> devices but you can use the pv devices anyway.
>
> So no, we shouldn't check for XEN_UNPLUG_UNNECESSARY here.
Oh, we will eventually fall through to the return true, so it does
actually work out OK.
I'd still be in favour of handling each option explicitly, for clarity.
Which means checking for XEN_UNPLUG_UNNECESSARY.
> > > + /* And user has xen_platform_pci=0 set in guest config as
> > > + * driver did not modify the value. */
> > > + if (!xen_platform_pci_unplug)
> > > + return false;
I assume this check doesn't trigger if unnecessary has been specified?
> > > + }
> > > + return true;
> > > +}
> > > +EXPORT_SYMBOL_GPL(xen_has_pv_devices);
> > > +
> > > void xen_unplug_emulated_devices(void)
> > > {
> > > int r;
> >
> >
^ permalink raw reply
* Re: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
From: Stefano Stabellini @ 2013-12-04 10:51 UTC (permalink / raw)
To: Ian Campbell
Cc: Konrad Rzeszutek Wilk, stefano.stabellini, xen-devel,
linux-kernel, boris.ostrovsky, david.vrabel, leosilva, ashley,
peterhuewe, mail, tpmdd, tpmdd, dmitry.torokhov, bhelgaas,
plagnioj, tomi.valkeinen, tpmdd-devel, linux-input, netdev,
linux-pci, linux-fbdev
In-Reply-To: <1386149848.13256.86.camel@kazak.uk.xensource.com>
On Wed, 4 Dec 2013, Ian Campbell wrote:
> > +bool xen_has_pv_devices(void)
> > +{
> > + if (!xen_domain())
> > + return false;
> > +
> > + if (xen_hvm_domain()) {
> > + /* User requested no unplug, so no PV drivers. */
> > + if (xen_emul_unplug & XEN_UNPLUG_NEVER)
> > + return false;
>
> I think you need
> if (xen_emul_unpug & XEN_UNPLUG_UNNECESSARY)
> return true;
> don't you?
XEN_UNPLUG_UNNECESSARY was introduced to enable the platform PCI device
even if it didn't respond properly to the unplug protocol.
The corresponding parameter is called "unnecessary" because if you pass
it to the kernel you mean that it is unnecessary to unplug the emulated
devices but you can use the pv devices anyway.
So no, we shouldn't check for XEN_UNPLUG_UNNECESSARY here.
> > + /* And user has xen_platform_pci=0 set in guest config as
> > + * driver did not modify the value. */
> > + if (!xen_platform_pci_unplug)
> > + return false;
> > + }
> > + return true;
> > +}
> > +EXPORT_SYMBOL_GPL(xen_has_pv_devices);
> > +
> > void xen_unplug_emulated_devices(void)
> > {
> > int r;
>
>
^ permalink raw reply
* Re: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
From: Stefano Stabellini @ 2013-12-04 10:48 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: stefano.stabellini, ian.campbell, xen-devel, linux-kernel,
boris.ostrovsky, david.vrabel, leosilva, ashley, peterhuewe, mail,
tpmdd, tpmdd, dmitry.torokhov, bhelgaas, plagnioj, tomi.valkeinen,
tpmdd-devel, linux-input, netdev, linux-pci, linux-fbdev
In-Reply-To: <1386105246-14337-1-git-send-email-konrad.wilk@oracle.com>
On Tue, 3 Dec 2013, Konrad Rzeszutek Wilk wrote:
> diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c
> index 0a78524..087dfeb 100644
> --- a/arch/x86/xen/platform-pci-unplug.c
> +++ b/arch/x86/xen/platform-pci-unplug.c
> @@ -69,6 +69,24 @@ static int check_platform_magic(void)
> return 0;
> }
>
> +bool xen_has_pv_devices(void)
> +{
> + if (!xen_domain())
> + return false;
> +
> + if (xen_hvm_domain()) {
> + /* User requested no unplug, so no PV drivers. */
> + if (xen_emul_unplug & XEN_UNPLUG_NEVER)
> + return false;
Considering that if (xen_emul_unplug & XEN_UNPLUG_NEVER) we never set
xen_platform_pci_unplug, this check is redundant.
> + /* And user has xen_platform_pci=0 set in guest config as
> + * driver did not modify the value. */
> + if (!xen_platform_pci_unplug)
> + return false;
> + }
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(xen_has_pv_devices);
> +
> void xen_unplug_emulated_devices(void)
> {
> int r;
^ permalink raw reply
* Re: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
From: Ian Campbell @ 2013-12-04 9:37 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: stefano.stabellini, xen-devel, linux-kernel, boris.ostrovsky,
david.vrabel, leosilva, ashley, peterhuewe, mail, tpmdd, tpmdd,
dmitry.torokhov, bhelgaas, plagnioj, tomi.valkeinen, tpmdd-devel,
linux-input, netdev, linux-pci, linux-fbdev
In-Reply-To: <1386105246-14337-1-git-send-email-konrad.wilk@oracle.com>
On Tue, 2013-12-03 at 16:14 -0500, Konrad Rzeszutek Wilk wrote:
> The user has the option of disabling the platform driver:
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
>
> which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
> and allow the PV drivers to take over. If the user wishes
> to disable that they can set:
>
> xen_platform_pci=0
> (in the guest config file)
>
> or
> xen_emul_unplug=never
> (on the Linux command line)
>
> except it does not work properly. The PV drivers still try to
> load and since the Xen platform driver is not run - and it
> has not initialized the grant tables, most of the PV drivers
> stumble upon:
>
> input: Xen Virtual Keyboard as /devices/virtual/input/input5
> input: Xen Virtual Pointer as /devices/virtual/input/input6M
> ------------[ cut here ]------------
> kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
> invalid opcode: 0000 [#1] SMP
> Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
> CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
> Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
> RIP: 0010:[<ffffffff813ddc40>] [<ffffffff813ddc40>] get_free_entries+0x2e0/0x300
> Call Trace:
> [<ffffffff8150d9a3>] ? evdev_connect+0x1e3/0x240
> [<ffffffff813ddd0e>] gnttab_grant_foreign_access+0x2e/0x70
> [<ffffffffa0010081>] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
> [<ffffffffa0010a12>] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
> [<ffffffff813e5757>] xenbus_dev_probe+0x77/0x130
> [<ffffffff813e7217>] xenbus_frontend_dev_probe+0x47/0x50
> [<ffffffff8145e9a9>] driver_probe_device+0x89/0x230
> [<ffffffff8145ebeb>] __driver_attach+0x9b/0xa0
> [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
> [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
> [<ffffffff8145cf1c>] bus_for_each_dev+0x8c/0xb0
> [<ffffffff8145e7d9>] driver_attach+0x19/0x20
> [<ffffffff8145e260>] bus_add_driver+0x1a0/0x220
> [<ffffffff8145f1ff>] driver_register+0x5f/0xf0
> [<ffffffff813e55c5>] xenbus_register_driver_common+0x15/0x20
> [<ffffffff813e76b3>] xenbus_register_frontend+0x23/0x40
> [<ffffffffa0015000>] ? 0xffffffffa0014fff
> [<ffffffffa001502b>] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
> [<ffffffff81002049>] do_one_initcall+0x49/0x170
>
> .. snip..
>
> which is hardly nice. This patch fixes this by having each
> PV driver check for:
> - if running in PV, then it is fine to execute (as that is their
> native environment).
> - if running in HVM, check if user wanted 'xen_emul_unplug=never',
> in which case bail out and don't load PV drivers.
> - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
> does not exist, then bail out and not load PV drivers.
>
> P.S.
> Ian Campbell suggested getting rid of 'xen_platform_pci_unplug'
> but unfortunatly the xen-blkfront driver is using it, so we
> cannot do it.
It might still be nice to expose a suitable semantic interface (i.e.
some relevant predicate) rather than the raw value for blkfront to use.
But that can be a future thing I think.
> Reported-by: Sander Eikelenboom <linux@eikelenboom.it
> Reported-by: Anthony PERARD <anthony.perard@citrix.com>
> Reported-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
> ---
> arch/x86/xen/platform-pci-unplug.c | 18 ++++++++++++++++++
> drivers/block/xen-blkfront.c | 2 +-
> drivers/char/tpm/xen-tpmfront.c | 4 ++++
> drivers/input/misc/xen-kbdfront.c | 4 ++++
> drivers/net/xen-netfront.c | 2 +-
> drivers/pci/xen-pcifront.c | 4 ++++
> drivers/video/xen-fbfront.c | 4 ++++
> drivers/xen/xenbus/xenbus_probe_frontend.c | 2 +-
> include/xen/platform_pci.h | 13 ++++++++++++-
> 9 files changed, 49 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c
> index 0a78524..087dfeb 100644
> --- a/arch/x86/xen/platform-pci-unplug.c
> +++ b/arch/x86/xen/platform-pci-unplug.c
> @@ -69,6 +69,24 @@ static int check_platform_magic(void)
> return 0;
> }
>
> +bool xen_has_pv_devices(void)
> +{
> + if (!xen_domain())
> + return false;
> +
> + if (xen_hvm_domain()) {
> + /* User requested no unplug, so no PV drivers. */
> + if (xen_emul_unplug & XEN_UNPLUG_NEVER)
> + return false;
I think you need
if (xen_emul_unpug & XEN_UNPLUG_UNNECESSARY)
return true;
don't you?
> + /* And user has xen_platform_pci=0 set in guest config as
> + * driver did not modify the value. */
> + if (!xen_platform_pci_unplug)
> + return false;
> + }
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(xen_has_pv_devices);
> +
> void xen_unplug_emulated_devices(void)
> {
> int r;
^ permalink raw reply
* Re: [patch] video: vt8500: fix error handling in probe()
From: Tomi Valkeinen @ 2013-12-04 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131202081118.GB3852@elgon.mountain>
[-- Attachment #1: Type: text/plain, Size: 2667 bytes --]
On 2013-12-02 10:11, Dan Carpenter wrote:
> We shouldn't kfree(fbi) because that was allocated with devm_kzalloc().
> There were several error paths which returned directly instead of
> releasing resources.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
> index b30e5a439d1f..a8f2b280f796 100644
> --- a/drivers/video/vt8500lcdfb.c
> +++ b/drivers/video/vt8500lcdfb.c
> @@ -293,8 +293,7 @@ static int vt8500lcd_probe(struct platform_device *pdev)
> + sizeof(u32) * 16, GFP_KERNEL);
> if (!fbi) {
> dev_err(&pdev->dev, "Failed to initialize framebuffer device\n");
> - ret = -ENOMEM;
> - goto failed;
> + return -ENOMEM;
> }
>
> strcpy(fbi->fb.fix.id, "VT8500 LCD");
> @@ -327,15 +326,13 @@ static int vt8500lcd_probe(struct platform_device *pdev)
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (res == NULL) {
> dev_err(&pdev->dev, "no I/O memory resource defined\n");
> - ret = -ENODEV;
> - goto failed_fbi;
> + return -ENODEV;
> }
>
> res = request_mem_region(res->start, resource_size(res), "vt8500lcd");
> if (res == NULL) {
> dev_err(&pdev->dev, "failed to request I/O memory\n");
> - ret = -EBUSY;
> - goto failed_fbi;
> + return -EBUSY;
> }
>
> fbi->regbase = ioremap(res->start, resource_size(res));
> @@ -346,17 +343,19 @@ static int vt8500lcd_probe(struct platform_device *pdev)
> }
>
> disp_timing = of_get_display_timings(pdev->dev.of_node);
> - if (!disp_timing)
> - return -EINVAL;
> + if (!disp_timing) {
> + ret = -EINVAL;
> + goto failed_free_io;
> + }
>
> ret = of_get_fb_videomode(pdev->dev.of_node, &of_mode,
> OF_USE_NATIVE_MODE);
> if (ret)
> - return ret;
> + goto failed_free_io;
>
> ret = of_property_read_u32(pdev->dev.of_node, "bits-per-pixel", &bpp);
> if (ret)
> - return ret;
> + goto failed_free_io;
>
> /* try allocating the framebuffer */
> fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
> @@ -364,7 +363,8 @@ static int vt8500lcd_probe(struct platform_device *pdev)
> GFP_KERNEL);
> if (!fb_mem_virt) {
> pr_err("%s: Failed to allocate framebuffer\n", __func__);
> - return -ENOMEM;
> + ret = -ENOMEM;
> + goto failed_free_io;
> }
>
> fbi->fb.fix.smem_start = fb_mem_phys;
> @@ -447,9 +447,6 @@ failed_free_io:
> iounmap(fbi->regbase);
> failed_free_res:
> release_mem_region(res->start, resource_size(res));
> -failed_fbi:
> - kfree(fbi);
> -failed:
> return ret;
> }
Thanks, queued for 3.13 fbdev fixes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] atmel_lcdfb: fix module autoload
From: Tomi Valkeinen @ 2013-12-04 8:49 UTC (permalink / raw)
To: Nicolas Ferre, Johan Hovold, linux-fbdev,
Jean-Christophe PLAGNIOL-VILLARD
Cc: linux-kernel
In-Reply-To: <529CD0B5.600@atmel.com>
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]
On 2013-12-02 20:25, Nicolas Ferre wrote:
> On 22/10/2013 18:36, Johan Hovold :
>> Add missing module device table which is needed for module autoloading.
>>
>> Signed-off-by: Johan Hovold <jhovold@gmail.com>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Jean-Christophe, Tomi,
>
> Can you please take this patch?
>
> Best regards,
>
>
>> ---
>> drivers/video/atmel_lcdfb.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
>> index 088511a..67b339c 100644
>> --- a/drivers/video/atmel_lcdfb.c
>> +++ b/drivers/video/atmel_lcdfb.c
>> @@ -94,6 +94,7 @@ static const struct platform_device_id
>> atmel_lcdfb_devtypes[] = {
>> /* terminator */
>> }
>> };
>> +MODULE_DEVICE_TABLE(platform, atmel_lcdfb_devtypes);
>>
>> static struct atmel_lcdfb_config *
>> atmel_lcdfb_get_config(struct platform_device *pdev)
>>
Thanks, queued for 3.13 fbdev fixes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [Xen-devel] [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
From: Matthew Daley @ 2013-12-04 0:03 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini, Ian Campbell, xen-devel, linux-kernel,
boris.ostrovsky, david.vrabel, leosilva, ashley, peterhuewe, mail,
tpmdd, tpmdd, dmitry.torokhov, bhelgaas, plagnioj, tomi.valkeinen,
tpmdd-devel, linux-input, netdev, linux-pci, linux-fbdev
In-Reply-To: <1386105246-14337-1-git-send-email-konrad.wilk@oracle.com>
On Wed, Dec 4, 2013 at 10:14 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> The user has the option of disabling the platform driver:
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
>
> which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
> and allow the PV drivers to take over. If the user wishes
> to disable that they can set:
>
> xen_platform_pci=0
> (in the guest config file)
>
> or
> xen_emul_unplug=never
> (on the Linux command line)
>
> except it does not work properly. The PV drivers still try to
> load and since the Xen platform driver is not run - and it
> has not initialized the grant tables, most of the PV drivers
> stumble upon:
>
> input: Xen Virtual Keyboard as /devices/virtual/input/input5
> input: Xen Virtual Pointer as /devices/virtual/input/input6M
> ------------[ cut here ]------------
> kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
> invalid opcode: 0000 [#1] SMP
> Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
> CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
> Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
> RIP: 0010:[<ffffffff813ddc40>] [<ffffffff813ddc40>] get_free_entries+0x2e0/0x300
> Call Trace:
> [<ffffffff8150d9a3>] ? evdev_connect+0x1e3/0x240
> [<ffffffff813ddd0e>] gnttab_grant_foreign_access+0x2e/0x70
> [<ffffffffa0010081>] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
> [<ffffffffa0010a12>] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
> [<ffffffff813e5757>] xenbus_dev_probe+0x77/0x130
> [<ffffffff813e7217>] xenbus_frontend_dev_probe+0x47/0x50
> [<ffffffff8145e9a9>] driver_probe_device+0x89/0x230
> [<ffffffff8145ebeb>] __driver_attach+0x9b/0xa0
> [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
> [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
> [<ffffffff8145cf1c>] bus_for_each_dev+0x8c/0xb0
> [<ffffffff8145e7d9>] driver_attach+0x19/0x20
> [<ffffffff8145e260>] bus_add_driver+0x1a0/0x220
> [<ffffffff8145f1ff>] driver_register+0x5f/0xf0
> [<ffffffff813e55c5>] xenbus_register_driver_common+0x15/0x20
> [<ffffffff813e76b3>] xenbus_register_frontend+0x23/0x40
> [<ffffffffa0015000>] ? 0xffffffffa0014fff
> [<ffffffffa001502b>] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
> [<ffffffff81002049>] do_one_initcall+0x49/0x170
>
> .. snip..
>
> which is hardly nice. This patch fixes this by having each
> PV driver check for:
> - if running in PV, then it is fine to execute (as that is their
> native environment).
> - if running in HVM, check if user wanted 'xen_emul_unplug=never',
> in which case bail out and don't load PV drivers.
> - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
> does not exist, then bail out and not load PV drivers.
>
> P.S.
> Ian Campbell suggested getting rid of 'xen_platform_pci_unplug'
> but unfortunatly the xen-blkfront driver is using it, so we
> cannot do it.
>
> Reported-by: Sander Eikelenboom <linux@eikelenboom.it
> Reported-by: Anthony PERARD <anthony.perard@citrix.com>
> Reported-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
I think you forgot your Signed-off-by line.
- Matthew
^ permalink raw reply
* [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
From: Konrad Rzeszutek Wilk @ 2013-12-03 21:14 UTC (permalink / raw)
To: stefano.stabellini, ian.campbell, xen-devel, linux-kernel,
boris.ostrovsky, david.vrabel, leosilva, ashley, peterhuewe, mail,
tpmdd, tpmdd, dmitry.torokhov, bhelgaas, plagnioj, tomi.valkeinen,
tpmdd-devel, linux-input, netdev, linux-pci, linux-fbdev
Cc: Konrad Rzeszutek Wilk
The user has the option of disabling the platform driver:
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
and allow the PV drivers to take over. If the user wishes
to disable that they can set:
xen_platform_pci=0
(in the guest config file)
or
xen_emul_unplug=never
(on the Linux command line)
except it does not work properly. The PV drivers still try to
load and since the Xen platform driver is not run - and it
has not initialized the grant tables, most of the PV drivers
stumble upon:
input: Xen Virtual Keyboard as /devices/virtual/input/input5
input: Xen Virtual Pointer as /devices/virtual/input/input6M
------------[ cut here ]------------
kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
invalid opcode: 0000 [#1] SMP
Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
RIP: 0010:[<ffffffff813ddc40>] [<ffffffff813ddc40>] get_free_entries+0x2e0/0x300
Call Trace:
[<ffffffff8150d9a3>] ? evdev_connect+0x1e3/0x240
[<ffffffff813ddd0e>] gnttab_grant_foreign_access+0x2e/0x70
[<ffffffffa0010081>] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
[<ffffffffa0010a12>] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
[<ffffffff813e5757>] xenbus_dev_probe+0x77/0x130
[<ffffffff813e7217>] xenbus_frontend_dev_probe+0x47/0x50
[<ffffffff8145e9a9>] driver_probe_device+0x89/0x230
[<ffffffff8145ebeb>] __driver_attach+0x9b/0xa0
[<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
[<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
[<ffffffff8145cf1c>] bus_for_each_dev+0x8c/0xb0
[<ffffffff8145e7d9>] driver_attach+0x19/0x20
[<ffffffff8145e260>] bus_add_driver+0x1a0/0x220
[<ffffffff8145f1ff>] driver_register+0x5f/0xf0
[<ffffffff813e55c5>] xenbus_register_driver_common+0x15/0x20
[<ffffffff813e76b3>] xenbus_register_frontend+0x23/0x40
[<ffffffffa0015000>] ? 0xffffffffa0014fff
[<ffffffffa001502b>] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
[<ffffffff81002049>] do_one_initcall+0x49/0x170
.. snip..
which is hardly nice. This patch fixes this by having each
PV driver check for:
- if running in PV, then it is fine to execute (as that is their
native environment).
- if running in HVM, check if user wanted 'xen_emul_unplug=never',
in which case bail out and don't load PV drivers.
- if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
does not exist, then bail out and not load PV drivers.
P.S.
Ian Campbell suggested getting rid of 'xen_platform_pci_unplug'
but unfortunatly the xen-blkfront driver is using it, so we
cannot do it.
Reported-by: Sander Eikelenboom <linux@eikelenboom.it
Reported-by: Anthony PERARD <anthony.perard@citrix.com>
Reported-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
---
arch/x86/xen/platform-pci-unplug.c | 18 ++++++++++++++++++
drivers/block/xen-blkfront.c | 2 +-
drivers/char/tpm/xen-tpmfront.c | 4 ++++
drivers/input/misc/xen-kbdfront.c | 4 ++++
drivers/net/xen-netfront.c | 2 +-
drivers/pci/xen-pcifront.c | 4 ++++
drivers/video/xen-fbfront.c | 4 ++++
drivers/xen/xenbus/xenbus_probe_frontend.c | 2 +-
include/xen/platform_pci.h | 13 ++++++++++++-
9 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c
index 0a78524..087dfeb 100644
--- a/arch/x86/xen/platform-pci-unplug.c
+++ b/arch/x86/xen/platform-pci-unplug.c
@@ -69,6 +69,24 @@ static int check_platform_magic(void)
return 0;
}
+bool xen_has_pv_devices(void)
+{
+ if (!xen_domain())
+ return false;
+
+ if (xen_hvm_domain()) {
+ /* User requested no unplug, so no PV drivers. */
+ if (xen_emul_unplug & XEN_UNPLUG_NEVER)
+ return false;
+ /* And user has xen_platform_pci=0 set in guest config as
+ * driver did not modify the value. */
+ if (!xen_platform_pci_unplug)
+ return false;
+ }
+ return true;
+}
+EXPORT_SYMBOL_GPL(xen_has_pv_devices);
+
void xen_unplug_emulated_devices(void)
{
int r;
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 432db1b..9616b81 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
if (!xen_domain())
return -ENODEV;
- if (xen_hvm_domain() && !xen_platform_pci_unplug)
+ if (!xen_has_pv_devices())
return -ENODEV;
if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
index c8ff4df..62e7d38 100644
--- a/drivers/char/tpm/xen-tpmfront.c
+++ b/drivers/char/tpm/xen-tpmfront.c
@@ -17,6 +17,7 @@
#include <xen/xenbus.h>
#include <xen/page.h>
#include "tpm.h"
+#include <xen/platform_pci.h>
struct tpm_private {
struct tpm_chip *chip;
@@ -421,6 +422,9 @@ static int __init xen_tpmfront_init(void)
if (!xen_domain())
return -ENODEV;
+ if (!xen_has_pv_devices())
+ return -ENODEV;
+
return xenbus_register_frontend(&tpmfront_driver);
}
module_init(xen_tpmfront_init);
diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index e21c181..fbfdc10 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -29,6 +29,7 @@
#include <xen/interface/io/fbif.h>
#include <xen/interface/io/kbdif.h>
#include <xen/xenbus.h>
+#include <xen/platform_pci.h>
struct xenkbd_info {
struct input_dev *kbd;
@@ -380,6 +381,9 @@ static int __init xenkbd_init(void)
if (xen_initial_domain())
return -ENODEV;
+ if (!xen_has_pv_devices())
+ return -ENODEV;
+
return xenbus_register_frontend(&xenkbd_driver);
}
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index e59acb1..d4b52e9 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -2115,7 +2115,7 @@ static int __init netif_init(void)
if (!xen_domain())
return -ENODEV;
- if (xen_hvm_domain() && !xen_platform_pci_unplug)
+ if (!xen_has_pv_devices())
return -ENODEV;
pr_info("Initialising Xen virtual ethernet driver\n");
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index f7197a7..eae7cd9 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -20,6 +20,7 @@
#include <linux/workqueue.h>
#include <linux/bitops.h>
#include <linux/time.h>
+#include <xen/platform_pci.h>
#include <asm/xen/swiotlb-xen.h>
#define INVALID_GRANT_REF (0)
@@ -1138,6 +1139,9 @@ static int __init pcifront_init(void)
if (!xen_pv_domain() || xen_initial_domain())
return -ENODEV;
+ if (!xen_has_pv_devices())
+ return -ENODEV;
+
pci_frontend_registrar(1 /* enable */);
return xenbus_register_frontend(&xenpci_driver);
diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index cd005c2..4b2d3ab 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -35,6 +35,7 @@
#include <xen/interface/io/fbif.h>
#include <xen/interface/io/protocols.h>
#include <xen/xenbus.h>
+#include <xen/platform_pci.h>
struct xenfb_info {
unsigned char *fb;
@@ -699,6 +700,9 @@ static int __init xenfb_init(void)
if (xen_initial_domain())
return -ENODEV;
+ if (!xen_has_pv_devices())
+ return -ENODEV;
+
return xenbus_register_frontend(&xenfb_driver);
}
diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
index 129bf84..cb385c1 100644
--- a/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -496,7 +496,7 @@ subsys_initcall(xenbus_probe_frontend_init);
#ifndef MODULE
static int __init boot_wait_for_devices(void)
{
- if (xen_hvm_domain() && !xen_platform_pci_unplug)
+ if (!xen_has_pv_devices())
return -ENODEV;
ready_to_wait_for_devices = 1;
diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
index 438c256..87bc59c 100644
--- a/include/xen/platform_pci.h
+++ b/include/xen/platform_pci.h
@@ -47,5 +47,16 @@ static inline int xen_must_unplug_disks(void) {
}
extern int xen_platform_pci_unplug;
-
+#if defined(CONFIG_XEN_PVHVM)
+extern bool xen_has_pv_devices(void);
+#else
+static inline bool xen_has_pv_devices(void)
+{
+#if defined(CONFIG_XEN)
+ return true;
+#else
+ return false;
+#endif
+}
+#endif
#endif /* _XEN_PLATFORM_PCI_H */
--
1.8.3.1
^ permalink raw reply related
* [PATCH 32/39] video: remove DEFINE_PCI_DEVICE_TABLE macro
From: Jingoo Han @ 2013-12-02 23:28 UTC (permalink / raw)
To: 'Greg Kroah-Hartman'
Cc: linux-kernel, 'Jingoo Han', 'Tomi Valkeinen',
linux-fbdev
In-Reply-To: <001501ceefb1$69c96820$3d5c3860$%han@samsung.com>
Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro
is not preferred.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/hyperv_fb.c | 2 +-
drivers/video/i740fb.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
index 130708f..8254ed7 100644
--- a/drivers/video/hyperv_fb.c
+++ b/drivers/video/hyperv_fb.c
@@ -800,7 +800,7 @@ static int hvfb_remove(struct hv_device *hdev)
}
-static DEFINE_PCI_DEVICE_TABLE(pci_stub_id_table) = {
+static const struct pci_device_id pci_stub_id_table[] = {
{
.vendor = PCI_VENDOR_ID_MICROSOFT,
.device = PCI_DEVICE_ID_HYPERV_VIDEO,
diff --git a/drivers/video/i740fb.c b/drivers/video/i740fb.c
index ca7c9df..a2b4204 100644
--- a/drivers/video/i740fb.c
+++ b/drivers/video/i740fb.c
@@ -1260,7 +1260,7 @@ fail:
#define I740_ID_PCI 0x00d1
#define I740_ID_AGP 0x7800
-static DEFINE_PCI_DEVICE_TABLE(i740fb_id_table) = {
+static const struct pci_device_id i740fb_id_table[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, I740_ID_PCI) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, I740_ID_AGP) },
{ 0 }
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] atmel_lcdfb: fix module autoload
From: Nicolas Ferre @ 2013-12-02 18:25 UTC (permalink / raw)
To: Johan Hovold, linux-fbdev, Jean-Christophe PLAGNIOL-VILLARD,
Tomi Valkeinen
Cc: linux-kernel
In-Reply-To: <1382459817-26990-1-git-send-email-jhovold@gmail.com>
On 22/10/2013 18:36, Johan Hovold :
> Add missing module device table which is needed for module autoloading.
>
> Signed-off-by: Johan Hovold <jhovold@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Jean-Christophe, Tomi,
Can you please take this patch?
Best regards,
> ---
> drivers/video/atmel_lcdfb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 088511a..67b339c 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -94,6 +94,7 @@ static const struct platform_device_id atmel_lcdfb_devtypes[] = {
> /* terminator */
> }
> };
> +MODULE_DEVICE_TABLE(platform, atmel_lcdfb_devtypes);
>
> static struct atmel_lcdfb_config *
> atmel_lcdfb_get_config(struct platform_device *pdev)
>
--
Nicolas Ferre
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox