* [PATCHv2 25/27] OMAPDSS: hdmi-connector: Add DT support
From: Tomi Valkeinen @ 2013-12-16 14:56 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree; +Cc: Tomi Valkeinen
In-Reply-To: <1387205794-32246-1-git-send-email-tomi.valkeinen@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays-new/connector-hdmi.c | 30 +++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/video/omap2/displays-new/connector-hdmi.c b/drivers/video/omap2/displays-new/connector-hdmi.c
index 9abe2c039ae9..12246b5841c0 100644
--- a/drivers/video/omap2/displays-new/connector-hdmi.c
+++ b/drivers/video/omap2/displays-new/connector-hdmi.c
@@ -12,6 +12,7 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
#include <drm/drm_edid.h>
@@ -301,6 +302,23 @@ static int hdmic_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int hdmic_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ return 0;
+}
+
static int hdmic_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -318,6 +336,10 @@ static int hdmic_probe(struct platform_device *pdev)
r = hdmic_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = hdmic_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -359,12 +381,20 @@ static int __exit hdmic_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id hdmic_of_match[] = {
+ { .compatible = "hdmi-connector", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, hdmic_of_match);
+
static struct platform_driver hdmi_connector_driver = {
.probe = hdmic_probe,
.remove = __exit_p(hdmic_remove),
.driver = {
.name = "connector-hdmi",
.owner = THIS_MODULE,
+ .of_match_table = hdmic_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related
* [PATCHv2 26/27] OMAPDSS: panel-dpi: Add DT support
From: Tomi Valkeinen @ 2013-12-16 14:56 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree; +Cc: Tomi Valkeinen
In-Reply-To: <1387205794-32246-1-git-send-email-tomi.valkeinen@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays-new/panel-dpi.c | 64 +++++++++++++++++++++++++++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/panel-dpi.c b/drivers/video/omap2/displays-new/panel-dpi.c
index 5f8f7e7c81ef..f1653042c21d 100644
--- a/drivers/video/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/omap2/displays-new/panel-dpi.c
@@ -13,9 +13,12 @@
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
+#include <video/of_display_timing.h>
struct panel_drv_data {
struct omap_dss_device dssdev;
@@ -70,7 +73,8 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in->ops.dpi->set_data_lines(in, ddata->data_lines);
+ if (ddata->data_lines)
+ in->ops.dpi->set_data_lines(in, ddata->data_lines);
in->ops.dpi->set_timings(in, &ddata->videomode);
r = in->ops.dpi->enable(in);
@@ -182,6 +186,52 @@ static int panel_dpi_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int panel_dpi_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+ int r;
+ struct display_timing timing;
+ struct videomode vm;
+ int gpio;
+
+ gpio = of_get_gpio(node, 0);
+ if (gpio_is_valid(gpio) || gpio = -ENOENT) {
+ ddata->enable_gpio = gpio;
+ } else {
+ dev_err(&pdev->dev, "failed to parse enable gpio\n");
+ return gpio;
+ }
+
+ gpio = of_get_gpio(node, 1);
+ if (gpio_is_valid(gpio) || gpio = -ENOENT) {
+ ddata->backlight_gpio = gpio;
+ } else {
+ dev_err(&pdev->dev, "failed to parse backlight gpio\n");
+ return gpio;
+ }
+
+ r = of_get_display_timing(node, "panel-timing", &timing);
+ if (r) {
+ dev_err(&pdev->dev, "failed to get video timing\n");
+ return r;
+ }
+
+ videomode_from_timing(&timing, &vm);
+ videomode_to_omap_video_timings(&vm, &ddata->videomode);
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ return 0;
+}
+
static int panel_dpi_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -198,6 +248,10 @@ static int panel_dpi_probe(struct platform_device *pdev)
r = panel_dpi_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = panel_dpi_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -254,12 +308,20 @@ static int __exit panel_dpi_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id panel_dpi_of_match[] = {
+ { .compatible = "panel-dpi", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, panel_dpi_of_match);
+
static struct platform_driver panel_dpi_driver = {
.probe = panel_dpi_probe,
.remove = __exit_p(panel_dpi_remove),
.driver = {
.name = "panel-dpi",
.owner = THIS_MODULE,
+ .of_match_table = panel_dpi_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related
* [PATCHv2 27/27] OMAPDSS: connector-analog-tv: Add DT support
From: Tomi Valkeinen @ 2013-12-16 14:56 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree; +Cc: Tomi Valkeinen
In-Reply-To: <1387205794-32246-1-git-send-email-tomi.valkeinen@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../video/omap2/displays-new/connector-analog-tv.c | 66 +++++++++++++++++++++-
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/connector-analog-tv.c b/drivers/video/omap2/displays-new/connector-analog-tv.c
index ccd9073f706f..ebed25a86487 100644
--- a/drivers/video/omap2/displays-new/connector-analog-tv.c
+++ b/drivers/video/omap2/displays-new/connector-analog-tv.c
@@ -12,6 +12,7 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
@@ -42,6 +43,12 @@ static const struct omap_video_timings tvc_pal_timings = {
.interlace = true,
};
+static const struct of_device_id tvc_of_match[];
+
+struct tvc_of_data {
+ enum omap_dss_venc_type connector_type;
+};
+
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
static int tvc_connect(struct omap_dss_device *dssdev)
@@ -92,7 +99,10 @@ static int tvc_enable(struct omap_dss_device *dssdev)
in->ops.atv->set_timings(in, &ddata->timings);
in->ops.atv->set_type(in, ddata->connector_type);
- in->ops.atv->invert_vid_out_polarity(in, ddata->invert_polarity);
+
+ if (!ddata->dev->of_node)
+ in->ops.atv->invert_vid_out_polarity(in,
+ ddata->invert_polarity);
r = in->ops.atv->enable(in);
if (r)
@@ -205,6 +215,35 @@ static int tvc_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tvc_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+ const struct of_device_id *match;
+ const struct tvc_of_data *data;
+
+ match = of_match_node(tvc_of_match, pdev->dev.of_node);
+ if (!match) {
+ dev_err(&pdev->dev, "unsupported device\n");
+ return -ENODEV;
+ }
+
+ data = match->data;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ ddata->connector_type = data->connector_type;
+
+ return 0;
+}
+
static int tvc_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -222,6 +261,10 @@ static int tvc_probe(struct platform_device *pdev)
r = tvc_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = tvc_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -263,12 +306,33 @@ static int __exit tvc_remove(struct platform_device *pdev)
return 0;
}
+static const struct tvc_of_data tv_svideo_data = {
+ .connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static const struct tvc_of_data tv_composite_video_data = {
+ .connector_type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+};
+
+static const struct of_device_id tvc_of_match[] = {
+ {
+ .compatible = "svideo-connector",
+ .data = &tv_svideo_data,
+ },
+ {
+ .compatible = "composite-video-connector",
+ .data = &tv_composite_video_data,
+ },
+ {},
+};
+
static struct platform_driver tvc_connector_driver = {
.probe = tvc_probe,
.remove = __exit_p(tvc_remove),
.driver = {
.name = "connector-analog-tv",
.owner = THIS_MODULE,
+ .of_match_table = tvc_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3] if xen_platform_pci=0 is set don't blow up.
From: Konrad Rzeszutek Wilk @ 2013-12-16 15:04 UTC (permalink / raw)
To: axboe, stefano.stabellini, ian.campbell, xen-devel, linux-kernel,
boris.ostrovsky, david.vrabel, leosilva, ashley, peterhuewe, mail,
tpmdd, dmitry.torokhov, bhelgaas, plagnioj, tomi.valkeinen,
tpmdd-devel, linux-input, netdev, linux-pci, linux-fbdev
The first patch:
[PATCH v3 1/2] xen/pvhvm: If xen_platform_pci=0 is set don't blow up
I would like to commit to stable as it is fixing an eggregious bug -
where we blow up if the guest config has: "xen_platform_pci=0" setup.
This bug has been in existence for years and it is time to stamp it out.
The second patch is a cleanup - not a stable candidate.
It touches all of the Xen frontend drivers and adds the logic of:
"if user disabled us, don't init" - with variations. As you can
specify exactly which ones you want to init and which ones
not (Linux runtime parameter 'xen_emul_unplug'). But for the majority
of drivers - it is just an on/off switch.
Since it touches a lot of maintainers I figured I would send it
to Linus on Wednesday or Thursday.
Thank you!
arch/x86/xen/platform-pci-unplug.c | 79 ++++++++++++++++++++++++++++--
drivers/block/xen-blkfront.c | 4 +-
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 | 25 +++++++++-
9 files changed, 119 insertions(+), 9 deletions(-)
Konrad Rzeszutek Wilk (2):
xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v3).
xen/pvhvm: Remove the xen_platform_pci int.
^ permalink raw reply
* [PATCH v3 1/2] xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v3).
From: Konrad Rzeszutek Wilk @ 2013-12-16 15:04 UTC (permalink / raw)
To: axboe, stefano.stabellini, ian.campbell, xen-devel, linux-kernel,
boris.ostrovsky, david.vrabel, leosilva, ashley, peterhuewe, mail,
tpmdd, dmitry.torokhov, bhelgaas, plagnioj, tomi.valkeinen,
tpmdd-devel, linux-input, netdev, linux-pci, linux-fbdev
Cc: Konrad Rzeszutek Wilk
In-Reply-To: <1387206250-13963-1-git-send-email-konrad.wilk@oracle.com>
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 any 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.
- (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=disks',
then bail out for all PV devices _except_ the block one.
Ditto for the network one ('nics').
- (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
then load block PV driver, and also setup the legacy IDE paths.
In (v3) make it actually load PV drivers.
Reported-by: Sander Eikelenboom <linux@eikelenboom.it
Reported-by: Anthony PERARD <anthony.perard@citrix.com>
Reported-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v2: Add extra logic to handle the myrid ways 'xen_emul_unplug'
can be used per Ian and Stefano suggestion]
[v3: Make the unnecessary case work properly]
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/x86/xen/platform-pci-unplug.c | 74 ++++++++++++++++++++++++++++++
drivers/block/xen-blkfront.c | 4 +-
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 | 23 ++++++++++
9 files changed, 117 insertions(+), 4 deletions(-)
diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c
index 0a78524..ab84ac1 100644
--- a/arch/x86/xen/platform-pci-unplug.c
+++ b/arch/x86/xen/platform-pci-unplug.c
@@ -69,6 +69,80 @@ static int check_platform_magic(void)
return 0;
}
+bool xen_has_pv_devices()
+{
+ if (!xen_domain())
+ return false;
+
+ /* PV domains always have them. */
+ if (xen_pv_domain())
+ return true;
+
+ /* And user has xen_platform_pci=0 set in guest config as
+ * driver did not modify the value. */
+ if (xen_platform_pci_unplug = 0)
+ return false;
+
+ if (xen_platform_pci_unplug & XEN_UNPLUG_NEVER)
+ return false;
+
+ if (xen_platform_pci_unplug & XEN_UNPLUG_ALL)
+ return true;
+
+ /* This is an odd one - we are going to run legacy
+ * and PV drivers at the same time. */
+ if (xen_platform_pci_unplug & XEN_UNPLUG_UNNECESSARY)
+ return true;
+
+ /* And the caller has to follow with xen_pv_{disk,nic}_devices
+ * to be certain which driver can load. */
+ return false;
+}
+EXPORT_SYMBOL_GPL(xen_has_pv_devices);
+
+static bool __xen_has_pv_device(int state)
+{
+ /* HVM domains might or might not */
+ if (xen_hvm_domain() && (xen_platform_pci_unplug & state))
+ return true;
+
+ return xen_has_pv_devices();
+}
+
+bool xen_has_pv_nic_devices(void)
+{
+ return __xen_has_pv_device(XEN_UNPLUG_ALL_NICS | XEN_UNPLUG_ALL);
+}
+EXPORT_SYMBOL_GPL(xen_has_pv_nic_devices);
+
+bool xen_has_pv_disk_devices(void)
+{
+ return __xen_has_pv_device(XEN_UNPLUG_ALL_IDE_DISKS |
+ XEN_UNPLUG_AUX_IDE_DISKS | XEN_UNPLUG_ALL);
+}
+EXPORT_SYMBOL_GPL(xen_has_pv_disk_devices);
+
+/*
+ * This one is odd - it determines whether you want to run PV _and_
+ * legacy (IDE) drivers together. This combination is only possible
+ * under HVM.
+ */
+bool xen_has_pv_and_legacy_disk_devices(void)
+{
+ if (!xen_domain())
+ return false;
+
+ /* N.B. This is only ever used in HVM mode */
+ if (xen_pv_domain())
+ return false;
+
+ if (xen_platform_pci_unplug & XEN_UNPLUG_UNNECESSARY)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(xen_has_pv_and_legacy_disk_devices);
+
void xen_unplug_emulated_devices(void)
{
int r;
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index a4660bb..ed88b3c 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1278,7 +1278,7 @@ static int blkfront_probe(struct xenbus_device *dev,
char *type;
int len;
/* no unplug has been done: do not hook devices != xen vbds */
- if (xen_platform_pci_unplug & XEN_UNPLUG_UNNECESSARY) {
+ if (xen_has_pv_and_legacy_disk_devices()) {
int major;
if (!VDEV_IS_EXTENDED(vdevice))
@@ -2022,7 +2022,7 @@ static int __init xlblk_init(void)
if (!xen_domain())
return -ENODEV;
- if (xen_hvm_domain() && !xen_platform_pci_unplug)
+ if (!xen_has_pv_disk_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 06189e5..9c2cbd1 100644
--- a/drivers/char/tpm/xen-tpmfront.c
+++ b/drivers/char/tpm/xen-tpmfront.c
@@ -16,6 +16,7 @@
#include <xen/xenbus.h>
#include <xen/page.h>
#include "tpm.h"
+#include <xen/platform_pci.h>
struct tpm_private {
struct tpm_chip *chip;
@@ -422,6 +423,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 36808bf..eea2392 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -2106,7 +2106,7 @@ static int __init netif_init(void)
if (!xen_domain())
return -ENODEV;
- if (xen_hvm_domain() && !xen_platform_pci_unplug)
+ if (!xen_has_pv_nic_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 34b20bf..6244f9c 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..b49eeab 100644
--- a/include/xen/platform_pci.h
+++ b/include/xen/platform_pci.h
@@ -48,4 +48,27 @@ 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);
+extern bool xen_has_pv_disk_devices(void);
+extern bool xen_has_pv_nic_devices(void);
+extern bool xen_has_pv_and_legacy_disk_devices(void);
+#else
+static inline bool xen_has_pv_devices(void)
+{
+ return IS_ENABLED(CONFIG_XEN);
+}
+static inline bool xen_has_pv_disk_devices(void)
+{
+ return IS_ENABLED(CONFIG_XEN);
+}
+static inline bool xen_has_pv_nic_devices(void)
+{
+ return IS_ENABLED(CONFIG_XEN);
+}
+static inline bool xen_has_pv_and_legacy_disk_devices(void)
+{
+ return false;
+}
+#endif
#endif /* _XEN_PLATFORM_PCI_H */
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 2/2] xen/pvhvm: Remove the xen_platform_pci int.
From: Konrad Rzeszutek Wilk @ 2013-12-16 15:04 UTC (permalink / raw)
To: axboe, stefano.stabellini, ian.campbell, xen-devel, linux-kernel,
boris.ostrovsky, david.vrabel, leosilva, ashley, peterhuewe, mail,
tpmdd, dmitry.torokhov, bhelgaas, plagnioj, tomi.valkeinen,
tpmdd-devel, linux-input, netdev, linux-pci, linux-fbdev
Cc: Konrad Rzeszutek Wilk
In-Reply-To: <1387206250-13963-1-git-send-email-konrad.wilk@oracle.com>
Since we have xen_has_pv_devices,xen_has_pv_disk_devices,
xen_has_pv_nic_devices, and xen_has_pv_and_legacy_disk_devices
to figure out the different 'unplug' behaviors - lets
use those instead of this single int.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
arch/x86/xen/platform-pci-unplug.c | 5 ++---
include/xen/platform_pci.h | 2 --
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c
index ab84ac1..a826171 100644
--- a/arch/x86/xen/platform-pci-unplug.c
+++ b/arch/x86/xen/platform-pci-unplug.c
@@ -30,10 +30,9 @@
#define XEN_PLATFORM_ERR_PROTOCOL -2
#define XEN_PLATFORM_ERR_BLACKLIST -3
-/* store the value of xen_emul_unplug after the unplug is done */
-int xen_platform_pci_unplug;
-EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
#ifdef CONFIG_XEN_PVHVM
+/* store the value of xen_emul_unplug after the unplug is done */
+static int xen_platform_pci_unplug;
static int xen_emul_unplug;
static int check_platform_magic(void)
diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
index b49eeab..5c52b55 100644
--- a/include/xen/platform_pci.h
+++ b/include/xen/platform_pci.h
@@ -46,8 +46,6 @@ static inline int xen_must_unplug_disks(void) {
#endif
}
-extern int xen_platform_pci_unplug;
-
#if defined(CONFIG_XEN_PVHVM)
extern bool xen_has_pv_devices(void);
extern bool xen_has_pv_disk_devices(void);
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/2] video/fb: Propagate error code from failing to unregister conflicting fb
From: Chris Wilson @ 2013-12-16 15:57 UTC (permalink / raw)
To: intel-gfx
Cc: linux-fbdev, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
dri-devel
If we fail to remove a conflicting fb driver, we need to abort the
loading of the second driver to avoid likely kernel panics.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/video/fbmem.c | 31 +++++++++++++++++++++----------
include/linux/fb.h | 4 ++--
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 010d19105ebc..e296967a3abb 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1577,10 +1577,10 @@ static bool fb_do_apertures_overlap(struct apertures_struct *gena,
static int do_unregister_framebuffer(struct fb_info *fb_info);
#define VGA_FB_PHYS 0xA0000
-static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
- const char *name, bool primary)
+static int do_remove_conflicting_framebuffers(struct apertures_struct *a,
+ const char *name, bool primary)
{
- int i;
+ int i, ret;
/* check all firmware fbs and kick off if the base addr overlaps */
for (i = 0 ; i < FB_MAX; i++) {
@@ -1599,22 +1599,29 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
printk(KERN_INFO "fb: conflicting fb hw usage "
"%s vs %s - removing generic driver\n",
name, registered_fb[i]->fix.id);
- do_unregister_framebuffer(registered_fb[i]);
+ ret = do_unregister_framebuffer(registered_fb[i]);
+ if (ret)
+ return ret;
}
}
+
+ return 0;
}
static int do_register_framebuffer(struct fb_info *fb_info)
{
- int i;
+ int i, ret;
struct fb_event event;
struct fb_videomode mode;
if (fb_check_foreignness(fb_info))
return -ENOSYS;
- do_remove_conflicting_framebuffers(fb_info->apertures, fb_info->fix.id,
- fb_is_primary_device(fb_info));
+ ret = do_remove_conflicting_framebuffers(fb_info->apertures,
+ fb_info->fix.id,
+ fb_is_primary_device(fb_info));
+ if (ret)
+ return ret;
if (num_registered_fb = FB_MAX)
return -ENXIO;
@@ -1739,12 +1746,16 @@ int unlink_framebuffer(struct fb_info *fb_info)
}
EXPORT_SYMBOL(unlink_framebuffer);
-void remove_conflicting_framebuffers(struct apertures_struct *a,
- const char *name, bool primary)
+int remove_conflicting_framebuffers(struct apertures_struct *a,
+ const char *name, bool primary)
{
+ int ret;
+
mutex_lock(®istration_lock);
- do_remove_conflicting_framebuffers(a, name, primary);
+ ret = do_remove_conflicting_framebuffers(a, name, primary);
mutex_unlock(®istration_lock);
+
+ return ret;
}
EXPORT_SYMBOL(remove_conflicting_framebuffers);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 70c4836e4a9f..fe6ac956550e 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -613,8 +613,8 @@ extern ssize_t fb_sys_write(struct fb_info *info, const char __user *buf,
extern int register_framebuffer(struct fb_info *fb_info);
extern int unregister_framebuffer(struct fb_info *fb_info);
extern int unlink_framebuffer(struct fb_info *fb_info);
-extern void remove_conflicting_framebuffers(struct apertures_struct *a,
- const char *name, bool primary);
+extern int remove_conflicting_framebuffers(struct apertures_struct *a,
+ const char *name, bool primary);
extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
extern int fb_show_logo(struct fb_info *fb_info, int rotate);
extern char* fb_get_buffer_offset(struct fb_info *info, struct fb_pixmap *buf, u32 size);
--
1.8.5.1
^ permalink raw reply related
* Re: [PATCH 3/4] backlight: lcd: call put_device if device_register fails
From: Levente Kurusa @ 2013-12-16 17:16 UTC (permalink / raw)
To: Jingoo Han, 'Andrew Morton'
Cc: 'LKML', 'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen', linux-fbdev
In-Reply-To: <006f01cefa1a$97ea4710$c7bed530$%han@samsung.com>
On 12/16/2013 05:52 AM, Jingoo Han wrote:
> On Saturday, December 14, 2013 3:40 AM, Levente Kurusa wrote:
>>
>> Currently we kfree the container of the device which failed to register.
>> This is wrong as the last reference is not given up with a put_device
>> call. Also, now that we have put_device() callen, we no longer need
>> the kfree as the new_ld->dev.release function will take care of kfreeing
>> the associated memory.
>>
>> Signed-off-by: Levente Kurusa <levex@linux.com>
>
> (+cc Andrew Morton)
>
> Acked-by: Jingoo Han <jg1.han@samsung.com>
>
> It looks good.
> According to the comment of device_register, put_device()
> should be used, instead of directly freeing.
Indeed, this is also mostly explained in [0/4]. Thanks for the Ack!
>
[...]
>
> Levente Kurusa,
> By the way, don't send the same mails three times, without any
> reason. It is the waste of traffic. :-(
>
Yea, sorry about that I messed up my git's smtp config and hence most of the
messages bounced off. It didn't even reach LKML. Sorry once more.
--
Regards,
Levente Kurusa
^ permalink raw reply
* Re: [PATCHv2 01/27] ARM: OMAP: remove DSS DT hack
From: Tony Lindgren @ 2013-12-16 18:41 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, devicetree
In-Reply-To: <1387205794-32246-2-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131216 06:59]:
> 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.
I guess this patch should be merged later on after we have the DT support
working?
Regards,
Tony
^ permalink raw reply
* Re: [PATCHv2 02/27] OMAPDSS: remove DT hacks for regulators
From: Tony Lindgren @ 2013-12-16 18:42 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, devicetree
In-Reply-To: <1387205794-32246-3-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131216 06:59]:
> 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.
This too we should probably keep for a while and remove after we've
converted DSS over to DT?
Regards,
Tony
^ permalink raw reply
* Re: [PATCHv2 03/27] ARM: OMAP2+: add omapdss_init_of()
From: Tony Lindgren @ 2013-12-16 18:46 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, devicetree
In-Reply-To: <1387205794-32246-4-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131216 07:02]:
> 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.
...
> --- 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"
> @@ -514,3 +516,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;
> + }
You can populate the callback functions in the pdata using
OF_DEV_AUXDATA entries in the pdata-quirks.c. That way you could
instantiate the dev entry for omap_display_device using DT
and deal with it in drivers/video/omap except for the pdata
callbacks.
Of course that can be done later too.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v3] if xen_platform_pci=0 is set don't blow up.
From: Bjorn Helgaas @ 2013-12-17 1:00 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Jens Axboe, Stefano Stabellini, ian.campbell, xen-devel,
linux-kernel@vger.kernel.org, boris.ostrovsky, David Vrabel,
leosilva, ashley, Peter Hüwe, mail, tpmdd, Dmitry Torokhov,
plagnioj, tomi.valkeinen, tpmdd-devel,
linux-input@vger.kernel.org, netdev, linux-pci@vger.kernel.org,
linux-fbdev
In-Reply-To: <1387206250-13963-1-git-send-email-konrad.wilk@oracle.com>
On Mon, Dec 16, 2013 at 8:04 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> The first patch:
> [PATCH v3 1/2] xen/pvhvm: If xen_platform_pci=0 is set don't blow up
>
> I would like to commit to stable as it is fixing an eggregious bug -
> where we blow up if the guest config has: "xen_platform_pci=0" setup.
> This bug has been in existence for years and it is time to stamp it out.
>
> The second patch is a cleanup - not a stable candidate.
>
> It touches all of the Xen frontend drivers and adds the logic of:
> "if user disabled us, don't init" - with variations. As you can
> specify exactly which ones you want to init and which ones
> not (Linux runtime parameter 'xen_emul_unplug'). But for the majority
> of drivers - it is just an on/off switch.
>
> Since it touches a lot of maintainers I figured I would send it
> to Linus on Wednesday or Thursday.
>
> Thank you!
>
> arch/x86/xen/platform-pci-unplug.c | 79 ++++++++++++++++++++++++++++--
> drivers/block/xen-blkfront.c | 4 +-
> 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 | 25 +++++++++-
> 9 files changed, 119 insertions(+), 9 deletions(-)
If you want it:
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
for the PCI parts.
>
> Konrad Rzeszutek Wilk (2):
> xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v3).
> xen/pvhvm: Remove the xen_platform_pci int.
>
^ permalink raw reply
* Re: [PATCHv2 03/27] ARM: OMAP2+: add omapdss_init_of()
From: Tomi Valkeinen @ 2013-12-17 6:20 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev, devicetree
In-Reply-To: <20131216184623.GC26293@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2634 bytes --]
On 2013-12-16 20:46, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131216 07:02]:
>> 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.
> ...
>
>> --- 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"
>> @@ -514,3 +516,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;
>> + }
>
> You can populate the callback functions in the pdata using
> OF_DEV_AUXDATA entries in the pdata-quirks.c. That way you could
> instantiate the dev entry for omap_display_device using DT
> and deal with it in drivers/video/omap except for the pdata
> callbacks.
The device we are creating here is not something to be created via DT.
So in addition to the devices that match to the DSS hardware blocks, we
have a 'omapdss' platform device. That's a legacy one, and it's
"virtual" in the sense that it doesn't match any HW block as such.
At some point the device should be removed totally, but for now it's
there and it's a convenient way to pass the platform data.
> Of course that can be done later too.
Yes, at the moment I'm trying to minimize the kind of code changes that
can be done later. It'd be great to get this into next merge window, but
time is running short if I do any bigger changes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCHv2 02/27] OMAPDSS: remove DT hacks for regulators
From: Tomi Valkeinen @ 2013-12-17 6:42 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev, devicetree
In-Reply-To: <20131216184247.GB26293@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 551 bytes --]
On 2013-12-16 20:42, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131216 06:59]:
>> 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.
>
> This too we should probably keep for a while and remove after we've
> converted DSS over to DT?
Hmm, yes, this one can be moved at the end of the series, as at that
point the DT is supported for Panda and 4430SDP.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCHv2 01/27] ARM: OMAP: remove DSS DT hack
From: Tomi Valkeinen @ 2013-12-17 6:45 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev, devicetree
In-Reply-To: <20131216184157.GA26293@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
On 2013-12-16 20:41, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131216 06:59]:
>> 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.
>
> I guess this patch should be merged later on after we have the DT support
> working?
I'll move this patch also to the end of the series.
"Merged later" sounds like you mean this could be merged in a separate
series. I think this and the other removal can be in this series, they
just need to be at the end.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCHv2 08/27] OMAPDSS: add of helpers
From: Tomi Valkeinen @ 2013-12-17 7:01 UTC (permalink / raw)
To: Archit Taneja, linux-omap, linux-fbdev, devicetree
In-Reply-To: <52AFF685.6010209@ti.com>
[-- Attachment #1: Type: text/plain, Size: 210 bytes --]
On 2013-12-17 09:00, Archit Taneja wrote:
>> +#include "dss.h"
>> +#include "dss_features.h"
>
> Minor nitpick. The above 2 headers aren't needed.
Ah, thanks. Forgot to remove those =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCHv2 23/27] OMAPDSS: connector-dvi: Add DT support
From: Sascha Hauer @ 2013-12-17 7:05 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, devicetree
In-Reply-To: <1387205794-32246-24-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On Mon, Dec 16, 2013 at 04:56:30PM +0200, Tomi Valkeinen wrote:
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/displays-new/connector-dvi.c | 43 ++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/drivers/video/omap2/displays-new/connector-dvi.c b/drivers/video/omap2/displays-new/connector-dvi.c
> index b6c50904038e..d1204b1c5182 100644
>
> +static const struct of_device_id dvic_of_match[] = {
> + { .compatible = "dvi-connector", },
Either the driver is too specific or the binding is too generic, but
having such a generic name for an omap specific driver seems wrong. Same
for panel-dpi, svideo-connector, composite-video-connector and hdmi-connector,
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCHv2 08/27] OMAPDSS: add of helpers
From: Archit Taneja @ 2013-12-17 7:12 UTC (permalink / raw)
To: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree
In-Reply-To: <1387205794-32246-9-git-send-email-tomi.valkeinen@ti.com>
Hi,
On Monday 16 December 2013 08:26 PM, Tomi Valkeinen wrote:
> Add helpers to get ports and endpoints from DT data.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/Makefile | 2 +-
> drivers/video/omap2/dss/dss-of.c | 162 +++++++++++++++++++++++++++++++++++++++
> include/video/omapdss.h | 14 ++++
> 3 files changed, 177 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..59213cf2ffa2
> --- /dev/null
> +++ b/drivers/video/omap2/dss/dss-of.c
> @@ -0,0 +1,162 @@
> +/*
> + * 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"
Minor nitpick. The above 2 headers aren't needed.
Archit
^ permalink raw reply
* Re: [PATCHv2 23/27] OMAPDSS: connector-dvi: Add DT support
From: Tomi Valkeinen @ 2013-12-17 7:15 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-omap, linux-fbdev, devicetree, Laurent Pinchart,
Tony Lindgren
In-Reply-To: <20131217070551.GR24559@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1928 bytes --]
On 2013-12-17 09:05, Sascha Hauer wrote:
> Hi Tomi,
>
> On Mon, Dec 16, 2013 at 04:56:30PM +0200, Tomi Valkeinen wrote:
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> drivers/video/omap2/displays-new/connector-dvi.c | 43 ++++++++++++++++++++++++
>> 1 file changed, 43 insertions(+)
>>
>> diff --git a/drivers/video/omap2/displays-new/connector-dvi.c b/drivers/video/omap2/displays-new/connector-dvi.c
>> index b6c50904038e..d1204b1c5182 100644
>>
>> +static const struct of_device_id dvic_of_match[] = {
>> + { .compatible = "dvi-connector", },
>
> Either the driver is too specific or the binding is too generic, but
> having such a generic name for an omap specific driver seems wrong. Same
> for panel-dpi, svideo-connector, composite-video-connector and hdmi-connector,
Hmm. Good point. I was thinking that the driver is only used on OMAP,
but of course that's not true, the driver is there for all platforms if
the kernel just happens to be compiled with the driver.
And it's not just about those drivers you mention. The same issue is
there for, say, "ti,tpd12s015". I have an omapdss specific driver for
that, but if some other platform uses the same chip, they'll have a
driver for it also...
Sigh. I wonder how this should be handled... The only solution that
comes to my mind is to have all the compatible strings as "ti,...". But
that's not correct, as they are not TI components, but some are generic
ones and some from another vendor.
And even "ti,..." is not good, as there are other TI SoCs with other
display drivers. So I'd need to prepend the compatible strings with
"omapdss,...", making the hardware components driver specific.
The long term plan is to make the drivers generic (or implement the same
driver for common display framework). But for now I need to have future
proof DT bindings with omapdss specific drivers...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 1/2] video/fb: Propagate error code from failing to unregister conflicting fb
From: Jani Nikula @ 2013-12-17 7:33 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
Cc: linux-fbdev, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
dri-devel
In-Reply-To: <1387209460-9042-1-git-send-email-chris@chris-wilson.co.uk>
On Mon, 16 Dec 2013, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> If we fail to remove a conflicting fb driver, we need to abort the
> loading of the second driver to avoid likely kernel panics.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/video/fbmem.c | 31 +++++++++++++++++++++----------
> include/linux/fb.h | 4 ++--
> 2 files changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 010d19105ebc..e296967a3abb 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1577,10 +1577,10 @@ static bool fb_do_apertures_overlap(struct apertures_struct *gena,
> static int do_unregister_framebuffer(struct fb_info *fb_info);
>
> #define VGA_FB_PHYS 0xA0000
> -static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
> - const char *name, bool primary)
> +static int do_remove_conflicting_framebuffers(struct apertures_struct *a,
> + const char *name, bool primary)
> {
> - int i;
> + int i, ret;
>
> /* check all firmware fbs and kick off if the base addr overlaps */
> for (i = 0 ; i < FB_MAX; i++) {
> @@ -1599,22 +1599,29 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
> printk(KERN_INFO "fb: conflicting fb hw usage "
> "%s vs %s - removing generic driver\n",
> name, registered_fb[i]->fix.id);
> - do_unregister_framebuffer(registered_fb[i]);
> + ret = do_unregister_framebuffer(registered_fb[i]);
> + if (ret)
> + return ret;
An observation, this bails out early instead of trying to unregister all
the conflicting framebuffers regardless of errors like before. We're
probably doomed either way?
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> }
> }
> +
> + return 0;
> }
>
> static int do_register_framebuffer(struct fb_info *fb_info)
> {
> - int i;
> + int i, ret;
> struct fb_event event;
> struct fb_videomode mode;
>
> if (fb_check_foreignness(fb_info))
> return -ENOSYS;
>
> - do_remove_conflicting_framebuffers(fb_info->apertures, fb_info->fix.id,
> - fb_is_primary_device(fb_info));
> + ret = do_remove_conflicting_framebuffers(fb_info->apertures,
> + fb_info->fix.id,
> + fb_is_primary_device(fb_info));
> + if (ret)
> + return ret;
>
> if (num_registered_fb = FB_MAX)
> return -ENXIO;
> @@ -1739,12 +1746,16 @@ int unlink_framebuffer(struct fb_info *fb_info)
> }
> EXPORT_SYMBOL(unlink_framebuffer);
>
> -void remove_conflicting_framebuffers(struct apertures_struct *a,
> - const char *name, bool primary)
> +int remove_conflicting_framebuffers(struct apertures_struct *a,
> + const char *name, bool primary)
> {
> + int ret;
> +
> mutex_lock(®istration_lock);
> - do_remove_conflicting_framebuffers(a, name, primary);
> + ret = do_remove_conflicting_framebuffers(a, name, primary);
> mutex_unlock(®istration_lock);
> +
> + return ret;
> }
> EXPORT_SYMBOL(remove_conflicting_framebuffers);
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 70c4836e4a9f..fe6ac956550e 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -613,8 +613,8 @@ extern ssize_t fb_sys_write(struct fb_info *info, const char __user *buf,
> extern int register_framebuffer(struct fb_info *fb_info);
> extern int unregister_framebuffer(struct fb_info *fb_info);
> extern int unlink_framebuffer(struct fb_info *fb_info);
> -extern void remove_conflicting_framebuffers(struct apertures_struct *a,
> - const char *name, bool primary);
> +extern int remove_conflicting_framebuffers(struct apertures_struct *a,
> + const char *name, bool primary);
> extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
> extern int fb_show_logo(struct fb_info *fb_info, int rotate);
> extern char* fb_get_buffer_offset(struct fb_info *info, struct fb_pixmap *buf, u32 size);
> --
> 1.8.5.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH 0/4] OMAPDSS: DT support for N900 panel
From: Tomi Valkeinen @ 2013-12-17 7:37 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Benoît Cousson, Tony Lindgren,
Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Rob Landley, linux-omap, linux-fbdev, devicetree
In-Reply-To: <1386958650-2404-1-git-send-email-sre@debian.org>
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
Hi,
On 2013-12-13 20:17, Sebastian Reichel wrote:
> Hi,
>
> This patchset adds DT support for the N900 panel. The patchset is based on
> Tomi's work/dss-dt-2 branch [0]. I suggest to send the DT changes through
> Benoits queue, since I have more N900 DT changes for 3.14. Also the patch
> editing the rx51 boardcode can be dropped, since the file is removed in 3.14.
> I included those two with this patchset, since they are needed to test the
> other two patches.
>
> I did not include a documentation for the DT API, since the omapdss
> documentation is still missing.
>
> I have successfully tested this on the N900.
>
> [0] https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/log/?h=work/dss-dt-2
I added N900 display DT support on top of my v2 series, including
pinmuxing. Can you check if it looks right and works?
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [Xen-devel] [PATCH v3 1/2] xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v3).
From: Fabio Fantoni @ 2013-12-17 9:54 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, axboe, stefano.stabellini, ian.campbell,
xen-devel, linux-kernel, boris.ostrovsky, david.vrabel, leosilva,
ashley, peterhuewe, mail, tpmdd, dmitry.torokhov, bhelgaas,
plagnioj, tomi.valkeinen, tpmdd-devel, linux-input, netdev,
linux-pci, linux-fbdev
In-Reply-To: <1387206250-13963-2-git-send-email-konrad.wilk@oracle.com>
Il 16/12/2013 16:04, Konrad Rzeszutek Wilk ha scritto:
> 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 any 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.
> - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=disks',
> then bail out for all PV devices _except_ the block one.
> Ditto for the network one ('nics').
> - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
> then load block PV driver, and also setup the legacy IDE paths.
> In (v3) make it actually load PV drivers.
>
> Reported-by: Sander Eikelenboom <linux@eikelenboom.it
> Reported-by: Anthony PERARD <anthony.perard@citrix.com>
> Reported-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> [v2: Add extra logic to handle the myrid ways 'xen_emul_unplug'
> can be used per Ian and Stefano suggestion]
> [v3: Make the unnecessary case work properly]
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
I tested this patch with all possible cases that I know, no crash or
calltrace found.
I don't understand the utility of 'xen_emul_unplug=unnecessary' but
probably it is working correctly, it shows both pv and not pv for blocks
and nics.
About 'xen_emul_unplug=disks' and 'xen_emul_unplug=nics' probably there
is something wrong.
With 'xen_emul_unplug=nics' it shows pv nic (this should be correct) and
about disks it shows the same disk twice, as pv and not pv (xvda and
sda) with different device number.
With 'xen_emul_unplug=disks' it shows pv block (this should be correct)
and it seems to show the pv nic too (this should be wrong).
Thanks for any reply.
> ---
> arch/x86/xen/platform-pci-unplug.c | 74 ++++++++++++++++++++++++++++++
> drivers/block/xen-blkfront.c | 4 +-
> 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 | 23 ++++++++++
> 9 files changed, 117 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c
> index 0a78524..ab84ac1 100644
> --- a/arch/x86/xen/platform-pci-unplug.c
> +++ b/arch/x86/xen/platform-pci-unplug.c
> @@ -69,6 +69,80 @@ static int check_platform_magic(void)
> return 0;
> }
>
> +bool xen_has_pv_devices()
> +{
> + if (!xen_domain())
> + return false;
> +
> + /* PV domains always have them. */
> + if (xen_pv_domain())
> + return true;
> +
> + /* And user has xen_platform_pci=0 set in guest config as
> + * driver did not modify the value. */
> + if (xen_platform_pci_unplug = 0)
> + return false;
> +
> + if (xen_platform_pci_unplug & XEN_UNPLUG_NEVER)
> + return false;
> +
> + if (xen_platform_pci_unplug & XEN_UNPLUG_ALL)
> + return true;
> +
> + /* This is an odd one - we are going to run legacy
> + * and PV drivers at the same time. */
> + if (xen_platform_pci_unplug & XEN_UNPLUG_UNNECESSARY)
> + return true;
> +
> + /* And the caller has to follow with xen_pv_{disk,nic}_devices
> + * to be certain which driver can load. */
> + return false;
> +}
> +EXPORT_SYMBOL_GPL(xen_has_pv_devices);
> +
> +static bool __xen_has_pv_device(int state)
> +{
> + /* HVM domains might or might not */
> + if (xen_hvm_domain() && (xen_platform_pci_unplug & state))
> + return true;
> +
> + return xen_has_pv_devices();
> +}
> +
> +bool xen_has_pv_nic_devices(void)
> +{
> + return __xen_has_pv_device(XEN_UNPLUG_ALL_NICS | XEN_UNPLUG_ALL);
> +}
> +EXPORT_SYMBOL_GPL(xen_has_pv_nic_devices);
> +
> +bool xen_has_pv_disk_devices(void)
> +{
> + return __xen_has_pv_device(XEN_UNPLUG_ALL_IDE_DISKS |
> + XEN_UNPLUG_AUX_IDE_DISKS | XEN_UNPLUG_ALL);
> +}
> +EXPORT_SYMBOL_GPL(xen_has_pv_disk_devices);
> +
> +/*
> + * This one is odd - it determines whether you want to run PV _and_
> + * legacy (IDE) drivers together. This combination is only possible
> + * under HVM.
> + */
> +bool xen_has_pv_and_legacy_disk_devices(void)
> +{
> + if (!xen_domain())
> + return false;
> +
> + /* N.B. This is only ever used in HVM mode */
> + if (xen_pv_domain())
> + return false;
> +
> + if (xen_platform_pci_unplug & XEN_UNPLUG_UNNECESSARY)
> + return true;
> +
> + return false;
> +}
> +EXPORT_SYMBOL_GPL(xen_has_pv_and_legacy_disk_devices);
> +
> void xen_unplug_emulated_devices(void)
> {
> int r;
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index a4660bb..ed88b3c 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1278,7 +1278,7 @@ static int blkfront_probe(struct xenbus_device *dev,
> char *type;
> int len;
> /* no unplug has been done: do not hook devices != xen vbds */
> - if (xen_platform_pci_unplug & XEN_UNPLUG_UNNECESSARY) {
> + if (xen_has_pv_and_legacy_disk_devices()) {
> int major;
>
> if (!VDEV_IS_EXTENDED(vdevice))
> @@ -2022,7 +2022,7 @@ static int __init xlblk_init(void)
> if (!xen_domain())
> return -ENODEV;
>
> - if (xen_hvm_domain() && !xen_platform_pci_unplug)
> + if (!xen_has_pv_disk_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 06189e5..9c2cbd1 100644
> --- a/drivers/char/tpm/xen-tpmfront.c
> +++ b/drivers/char/tpm/xen-tpmfront.c
> @@ -16,6 +16,7 @@
> #include <xen/xenbus.h>
> #include <xen/page.h>
> #include "tpm.h"
> +#include <xen/platform_pci.h>
>
> struct tpm_private {
> struct tpm_chip *chip;
> @@ -422,6 +423,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 36808bf..eea2392 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -2106,7 +2106,7 @@ static int __init netif_init(void)
> if (!xen_domain())
> return -ENODEV;
>
> - if (xen_hvm_domain() && !xen_platform_pci_unplug)
> + if (!xen_has_pv_nic_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 34b20bf..6244f9c 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..b49eeab 100644
> --- a/include/xen/platform_pci.h
> +++ b/include/xen/platform_pci.h
> @@ -48,4 +48,27 @@ 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);
> +extern bool xen_has_pv_disk_devices(void);
> +extern bool xen_has_pv_nic_devices(void);
> +extern bool xen_has_pv_and_legacy_disk_devices(void);
> +#else
> +static inline bool xen_has_pv_devices(void)
> +{
> + return IS_ENABLED(CONFIG_XEN);
> +}
> +static inline bool xen_has_pv_disk_devices(void)
> +{
> + return IS_ENABLED(CONFIG_XEN);
> +}
> +static inline bool xen_has_pv_nic_devices(void)
> +{
> + return IS_ENABLED(CONFIG_XEN);
> +}
> +static inline bool xen_has_pv_and_legacy_disk_devices(void)
> +{
> + return false;
> +}
> +#endif
> #endif /* _XEN_PLATFORM_PCI_H */
^ permalink raw reply
* [PATCH] omapdss: dispc: Preload more data in pipeline DMAs for OMAP4+ SoCs
From: Archit Taneja @ 2013-12-17 11:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
DISPC pipeline DMAs preload some bytes of pixel data in the vertical blanking
region before the start of each frame. The preload ensures the pipeline doesn't
underflow when the active region of the display starts.
DISPC_GFX/VIDp_PRELOAD registers allow us to program how many bytes of data
should be preloaded for each pipeline. Calculating a precise preload value
would be a complex function of the pixel clock of the connected display, the
vertical blanking duration and the interconnect traffic at that instance. If
the register is left untouched, a default value is preloaded.
We observe underflows for OMAP4+ SoCs for certain bandwidth intensive use cases
with many other initiators active, and in situations where memory access isn't
very efficient(like accessing Tiler mapped buffers and EMIF configured in
non-interleaved more). The cause of the underflow is because the default preload
value isn't sufficient for the DMA to reach a steady state. We configure the
PRELOAD register such that the pipelines preload data up to the high threshold
of the FIFO.
Preloading lot of data for older SoCs can have a negative impact. Due to slower
interconnects, it's possible that the DISPC DMA cannot preload up to the high
threshold within the vertical blanking region of the panel. We leave the PRELOAD
registers to their reset values since we haven't faced underflows with these
SoCs because of low value of PRELOAD.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 6578540..ace179e 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -90,6 +90,8 @@ struct dispc_features {
/* revert to the OMAP4 mechanism of DISPC Smart Standby operation */
bool mstandby_workaround:1;
+
+ bool set_max_preload:1;
};
#define DISPC_MAX_NR_FIFOS 5
@@ -1200,6 +1202,15 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high)
dispc_write_reg(DISPC_OVL_FIFO_THRESHOLD(plane),
FLD_VAL(high, hi_start, hi_end) |
FLD_VAL(low, lo_start, lo_end));
+
+ /*
+ * configure the preload to the pipeline's high threhold, if HT it's too
+ * large for the preload field, set the threshold to the maximum value
+ * that can be held by the preload register
+ */
+ if (dss_has_feature(FEAT_PRELOAD) && dispc.feat->set_max_preload &&
+ plane != OMAP_DSS_WB)
+ dispc_write_reg(DISPC_OVL_PRELOAD(plane), min(high, 0xfff));
}
EXPORT_SYMBOL(dispc_ovl_set_fifo_threshold);
@@ -3525,6 +3536,7 @@ static const struct dispc_features omap24xx_dispc_feats __initconst = {
.calc_core_clk = calc_core_clk_24xx,
.num_fifos = 3,
.no_framedone_tv = true,
+ .set_max_preload = false,
};
static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
@@ -3544,6 +3556,7 @@ static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
.calc_core_clk = calc_core_clk_34xx,
.num_fifos = 3,
.no_framedone_tv = true,
+ .set_max_preload = false,
};
static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
@@ -3563,6 +3576,7 @@ static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
.calc_core_clk = calc_core_clk_34xx,
.num_fifos = 3,
.no_framedone_tv = true,
+ .set_max_preload = false,
};
static const struct dispc_features omap44xx_dispc_feats __initconst = {
@@ -3582,6 +3596,7 @@ static const struct dispc_features omap44xx_dispc_feats __initconst = {
.calc_core_clk = calc_core_clk_44xx,
.num_fifos = 5,
.gfx_fifo_workaround = true,
+ .set_max_preload = true,
};
static const struct dispc_features omap54xx_dispc_feats __initconst = {
@@ -3602,6 +3617,7 @@ static const struct dispc_features omap54xx_dispc_feats __initconst = {
.num_fifos = 5,
.gfx_fifo_workaround = true,
.mstandby_workaround = true,
+ .set_max_preload = true,
};
static int __init dispc_init_features(struct platform_device *pdev)
--
1.8.3.2
^ permalink raw reply related
* Re: [Intel-gfx] [PATCH 1/2] video/fb: Propagate error code from failing to unregister conflicting fb
From: Chris Wilson @ 2013-12-17 12:14 UTC (permalink / raw)
To: Jani Nikula
Cc: intel-gfx, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
linux-fbdev, dri-devel
In-Reply-To: <878uvk3paj.fsf@intel.com>
On Tue, Dec 17, 2013 at 09:33:08AM +0200, Jani Nikula wrote:
> On Mon, 16 Dec 2013, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > If we fail to remove a conflicting fb driver, we need to abort the
> > loading of the second driver to avoid likely kernel panics.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: linux-fbdev@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
> > ---
> > drivers/video/fbmem.c | 31 +++++++++++++++++++++----------
> > include/linux/fb.h | 4 ++--
> > 2 files changed, 23 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> > index 010d19105ebc..e296967a3abb 100644
> > --- a/drivers/video/fbmem.c
> > +++ b/drivers/video/fbmem.c
> > @@ -1577,10 +1577,10 @@ static bool fb_do_apertures_overlap(struct apertures_struct *gena,
> > static int do_unregister_framebuffer(struct fb_info *fb_info);
> >
> > #define VGA_FB_PHYS 0xA0000
> > -static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
> > - const char *name, bool primary)
> > +static int do_remove_conflicting_framebuffers(struct apertures_struct *a,
> > + const char *name, bool primary)
> > {
> > - int i;
> > + int i, ret;
> >
> > /* check all firmware fbs and kick off if the base addr overlaps */
> > for (i = 0 ; i < FB_MAX; i++) {
> > @@ -1599,22 +1599,29 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
> > printk(KERN_INFO "fb: conflicting fb hw usage "
> > "%s vs %s - removing generic driver\n",
> > name, registered_fb[i]->fix.id);
> > - do_unregister_framebuffer(registered_fb[i]);
> > + ret = do_unregister_framebuffer(registered_fb[i]);
> > + if (ret)
> > + return ret;
>
> An observation, this bails out early instead of trying to unregister all
> the conflicting framebuffers regardless of errors like before. We're
> probably doomed either way?
Indeed. Early exit hopefully leaves the machine usable for bug reporting.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* [PATCH] fbcon: Avoid corrupting active workqueue entries
From: Chris Wilson @ 2013-12-17 14:27 UTC (permalink / raw)
To: intel-gfx
Cc: Chris Wilson, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev, dri-devel, stable
We attempt to reschedule an active work which can itself corrupt the
workqueue lists, and we may then free the work item whilst the task is
still pending. Both of these may lead to a system deadlock and an
unresponsive machine without any outputs for a panic to even be shown.
[ 7.372961] WARNING: at kernel/workqueue.c:1365 __queue_work+0x216/0x292()
[ 7.372964] Modules linked in: coretemp arc4 kvm_intel kvm iwldvm crc32c_intel mac80211 ghash_clmulni_intel cryptd joydev hid_lenovo_tpkbd lib80211 iTCO_wdt iwlwifi iTCO_vendor_support i915(+) btusb snd_hda_codec_hdmi bluetooth evdev snd_hda_intel usbhid snd_hda_codec pcspkr hid cfg80211 microcode snd_hwdep i2c_i801 snd_pcm drm_kms_helper lpc_ich drm mfd_core snd_page_alloc rfkill snd_timer snd soundcore mei_me i2c_algo_bit video mei acpi_cpufreq mperf i2c_core button processor ext4 crc16 jbd2 mbcache sg sd_mod crc_t10dif ahci libahci libata scsi_mod thermal fan ehci_pci ehci_hcd thermal_sys usbcore usb_common
[ 7.373068] CPU: 0 PID: 660 Comm: ps Not tainted 3.10.9+ #55
[ 7.373071] Hardware name: /D33217CK, BIOS GKPPT10H.86A.0025.2012.1011.1534 10/11/2012
[ 7.373075] ffffffff81596a1e ffff88045f203d38 ffffffff813eaef6 ffff88045f203d78
[ 7.373083] ffffffff81041027 ffff88045f203d78 0000000000000000 ffff88045f217f00
[ 7.373091] ffff88044a89c800 ffff88042b473aa0 0000000000000000 ffff88045f203d88
[ 7.373098] Call Trace:
[ 7.373101] <IRQ> [<ffffffff813eaef6>] dump_stack+0x19/0x1b
[ 7.373115] [<ffffffff81041027>] warn_slowpath_common+0x62/0x7b
[ 7.373121] [<ffffffff81041055>] warn_slowpath_null+0x15/0x17
[ 7.373127] [<ffffffff8105aa82>] __queue_work+0x216/0x292
[ 7.373133] [<ffffffff8105ab65>] queue_work_on+0x4c/0x7c
[ 7.373140] [<ffffffff8123cebb>] ? fbcon_add_cursor_timer+0xfb/0xfb
[ 7.373146] [<ffffffff8123cee1>] cursor_timer_handler+0x26/0x42
[ 7.373153] [<ffffffff8104ee1f>] call_timer_fn+0xcc/0x1ea
[ 7.373160] [<ffffffff8104ed53>] ? detach_if_pending+0x7a/0x7a
[ 7.373166] [<ffffffff8123cebb>] ? fbcon_add_cursor_timer+0xfb/0xfb
[ 7.373172] [<ffffffff8104f27b>] run_timer_softirq+0x19c/0x1e4
[ 7.373178] [<ffffffff8104874e>] ? __do_softirq+0x9e/0x2a7
[ 7.373183] [<ffffffff810487e9>] __do_softirq+0x139/0x2a7
[ 7.373189] [<ffffffff81048a7a>] irq_exit+0x56/0x9b
[ 7.373196] [<ffffffff8102af31>] smp_apic_timer_interrupt+0x77/0x85
[ 7.373203] [<ffffffff813f5ff2>] apic_timer_interrupt+0x72/0x80
[ 7.373206] <EOI> [<ffffffff8113ea70>] ? spin_lock+0x9/0xb
[ 7.373217] [<ffffffff8120d8c1>] ? do_raw_spin_trylock+0x42/0x42
[ 7.373223] [<ffffffff813ef2e0>] ? _raw_spin_unlock+0x23/0x36
[ 7.373229] [<ffffffff8113ea7b>] spin_unlock+0x9/0xb
[ 7.373235] [<ffffffff8113fd25>] dput+0xd9/0xf8
[ 7.373241] [<ffffffff8113685e>] path_put+0x13/0x20
[ 7.373247] [<ffffffff8113a6f3>] do_last+0x925/0xa0d
[ 7.373253] [<ffffffff81137fa4>] ? inode_permission+0x40/0x42
[ 7.373259] [<ffffffff8113a89c>] path_openat+0xc1/0x325
[ 7.373265] [<ffffffff8113ae0c>] do_filp_open+0x33/0x81
[ 7.373271] [<ffffffff811455bd>] ? __alloc_fd+0x169/0x17b
[ 7.373279] [<ffffffff8112d78f>] do_sys_open+0x67/0xf4
[ 7.373285] [<ffffffff8112d839>] SyS_open+0x1d/0x1f
[ 7.373290] [<ffffffff813f5369>] system_call_fastpath+0x16/0x1b
[ 7.373294] ---[ end trace 78bba0b9776072a9 ]---
[ 7.538936] fbcon: inteldrmfb (fb0) is primary device
[ 7.539446] Console: switching consoles 2-6 to frame buffer device
[ 7.539463] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 7.539468] i915 0000:00:02.0: registered panic notifier
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?idr765
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: stable@vger.kernel.org
---
drivers/video/console/fbcon.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index cd8a8027f8ae..f474976f6b34 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -397,6 +397,8 @@ static void fb_flashcursor(struct work_struct *work)
ops->cursor(vc, info, mode, softback_lines, get_color(vc, info, c, 1),
get_color(vc, info, c, 0));
console_unlock();
+
+ mod_timer(&ops->cursor_timer, jiffies + HZ/5);
}
static void cursor_timer_handler(unsigned long dev_addr)
@@ -405,7 +407,6 @@ static void cursor_timer_handler(unsigned long dev_addr)
struct fbcon_ops *ops = info->fbcon_par;
queue_work(system_power_efficient_wq, &info->queue);
- mod_timer(&ops->cursor_timer, jiffies + HZ/5);
}
static void fbcon_add_cursor_timer(struct fb_info *info)
@@ -417,6 +418,8 @@ static void fbcon_add_cursor_timer(struct fb_info *info)
!fbcon_cursor_noblink) {
if (!info->queue.func)
INIT_WORK(&info->queue, fb_flashcursor);
+ else
+ flush_work(&info->queue);
init_timer(&ops->cursor_timer);
ops->cursor_timer.function = cursor_timer_handler;
@@ -433,6 +436,7 @@ static void fbcon_del_cursor_timer(struct fb_info *info)
if (info->queue.func = fb_flashcursor &&
ops->flags & FBCON_FLAGS_CURSOR_TIMER) {
+ flush_work(&info->queue);
del_timer_sync(&ops->cursor_timer);
ops->flags &= ~FBCON_FLAGS_CURSOR_TIMER;
}
--
1.8.5.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox