[PATCH] Staging: comedi: addi-data: clean-up variable use in hwdrv_apci035.c
The static variable ui_Command is as of right now being cleared to a value of zero between everytime that it writes to a port and then takes a new value from a port. Seems like this zeroing is unnecessary, so we can just remove these lines. Signed-off-by: Chase Southwood chase.southw...@yahoo.com --- This sort of thing seems like a copy/paste sort of error to me, but there could as easily be some reason here that I'm missing that this is needed here. My first impression, however, was that this extra clearing is useless. drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c index 6fca105..9041fdf 100644 --- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c +++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c @@ -182,11 +182,9 @@ static int i_APCI035_ConfigTimerWatchdog(struct comedi_device *dev, else ui_Mode = 0; -/* ui_Command = inl(devpriv-iobase+((i_WatchdogNbr-1)*32)+12); */ ui_Command = 0; -/* ui_Command = ui_Command 0xF9FEUL; */ outl(ui_Command, devpriv-iobase + ((i_WatchdogNbr - 1) * 32) + 12); - ui_Command = 0; + ui_Command = inl(devpriv-iobase + ((i_WatchdogNbr - 1) * 32) + 12); /* Set the reload value */ @@ -224,7 +222,7 @@ static int i_APCI035_ConfigTimerWatchdog(struct comedi_device *dev, } outl(ui_Command, devpriv-iobase + ((i_WatchdogNbr - 1) * 32) + 12); - ui_Command = 0; + ui_Command = inl(devpriv-iobase + ((i_WatchdogNbr - 1) * 32) + 12); /* Disable the hardware trigger */ @@ -235,7 +233,7 @@ static int i_APCI035_ConfigTimerWatchdog(struct comedi_device *dev, ui_Command = ui_Command | (data[5] 5); } outl(ui_Command, devpriv-iobase + ((i_WatchdogNbr - 1) * 32) + 12); - ui_Command = 0; + ui_Command = inl(devpriv-iobase + ((i_WatchdogNbr - 1) * 32) + 12); /* Disable the hardware gate */ @@ -246,7 +244,7 @@ static int i_APCI035_ConfigTimerWatchdog(struct comedi_device *dev, ui_Command = ui_Command | (data[7] 7); } outl(ui_Command, devpriv-iobase + ((i_WatchdogNbr - 1) * 32) + 12); - ui_Command = 0; + ui_Command = inl(devpriv-iobase + ((i_WatchdogNbr - 1) * 32) + 12); /* Disable the hardware output */ @@ -266,7 +264,6 @@ static int i_APCI035_ConfigTimerWatchdog(struct comedi_device *dev, devpriv-iobase + ((i_WatchdogNbr - 1) * 32) + 28); } - ui_Command = 0; ui_Command = inl(devpriv-iobase + ((i_WatchdogNbr - 1) * 32) + 12); /* Disable the hardware output */ @@ -277,7 +274,6 @@ static int i_APCI035_ConfigTimerWatchdog(struct comedi_device *dev, outl(ui_Command, devpriv-iobase + ((i_WatchdogNbr - 1) * 32) + 12); /* Enable the watchdog interrupt */ - ui_Command = 0; ui_Command = inl(devpriv-iobase + ((i_WatchdogNbr - 1) * 32) + 12); /* Set the interrupt selection */ -- 1.8.5.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 18/19] staging: dgap: Rename driver
On 02/24/2014 07:49 PM, Greg Kroah-Hartman wrote: On Wed, Feb 19, 2014 at 01:12:14PM -0500, Mark Hounschell wrote: Renames driver file dgap_driver.c and dgap_driver.h to dgap.c and dgap.h because we are now single source and include file and better fits kernel naming conventions. Signed-off-by: Mark Hounschell ma...@compro.net --- drivers/staging/dgap/Makefile |4 - drivers/staging/dgap/dgap.c| 8506 drivers/staging/dgap/dgap.h| 1504 +++ drivers/staging/dgap/dgap_driver.c | 8506 drivers/staging/dgap/dgap_driver.h | 1504 --- 5 files changed, 10010 insertions(+), 10014 deletions(-) create mode 100644 drivers/staging/dgap/dgap.c create mode 100644 drivers/staging/dgap/dgap.h delete mode 100644 drivers/staging/dgap/dgap_driver.c delete mode 100644 drivers/staging/dgap/dgap_driver.h There are a bunch of compiler warnings about unused static functions in this code now, after this series. Can you send me some follow-on patches to fix that up? Yes, I was waiting for this email before going further. There will be more coming. Thanks Mark ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: comedi: Fix line length exceeding 80 characters
On 2014-02-24 16:49, Monam Agarwal wrote:
Signed-off-by: Monam Agarwal monamagarwal...@gmail.com
---
drivers/staging/comedi/comedi_fops.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/comedi_fops.c
b/drivers/staging/comedi/comedi_fops.c
index ac1edd9..7da8566 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -1481,7 +1481,8 @@ static int do_cmd_ioctl(struct comedi_device *dev,
async-cmd.data = NULL;
/* load channel/gain list */
async-cmd.chanlist = memdup_user(user_chanlist,
- async-cmd.chanlist_len *
sizeof(int));
+ async-cmd.chanlist_len
+ * sizeof(int));
The `*` operator should go at the end of the line according to the
CodingStyle.
if (IS_ERR(async-cmd.chanlist)) {
ret = PTR_ERR(async-cmd.chanlist);
async-cmd.chanlist = NULL;
--
-=( Ian Abbott @ MEV Ltd.E-mail: abbo...@mev.co.uk)=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: comedi: Fix line length exceeding 80 characters
On Tue, 2014-02-25 at 09:46 +, Ian Abbott wrote: On 2014-02-24 16:49, Monam Agarwal wrote: [] diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c [] @@ -1481,7 +1481,8 @@ static int do_cmd_ioctl(struct comedi_device *dev, async-cmd.data = NULL; /* load channel/gain list */ async-cmd.chanlist = memdup_user(user_chanlist, - async-cmd.chanlist_len * sizeof(int)); + async-cmd.chanlist_len + * sizeof(int)); The `*` operator should go at the end of the line according to the CodingStyle. I don't believe there's a CodingStyle guide for this. Another way to do this is to move the memdup_user to a separate line like: async-cmd_chanlist = memdup_user(user_chanlist, async-cmd.chanlist_len * sizeof(int)); but I'm not bothered by the existing 80 column use. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] imx-drm: parallel-display: Add drm_panel support
This patch allows to optionally attach the parallel-display to a panel
supported by a drm_panel driver instead of supplying the modes via
device tree.
Before:
parallel-display {
compatible = fsl,imx-parallel-display;
...
display-timings {
native-timing = timing1;
timing1: etm0700g0dh6 {
hactive = 800;
vactive = 480;
clock-frequency = 3326;
hsync-len = 128;
hback-porch = 88;
hfront-porch = 40;
vsync-len = 2;
vback-porch = 33;
vfront-porch = 10;
hsync-active = 0;
vsync-active = 0;
...
};
};
...
};
After:
parallel-display {
compatible = fsl,imx-parallel-display;
fsl,panel = panel;
...
};
panel: panel {
compatible = edt,etm0700g0dh6, simple-panel;
};
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/staging/imx-drm/Kconfig| 1 +
drivers/staging/imx-drm/parallel-display.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 78319ad..c6e8ba7 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -20,6 +20,7 @@ config DRM_IMX_FB_HELPER
config DRM_IMX_PARALLEL_DISPLAY
tristate Support for parallel displays
+ select DRM_PANEL
depends on DRM_IMX
select VIDEOMODE_HELPERS
diff --git a/drivers/staging/imx-drm/parallel-display.c
b/drivers/staging/imx-drm/parallel-display.c
index d610f07..6bce140 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -23,6 +23,7 @@
#include drm/drmP.h
#include drm/drm_fb_helper.h
#include drm/drm_crtc_helper.h
+#include drm/drm_panel.h
#include linux/videodev2.h
#include video/of_display_timing.h
@@ -40,6 +41,7 @@ struct imx_parallel_display {
u32 interface_pix_fmt;
int mode_valid;
struct drm_display_mode mode;
+ struct drm_panel *panel;
};
static enum drm_connector_status imx_pd_connector_detect(
@@ -54,6 +56,13 @@ static int imx_pd_connector_get_modes(struct drm_connector
*connector)
struct device_node *np = imxpd-dev-of_node;
int num_modes = 0;
+ if (imxpd-panel imxpd-panel-funcs
+ imxpd-panel-funcs-get_modes) {
+ num_modes = imxpd-panel-funcs-get_modes(imxpd-panel);
+ if (num_modes 0)
+ return num_modes;
+ }
+
if (imxpd-edid) {
drm_mode_connector_update_edid_property(connector, imxpd-edid);
num_modes = drm_add_edid_modes(connector, imxpd-edid);
@@ -89,6 +98,12 @@ static struct drm_encoder *imx_pd_connector_best_encoder(
static void imx_pd_encoder_dpms(struct drm_encoder *encoder, int mode)
{
+ struct imx_parallel_display *imxpd = enc_to_imxpd(encoder);
+
+ if (mode != DRM_MODE_DPMS_ON)
+ drm_panel_disable(imxpd-panel);
+ else
+ drm_panel_enable(imxpd-panel);
}
static bool imx_pd_encoder_mode_fixup(struct drm_encoder *encoder,
@@ -164,6 +179,9 @@ static int imx_pd_register(struct drm_device *drm,
drm_connector_init(drm, imxpd-connector, imx_pd_connector_funcs,
DRM_MODE_CONNECTOR_VGA);
+ if (imxpd-panel)
+ drm_panel_attach(imxpd-panel, imxpd-connector);
+
drm_mode_connector_attach_encoder(imxpd-connector, imxpd-encoder);
imxpd-connector.encoder = imxpd-encoder;
@@ -175,6 +193,7 @@ static int imx_pd_bind(struct device *dev, struct device
*master, void *data)
{
struct drm_device *drm = data;
struct device_node *np = dev-of_node;
+ struct device_node *panel_node;
const u8 *edidp;
struct imx_parallel_display *imxpd;
int ret;
@@ -198,6 +217,10 @@ static int imx_pd_bind(struct device *dev, struct device
*master, void *data)
imxpd-interface_pix_fmt = V4L2_PIX_FMT_BGR666;
}
+ panel_node = of_parse_phandle(np, fsl,panel, 0);
+ if (panel_node)
+ imxpd-panel = of_drm_find_panel(panel_node);
+
imxpd-dev = dev;
ret = imx_pd_register(drm, imxpd);
--
1.8.5.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: comedi: Fix line length exceeding 80 characters
On Tue, Feb 25, 2014 at 01:59:25AM -0800, Joe Perches wrote: On Tue, 2014-02-25 at 09:46 +, Ian Abbott wrote: On 2014-02-24 16:49, Monam Agarwal wrote: [] diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c [] @@ -1481,7 +1481,8 @@ static int do_cmd_ioctl(struct comedi_device *dev, async-cmd.data = NULL; /* load channel/gain list */ async-cmd.chanlist = memdup_user(user_chanlist, - async-cmd.chanlist_len * sizeof(int)); + async-cmd.chanlist_len + * sizeof(int)); The `*` operator should go at the end of the line according to the CodingStyle. I don't believe there's a CodingStyle guide for this. Meanwhile you have felt totally justified in correcting me on this in the past. :P Anyway, it should be that the operator goes on the first line like Ian says... regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/3] Move IPUv3 core out of staging
Hi, this series has two small cleanups for the IPUv3 core driver and then moves it from drivers/staging/imx-drm/ipu-v3 to drivers/gpu. In this directory there is already the host1x driver, which serves a similar purpose. I have dropped the CSI (capture interface) patches from the RFC series. This series applies on top of Russell's imx-drm-staging branch, which just was merged into staging-next. I'd like to move the core code out of staging so that we can start submitting V4L2 code for video capture and scaling / colorspace conversion in parallel. I'll post the third patch in both versions with and without --find-renames. To move the remaining DRM part out of staging, I'd like to get the device tree bindings sorted out. This is currently pending on the move of OF graph parsing helpers and review of the imx-drm dt bindings patch series. regards Philipp Philipp Zabel (3): imx-drm: Move IPU_PIX_FMT_GBR24 definition into imx-ipu-v3.h imx-drm: ipu-dc: Use usleep_range instead of msleep gpu: ipu-v3: Move i.MX IPUv3 core driver out of staging drivers/gpu/Makefile|1 + drivers/gpu/ipu-v3/Kconfig |7 + drivers/gpu/ipu-v3/Makefile |3 + drivers/gpu/ipu-v3/ipu-common.c | 1261 +++ drivers/gpu/ipu-v3/ipu-dc.c | 411 + drivers/gpu/ipu-v3/ipu-di.c | 730 drivers/gpu/ipu-v3/ipu-dmfc.c | 418 + drivers/gpu/ipu-v3/ipu-dp.c | 338 +++ drivers/gpu/ipu-v3/ipu-prv.h| 206 + drivers/staging/imx-drm/Kconfig | 11 +- drivers/staging/imx-drm/Makefile|1 - drivers/staging/imx-drm/imx-drm.h |4 - drivers/staging/imx-drm/imx-tve.c |1 + drivers/staging/imx-drm/ipu-v3/Makefile |3 - drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 324 --- drivers/staging/imx-drm/ipu-v3/ipu-common.c | 1261 --- drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 412 - drivers/staging/imx-drm/ipu-v3/ipu-di.c | 730 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 418 - drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 338 --- drivers/staging/imx-drm/ipu-v3/ipu-prv.h| 206 - drivers/staging/imx-drm/ipuv3-crtc.c|2 +- drivers/staging/imx-drm/ipuv3-plane.c |2 +- drivers/video/Kconfig |1 + include/video/imx-ipu-v3.h | 326 +++ 25 files changed, 3706 insertions(+), 3709 deletions(-) create mode 100644 drivers/gpu/ipu-v3/Kconfig create mode 100644 drivers/gpu/ipu-v3/Makefile create mode 100644 drivers/gpu/ipu-v3/ipu-common.c create mode 100644 drivers/gpu/ipu-v3/ipu-dc.c create mode 100644 drivers/gpu/ipu-v3/ipu-di.c create mode 100644 drivers/gpu/ipu-v3/ipu-dmfc.c create mode 100644 drivers/gpu/ipu-v3/ipu-dp.c create mode 100644 drivers/gpu/ipu-v3/ipu-prv.h delete mode 100644 drivers/staging/imx-drm/ipu-v3/Makefile delete mode 100644 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h delete mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-common.c delete mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dc.c delete mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-di.c delete mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c delete mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dp.c delete mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-prv.h create mode 100644 include/video/imx-ipu-v3.h -- 1.8.5.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3] imx-drm: Move IPU_PIX_FMT_GBR24 definition into imx-ipu-v3.h
The IPU display controller supports a non-standard green-red-blue ordered
format that is used on the connection between IPU display interface 1 and
the TV encoder on i.MX53.
In preparation for the move of IPU core code out of staging, place the
IPU_PIX_FMT_GBR24 definition in imx-ipu-v3.h, so that both the IPU
display interface driver and the TVE encoder driver can access it.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/staging/imx-drm/imx-drm.h | 4
drivers/staging/imx-drm/imx-tve.c | 1 +
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 2 ++
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-drm.h
b/drivers/staging/imx-drm/imx-drm.h
index aa21028..035ab62 100644
--- a/drivers/staging/imx-drm/imx-drm.h
+++ b/drivers/staging/imx-drm/imx-drm.h
@@ -1,10 +1,6 @@
#ifndef _IMX_DRM_H_
#define _IMX_DRM_H_
-#include linux/videodev2.h
-
-#define IPU_PIX_FMT_GBR24 v4l2_fourcc('G', 'B', 'R', '3')
-
struct device_node;
struct drm_crtc;
struct drm_connector;
diff --git a/drivers/staging/imx-drm/imx-tve.c
b/drivers/staging/imx-drm/imx-tve.c
index 702c0c3..50b25f1 100644
--- a/drivers/staging/imx-drm/imx-tve.c
+++ b/drivers/staging/imx-drm/imx-tve.c
@@ -31,6 +31,7 @@
#include drm/drm_fb_helper.h
#include drm/drm_crtc_helper.h
+#include ipu-v3/imx-ipu-v3.h
#include imx-drm.h
#define TVE_COM_CONF_REG 0x00
diff --git a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
index 4826b5c..c4d14ea 100644
--- a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
+++ b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
@@ -25,6 +25,8 @@ enum ipuv3_type {
IPUV3H,
};
+#define IPU_PIX_FMT_GBR24 v4l2_fourcc('G', 'B', 'R', '3')
+
/*
* Bitfield of Display Interface signal polarities.
*/
--
1.8.5.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3] imx-drm: ipu-dc: Use usleep_range instead of msleep
Since msleep(2) can sleep up to 20ms anyway, make this explicit by using
usleep_range(2000, 2).
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index d0e3bc3..d5de8bb 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -262,7 +262,7 @@ void ipu_dc_disable_channel(struct ipu_dc *dc)
/* Wait for DC triple buffer to empty */
while ((readl(priv-dc_reg + DC_STAT) val) != val) {
- msleep(2);
+ usleep_range(2000, 2);
timeout -= 2;
if (timeout = 0)
break;
--
1.8.5.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3] gpu: ipu-v3: Move i.MX IPUv3 core driver out of staging
The i.MX Image Processing Unit (IPU) contains a number of image processing
blocks that sit right in the middle between DRM and V4L2. Some of the modules,
such as Display Controller, Processor, and Interface (DC, DP, DI) or CMOS
Sensor Interface (CSI) and their FIFOs could be assigned to either framework,
but others, such as the dma controller (IDMAC) and image converter (IC) can
be used by both.
The IPUv3 core driver provides an internal API to access the modules, to be
used by both DRM and V4L2 IPUv3 drivers.
Signed-off-by: Lucas Stach l.st...@pengutronix.de
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/gpu/Makefile | 1 +
drivers/gpu/ipu-v3/Kconfig| 7 +++
drivers/{staging/imx-drm = gpu}/ipu-v3/Makefile | 2 +-
drivers/{staging/imx-drm = gpu}/ipu-v3/ipu-common.c | 2 +-
drivers/{staging/imx-drm = gpu}/ipu-v3/ipu-dc.c | 3 +--
drivers/{staging/imx-drm = gpu}/ipu-v3/ipu-di.c | 2 +-
drivers/{staging/imx-drm = gpu}/ipu-v3/ipu-dmfc.c| 2 +-
drivers/{staging/imx-drm = gpu}/ipu-v3/ipu-dp.c | 2 +-
drivers/{staging/imx-drm = gpu}/ipu-v3/ipu-prv.h | 2 +-
drivers/staging/imx-drm/Kconfig | 11 +--
drivers/staging/imx-drm/Makefile | 1 -
drivers/staging/imx-drm/imx-tve.c | 2 +-
drivers/staging/imx-drm/ipuv3-crtc.c | 2 +-
drivers/staging/imx-drm/ipuv3-plane.c | 2 +-
drivers/video/Kconfig | 1 +
.../staging/imx-drm/ipu-v3 = include/video}/imx-ipu-v3.h | 0
16 files changed, 20 insertions(+), 22 deletions(-)
create mode 100644 drivers/gpu/ipu-v3/Kconfig
rename drivers/{staging/imx-drm = gpu}/ipu-v3/Makefile (59%)
rename drivers/{staging/imx-drm = gpu}/ipu-v3/ipu-common.c (99%)
rename drivers/{staging/imx-drm = gpu}/ipu-v3/ipu-dc.c (99%)
rename drivers/{staging/imx-drm = gpu}/ipu-v3/ipu-di.c (99%)
rename drivers/{staging/imx-drm = gpu}/ipu-v3/ipu-dmfc.c (99%)
rename drivers/{staging/imx-drm = gpu}/ipu-v3/ipu-dp.c (99%)
rename drivers/{staging/imx-drm = gpu}/ipu-v3/ipu-prv.h (99%)
rename {drivers/staging/imx-drm/ipu-v3 = include/video}/imx-ipu-v3.h (100%)
diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index d8a22c2..70da9eb 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -1,2 +1,3 @@
obj-y += drm/ vga/
obj-$(CONFIG_TEGRA_HOST1X) += host1x/
+obj-$(CONFIG_IMX_IPUV3_CORE) += ipu-v3/
diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
new file mode 100644
index 000..2f228a2
--- /dev/null
+++ b/drivers/gpu/ipu-v3/Kconfig
@@ -0,0 +1,7 @@
+config IMX_IPUV3_CORE
+ tristate IPUv3 core support
+ depends on SOC_IMX5 || SOC_IMX6Q || SOC_IMX6SL || ARCH_MULTIPLATFORM
+ depends on RESET_CONTROLLER
+ help
+ Choose this if you have a i.MX5/6 system and want to use the Image
+ Processing Unit. This option only enables IPU base support.
diff --git a/drivers/staging/imx-drm/ipu-v3/Makefile
b/drivers/gpu/ipu-v3/Makefile
similarity index 59%
rename from drivers/staging/imx-drm/ipu-v3/Makefile
rename to drivers/gpu/ipu-v3/Makefile
index 28ed72e..d21cc37 100644
--- a/drivers/staging/imx-drm/ipu-v3/Makefile
+++ b/drivers/gpu/ipu-v3/Makefile
@@ -1,3 +1,3 @@
-obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += imx-ipu-v3.o
+obj-$(CONFIG_IMX_IPUV3_CORE) += imx-ipu-v3.o
imx-ipu-v3-objs := ipu-common.o ipu-dc.o ipu-di.o ipu-dp.o ipu-dmfc.o
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
b/drivers/gpu/ipu-v3/ipu-common.c
similarity index 99%
rename from drivers/staging/imx-drm/ipu-v3/ipu-common.c
rename to drivers/gpu/ipu-v3/ipu-common.c
index ca85d3d..7e1f614 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -31,7 +31,7 @@
#include drm/drm_fourcc.h
-#include imx-ipu-v3.h
+#include video/imx-ipu-v3.h
#include ipu-prv.h
static inline u32 ipu_cm_read(struct ipu_soc *ipu, unsigned offset)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
b/drivers/gpu/ipu-v3/ipu-dc.c
similarity index 99%
rename from drivers/staging/imx-drm/ipu-v3/ipu-dc.c
rename to drivers/gpu/ipu-v3/ipu-dc.c
index d5de8bb..9f1e5ef 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/gpu/ipu-v3/ipu-dc.c
@@ -20,8 +20,7 @@
#include linux/delay.h
#include linux/io.h
-#include ../imx-drm.h
-#include imx-ipu-v3.h
+#include video/imx-ipu-v3.h
#include ipu-prv.h
#define DC_MAP_CONF_PTR(n) (0x108 + ((n) ~0x1) * 2)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
b/drivers/gpu/ipu-v3/ipu-di.c
similarity index 99%
rename from drivers/staging/imx-drm/ipu-v3/ipu-di.c
rename to drivers/gpu/ipu-v3/ipu-di.c
index 82a9eba..42e60b4 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
+++
Re: [PATCH 3/3] gpu: ipu-v3: Move i.MX IPUv3 core driver out of staging
Am Dienstag, den 25.02.2014, 12:43 +0100 schrieb Philipp Zabel: The i.MX Image Processing Unit (IPU) contains a number of image processing blocks that sit right in the middle between DRM and V4L2. Some of the modules, such as Display Controller, Processor, and Interface (DC, DP, DI) or CMOS Sensor Interface (CSI) and their FIFOs could be assigned to either framework, but others, such as the dma controller (IDMAC) and image converter (IC) can be used by both. The IPUv3 core driver provides an internal API to access the modules, to be used by both DRM and V4L2 IPUv3 drivers. [...] This one is missing: diff --git a/drivers/staging/imx-drm/imx-hdmi.c b/drivers/staging/imx-drm/imx-hdmi.c index cb4eb76..9aeb863 100644 --- a/drivers/staging/imx-drm/imx-hdmi.c +++ b/drivers/staging/imx-drm/imx-hdmi.c @@ -28,7 +28,8 @@ #include drm/drm_edid.h #include drm/drm_encoder_slave.h -#include ipu-v3/imx-ipu-v3.h +#include video/imx-ipu-v3.h + #include imx-hdmi.h #include imx-drm.h regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 2/2] hyperv-fb: kick off efifb early
Remove firmware framebuffer before initializing hyperv-fb. Needed on gen2 virtual machines. Letting register_framebuffer handle the switchover results in efifb still being active while hyperv graphics are initialized, which in turn can make the linux kernel hang. Signed-off-by: Gerd Hoffmann kra...@redhat.com --- drivers/video/hyperv_fb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c index b7b3dd0..1b11886 100644 --- a/drivers/video/hyperv_fb.c +++ b/drivers/video/hyperv_fb.c @@ -683,6 +683,7 @@ static int hvfb_getmem(struct fb_info *info) info-apertures-ranges[0].base = pci_resource_start(pdev, 0); info-apertures-ranges[0].size = pci_resource_len(pdev, 0); } + remove_conflicting_framebuffers(info-apertures, KBUILD_MODNAME, false); info-fix.smem_start = par-mem.start; info-fix.smem_len = screen_fb_size; -- 1.8.3.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 1/2] hyperv-fb: add support for generation 2 virtual machines.
UEFI-based generation 2 virtual machines support vmbus devices only.
There is no pci bus. Thus they use a different mechanism for the
graphics framebuffer: Instead of using the vga pci bar a chunk of
memory muct be allocated from the hyperv mmio region declared using
APCI. This patch implements support for it.
Based on a patch by Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
drivers/video/hyperv_fb.c | 86 +--
1 file changed, 60 insertions(+), 26 deletions(-)
diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
index 130708f..b7b3dd0 100644
--- a/drivers/video/hyperv_fb.c
+++ b/drivers/video/hyperv_fb.c
@@ -42,6 +42,7 @@
#include linux/completion.h
#include linux/fb.h
#include linux/pci.h
+#include linux/efi.h
#include linux/hyperv.h
@@ -212,6 +213,7 @@ struct synthvid_msg {
struct hvfb_par {
struct fb_info *info;
+ struct resource mem;
bool fb_ready; /* fb device is ready */
struct completion wait;
u32 synthvid_version;
@@ -460,13 +462,13 @@ static int synthvid_connect_vsp(struct hv_device *hdev)
goto error;
}
- if (par-synthvid_version == SYNTHVID_VERSION_WIN7) {
+ if (par-synthvid_version == SYNTHVID_VERSION_WIN7)
screen_depth = SYNTHVID_DEPTH_WIN7;
- screen_fb_size = SYNTHVID_FB_SIZE_WIN7;
- } else {
+ else
screen_depth = SYNTHVID_DEPTH_WIN8;
- screen_fb_size = SYNTHVID_FB_SIZE_WIN8;
- }
+
+ screen_fb_size = hdev-channel-offermsg.offer.
+ mmio_megabytes * 1024 * 1024;
return 0;
@@ -627,26 +629,46 @@ static void hvfb_get_option(struct fb_info *info)
/* Get framebuffer memory from Hyper-V video pci space */
static int hvfb_getmem(struct fb_info *info)
{
- struct pci_dev *pdev;
- ulong fb_phys;
+ struct hvfb_par *par = info-par;
+ struct pci_dev *pdev = NULL;
void __iomem *fb_virt;
+ int gen2vm = efi_enabled(EFI_BOOT);
+ int ret;
- pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
+ par-mem.name = KBUILD_MODNAME;
+ par-mem.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+ if (gen2vm) {
+ ret = allocate_resource(hyperv_mmio, par-mem,
+ screen_fb_size,
+ 0, -1,
+ screen_fb_size,
+ NULL, NULL);
+ if (ret != 0) {
+ pr_err(Unable to allocate framebuffer memory\n);
+ return -ENODEV;
+ }
+ } else {
+ pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
- if (!pdev) {
- pr_err(Unable to find PCI Hyper-V video\n);
- return -ENODEV;
- }
+ if (!pdev) {
+ pr_err(Unable to find PCI Hyper-V video\n);
+ return -ENODEV;
+ }
- if (!(pci_resource_flags(pdev, 0) IORESOURCE_MEM) ||
- pci_resource_len(pdev, 0) screen_fb_size)
- goto err1;
+ if (!(pci_resource_flags(pdev, 0) IORESOURCE_MEM) ||
+ pci_resource_len(pdev, 0) screen_fb_size)
+ goto err1;
- fb_phys = pci_resource_end(pdev, 0) - screen_fb_size + 1;
- if (!request_mem_region(fb_phys, screen_fb_size, KBUILD_MODNAME))
- goto err1;
+ par-mem.end = pci_resource_end(pdev, 0);
+ par-mem.start = par-mem.end - screen_fb_size + 1;
+ ret = request_resource(pdev-resource[0], par-mem);
+ if (ret != 0) {
+ pr_err(Unable to request framebuffer memory\n);
+ goto err1;
+ }
+ }
- fb_virt = ioremap(fb_phys, screen_fb_size);
+ fb_virt = ioremap(par-mem.start, screen_fb_size);
if (!fb_virt)
goto err2;
@@ -654,30 +676,42 @@ static int hvfb_getmem(struct fb_info *info)
if (!info-apertures)
goto err3;
- info-apertures-ranges[0].base = pci_resource_start(pdev, 0);
- info-apertures-ranges[0].size = pci_resource_len(pdev, 0);
- info-fix.smem_start = fb_phys;
+ if (gen2vm) {
+ info-apertures-ranges[0].base = screen_info.lfb_base;
+ info-apertures-ranges[0].size = screen_info.lfb_size;
+ } else {
+ info-apertures-ranges[0].base = pci_resource_start(pdev, 0);
+ info-apertures-ranges[0].size = pci_resource_len(pdev, 0);
+ }
+
+ info-fix.smem_start = par-mem.start;
info-fix.smem_len = screen_fb_size;
info-screen_base = fb_virt;
info-screen_size = screen_fb_size;
-
[PATCH v4 0/2] hyperv-fb: add support for generation 2 virtual machines.
Hi, This patch series adds support for uefi-based gen2 virtual machines to the hyperv-fb driver. It depends on a few vmbus changes which are staged in Greg's char-misc tree (and linux-next). Patch #1 implements gen2 vm support for hyperv-fb. Patch #2 unregisters efifb early to make sure the framebuffer isn't used any more while hyperv-fb initialization is in progress. v4 changes: - use KBUILD_MODNAME everywhere for consistent naming. - drop the two patches which Greg has staged in char-misc. please apply, Gerd Gerd Hoffmann (2): hyperv-fb: add support for generation 2 virtual machines. hyperv-fb: kick off efifb early drivers/video/hyperv_fb.c | 87 +-- 1 file changed, 61 insertions(+), 26 deletions(-) -- 1.8.3.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: comedi: Fix line length exceeding 80 characters
On Tue, 2014-02-25 at 14:05 +0300, Dan Carpenter wrote: On Tue, Feb 25, 2014 at 01:59:25AM -0800, Joe Perches wrote: On Tue, 2014-02-25 at 09:46 +, Ian Abbott wrote: On 2014-02-24 16:49, Monam Agarwal wrote: [] diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c [] @@ -1481,7 +1481,8 @@ static int do_cmd_ioctl(struct comedi_device *dev, async-cmd.data = NULL; /* load channel/gain list */ async-cmd.chanlist = memdup_user(user_chanlist, - async-cmd.chanlist_len * sizeof(int)); + async-cmd.chanlist_len + * sizeof(int)); The `*` operator should go at the end of the line according to the CodingStyle. I don't believe there's a CodingStyle guide for this. Meanwhile you have felt totally justified in correcting me on this in the past. :P Doubtful. You're probably thinking of something else. Besides, we generally agree on style. Anything I may have written was more more suggestion than correction. Anyway, it should be that the operator goes on the first line like Ian says... Feel free to use whatever style you want. Feel free to update CodingStyle too. cheers, Joe ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings
This patch updates the device tree binding documentation for i.MX IPU/display
nodes using the OF graph bindings documented in
Documentation/devicetree/bindings/media/video-interfaces.txt.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
.../bindings/staging/imx-drm/fsl-imx-drm.txt | 48 +++---
.../devicetree/bindings/staging/imx-drm/ldb.txt| 20 +++--
2 files changed, 59 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index b876d49..bfa19a4 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -1,3 +1,22 @@
+Freescale i.MX DRM master device
+
+
+The freescale i.MX DRM master device is a virtual device needed to list all
+IPU or other display interface nodes that comprise the graphics subsystem.
+
+Required properties:
+- compatible: Should be fsl,imx-drm
+- ports: Should contain a list of phandles pointing to display interface ports
+ of IPU devices
+
+example:
+
+imx-drm {
+ compatible = fsl,imx-drm;
+ ports = ipu_di0;
+};
+
+
Freescale i.MX IPUv3
@@ -7,18 +26,31 @@ Required properties:
datasheet
- interrupts: Should contain sync interrupt and error interrupt,
in this order.
-- #crtc-cells: 1, See below
- resets: phandle pointing to the system reset controller and
reset line index, see reset/fsl,imx-src.txt for details
+Optional properties:
+- port@[0-3]: Port nodes with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ Ports 0 and 1 should correspond to CSI0 and CSI1,
+ ports 2 and 3 should correspond to DI0 and DI1, respectively.
example:
ipu: ipu@1800 {
- #crtc-cells = 1;
+ #address-cells = 1;
+ #size-cells = 0;
compatible = fsl,imx53-ipu;
reg = 0x1800 0x08000;
interrupts = 11 10;
resets = src 2;
+
+ ipu_di0: port@2 {
+ reg = 2;
+
+ ipu_di0_disp0: endpoint {
+ remote-endpoint = display_in;
+ };
+ };
};
Parallel display support
@@ -26,19 +58,25 @@ Parallel display support
Required properties:
- compatible: Should be fsl,imx-parallel-display
-- crtc: the crtc this display is connected to, see below
Optional properties:
- interface_pix_fmt: How this display is connected to the
- crtc. Currently supported types: rgb24, rgb565, bgr666
+ display interface. Currently supported types: rgb24, rgb565, bgr666
- edid: verbatim EDID data block describing attached display.
- ddc: phandle describing the i2c bus handling the display data
channel
+- port: A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
example:
display@di0 {
compatible = fsl,imx-parallel-display;
edid = [edid-data];
- crtc = ipu 0;
interface-pix-fmt = rgb24;
+
+ port {
+ display_in: endpoint {
+ remote-endpoint = ipu_di0_disp0;
+ };
+ };
};
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
index ed93778..578a1fc 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
@@ -50,12 +50,14 @@ have a look at
Documentation/devicetree/bindings/video/display-timing.txt.
Required properties:
- reg : should be 0 or 1
- - crtcs : a list of phandles with index pointing to the IPU display interfaces
- that can be used as video source for this channel.
- fsl,data-mapping : should be spwg or jeida
This describes how the color bits are laid out in the
serialized LVDS signal.
- fsl,data-width : should be 18 or 24
+ - port: A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ On i.MX6, there should be four ports (port@[0-3]) that correspond
+ to the four LVDS multiplexer inputs.
example:
@@ -77,23 +79,33 @@ ldb: ldb@53fa8008 {
lvds-channel@0 {
reg = 0;
- crtcs = ipu 0;
fsl,data-mapping = spwg;
fsl,data-width = 24;
display-timings {
/* ... */
};
+
+ port {
+ lvds0_in: endpoint {
+ remote-endpoint = ipu_di0_lvds0;
+ };
+ };
};
lvds-channel@1 {
reg = 1;
- crtcs = ipu 1;
fsl,data-mapping = spwg;
fsl,data-width = 24;
[RFC PATCH v4 8/8] staging: imx-drm: Update TODO
The device tree bindings are updated regardless of the common display framework and in the meantime the HDMI driver was included. Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- drivers/staging/imx-drm/TODO | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO index 6a9da94..29636fb 100644 --- a/drivers/staging/imx-drm/TODO +++ b/drivers/staging/imx-drm/TODO @@ -1,15 +1,10 @@ TODO: - get DRM Maintainer review for this code -- Wait for common display framework to hit mainline and update the IPU - driver to use it. This will most probably make changes to the devicetree - bindings necessary. -- Factor out more code to common helper functions - decide where to put the base driver. It is not specific to a subsystem and would be used by DRM/KMS and media/V4L2 Missing features (not necessarily for moving out of staging): -- Add i.MX6 HDMI support - Add support for IC (Image converter) - Add support for CSI (CMOS Sensor interface) - Add support for VDIC (Video Deinterlacer) -- 1.8.5.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH v4 7/8] ARM: dts: imx6qdl: Add IPU DI ports and endpoints, move imx-drm node to dtsi
This patch connects IPU and display encoder (HDMI, LVDS, MIPI)
device tree nodes, as well as parallel displays on the DISP0
and DISP1 outputs, using the OF graph bindings described in
Documentation/devicetree/bindings/media/video-interfaces.txt
The IPU ports correspond to the two display interfaces. The
order of endpoints in the ports is arbitrary.
Each encoder with an associated input multiplexer has multiple
input ports in the device tree. The order and reg property of
the ports must correspond to the multiplexer input order.
Since the imx-drm node now only needs to contain links to the
display interfaces, it can be moved to the SoC dtsi level. At
the board level, only connections between the display interface
ports and encoders or panels have to be added.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v3:
- Removed port@4 output nodes from lvds-channel nodes for now.
---
arch/arm/boot/dts/imx6dl.dtsi | 22 +++---
arch/arm/boot/dts/imx6q-sabresd.dts| 4 --
arch/arm/boot/dts/imx6q.dtsi | 124 ++--
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 6 --
arch/arm/boot/dts/imx6qdl.dtsi | 128 -
5 files changed, 253 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 6dc3970..8ba94b8 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -70,6 +70,15 @@
};
};
};
+
+ imx-drm {
+ compatible = fsl,imx-drm;
+ ports = ipu1_di0, ipu1_di1;
+ };
+};
+
+hdmi {
+ compatible = fsl,imx6dl-hdmi;
};
ldb {
@@ -79,17 +88,4 @@
clock-names = di0_pll, di1_pll,
di0_sel, di1_sel,
di0, di1;
-
- lvds-channel@0 {
- crtcs = ipu1 0, ipu1 1;
- };
-
- lvds-channel@1 {
- crtcs = ipu1 0, ipu1 1;
- };
-};
-
-hdmi {
- compatible = fsl,imx6dl-hdmi;
- crtcs = ipu1 0, ipu1 1;
};
diff --git a/arch/arm/boot/dts/imx6q-sabresd.dts
b/arch/arm/boot/dts/imx6q-sabresd.dts
index 66f220a..9cbdfe7 100644
--- a/arch/arm/boot/dts/imx6q-sabresd.dts
+++ b/arch/arm/boot/dts/imx6q-sabresd.dts
@@ -20,10 +20,6 @@
compatible = fsl,imx6q-sabresd, fsl,imx6q;
};
-imx_drm {
- crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
-};
-
sata {
status = okay;
};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 187fe33..db356e6 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -132,13 +132,84 @@
};
ipu2: ipu@0280 {
- #crtc-cells = 1;
+ #address-cells = 1;
+ #size-cells = 0;
compatible = fsl,imx6q-ipu;
reg = 0x0280 0x40;
interrupts = 0 8 0x4 0 7 0x4;
clocks = clks 133, clks 134, clks 137;
clock-names = bus, di0, di1;
resets = src 4;
+
+ ipu2_di0: port@2 {
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 2;
+
+ ipu2_di0_disp0: endpoint@0 {
+ };
+
+ ipu2_di0_hdmi: endpoint@1 {
+ remote-endpoint = hdmi_mux_2;
+ };
+
+ ipu2_di0_mipi: endpoint@2 {
+ };
+
+ ipu2_di0_lvds0: endpoint@3 {
+ remote-endpoint = lvds0_mux_2;
+ };
+
+ ipu2_di0_lvds1: endpoint@4 {
+ remote-endpoint = lvds1_mux_2;
+ };
+ };
+
+ ipu2_di1: port@3 {
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 3;
+
+ ipu2_di1_hdmi: endpoint@1 {
+ remote-endpoint = hdmi_mux_3;
+ };
+
+ ipu2_di1_mipi: endpoint@2 {
+ };
+
+ ipu2_di1_lvds0: endpoint@3 {
+ remote-endpoint = lvds0_mux_3;
+ };
+
+ ipu2_di1_lvds1: endpoint@4 {
+ remote-endpoint = lvds1_mux_3;
+ };
+ };
+ };
+ };
+
+ imx-drm {
+ compatible = fsl,imx-drm;
+
[RFC PATCH v4 1/8] staging: imx-drm-core: Use OF graph to find components and connections between encoder and crtcs
From: Philipp Zabel philipp.za...@gmail.com
This patch adds support to find the involved components connected to
the IPU display interface ports using the OF graph bindings documented
in Documentation/devicetree/bindings/media/video-interfaces.txt.
It makes use of the of_graph (formerly v4l2_of) parsing helpers and
thus depends on the patch that moves those out to drivers/of.
Each display interface needs to have an associated port node in the
device tree. We can associate this node with the crtc platform device
and use it to find the crtc corresponding to a given port node instead
of using a combination of parent device node and id number, as before.
Explicitly converting the void* cookie to the port device tree node
allows to get rid of the ipu_id and di_id fields. The multiplexer
setting on i.MX6 now can be obtained from the port id (reg property)
in the device tree.
The imx-drm node now needs a ports property that contains phandles
to each of the IPU display interface port nodes. From there, all
attached encoders are scanned and enabled encoders are added to a
waiting list.
The bind order makes sure that once all components are probed, crtcs
are bound before encoders, so that imx_drm_encoder_parse_of can be
called from the encoder bind callbacks.
For parsing the OF graph, temporary copies of the V4L2 OF graph
helpers are used, that can be removed again once those are available
at a generic place.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v3:
- Retain -EPROBE_DEFER behavior in imx_drm_encoder_parse_of
- Use of_graph helpers in drivers/of
---
drivers/staging/imx-drm/imx-drm-core.c | 215 +++--
drivers/staging/imx-drm/imx-drm.h | 5 +-
drivers/staging/imx-drm/imx-hdmi.c | 2 +-
drivers/staging/imx-drm/imx-ldb.c | 4 +-
drivers/staging/imx-drm/ipuv3-crtc.c | 47 +--
5 files changed, 198 insertions(+), 75 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-drm-core.c
b/drivers/staging/imx-drm/imx-drm-core.c
index dcba518..01bc1cf 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -17,6 +17,7 @@
#include linux/device.h
#include linux/fb.h
#include linux/module.h
+#include linux/of_graph.h
#include linux/platform_device.h
#include drm/drmP.h
#include drm/drm_fb_helper.h
@@ -30,6 +31,11 @@
struct imx_drm_crtc;
+struct imx_drm_component {
+ struct device_node *of_node;
+ struct list_head list;
+};
+
struct imx_drm_device {
struct drm_device *drm;
struct imx_drm_crtc *crtc[MAX_CRTC];
@@ -41,9 +47,7 @@ struct imx_drm_crtc {
struct drm_crtc *crtc;
int pipe;
struct imx_drm_crtc_helper_funcsimx_drm_helper_funcs;
- void*cookie;
- int id;
- int mux_id;
+ struct device_node *port;
};
static int legacyfb_depth = 16;
@@ -341,14 +345,11 @@ err_kms:
/*
* imx_drm_add_crtc - add a new crtc
- *
- * The return value if !NULL is a cookie for the caller to pass to
- * imx_drm_remove_crtc later.
*/
int imx_drm_add_crtc(struct drm_device *drm, struct drm_crtc *crtc,
struct imx_drm_crtc **new_crtc,
const struct imx_drm_crtc_helper_funcs *imx_drm_helper_funcs,
- void *cookie, int id)
+ struct device_node *port)
{
struct imx_drm_device *imxdrm = drm-dev_private;
struct imx_drm_crtc *imx_drm_crtc;
@@ -370,9 +371,7 @@ int imx_drm_add_crtc(struct drm_device *drm, struct
drm_crtc *crtc,
imx_drm_crtc-imx_drm_helper_funcs = *imx_drm_helper_funcs;
imx_drm_crtc-pipe = imxdrm-pipes++;
- imx_drm_crtc-cookie = cookie;
- imx_drm_crtc-id = id;
- imx_drm_crtc-mux_id = imx_drm_crtc-pipe;
+ imx_drm_crtc-port = port;
imx_drm_crtc-crtc = crtc;
imxdrm-crtc[imx_drm_crtc-pipe] = imx_drm_crtc;
@@ -416,49 +415,56 @@ int imx_drm_remove_crtc(struct imx_drm_crtc *imx_drm_crtc)
EXPORT_SYMBOL_GPL(imx_drm_remove_crtc);
/*
- * Find the DRM CRTC possible mask for the device node cookie/id.
+ * Find the DRM CRTC possible mask for the connected endpoint.
*
* The encoder possible masks are defined by their position in the
* mode_config crtc_list. This means that CRTCs must not be added
* or removed once the DRM device has been fully initialised.
*/
static uint32_t imx_drm_find_crtc_mask(struct imx_drm_device *imxdrm,
- void *cookie, int id)
+ struct device_node *endpoint)
{
+ struct device_node *port;
unsigned i;
+ port = of_graph_get_remote_port(endpoint);
+ if (!port)
+ return 0;
+ of_node_put(port);
+
for (i = 0; i MAX_CRTC; i++) {
struct imx_drm_crtc
[RFC PATCH v4 0/8] imx-drm dt bindings
Hi, here is an updated version of the imx-drm DT binding series. These patches apply on top of Russell's imx-drm-staging branch that just got merged int staging-next. I have added device tree bindings between IPU and the encoders as documented in Documentation/devicetree/bindings/media/video-interfaces.txt and used those to determine the possible_crtcs and mux_id, and to find all necessary components that hang off of the display interface ports. This allows to move the imx-drm node into the SoC level dtsi. The existing i.MX51 and i.MX53 device trees are updated and device tree binding documentation is included. Changes since v3: - Kept the -EPROBE_DEFER in of_parse_endpoint and removed LVDS output ports for now. This can be revisited once drm_panel support is added. - Dropped the temporary of_graph helper copies, so this depends on the patch that moves the v4l2_of helpers to drivers/of. regards Philipp Philipp Zabel (8): staging: imx-drm-core: Use OF graph to find components and connections between encoder and crtcs staging: imx-drm-core: use of_graph_parse_endpoint staging: imx-drm: Document updated imx-drm device tree bindings staging: imx-drm: Document imx-hdmi device tree bindings ARM: dts: imx51: Add IPU ports and endpoints, move imx-drm node to dtsi ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to dtsi ARM: dts: imx6qdl: Add IPU DI ports and endpoints, move imx-drm node to dtsi staging: imx-drm: Update TODO .../bindings/staging/imx-drm/fsl-imx-drm.txt | 48 - .../devicetree/bindings/staging/imx-drm/hdmi.txt | 53 + .../devicetree/bindings/staging/imx-drm/ldb.txt| 20 +- arch/arm/boot/dts/imx51-apf51dev.dts | 11 +- arch/arm/boot/dts/imx51-babbage.dts| 28 ++- arch/arm/boot/dts/imx51.dtsi | 22 ++- arch/arm/boot/dts/imx53-m53evk.dts | 17 +- arch/arm/boot/dts/imx53-mba53.dts | 15 +- arch/arm/boot/dts/imx53-qsb.dts| 17 +- arch/arm/boot/dts/imx53.dtsi | 64 +- arch/arm/boot/dts/imx6dl.dtsi | 22 +-- arch/arm/boot/dts/imx6q-sabresd.dts| 4 - arch/arm/boot/dts/imx6q.dtsi | 124 +++- arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 6 - arch/arm/boot/dts/imx6qdl.dtsi | 128 +++- drivers/staging/imx-drm/TODO | 5 - drivers/staging/imx-drm/imx-drm-core.c | 215 +++-- drivers/staging/imx-drm/imx-drm.h | 5 +- drivers/staging/imx-drm/imx-hdmi.c | 2 +- drivers/staging/imx-drm/imx-ldb.c | 4 +- drivers/staging/imx-drm/ipuv3-crtc.c | 47 - 21 files changed, 703 insertions(+), 154 deletions(-) create mode 100644 Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt -- 1.8.5.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH v4 5/8] ARM: dts: imx51: Add IPU ports and endpoints, move imx-drm node to dtsi
This patch connects IPU and and parallel display device tree
nodes using the OF graph bindings described in
Documentation/devicetree/bindings/media/video-interfaces.txt
The IPU ports correspond to the two display interfaces. The
order of endpoints in the ports is arbitrary.
Since the imx-drm node now only needs to contain links to the
display interfaces, it can be moved to the SoC dtsi level. At
the board level, only connections between the display interface
ports and panels have to be added.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
arch/arm/boot/dts/imx51-apf51dev.dts | 11 ++-
arch/arm/boot/dts/imx51-babbage.dts | 28
arch/arm/boot/dts/imx51.dtsi | 22 +-
3 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-apf51dev.dts
b/arch/arm/boot/dts/imx51-apf51dev.dts
index 5a7f552..d3f9814 100644
--- a/arch/arm/boot/dts/imx51-apf51dev.dts
+++ b/arch/arm/boot/dts/imx51-apf51dev.dts
@@ -18,7 +18,6 @@
display@di1 {
compatible = fsl,imx-parallel-display;
- crtcs = ipu 0;
interface-pix-fmt = bgr666;
pinctrl-names = default;
pinctrl-0 = pinctrl_ipu_disp1_1;
@@ -41,6 +40,12 @@
pixelclk-active = 0;
};
};
+
+ port {
+ display_in: endpoint {
+ remote-endpoint = ipu_di0_disp0;
+ };
+ };
};
gpio-keys {
@@ -122,3 +127,7 @@
};
};
};
+
+ipu_di0_disp0 {
+ remote-endpoint = display_in;
+};
diff --git a/arch/arm/boot/dts/imx51-babbage.dts
b/arch/arm/boot/dts/imx51-babbage.dts
index 6ff15a0..6719271 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -23,7 +23,6 @@
display0: display@di0 {
compatible = fsl,imx-parallel-display;
- crtcs = ipu 0;
interface-pix-fmt = rgb24;
pinctrl-names = default;
pinctrl-0 = pinctrl_ipu_disp1_1;
@@ -41,11 +40,16 @@
vsync-len = 10;
};
};
+
+ port {
+ display0_in: endpoint {
+ remote-endpoint = ipu_di0_disp0;
+ };
+ };
};
display1: display@di1 {
compatible = fsl,imx-parallel-display;
- crtcs = ipu 1;
interface-pix-fmt = rgb565;
pinctrl-names = default;
pinctrl-0 = pinctrl_ipu_disp2_1;
@@ -68,6 +72,12 @@
pixelclk-active = 0;
};
};
+
+ port {
+ display1_in: endpoint {
+ remote-endpoint = ipu_di1_disp1;
+ };
+ };
};
gpio-keys {
@@ -81,12 +91,6 @@
};
};
- imx-drm {
- compatible = fsl,imx-drm;
- crtcs = ipu 0, ipu 1;
- connectors = display0, display1;
- };
-
sound {
compatible = fsl,imx51-babbage-sgtl5000,
fsl,imx-audio-sgtl5000;
@@ -264,6 +268,14 @@
};
};
+ipu_di0_disp0 {
+ remote-endpoint = display0_in;
+};
+
+ipu_di1_disp1 {
+ remote-endpoint = display1_in;
+};
+
ssi2 {
fsl,mode = i2s-slave;
status = okay;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 4bcdd3a..536644c 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -79,6 +79,11 @@
};
};
+ imx-drm {
+ compatible = fsl,imx-drm;
+ ports = ipu_di0, ipu_di1;
+ };
+
soc {
#address-cells = 1;
#size-cells = 1;
@@ -92,13 +97,28 @@
};
ipu: ipu@4000 {
- #crtc-cells = 1;
+ #address-cells = 1;
+ #size-cells = 0;
compatible = fsl,imx51-ipu;
reg = 0x4000 0x2000;
interrupts = 11 10;
clocks = clks 59, clks 110, clks 61;
clock-names = bus, di0, di1;
resets = src 2;
+
+ ipu_di0: port@2 {
+ reg = 2;
+
+ ipu_di0_disp0: endpoint {
+ };
+ };
+
+ ipu_di1: port@3 {
+ reg = 3;
+
+ ipu_di1_disp1: endpoint {
+ };
+ };
[RFC PATCH v4 6/8] ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to dtsi
This patch connects IPU and display encoder (VGA, LVDS)
device tree nodes, as well as parallel displays on the DISP0
and DISP1 outputs, using the OF graph bindings described in
Documentation/devicetree/bindings/media/video-interfaces.txt
The IPU ports correspond to the two display interfaces. The
order of endpoints in the ports is arbitrary.
Since the imx-drm node now only needs to contain links to the
display interfaces, it can be moved to the SoC dtsi level. At
the board level, only connections between the display interface
ports and encoders or panels have to be added.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
arch/arm/boot/dts/imx53-m53evk.dts | 17 +-
arch/arm/boot/dts/imx53-mba53.dts | 15 +
arch/arm/boot/dts/imx53-qsb.dts| 17 +-
arch/arm/boot/dts/imx53.dtsi | 64 +++---
4 files changed, 89 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/imx53-m53evk.dts
b/arch/arm/boot/dts/imx53-m53evk.dts
index ee6107b..0298adc 100644
--- a/arch/arm/boot/dts/imx53-m53evk.dts
+++ b/arch/arm/boot/dts/imx53-m53evk.dts
@@ -23,7 +23,6 @@
soc {
display1: display@di1 {
compatible = fsl,imx-parallel-display;
- crtcs = ipu 1;
interface-pix-fmt = bgr666;
pinctrl-names = default;
pinctrl-0 = pinctrl_ipu_disp2_1;
@@ -44,6 +43,12 @@
};
};
};
+
+ port {
+ display1_in: endpoint {
+ remote-endpoint = ipu_di1_disp1;
+ };
+ };
};
backlight {
@@ -53,12 +58,6 @@
default-brightness-level = 6;
};
- imx-drm {
- compatible = fsl,imx-drm;
- crtcs = ipu 1;
- connectors = display1;
- };
-
leds {
compatible = gpio-leds;
pinctrl-names = default;
@@ -227,6 +226,10 @@
};
};
+ipu_di1_disp1 {
+ remote-endpoint = display1_in;
+};
+
nfc {
pinctrl-names = default;
pinctrl-0 = pinctrl_nand_1;
diff --git a/arch/arm/boot/dts/imx53-mba53.dts
b/arch/arm/boot/dts/imx53-mba53.dts
index 9b6e769..3c3d69e 100644
--- a/arch/arm/boot/dts/imx53-mba53.dts
+++ b/arch/arm/boot/dts/imx53-mba53.dts
@@ -38,15 +38,14 @@
compatible = fsl,imx-parallel-display;
pinctrl-names = default;
pinctrl-0 = pinctrl_disp1_1;
- crtcs = ipu 1;
interface-pix-fmt = rgb24;
status = disabled;
- };
- imx-drm {
- compatible = fsl,imx-drm;
- crtcs = ipu 1;
- connectors = disp1, tve;
+ port {
+ display1_in: endpoint {
+ remote-endpoint = ipu_di1_disp1;
+ };
+ };
};
reg_3p2v: 3p2v {
@@ -147,6 +146,10 @@
};
};
+ipu_di1_disp1 {
+ remote-endpoint = display1_in;
+};
+
cspi {
status = okay;
};
diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
index 3cb4f77..8b25428 100644
--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@ -23,7 +23,6 @@
display0: display@di0 {
compatible = fsl,imx-parallel-display;
- crtcs = ipu 0;
interface-pix-fmt = rgb565;
pinctrl-names = default;
pinctrl-0 = pinctrl_ipu_disp0_1;
@@ -46,6 +45,12 @@
pixelclk-active = 0;
};
};
+
+ port {
+ display0_in: endpoint {
+ remote-endpoint = ipu_di0_disp0;
+ };
+ };
};
gpio-keys {
@@ -72,12 +77,6 @@
};
};
- imx-drm {
- compatible = fsl,imx-drm;
- crtcs = ipu 0;
- connectors = display0;
- };
-
leds {
compatible = gpio-leds;
pinctrl-names = default;
@@ -132,6 +131,10 @@
status = okay;
};
+ipu_di0_disp0 {
+ remote-endpoint = display0_in;
+};
+
ssi2 {
fsl,mode = i2s-slave;
status = okay;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 4307e80..5b89b91 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -45,6 +45,11 @@
};
};
+ imx-drm {
+ compatible = fsl,imx-drm;
+ ports = ipu_di0, ipu_di1;
+ };
+
tzic: tz-interrupt-controller@0fffc000 {
compatible = fsl,imx53-tzic, fsl,tzic;
interrupt-controller;
@@ -85,13 +90,49 @@
[RFC PATCH v4 2/8] staging: imx-drm-core: use of_graph_parse_endpoint
Using of_graph_parse_endpoint recovers the port id from an endpoint device
tree node. This just replaces an open coded read of the reg property.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/staging/imx-drm/imx-drm-core.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-drm-core.c
b/drivers/staging/imx-drm/imx-drm-core.c
index 01bc1cf..009805a 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -501,8 +501,9 @@ int imx_drm_encoder_get_mux_id(struct device_node *node,
{
struct imx_drm_crtc *imx_crtc = imx_drm_find_crtc(encoder-crtc);
struct device_node *ep = NULL;
+ struct of_endpoint endpoint;
struct device_node *port;
- int id, ret;
+ int ret;
if (!node || !imx_crtc)
return -EINVAL;
@@ -515,9 +516,8 @@ int imx_drm_encoder_get_mux_id(struct device_node *node,
port = of_graph_get_remote_port(ep);
of_node_put(port);
if (port == imx_crtc-port) {
- ret = of_property_read_u32(ep-parent, reg, id);
- of_node_put(ep);
- return ret ? ret : id;
+ ret = of_graph_parse_endpoint(ep, endpoint);
+ return ret ? ret : endpoint.id;
}
} while (ep);
--
1.8.5.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: comedi: Fix line length exceeding 80 characters
On Tue, Feb 25, 2014 at 09:46:19AM +, Ian Abbott wrote: On 2014-02-24 16:49, Monam Agarwal wrote: Signed-off-by: Monam Agarwal monamagarwal...@gmail.com --- drivers/staging/comedi/comedi_fops.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c index ac1edd9..7da8566 100644 --- a/drivers/staging/comedi/comedi_fops.c +++ b/drivers/staging/comedi/comedi_fops.c @@ -1481,7 +1481,8 @@ static int do_cmd_ioctl(struct comedi_device *dev, async-cmd.data = NULL; /* load channel/gain list */ async-cmd.chanlist = memdup_user(user_chanlist, - async-cmd.chanlist_len * sizeof(int)); + async-cmd.chanlist_len + * sizeof(int)); The `*` operator should go at the end of the line according to the CodingStyle. Which is why I modified it by hand before applying it :) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC]: staging: dgap
I have a couple basic questions concerning the Digi International staging/dgap driver about how I might be able to help clean it up more. 1. This driver has/had a built-in tracing system that during driver and board development that I'm sure was useful to Digi International at the time. Since this driver and board are basically mature, (at least by Digi's standards), can I assume that this code should be removed. 2. When finally getting to the point of running the whole source and include file though checkpatch, should I go in small steps fixing specific checkpatch problem types such as returns, white space, 80 char limits, etc, by individual patches? Or would a one shot patch fixing all that checkpatch finds be OK? Thanks mark ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: et131x: let the freeing of memory more reasonable in error path
On Tue, Feb 25, 2014 at 02:45:53PM +, Alan Cox wrote: On Mon, 2014-02-24 at 16:54 -0800, Greg Kroah-Hartman wrote: On Sat, Feb 22, 2014 at 12:33:36PM +0800, Zhao, Gang wrote: On Fri, 2014-02-21 at 20:35:50 +0800, Dan Carpenter wrote: On Fri, Feb 21, 2014 at 08:22:21PM +0800, Zhao, Gang wrote: If we add your patch and the reviewer does a search for fb[0] then it is confusing what the right thing to do is. My fault. I should remove that two lines of code in et131x_rx_dma_memory_free(), although they don't break the code. Think about what you are saying here for a minute. Oh, a cold makes me stupid. that two lines of code is needed definitively. So is additional modification needed to let this patch be accepted ? As I can't take this as-is, yes. Sorry I'm completely lost here, can someone explain the problem they are seeing after the changes ? There is no problem. Zhao, Gang is just randomly sprinklying kfree()s around to simplify the code... regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/5] staging: rtl8821ae: Fix C99 style comments in pci.c and pci.h
This patch fix C99 style comments in pci.c and pci.h
Signed-off-by: Masanari Iida standby2...@gmail.com
---
drivers/staging/rtl8821ae/pci.c | 10 +-
drivers/staging/rtl8821ae/pci.h | 6 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8821ae/pci.c b/drivers/staging/rtl8821ae/pci.c
index 0600495..a562aa6 100644
--- a/drivers/staging/rtl8821ae/pci.c
+++ b/drivers/staging/rtl8821ae/pci.c
@@ -2428,13 +2428,13 @@ fail1:
return -ENODEV;
}
-//EXPORT_SYMBOL(rtl_pci_probe);
+/* EXPORT_SYMBOL(rtl_pci_probe); */
struct ieee80211_hw *rtl_pci_get_hw_pointer(void)
{
return hw_export;
}
-//EXPORT_SYMBOL(rtl_pci_get_hw_pointer);
+/* EXPORT_SYMBOL(rtl_pci_get_hw_pointer); */
void rtl_pci_disconnect(struct pci_dev *pdev)
{
@@ -2491,7 +2491,7 @@ void rtl_pci_disconnect(struct pci_dev *pdev)
ieee80211_free_hw(hw);
}
-//EXPORT_SYMBOL(rtl_pci_disconnect);
+/* EXPORT_SYMBOL(rtl_pci_disconnect); */
/***
kernel pci power state define:
@@ -2519,7 +2519,7 @@ int rtl_pci_suspend(struct device *dev)
return 0;
}
-//EXPORT_SYMBOL(rtl_pci_suspend);
+/* EXPORT_SYMBOL(rtl_pci_suspend); */
int rtl_pci_resume(struct device *dev)
{
@@ -2532,7 +2532,7 @@ int rtl_pci_resume(struct device *dev)
return 0;
}
-//EXPORT_SYMBOL(rtl_pci_resume);
+/* EXPORT_SYMBOL(rtl_pci_resume); */
struct rtl_intf_ops rtl_pci_ops = {
.read_efuse_byte = read_efuse_byte,
diff --git a/drivers/staging/rtl8821ae/pci.h b/drivers/staging/rtl8821ae/pci.h
index 9d8f0ac..06eaa52 100644
--- a/drivers/staging/rtl8821ae/pci.h
+++ b/drivers/staging/rtl8821ae/pci.h
@@ -148,11 +148,11 @@ struct rtl_pci_capabilities_header {
* RX wifi info == RX descriptor in old flow */
struct rtl_tx_buffer_desc {
#if (RTL8192EE_SEG_NUM == 2)
- u32 dword[2*(DMA_IS_64BIT + 1)*8]; //seg = 8
+ u32 dword[2*(DMA_IS_64BIT + 1)*8]; /* seg = 8 */
#elif (RTL8192EE_SEG_NUM == 1)
- u32 dword[2*(DMA_IS_64BIT + 1)*4]; //seg = 4
+ u32 dword[2*(DMA_IS_64BIT + 1)*4]; /* seg = 4 */
#elif (RTL8192EE_SEG_NUM == 0)
- u32 dword[2*(DMA_IS_64BIT + 1)*2]; //seg = 2
+ u32 dword[2*(DMA_IS_64BIT + 1)*2]; /* seg = 2 */
#endif
} __packed;
--
1.9.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/5] staging: rtl8821ae: Fix C99 style comments in efuse.c
Fix C99 style comments in efuse.c.
Signed-off-by: Masanari Iida standby2...@gmail.com
---
drivers/staging/rtl8821ae/efuse.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/rtl8821ae/efuse.c
b/drivers/staging/rtl8821ae/efuse.c
index d40ffd6..250aae1 100644
--- a/drivers/staging/rtl8821ae/efuse.c
+++ b/drivers/staging/rtl8821ae/efuse.c
@@ -149,7 +149,7 @@ u8 efuse_read_1byte(struct ieee80211_hw *hw, u16 address)
return 0xFF;
}
-//EXPORT_SYMBOL(efuse_read_1byte);
+/* EXPORT_SYMBOL(efuse_read_1byte); */
void efuse_write_1byte(struct ieee80211_hw *hw, u16 address, u8 value)
{
@@ -517,7 +517,7 @@ void rtl_efuse_shadow_map_update(struct ieee80211_hw *hw)
rtlpriv-cfg-maps[EFUSE_HWSET_MAX_SIZE]);
}
-//EXPORT_SYMBOL(rtl_efuse_shadow_map_update);
+/* EXPORT_SYMBOL(rtl_efuse_shadow_map_update); */
void efuse_force_write_vendor_Id(struct ieee80211_hw *hw)
{
@@ -628,7 +628,7 @@ int efuse_one_byte_read(struct ieee80211_hw *hw, u16 addr,
u8 *data)
}
return bresult;
}
-//EXPORT_SYMBOL(efuse_one_byte_read);
+/* EXPORT_SYMBOL(efuse_one_byte_read); */
static int efuse_one_byte_write(struct ieee80211_hw *hw, u16 addr, u8 data)
{
@@ -1120,16 +1120,16 @@ static void efuse_power_switch(struct ieee80211_hw *hw,
u8 bwrite, u8 pwrstate)
{
rtl_write_byte(rtlpriv,
rtlpriv-cfg-maps[EFUSE_ACCESS], 0x69);
- // 1.2V Power: From VDDON with Power Cut(0xh[15]),
default valid
+ /* 1.2V Power: From VDDON with Power Cut(0xh[15]),
default valid */
tmpV16 = rtl_read_word(rtlpriv,
rtlpriv-cfg-maps[SYS_ISO_CTRL]);
printk(SYS_ISO_CTRL=%04x.\n,tmpV16);
if( ! (tmpV16 PWC_EV12V ) ){
tmpV16 |= PWC_EV12V ;
-
//PlatformEFIOWrite2Byte(pAdapter,REG_SYS_ISO_CTRL,tmpV16);
+/*
PlatformEFIOWrite2Byte(pAdapter,REG_SYS_ISO_CTRL,tmpV16); */
}
- // Reset: 0xh[28], default valid
+ /* Reset: 0xh[28], default valid */
tmpV16 = rtl_read_word(rtlpriv,
rtlpriv-cfg-maps[SYS_FUNC_EN]);
printk(SYS_FUNC_EN=%04x.\n,tmpV16);
if( !(tmpV16 FEN_ELDR) ){
@@ -1137,7 +1137,7 @@ static void efuse_power_switch(struct ieee80211_hw *hw,
u8 bwrite, u8 pwrstate)
rtl_write_byte(rtlpriv,
rtlpriv-cfg-maps[SYS_FUNC_EN], tmpV16);
}
- // Clock: Gated(0x0008h[5]) 8M(0x0008h[1]) clock from
ANA, default valid
+ /* Clock: Gated(0x0008h[5]) 8M(0x0008h[1]) clock from
ANA, default valid */
tmpV16 = rtl_read_word(rtlpriv,
rtlpriv-cfg-maps[SYS_CLK] );
printk(SYS_CLK=%04x.\n,tmpV16);
if( (!(tmpV16 LOADER_CLK_EN) ) ||(!(tmpV16 ANA8M)
) )
@@ -1148,7 +1148,7 @@ static void efuse_power_switch(struct ieee80211_hw *hw,
u8 bwrite, u8 pwrstate)
if(bwrite == true)
{
- // Enable LDO 2.5V before read/write action
+ /* Enable LDO 2.5V before read/write action */
tempval = rtl_read_word(rtlpriv,
rtlpriv-cfg-maps[EFUSE_TEST] + 3);
printk(EFUSE_TEST=%04x.\n,tmpV16);
tempval = ~(BIT(3) | BIT(4) |BIT(5) | BIT(6));
@@ -1161,7 +1161,7 @@ static void efuse_power_switch(struct ieee80211_hw *hw,
u8 bwrite, u8 pwrstate)
{
rtl_write_byte(rtlpriv,
rtlpriv-cfg-maps[EFUSE_ACCESS], 0x00);
if(bwrite == true){
- // Disable LDO 2.5V after read/write action
+ /* Disable LDO 2.5V after read/write action */
tempval = rtl_read_word(rtlpriv,
rtlpriv-cfg-maps[EFUSE_TEST] + 3);
rtl_write_byte(rtlpriv,
rtlpriv-cfg-maps[EFUSE_TEST] + 3, (tempval 0x7F));
}
--
1.9.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/5] staging: rtl8821ae: Fix typo in rtl8821ae/rtl8821ae.
Fix spelling typo in comment and printk within
rtl8821ae/rtl8821ae.
Signed-off-by: Masanari Iida standby2...@gmail.com
---
drivers/staging/rtl8821ae/rtl8821ae/dm.c | 24 +--
drivers/staging/rtl8821ae/rtl8821ae/fw.c | 8 +++
.../staging/rtl8821ae/rtl8821ae/hal_bt_coexist.h | 2 +-
drivers/staging/rtl8821ae/rtl8821ae/hal_btc.c | 4 ++--
drivers/staging/rtl8821ae/rtl8821ae/hw.c | 10
drivers/staging/rtl8821ae/rtl8821ae/phy.c | 4 ++--
drivers/staging/rtl8821ae/rtl8821ae/phy.h | 2 +-
drivers/staging/rtl8821ae/rtl8821ae/pwrseq.h | 10
drivers/staging/rtl8821ae/rtl8821ae/pwrseqcmd.c| 2 +-
drivers/staging/rtl8821ae/rtl8821ae/reg.h | 28 +++---
drivers/staging/rtl8821ae/rtl8821ae/sw.c | 4 ++--
drivers/staging/rtl8821ae/rtl8821ae/trx.c | 6 ++---
12 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/dm.c
b/drivers/staging/rtl8821ae/rtl8821ae/dm.c
index 8634206..e0efcd2 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/dm.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/dm.c
@@ -731,7 +731,7 @@ void rtl8821ae_dm_find_minimum_rssi(struct ieee80211_hw *hw)
rtl_dm_dig-min_undecorated_pwdb_for_dm =
rtlpriv-dm.entry_min_undecoratedsmoothed_pwdb;
RT_TRACE(COMP_BB_POWERSAVING, DBG_LOUD,
-(AP Ext Port or disconnet PWDB = 0x%x \n,
+(AP Ext Port or disconnect PWDB = 0x%x \n,
rtl_dm_dig-min_undecorated_pwdb_for_dm));
}
RT_TRACE(COMP_DIG, DBG_LOUD, (MinUndecoratedPWDBForDM =%d\n,
@@ -925,7 +925,7 @@ static void rtl8821ae_dm_dig(struct ieee80211_hw *hw)
if (rtlpriv-falsealm_cnt.cnt_all 1) {
RT_TRACE(COMP_DIG, DBG_LOUD,
- (rtl8821ae_dm_dig(): Abnornally false alarm case.
\n));
+ (rtl8821ae_dm_dig(): Abnormally false alarm case.
\n));
if (dm_digtable.large_fa_hit != 3)
dm_digtable.large_fa_hit++;
@@ -1087,7 +1087,7 @@ static void
rtl8821ae_dm_false_alarm_counter_statistics(struct ieee80211_hw *hw)
else
falsealm_cnt-cnt_all = falsealm_cnt-cnt_ofdm_fail;
- /*reset OFDM FA coutner*/
+ /*reset OFDM FA counter*/
rtl_set_bbreg(hw, ODM_REG_OFDM_FA_RST_11AC, BIT(17), 1);
rtl_set_bbreg(hw, ODM_REG_OFDM_FA_RST_11AC, BIT(17), 0);
/* reset CCK FA counter*/
@@ -1316,7 +1316,7 @@ u8 rtl8812ae_hw_rate_to_mrate(
/*-
* Function: odm_TxPwrTrackSetPwr88E()
*
- * Overview: 88E change all channel tx power accordign to flag.
+ * Overview: 88E change all channel tx power according to flag.
* OFDM CCK are all different.
*
* Input: NONE
@@ -1537,7 +1537,7 @@ void rtl8812ae_dm_txpwr_track_set_pwr(struct ieee80211_hw
*hw,
rtldm-modify_txagc_flag_path_b = false;
RT_TRACE(COMP_POWER_TRACKING, DBG_LOUD,
- (**Path_B
pDM_Odm-Modify_TxAGC_Flag = FALSE \n));
+ (**Path_B
dm_Odm-Modify_TxAGC_Flag = FALSE \n));
}
}
}
@@ -1654,7 +1654,7 @@ void rtl8812ae_dm_txpower_tracking_callback_thermalmeter
if (delta 0 rtldm-txpower_track_control)
{
- /*delta here is used to record the absolute value of
differrence.*/
+ /*delta here is used to record the absolute value of
difference.*/
delta = thermal_value rtlefuse-eeprom_thermalmeter ? \
(thermal_value - rtlefuse-eeprom_thermalmeter) : \
(rtlefuse-eeprom_thermalmeter - thermal_value);
@@ -1976,7 +1976,7 @@ void rtl8821ae_phy_lccalibrate(
/*-
* Function: odm_TxPwrTrackSetPwr88E()
*
- * Overview: 88E change all channel tx power accordign to flag.
+ * Overview: 88E change all channel tx power according to flag.
* OFDM CCK are all different.
*
* Input: NONE
@@ -2159,7 +2159,7 @@ void rtl8821ae_dm_txpower_tracking_callback_thermalmeter
u8 *delta_swing_table_idx_tup_b;
u8 *delta_swing_table_idx_tdown_b;
- /*2. Initilization ( 7 steps in total )*/
+ /*2. Initialization ( 7 steps in total )*/
rtl8821ae_get_delta_swing_table(hw, (u8**)delta_swing_table_idx_tup_a,
(u8**)delta_swing_table_idx_tdown_a,
Re: [PATCH] staging: et131x: let the freeing of memory more reasonable in error path
On Mon, 2014-02-24 at 16:54 -0800, Greg Kroah-Hartman wrote: On Sat, Feb 22, 2014 at 12:33:36PM +0800, Zhao, Gang wrote: On Fri, 2014-02-21 at 20:35:50 +0800, Dan Carpenter wrote: On Fri, Feb 21, 2014 at 08:22:21PM +0800, Zhao, Gang wrote: If we add your patch and the reviewer does a search for fb[0] then it is confusing what the right thing to do is. My fault. I should remove that two lines of code in et131x_rx_dma_memory_free(), although they don't break the code. Think about what you are saying here for a minute. Oh, a cold makes me stupid. that two lines of code is needed definitively. So is additional modification needed to let this patch be accepted ? As I can't take this as-is, yes. Sorry I'm completely lost here, can someone explain the problem they are seeing after the changes ? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC]: staging: dgap
On Tue, Feb 25, 2014 at 09:44:40AM -0500, Mark Hounschell wrote: I have a couple basic questions concerning the Digi International staging/dgap driver about how I might be able to help clean it up more. 1. This driver has/had a built-in tracing system that during driver and board development that I'm sure was useful to Digi International at the time. Since this driver and board are basically mature, (at least by Digi's standards), can I assume that this code should be removed. Yes. 2. When finally getting to the point of running the whole source and include file though checkpatch, should I go in small steps fixing specific checkpatch problem types such as returns, white space, 80 char limits, etc, by individual patches? Or would a one shot patch fixing all that checkpatch finds be OK? One shot is not OK. One thing at a time. Normally for checkpatch.pl it means one type of cleanup at a time, but that's just something we tell newbies because a lot of people struggle with understanding where the line between one thing and multiple things is. (Newbies mess up on both sides of the line). No one wants to review a massive change. If it *only* changes whitespace then a many line patch is not too hard to review. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: dgap: fix compile warnings by remove dead code
The last patch series exposed some dead code causing compile warnings.
This patch removes that dead code and fixes the warnings
Signed-off-by: Mark Hounschell ma...@compro.net
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/staging/dgap/dgap.c | 145
1 file changed, 145 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 21af5fa..7cb1ad5 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -197,9 +197,6 @@ static void dgap_remove_ports_sysfiles(struct board_t *bd);
static void dgap_create_driver_sysfiles(struct pci_driver *);
static void dgap_remove_driver_sysfiles(struct pci_driver *);
-static int dgap_tty_class_init(void);
-static int dgap_tty_class_destroy(void);
-
static void dgap_create_tty_sysfs(struct un_t *un, struct device *c);
static void dgap_remove_tty_sysfs(struct device *c);
@@ -210,12 +207,10 @@ static int dgap_parsefile(char **in, int Remove);
static struct cnode *dgap_find_config(int type, int bus, int slot);
static uint dgap_config_get_number_of_ports(struct board_t *bd);
static char *dgap_create_config_string(struct board_t *bd, char *string);
-static char *dgap_get_config_letters(struct board_t *bd, char *string);
static uint dgap_config_get_useintr(struct board_t *bd);
static uint dgap_config_get_altpin(struct board_t *bd);
static int dgap_ms_sleep(ulong ms);
-static char*dgap_ioctl_name(int cmd);
static voiddgap_do_bios_load(struct board_t *brd, uchar __user *ubios, int
len);
static voiddgap_do_fep_load(struct board_t *brd, uchar __user *ufep, int
len);
#ifdef DIGI_CONCENTRATORS_SUPPORTED
@@ -390,29 +385,6 @@ static struct firmware_info fw_info[] = {
{0,}
};
-static char *dgap_state_text[] = {
- Board Failed,
- Configuration for board not found.\n\t\t\tRun mpi to configure board.,
- Board Found,
- Need Reset,
- Finished Reset,
- Need Config,
- Finished Config,
- Need Device Creation,
- Requested Device Creation,
- Finished Device Creation,
- Need BIOS Load,
- Requested BIOS,
- Doing BIOS Load,
- Finished BIOS Load,
- Need FEP Load,
- Requested FEP,
- Doing FEP Load,
- Finished FEP Load,
- Requested PROC creation,
- Finished PROC creation,
- Board READY,
-};
static char *dgap_driver_state_text[] = {
Driver Initialized,
@@ -1421,57 +1393,6 @@ static int dgap_ms_sleep(ulong ms)
-/*
- * dgap_ioctl_name() : Returns a text version of each ioctl value.
- */
-static char *dgap_ioctl_name(int cmd)
-{
- switch(cmd) {
-
- case TCGETA:return(TCGETA);
- case TCGETS:return(TCGETS);
- case TCSETA:return(TCSETA);
- case TCSETS:return(TCSETS);
- case TCSETAW: return(TCSETAW);
- case TCSETSW: return(TCSETSW);
- case TCSETAF: return(TCSETAF);
- case TCSETSF: return(TCSETSF);
- case TCSBRK:return(TCSBRK);
- case TCXONC:return(TCXONC);
- case TCFLSH:return(TCFLSH);
- case TIOCGSID: return(TIOCGSID);
-
- case TIOCGETD: return(TIOCGETD);
- case TIOCSETD: return(TIOCSETD);
- case TIOCGWINSZ:return(TIOCGWINSZ);
- case TIOCSWINSZ:return(TIOCSWINSZ);
-
- case TIOCMGET: return(TIOCMGET);
- case TIOCMSET: return(TIOCMSET);
- case TIOCMBIS: return(TIOCMBIS);
- case TIOCMBIC: return(TIOCMBIC);
-
- /* from digi.h */
- case DIGI_SETA: return(DIGI_SETA);
- case DIGI_SETAW:return(DIGI_SETAW);
- case DIGI_SETAF:return(DIGI_SETAF);
- case DIGI_SETFLOW: return(DIGI_SETFLOW);
- case DIGI_SETAFLOW: return(DIGI_SETAFLOW);
- case DIGI_GETFLOW: return(DIGI_GETFLOW);
- case DIGI_GETAFLOW: return(DIGI_GETAFLOW);
- case DIGI_GETA: return(DIGI_GETA);
- case DIGI_GEDELAY: return(DIGI_GEDELAY);
- case DIGI_SEDELAY: return(DIGI_SEDELAY);
- case DIGI_GETCUSTOMBAUD: return(DIGI_GETCUSTOMBAUD);
- case DIGI_SETCUSTOMBAUD: return(DIGI_SETCUSTOMBAUD);
- case TIOCMODG: return(TIOCMODG);
- case TIOCMODS: return(TIOCMODS);
- case TIOCSDTR: return(TIOCSDTR);
- case TIOCCDTR: return(TIOCCDTR);
-
- default:return(unknown);
- }
-}
/
*
@@ -8559,69 +8480,3 @@ static char *dgap_create_config_string(struct board_t
*bd, char *string)
*ptr = 0xff;
return string;
}
-
-
-
-static char *dgap_get_config_letters(struct board_t *bd, char *string)
-{
- int found = FALSE;
- char *ptr = string;
-
Re: [RFC PATCH v4 4/8] staging: imx-drm: Document imx-hdmi device tree bindings
On Tue, Feb 25, 2014 at 11:23 AM, Philipp Zabel p.za...@pengutronix.de wrote: This patch adds device tree binding documentation for the HDMI transmitter on i.MX6. Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- .../devicetree/bindings/staging/imx-drm/hdmi.txt | 53 ++ 1 file changed, 53 insertions(+) create mode 100644 Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt diff --git a/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt b/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt new file mode 100644 index 000..7dcd673a --- /dev/null +++ b/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt @@ -0,0 +1,53 @@ +Device-Tree bindings for HDMI Transmitter + +HDMI Transmitter + + +The LVDS Display Bridge device tree node contains up to two lvds-channel +nodes describing each of the two LVDS encoder channels of the bridge. Copy and paste error? ;-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v4 2/2] hyperv-fb: kick off efifb early
-Original Message- From: Gerd Hoffmann [mailto:kra...@redhat.com] Sent: Tuesday, February 25, 2014 7:29 AM To: linux-fb...@vger.kernel.org Cc: linux-ker...@vger.kernel.org; gre...@linuxfoundation.org; KY Srinivasan; Abhishek Gupta (LIS); Haiyang Zhang; jasow...@redhat.com; tomi.valkei...@ti.com; de...@linuxdriverproject.org; Gerd Hoffmann; Jean- Christophe Plagniol-Villard Subject: [PATCH v4 2/2] hyperv-fb: kick off efifb early Remove firmware framebuffer before initializing hyperv-fb. Needed on gen2 virtual machines. Letting register_framebuffer handle the switchover results in efifb still being active while hyperv graphics are initialized, which in turn can make the linux kernel hang. Signed-off-by: Gerd Hoffmann kra...@redhat.com --- drivers/video/hyperv_fb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c index b7b3dd0..1b11886 100644 --- a/drivers/video/hyperv_fb.c +++ b/drivers/video/hyperv_fb.c @@ -683,6 +683,7 @@ static int hvfb_getmem(struct fb_info *info) info-apertures-ranges[0].base = pci_resource_start(pdev, 0); info-apertures-ranges[0].size = pci_resource_len(pdev, 0); } + remove_conflicting_framebuffers(info-apertures, KBUILD_MODNAME, +false); Thanks for the updates. I'm concerned about, after removing efifb, if synthvid_send_config(hdev) fails, then there will be no video driver available. Is there a way to bring the generic driver back if synthvid_send_config(hdev) fails? If no way to recover the generic driver, please limit the early remove_conflicting_framebuffers() to Gen2 VM only. Thanks, - Haiyang ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH RFC only] staging: dgap: fix OOPS on open of port
When opening a port the dgap driver OOPs with a message:
tty_init_dev: driver does not set tty-port... will crash the kernel... fix the
driver... etc...
Then I have to reboot the box.
I think before too much more work is done on this driver (by me anyway),
it should at least be in a usable state. There are a lot more changes to come
and I would like to be able to test along the way.
I've looked at some of the other drivers as examples and come up with this
patch that
does in fact allow me to use the driver. I would like to submit it but am
uncertain that this
is proper.
Thanks for reviewing.
mark
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 7cb1ad5..d56b3b2 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -223,7 +223,7 @@ static void dgap_get_vpd(struct board_t *brd);
static void dgap_do_reset_board(struct board_t *brd);
static void dgap_do_wait_for_bios(struct board_t *brd);
static void dgap_do_wait_for_fep(struct board_t *brd);
-static void dgap_sysfs_create(struct board_t *brd);
+static int dgap_sysfs_create(struct board_t *brd);
static int dgap_firmware_load(struct pci_dev *pdev, int card_type);
/* Driver load/unload functions */
@@ -1098,7 +1098,9 @@ static int dgap_firmware_load(struct pci_dev *pdev, int
card_type)
return ret;
}
- dgap_sysfs_create(brd);
+ ret = dgap_sysfs_create(brd);
+ if (ret)
+ return ret;
brd-state = BOARD_READY;
brd-dpastatus = BD_RUNNING;
@@ -1730,6 +1732,7 @@ static void dgap_tty_uninit(struct board_t *brd)
dgap_BoardsByMajor[brd-SerialDriver-major] = NULL;
brd-dgap_Serial_Major = 0;
for (i = 0; i brd-nasync; i++) {
+ tty_port_destroy(brd-SerialPorts[i].port);
dgap_remove_tty_sysfs(brd-channels[i]-ch_tun.un_sysfs);
tty_unregister_device(brd-SerialDriver, i);
}
@@ -1737,6 +1740,7 @@ static void dgap_tty_uninit(struct board_t *brd)
kfree(brd-SerialDriver-ttys);
brd-SerialDriver-ttys = NULL;
put_tty_driver(brd-SerialDriver);
+ kfree(brd-SerialPorts);
brd-dgap_Major_Serial_Registered = FALSE;
}
@@ -1744,6 +1748,7 @@ static void dgap_tty_uninit(struct board_t *brd)
dgap_BoardsByMajor[brd-PrintDriver-major] = NULL;
brd-dgap_TransparentPrint_Major = 0;
for (i = 0; i brd-nasync; i++) {
+ tty_port_destroy(brd-PrinterPorts[i].port);
dgap_remove_tty_sysfs(brd-channels[i]-ch_pun.un_sysfs);
tty_unregister_device(brd-PrintDriver, i);
}
@@ -1751,6 +1756,7 @@ static void dgap_tty_uninit(struct board_t *brd)
kfree(brd-PrintDriver-ttys);
brd-PrintDriver-ttys = NULL;
put_tty_driver(brd-PrintDriver);
+ kfree(brd-PrinterPorts);
brd-dgap_Major_TransparentPrint_Registered = FALSE;
}
}
@@ -4813,25 +4819,51 @@ static int dgap_after_config_loaded(int board)
/*
* Create pr and tty device entries
*/
-static void dgap_sysfs_create(struct board_t *brd)
+static int dgap_sysfs_create(struct board_t *brd)
{
struct channel_t *ch;
- int j = 0;
+ struct dgap_port *p;
+ int j;
+
+ brd-SerialPorts = kcalloc(brd-nasync, sizeof(*brd-SerialPorts),
+ GFP_KERNEL);
+ if (brd-SerialPorts == NULL) {
+ pr_err(dgap: Cannot allocate serial port memory\n);
+ return -ENOMEM;
+ }
+
+ for (j = 0, p = brd-SerialPorts; j brd-nasync; j++, p++)
+ tty_port_init(p-port);
+
+ brd-PrinterPorts = kcalloc(brd-nasync, sizeof(*brd-PrinterPorts),
+ GFP_KERNEL);
+ if (brd-PrinterPorts == NULL) {
+ pr_err(dgap: Cannot allocate printer port memory\n);
+ return -ENOMEM;
+ }
+
+ for (j = 0, p = brd-PrinterPorts; j brd-nasync; j++, p++)
+ tty_port_init(p-port);
ch = brd-channels[0];
for (j = 0; j brd-nasync; j++, ch = brd-channels[j]) {
struct device *classp;
- classp = tty_register_device(brd-SerialDriver, j,
- (ch-ch_bd-pdev-dev));
+
+ classp = tty_port_register_device(brd-SerialPorts[j].port,
+ brd-SerialDriver, brd-firstminor + j, NULL);
+
ch-ch_tun.un_sysfs = classp;
dgap_create_tty_sysfs(ch-ch_tun, classp);
- classp = tty_register_device(brd-PrintDriver, j,
- (ch-ch_bd-pdev-dev));
+ classp = tty_port_register_device(brd-PrinterPorts[j].port,
+
Re: [PATCH RFC only] staging: dgap: fix OOPS on open of port
On Tue, Feb 25, 2014 at 10:56:22AM -0500, Mark Hounschell wrote:
When opening a port the dgap driver OOPs with a message:
tty_init_dev: driver does not set tty-port... will crash the kernel... fix
the driver... etc...
Then I have to reboot the box.
I think before too much more work is done on this driver (by me anyway),
it should at least be in a usable state. There are a lot more changes to come
and I would like to be able to test along the way.
I've looked at some of the other drivers as examples and come up with this
patch that
does in fact allow me to use the driver. I would like to submit it but am
uncertain that this
is proper.
Thanks for reviewing.
mark
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 7cb1ad5..d56b3b2 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -223,7 +223,7 @@ static void dgap_get_vpd(struct board_t *brd);
static void dgap_do_reset_board(struct board_t *brd);
static void dgap_do_wait_for_bios(struct board_t *brd);
static void dgap_do_wait_for_fep(struct board_t *brd);
-static void dgap_sysfs_create(struct board_t *brd);
+static int dgap_sysfs_create(struct board_t *brd);
static int dgap_firmware_load(struct pci_dev *pdev, int card_type);
/* Driver load/unload functions */
@@ -1098,7 +1098,9 @@ static int dgap_firmware_load(struct pci_dev *pdev, int
card_type)
return ret;
}
- dgap_sysfs_create(brd);
+ ret = dgap_sysfs_create(brd);
+ if (ret)
+ return ret;
Why are you putting the port initialization logic in the sysfs_create()
function?
Ideally we will get rid of that sysfs logic as a tty driver shouldn't be
creating special sysfs files for no real reason.
/*
* Create pr and tty device entries
*/
-static void dgap_sysfs_create(struct board_t *brd)
+static int dgap_sysfs_create(struct board_t *brd)
I think the function name is misleading, this does the tty registration,
and you are right to do it here. Just fix the name :)
{
struct channel_t *ch;
- int j = 0;
+ struct dgap_port *p;
+ int j;
+
+ brd-SerialPorts = kcalloc(brd-nasync, sizeof(*brd-SerialPorts),
+ GFP_KERNEL);
+ if (brd-SerialPorts == NULL) {
+ pr_err(dgap: Cannot allocate serial port memory\n);
+ return -ENOMEM;
+ }
+
+ for (j = 0, p = brd-SerialPorts; j brd-nasync; j++, p++)
+ tty_port_init(p-port);
+
+ brd-PrinterPorts = kcalloc(brd-nasync, sizeof(*brd-PrinterPorts),
+ GFP_KERNEL);
What are printer ports? How are they different from serial ports on
this device?
+struct dgap_port {
+ struct tty_port port;
+};
Do you really need a wrapping structure here?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v4 4/8] staging: imx-drm: Document imx-hdmi device tree bindings
On Tue, Feb 25, 2014 at 11:23 AM, Philipp Zabel p.za...@pengutronix.de wrote:
+Required properties:
+ - #address-cells : should be 1
+ - #size-cells : should be 0
+ - compatible : should be fsl,imx6q-hdmi or fsl,imx6dl-hdmi.
+ - gpr : should be gpr.
+ The phandle points to the iomuxc-gpr region containing the HDMI
+ multiplexer control register.
+ - clocks, clock-names : phandles to the HDMI iahb and isrf clocks, as
described
+ in Documentation/devicetree/bindings/clock/clock-bindings.txt and
+ Documentation/devicetree/bindings/clock/imx6q-clock.txt.
+ - port@[0-4]: Up to four port nodes with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt,
+ corresponding to the four inputs to the HDMI multiplexer.
+
+example:
+
+ gpr: iomuxc-gpr@020e {
+ /* ... */
+ };
+
+hdmi: hdmi@012 {
+#address-cells = 1;
+#size-cells = 0;
+reg = 0x0012 0x9000;
+interrupts = 0 115 0x04;
+gpr = gpr;
+clocks = clks 123, clks 124;
+clock-names = iahb, isfr;
The 'compatible' property is missing in the example.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v4 4/8] staging: imx-drm: Document imx-hdmi device tree bindings
Hi Fabio, Am Dienstag, den 25.02.2014, 12:13 -0300 schrieb Fabio Estevam: On Tue, Feb 25, 2014 at 11:23 AM, Philipp Zabel p.za...@pengutronix.de wrote: This patch adds device tree binding documentation for the HDMI transmitter on i.MX6. Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- .../devicetree/bindings/staging/imx-drm/hdmi.txt | 53 ++ 1 file changed, 53 insertions(+) create mode 100644 Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt diff --git a/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt b/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt new file mode 100644 index 000..7dcd673a --- /dev/null +++ b/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt @@ -0,0 +1,53 @@ +Device-Tree bindings for HDMI Transmitter + +HDMI Transmitter + + +The LVDS Display Bridge device tree node contains up to two lvds-channel +nodes describing each of the two LVDS encoder channels of the bridge. Copy and paste error? ;-) Thanks, yes. I don't have anything interesting to say about the HDMI TX there, so I'll just drop this sentence. regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC only] staging: dgap: fix OOPS on open of port
On 02/25/2014 11:48 AM, Greg KH wrote:
On Tue, Feb 25, 2014 at 10:56:22AM -0500, Mark Hounschell wrote:
When opening a port the dgap driver OOPs with a message:
tty_init_dev: driver does not set tty-port... will crash the kernel... fix the
driver... etc...
Then I have to reboot the box.
I think before too much more work is done on this driver (by me anyway),
it should at least be in a usable state. There are a lot more changes to come
and I would like to be able to test along the way.
I've looked at some of the other drivers as examples and come up with this
patch that
does in fact allow me to use the driver. I would like to submit it but am
uncertain that this
is proper.
Thanks for reviewing.
mark
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 7cb1ad5..d56b3b2 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -223,7 +223,7 @@ static void dgap_get_vpd(struct board_t *brd);
static void dgap_do_reset_board(struct board_t *brd);
static void dgap_do_wait_for_bios(struct board_t *brd);
static void dgap_do_wait_for_fep(struct board_t *brd);
-static void dgap_sysfs_create(struct board_t *brd);
+static int dgap_sysfs_create(struct board_t *brd);
static int dgap_firmware_load(struct pci_dev *pdev, int card_type);
/* Driver load/unload functions */
@@ -1098,7 +1098,9 @@ static int dgap_firmware_load(struct pci_dev *pdev, int
card_type)
return ret;
}
- dgap_sysfs_create(brd);
+ ret = dgap_sysfs_create(brd);
+ if (ret)
+ return ret;
Why are you putting the port initialization logic in the sysfs_create()
function?
Ideally we will get rid of that sysfs logic as a tty driver shouldn't be
creating special sysfs files for no real reason.
/*
* Create pr and tty device entries
*/
-static void dgap_sysfs_create(struct board_t *brd)
+static int dgap_sysfs_create(struct board_t *brd)
I think the function name is misleading, this does the tty registration,
and you are right to do it here. Just fix the name :)
That's easy enough. Will do in patch.
{
struct channel_t *ch;
- int j = 0;
+ struct dgap_port *p;
+ int j;
+
+ brd-SerialPorts = kcalloc(brd-nasync, sizeof(*brd-SerialPorts),
+ GFP_KERNEL);
+ if (brd-SerialPorts == NULL) {
+ pr_err(dgap: Cannot allocate serial port memory\n);
+ return -ENOMEM;
+ }
+
+ for (j = 0, p = brd-SerialPorts; j brd-nasync; j++, p++)
+ tty_port_init(p-port);
+
+ brd-PrinterPorts = kcalloc(brd-nasync, sizeof(*brd-PrinterPorts),
+ GFP_KERNEL);
What are printer ports? How are they different from serial ports on
this device?
As I'm not the original author of this driver, I'm not entirely certain
but this driver creates these device entries per board. Given an 8 port
board variant:
/dev/dgap_mgmtspecial managment node 1 per driver instance
/dev/pr_dgap_0_0 port 0 used for printer
/dev/pr_dgap_0_1
/dev/pr_dgap_0_2
/dev/pr_dgap_0_3
/dev/pr_dgap_0_4
/dev/pr_dgap_0_5
/dev/pr_dgap_0_6
/dev/pr_dgap_0_7
/dev/tty_dgap_0_0 port 0 used anything other than a printer
/dev/tty_dgap_0_1
/dev/tty_dgap_0_2
/dev/tty_dgap_0_3
/dev/tty_dgap_0_4
/dev/tty_dgap_0_5
/dev/tty_dgap_0_6
/dev/tty_dgap_0_7
I personally have not used the printer device nodes. Nor have I looked
into the driver deep enough to see why they are provided. I do remember
seeing something about Transparent Print though. We have some old rs232
terminals with an additional rs232 printer port output that can be
configured in Transparent Print mode such that certain things go
straight though to the printer while other things show on the terminal?
I just don't know for sure though.
As far as the dgap_mgmt device, some code using it was already removed
before or immediately after it got merged into staging. I think there
were only 3 or 4 ioctls that used it. These ioctls were for things like
setting special baud rates, statistics gathering, monitoring, etc...
IMHO, for user land compatibility I think that stuff should be added
back in before this driver leaves staging. Another day though.
+struct dgap_port {
+ struct tty_port port;
+};
Do you really need a wrapping structure here?
I may be incorrect, but I think so. I will investigate this further
before I make a patch.
Thanks
mark
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [patch 25/26] x86: hyperv: Cleanup the irq mess
On Tue, 25 Feb 2014, KY Srinivasan wrote:
-Original Message-
From: Thomas Gleixner [mailto:t...@linutronix.de]
Sent: Sunday, February 23, 2014 1:40 PM
To: LKML
Cc: Ingo Molnar; Peter Zijlstra; x86; KY Srinivasan; Greg Kroah-Hartman;
linuxdrivers
Subject: [patch 25/26] x86: hyperv: Cleanup the irq mess
The vmbus/hyperv interrupt handling is another complete trainwreck and
probably the worst of all currently in tree.
If CONFIG_HYPERV=y then the interrupt delivery to the vmbus happens via
the direct HYPERVISOR_CALLBACK_VECTOR. So far so good, but:
The driver requests first a normal device interrupt. The only reason
to do so is to increment the interrupt stats of that device
interrupt.
We have proper accounting mechanisms for direct vectors, but of
course it's too much effort to add that 5 lines of code.
Aside of that the alloc_intr_gate() is not protected against
reallocation which makes module reload impossible.
If CONFIG_HYPERV=n then the vmbus request a regular device interrupt via
request_irq() and installs it's own private flow handler. Of course this
lacks
any explanation why it can't use the standard flow handler or the existing
handle_percpu_irq handler.
Solution to the problem is simple to rip out the whole mess and implement it
correctly.
Thomas,
Thank you for cleaning up this code. When CONFIG_HYPERV== n, none of
the VMBUS code is active. The special case can go away as you have
noted.
So, if CONFIG_HYPERV=n then you do not need the request_irq() fallback
at all, right? Somehow I missed the HYPERV dependency of the VMBUS stuff
That makes stuff even simpler as we can get rid of those extra cases
including the extra flow handler.
New patch below.
Thanks,
tglx
---
arch/x86/include/asm/mshyperv.h |4 +-
arch/x86/kernel/cpu/mshyperv.c | 78
drivers/hv/vmbus_drv.c | 39 ++--
3 files changed, 47 insertions(+), 74 deletions(-)
Index: tip/arch/x86/include/asm/mshyperv.h
===
--- tip.orig/arch/x86/include/asm/mshyperv.h
+++ tip/arch/x86/include/asm/mshyperv.h
@@ -2,6 +2,7 @@
#define _ASM_X86_MSHYPER_H
#include linux/types.h
+#include linux/interrupt.h
#include asm/hyperv.h
struct ms_hyperv_info {
@@ -16,6 +17,7 @@ void hyperv_callback_vector(void);
#define trace_hyperv_callback_vector hyperv_callback_vector
#endif
void hyperv_vector_handler(struct pt_regs *regs);
-void hv_register_vmbus_handler(int irq, irq_handler_t handler);
+int hv_setup_vmbus_irq(int irq, irq_handler_t handler, void *dev_id);
+void hv_remove_vmbus_irq(int irq, void *dev_id);
#endif
Index: tip/arch/x86/kernel/cpu/mshyperv.c
===
--- tip.orig/arch/x86/kernel/cpu/mshyperv.c
+++ tip/arch/x86/kernel/cpu/mshyperv.c
@@ -17,6 +17,7 @@
#include linux/hardirq.h
#include linux/efi.h
#include linux/interrupt.h
+#include linux/irq.h
#include asm/processor.h
#include asm/hypervisor.h
#include asm/hyperv.h
@@ -30,6 +31,45 @@
struct ms_hyperv_info ms_hyperv;
EXPORT_SYMBOL_GPL(ms_hyperv);
+#ifdef CONFIG_HYPERV
+static irq_handler_t *vmbus_handler;
+
+void hyperv_vector_handler(struct pt_regs *regs)
+{
+ struct pt_regs *old_regs = set_irq_regs(regs);
+
+ irq_enter();
+ exit_idle();
+
+ inc_irq_stat(irq_hv_callback_count);
+ if (vmbus_handler)
+ vmbus_handler();
+
+ irq_exit();
+ set_irq_regs(old_regs);
+}
+
+int hv_setup_vmbus_irq(int irq, irq_handler_t *handler, void *dev_id)
+{
+ vmbus_handler = handler;
+ /*
+* Setup the IDT for hypervisor callback. Prevent reallocation
+* at module reload.
+*/
+ if (!test_bit(HYPERVISOR_CALLBACK_VECTOR, used_vectors))
+ alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
+ hyperv_callback_vector);
+}
+
+void hv_remove_vmbus_irq(unsigned int irq, void *dev_id)
+{
+ /* We have no way to deallocate the interrupt gate */
+ vmbus_handler = NULL;
+}
+EXPORT_SYMBOL_GPL(hv_setup_vmbus_irq);
+EXPORT_SYMBOL_GPL(hv_remove_vmbus_irq);
+#endif
+
static uint32_t __init ms_hyperv_platform(void)
{
u32 eax;
@@ -113,41 +153,3 @@ const __refconst struct hypervisor_x86 x
.init_platform = ms_hyperv_init_platform,
};
EXPORT_SYMBOL(x86_hyper_ms_hyperv);
-
-#if IS_ENABLED(CONFIG_HYPERV)
-static int vmbus_irq = -1;
-static irq_handler_t vmbus_isr;
-
-void hv_register_vmbus_handler(int irq, irq_handler_t handler)
-{
- /*
-* Setup the IDT for hypervisor callback.
-*/
- alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, hyperv_callback_vector);
-
- vmbus_irq = irq;
- vmbus_isr = handler;
-}
-
-void hyperv_vector_handler(struct pt_regs *regs)
-{
- struct pt_regs *old_regs = set_irq_regs(regs);
-
Re: [PATCH RFC only] staging: dgap: fix OOPS on open of port
On 02/25/2014 01:40 PM, Mark Hounschell wrote:
+struct dgap_port {
+struct tty_port port;
+};
Do you really need a wrapping structure here?
I may be incorrect, but I think so. I will investigate this further
before I make a patch.
It looks to me like this is how it should be done. As future serial
changes are done won't additional things be required to be added to
dgap_port? port_ops? I certainly don't know what those future changes
are but looking at other drivers (moxa.c) it looks so. What am I missing?
Thanks
mark
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: comedi: drivers: fix for a potential NULL pointer dereference
Return -ENOMEM in ni_E_init if ni_gpct_device_construct returns NULL
Signed-off-by: Kumar Amit Mehta gmate.a...@gmail.com
---
drivers/staging/comedi/drivers/ni_mio_common.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 8adb535..3a86d48 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -4407,6 +4407,9 @@ static int ni_E_init(struct comedi_device *dev)
ni_gpct_read_register,
counter_variant,
NUM_GPCT);
+ if (!devpriv-counter_dev)
+ return -ENOMEM;
+
/* General purpose counters */
for (j = 0; j NUM_GPCT; ++j) {
s = dev-subdevices[NI_GPCT_SUBDEV(j)];
--
1.8.5.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hello
Can I have ur name ? I going to report to lawyer but I m so sad with that please don't do that I'm just only love u in my life why what happen to u Why don't u tell me only need my money that is not right u using my heart and my life .but still I love u that is my problem ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: comedi: addi-data: clean-up variable use in hwdrv_apci035.c
On Tuesday, February 25, 2014 3:56 AM, Ian Abbott abbo...@mev.co.uk wrote: On 2014-02-25 08:15, Chase Southwood wrote: The static variable ui_Command is as of right now being cleared to a value of zero between everytime that it writes to a port and then takes a new value from a port. Seems like this zeroing is unnecessary, so we can just remove these lines. The description is slightly wrong as the variable isn't static storage class. Oh, shoot, you're exactly right. I was looking at some other variables which are static when I was making this up and I got storage classes all mixed up. I'll fix up the description and send it off to Greg again as it hasn't been applied yet. Signed-off-by: Chase Southwood chase.southw...@yahoo.com --- This sort of thing seems like a copy/paste sort of error to me, but there could as easily be some reason here that I'm missing that this is needed here. My first impression, however, was that this extra clearing is useless. Yes, the extra clearing was useless. There are also some useless initializers for this variable and others. Fine, apart from the description. Reviewed-by: Ian Abbott abbo...@mev.co.uk -- -=( Ian Abbott @ MEV Ltd. E-mail: abbo...@mev.co.uk )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
