[PATCH 09/10] MCDE: Add build files and bus
This patch adds support for the MCDE, Memory-to-display controller,
found in the ST-Ericsson ux500 products.
This patch adds the necessary build files for MCDE and the bus that
all displays are connected to.
Signed-off-by: Jimmy Rubin jimmy.ru...@stericsson.com
Acked-by: Linus Walleij linus.walleij.stericsson.com
---
drivers/video/Kconfig |2 +
drivers/video/Makefile|1 +
drivers/video/mcde/Kconfig| 39 ++
drivers/video/mcde/Makefile | 12 ++
drivers/video/mcde/mcde_bus.c | 259 +
drivers/video/mcde/mcde_mod.c | 67 +++
6 files changed, 380 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/mcde/Kconfig
create mode 100644 drivers/video/mcde/Makefile
create mode 100644 drivers/video/mcde/mcde_bus.c
create mode 100644 drivers/video/mcde/mcde_mod.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 935cdc2..04aecf4 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2260,6 +2260,8 @@ config FB_JZ4740
source drivers/video/omap/Kconfig
source drivers/video/omap2/Kconfig
+source drivers/video/mcde/Kconfig
+
source drivers/video/backlight/Kconfig
source drivers/video/display/Kconfig
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 485e8ed..325cdcc 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -128,6 +128,7 @@ obj-$(CONFIG_FB_SH_MOBILE_HDMI) += sh_mobile_hdmi.o
obj-$(CONFIG_FB_SH_MOBILE_LCDC) += sh_mobile_lcdcfb.o
obj-$(CONFIG_FB_OMAP) += omap/
obj-y += omap2/
+obj-$(CONFIG_FB_MCDE) += mcde/
obj-$(CONFIG_XEN_FBDEV_FRONTEND) += xen-fbfront.o
obj-$(CONFIG_FB_CARMINE) += carminefb.o
obj-$(CONFIG_FB_MB862XX) += mb862xx/
diff --git a/drivers/video/mcde/Kconfig b/drivers/video/mcde/Kconfig
new file mode 100644
index 000..5dab37b
--- /dev/null
+++ b/drivers/video/mcde/Kconfig
@@ -0,0 +1,39 @@
+config FB_MCDE
+ tristate MCDE support
+ depends on FB
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ ---help---
+ This enables support for MCDE based frame buffer driver.
+
+ Please read the file file:Documentation/fb/mcde.txt
+
+config MCDE_DISPLAY_GENERIC_DSI
+ tristate Generic display driver
+ depends on FB_MCDE
+
+config FB_MCDE_DEBUG
+ bool MCDE debug messages
+ depends on FB_MCDE
+ ---help---
+ Say Y here if you want the MCDE driver to output debug messages
+
+config FB_MCDE_VDEBUG
+ bool MCDE verbose debug messages
+ depends on FB_MCDE_DEBUG
+ ---help---
+ Say Y here if you want the MCDE driver to output more debug messages
+
+config MCDE_FB_AVOID_REALLOC
+ bool MCDE early allocate framebuffer
+ default n
+ depends on FB_MCDE
+ ---help---
+ If you say Y here maximum frame buffer size is allocated and
+ used for all resolutions. If you say N here, the frame buffer is
+ reallocated when resolution is changed. This reallocation might
+ fail because of fragmented memory. Note that this memory will
+ never be deallocated, while the MCDE framebuffer is used.
+
diff --git a/drivers/video/mcde/Makefile b/drivers/video/mcde/Makefile
new file mode 100644
index 000..f90979a
--- /dev/null
+++ b/drivers/video/mcde/Makefile
@@ -0,0 +1,12 @@
+
+mcde-objs := mcde_mod.o mcde_hw.o mcde_dss.o
mcde_display.o mcde_bus.o mcde_fb.o
+obj-$(CONFIG_FB_MCDE) += mcde.o
+
+obj-$(CONFIG_MCDE_DISPLAY_GENERIC_DSI) += display-generic_dsi.o
+
+ifdef CONFIG_FB_MCDE_DEBUG
+EXTRA_CFLAGS += -DDEBUG
+endif
+ifdef CONFIG_FB_MCDE_VDEBUG
+EXTRA_CFLAGS += -DVERBOSE_DEBUG
+endif
diff --git a/drivers/video/mcde/mcde_bus.c b/drivers/video/mcde/mcde_bus.c
new file mode 100644
index 000..bc1f048
--- /dev/null
+++ b/drivers/video/mcde/mcde_bus.c
@@ -0,0 +1,259 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2010
+ *
+ * ST-Ericsson MCDE display bus driver
+ *
+ * Author: Marcus Lorentzon marcus.xm.lorent...@stericsson.com
+ * for ST-Ericsson.
+ *
+ * License terms: GNU General Public License (GPL), version 2.
+ */
+
+#include linux/kernel.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/dma-mapping.h
+#include linux/notifier.h
+
+#include video/mcde/mcde_display.h
+#include video/mcde/mcde_dss.h
+
+#define to_mcde_display_driver(__drv) \
+ container_of((__drv), struct mcde_display_driver, driver)
+
+static BLOCKING_NOTIFIER_HEAD(bus_notifier_list);
+
+static int mcde_drv_suspend(struct device *_dev, pm_message_t state);
+static int mcde_drv_resume(struct device *_dev);
+struct bus_type mcde_bus_type;
+
+static int mcde_suspend_device(struct device *dev, void *data)
+{
+ pm_message_t* state = (pm_message_t *) data;
+ if (dev-driver-suspend)
+ return dev-driver-suspend(dev,
[PATCH 03/10] MCDE: Add pixel processing registers
This patch adds support for MCDE, Memory-to-display controller found in the ST-Ericsson ux500 products. This patch adds pixel processing registers found in MCDE. Signed-off-by: Jimmy Rubin jimmy.ru...@stericsson.com Acked-by: Linus Walleij linus.walleij.stericsson.com --- drivers/video/mcde/mcde_pixelprocess.h | 1137 1 files changed, 1137 insertions(+), 0 deletions(-) create mode 100644 drivers/video/mcde/mcde_pixelprocess.h diff --git a/drivers/video/mcde/mcde_pixelprocess.h b/drivers/video/mcde/mcde_pixelprocess.h new file mode 100644 index 000..b57c3e7 --- /dev/null +++ b/drivers/video/mcde/mcde_pixelprocess.h @@ -0,0 +1,1137 @@ + +#define MCDE_VAL2REG(__reg, __fld, __val) \ + (((__val) __reg##_##__fld##_SHIFT) __reg##_##__fld##_MASK) +#define MCDE_REG2VAL(__reg, __fld, __val) \ + (((__val) __reg##_##__fld##_MASK) __reg##_##__fld##_SHIFT) + +#define MCDE_CRA0 0x0800 +#define MCDE_CRA0_GROUPOFFSET 0x200 +#define MCDE_CRA0_FLOEN_SHIFT 0 +#define MCDE_CRA0_FLOEN_MASK 0x0001 +#define MCDE_CRA0_FLOEN(__x) \ + MCDE_VAL2REG(MCDE_CRA0, FLOEN, __x) +#define MCDE_CRA0_POWEREN_SHIFT 1 +#define MCDE_CRA0_POWEREN_MASK 0x0002 +#define MCDE_CRA0_POWEREN(__x) \ + MCDE_VAL2REG(MCDE_CRA0, POWEREN, __x) +#define MCDE_CRA0_BLENDEN_SHIFT 2 +#define MCDE_CRA0_BLENDEN_MASK 0x0004 +#define MCDE_CRA0_BLENDEN(__x) \ + MCDE_VAL2REG(MCDE_CRA0, BLENDEN, __x) +#define MCDE_CRA0_AFLICKEN_SHIFT 3 +#define MCDE_CRA0_AFLICKEN_MASK 0x0008 +#define MCDE_CRA0_AFLICKEN(__x) \ + MCDE_VAL2REG(MCDE_CRA0, AFLICKEN, __x) +#define MCDE_CRA0_PALEN_SHIFT 4 +#define MCDE_CRA0_PALEN_MASK 0x0010 +#define MCDE_CRA0_PALEN(__x) \ + MCDE_VAL2REG(MCDE_CRA0, PALEN, __x) +#define MCDE_CRA0_DITHEN_SHIFT 5 +#define MCDE_CRA0_DITHEN_MASK 0x0020 +#define MCDE_CRA0_DITHEN(__x) \ + MCDE_VAL2REG(MCDE_CRA0, DITHEN, __x) +#define MCDE_CRA0_GAMEN_SHIFT 6 +#define MCDE_CRA0_GAMEN_MASK 0x0040 +#define MCDE_CRA0_GAMEN(__x) \ + MCDE_VAL2REG(MCDE_CRA0, GAMEN, __x) +#define MCDE_CRA0_KEYCTRL_SHIFT 7 +#define MCDE_CRA0_KEYCTRL_MASK 0x0380 +#define MCDE_CRA0_KEYCTRL_OFF 0 +#define MCDE_CRA0_KEYCTRL_ALPHA_RGB 1 +#define MCDE_CRA0_KEYCTRL_RGB 2 +#define MCDE_CRA0_KEYCTRL_FALPHA_FRGB 4 +#define MCDE_CRA0_KEYCTRL_FRGB 5 +#define MCDE_CRA0_KEYCTRL_ENUM(__x) \ + MCDE_VAL2REG(MCDE_CRA0, KEYCTRL, MCDE_CRA0_KEYCTRL_##__x) +#define MCDE_CRA0_KEYCTRL(__x) \ + MCDE_VAL2REG(MCDE_CRA0, KEYCTRL, __x) +#define MCDE_CRA0_BLENDCTRL_SHIFT 10 +#define MCDE_CRA0_BLENDCTRL_MASK 0x0400 +#define MCDE_CRA0_BLENDCTRL_SOURCE 0 +#define MCDE_CRA0_BLENDCTRL_CONSTANT 1 +#define MCDE_CRA0_BLENDCTRL_ENUM(__x) \ + MCDE_VAL2REG(MCDE_CRA0, BLENDCTRL, MCDE_CRA0_BLENDCTRL_##__x) +#define MCDE_CRA0_BLENDCTRL(__x) \ + MCDE_VAL2REG(MCDE_CRA0, BLENDCTRL, __x) +#define MCDE_CRA0_FLICKMODE_SHIFT 11 +#define MCDE_CRA0_FLICKMODE_MASK 0x1800 +#define MCDE_CRA0_FLICKMODE_FORCE_FILTER_0 0 +#define MCDE_CRA0_FLICKMODE_ADAPTIVE 1 +#define MCDE_CRA0_FLICKMODE_TEST_MODE 2 +#define MCDE_CRA0_FLICKMODE_ENUM(__x) \ + MCDE_VAL2REG(MCDE_CRA0, FLICKMODE, MCDE_CRA0_FLICKMODE_##__x) +#define MCDE_CRA0_FLICKMODE(__x) \ + MCDE_VAL2REG(MCDE_CRA0, FLICKMODE, __x) +#define MCDE_CRA0_FLOCKFORMAT_SHIFT 13 +#define MCDE_CRA0_FLOCKFORMAT_MASK 0x2000 +#define MCDE_CRA0_FLOCKFORMAT_YCBCR 0 +#define MCDE_CRA0_FLOCKFORMAT_RGB 1 +#define MCDE_CRA0_FLOCKFORMAT_ENUM(__x) \ + MCDE_VAL2REG(MCDE_CRA0, FLOCKFORMAT, MCDE_CRA0_FLOCKFORMAT_##__x) +#define MCDE_CRA0_FLOCKFORMAT(__x) \ + MCDE_VAL2REG(MCDE_CRA0, FLOCKFORMAT, __x) +#define MCDE_CRA0_PALMODE_SHIFT 14 +#define MCDE_CRA0_PALMODE_MASK 0x4000 +#define MCDE_CRA0_PALMODE_PALETTE 0 +#define MCDE_CRA0_PALMODE_GAMMA 1 +#define MCDE_CRA0_PALMODE(__x) \ + MCDE_VAL2REG(MCDE_CRA0, PALMODE, __x) +#define MCDE_CRA0_OLEDEN_SHIFT 15 +#define MCDE_CRA0_OLEDEN_MASK 0x8000 +#define MCDE_CRA0_OLEDEN(__x) \ + MCDE_VAL2REG(MCDE_CRA0, OLEDEN, __x) +#define MCDE_CRA0_ALPHABLEND_SHIFT 16 +#define MCDE_CRA0_ALPHABLEND_MASK 0x00FF +#define MCDE_CRA0_ALPHABLEND(__x) \ + MCDE_VAL2REG(MCDE_CRA0, ALPHABLEND, __x) +#define MCDE_CRA0_ROTEN_SHIFT 24 +#define MCDE_CRA0_ROTEN_MASK 0x0100 +#define MCDE_CRA0_ROTEN(__x) \ + MCDE_VAL2REG(MCDE_CRA0, ROTEN, __x) +#define MCDE_CRA0_ROTBURSTSIZE_V1_SHIFT 25 +#define MCDE_CRA0_ROTBURSTSIZE_V1_MASK 0x0E00 +#define MCDE_CRA0_ROTBURSTSIZE_V1_1W 0 +#define MCDE_CRA0_ROTBURSTSIZE_V1_2W 1 +#define MCDE_CRA0_ROTBURSTSIZE_V1_4W 2 +#define MCDE_CRA0_ROTBURSTSIZE_V1_8W 3 +#define MCDE_CRA0_ROTBURSTSIZE_V1_16W 4 +#define MCDE_CRA0_ROTBURSTSIZE_V1_ENUM(__x) \ + MCDE_VAL2REG(MCDE_CRA0, ROTBURSTSIZE_V1, \ + MCDE_CRA0_ROTBURSTSIZE_V1_##__x) +#define MCDE_CRA0_ROTBURSTSIZE_V1(__x) \ + MCDE_VAL2REG(MCDE_CRA0, ROTBURSTSIZE_V1, __x) +#define MCDE_CRA0_ROTBURSTSIZE_HW_V1_SHIFT 28 +#define MCDE_CRA0_ROTBURSTSIZE_HW_V1_MASK 0x1000 +#define
[PATCH] i2c: Remove obsolete cleanup for clientdata
A few new i2c-drivers came into the kernel which clear the clientdata-pointer
on exit. This is obsolete meanwhile, so fix it and hope the word will spread.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
Like last time I suggest to collect acks from the driver authors and merge it
vie Jean's i2c-tree.
drivers/media/video/imx074.c |2 --
drivers/media/video/ov6650.c |2 --
drivers/misc/apds9802als.c|1 -
drivers/staging/olpc_dcon/olpc_dcon.c |3 ---
4 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/imx074.c b/drivers/media/video/imx074.c
index 380e459..27b5dfd 100644
--- a/drivers/media/video/imx074.c
+++ b/drivers/media/video/imx074.c
@@ -451,7 +451,6 @@ static int imx074_probe(struct i2c_client *client,
ret = imx074_video_probe(icd, client);
if (ret 0) {
icd-ops = NULL;
- i2c_set_clientdata(client, NULL);
kfree(priv);
return ret;
}
@@ -468,7 +467,6 @@ static int imx074_remove(struct i2c_client *client)
icd-ops = NULL;
if (icl-free_bus)
icl-free_bus(icl);
- i2c_set_clientdata(client, NULL);
client-driver = NULL;
kfree(priv);
diff --git a/drivers/media/video/ov6650.c b/drivers/media/video/ov6650.c
index b7cfeab..2dd5298 100644
--- a/drivers/media/video/ov6650.c
+++ b/drivers/media/video/ov6650.c
@@ -1176,7 +1176,6 @@ static int ov6650_probe(struct i2c_client *client,
if (ret) {
icd-ops = NULL;
- i2c_set_clientdata(client, NULL);
kfree(priv);
}
@@ -1187,7 +1186,6 @@ static int ov6650_remove(struct i2c_client *client)
{
struct ov6650 *priv = to_ov6650(client);
- i2c_set_clientdata(client, NULL);
kfree(priv);
return 0;
}
diff --git a/drivers/misc/apds9802als.c b/drivers/misc/apds9802als.c
index f9b91ba..abe3d21 100644
--- a/drivers/misc/apds9802als.c
+++ b/drivers/misc/apds9802als.c
@@ -251,7 +251,6 @@ static int apds9802als_probe(struct i2c_client *client,
return res;
als_error1:
- i2c_set_clientdata(client, NULL);
kfree(data);
return res;
}
diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c
b/drivers/staging/olpc_dcon/olpc_dcon.c
index 75aa7a36..f286a4c 100644
--- a/drivers/staging/olpc_dcon/olpc_dcon.c
+++ b/drivers/staging/olpc_dcon/olpc_dcon.c
@@ -733,7 +733,6 @@ static int dcon_probe(struct i2c_client *client, const
struct i2c_device_id *id)
edev:
platform_device_unregister(dcon_device);
dcon_device = NULL;
- i2c_set_clientdata(client, NULL);
eirq:
free_irq(DCON_IRQ, dcon_driver);
einit:
@@ -757,8 +756,6 @@ static int dcon_remove(struct i2c_client *client)
platform_device_unregister(dcon_device);
cancel_work_sync(dcon_work);
- i2c_set_clientdata(client, NULL);
-
return 0;
}
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/10] MCDE: Add formatter registers
This patch adds support for MCDE, Memory-to-display controller found in the ST-Ericsson ux500 products. This patch adds the formatter registers found in MCDE. Signed-off-by: Jimmy Rubin jimmy.ru...@stericsson.com Acked-by: Linus Walleij linus.walleij.stericsson.com --- drivers/video/mcde/mcde_formatter.h | 782 +++ 1 files changed, 782 insertions(+), 0 deletions(-) create mode 100644 drivers/video/mcde/mcde_formatter.h diff --git a/drivers/video/mcde/mcde_formatter.h b/drivers/video/mcde/mcde_formatter.h new file mode 100644 index 000..d7f5e15 --- /dev/null +++ b/drivers/video/mcde/mcde_formatter.h @@ -0,0 +1,782 @@ + +#define MCDE_VAL2REG(__reg, __fld, __val) \ + (((__val) __reg##_##__fld##_SHIFT) __reg##_##__fld##_MASK) +#define MCDE_REG2VAL(__reg, __fld, __val) \ + (((__val) __reg##_##__fld##_MASK) __reg##_##__fld##_SHIFT) + +#define MCDE_TVCRA 0x0838 +#define MCDE_TVCRA_GROUPOFFSET 0x200 +#define MCDE_TVCRA_SEL_MOD_SHIFT 0 +#define MCDE_TVCRA_SEL_MOD_MASK 0x0001 +#define MCDE_TVCRA_SEL_MOD_LCD 0 +#define MCDE_TVCRA_SEL_MOD_TV 1 +#define MCDE_TVCRA_SEL_MOD_ENUM(__x) \ + MCDE_VAL2REG(MCDE_TVCRA, SEL_MOD, MCDE_TVCRA_SEL_MOD_##__x) +#define MCDE_TVCRA_SEL_MOD(__x) \ + MCDE_VAL2REG(MCDE_TVCRA, SEL_MOD, __x) +#define MCDE_TVCRA_INTEREN_SHIFT 1 +#define MCDE_TVCRA_INTEREN_MASK 0x0002 +#define MCDE_TVCRA_INTEREN(__x) \ + MCDE_VAL2REG(MCDE_TVCRA, INTEREN, __x) +#define MCDE_TVCRA_IFIELD_SHIFT 2 +#define MCDE_TVCRA_IFIELD_MASK 0x0004 +#define MCDE_TVCRA_IFIELD(__x) \ + MCDE_VAL2REG(MCDE_TVCRA, IFIELD, __x) +#define MCDE_TVCRA_TVMODE_SHIFT 3 +#define MCDE_TVCRA_TVMODE_MASK 0x0038 +#define MCDE_TVCRA_TVMODE_SDTV_656P 0 +#define MCDE_TVCRA_TVMODE_HDTV_480P 1 +#define MCDE_TVCRA_TVMODE_HDTV_720P 2 +#define MCDE_TVCRA_TVMODE_SDTV_656P_LE 3 +#define MCDE_TVCRA_TVMODE_SDTV_656P_BE 4 +#define MCDE_TVCRA_TVMODE_ENUM(__x) \ + MCDE_VAL2REG(MCDE_TVCRA, TVMODE, MCDE_TVCRA_TVMODE_##__x) +#define MCDE_TVCRA_TVMODE(__x) \ + MCDE_VAL2REG(MCDE_TVCRA, TVMODE, __x) +#define MCDE_TVCRA_SDTVMODE_SHIFT 6 +#define MCDE_TVCRA_SDTVMODE_MASK 0x00C0 +#define MCDE_TVCRA_SDTVMODE_Y0CBY1CR 0 +#define MCDE_TVCRA_SDTVMODE_CBY0CRY1 1 +#define MCDE_TVCRA_SDTVMODE_ENUM(__x) \ + MCDE_VAL2REG(MCDE_TVCRA, SDTVMODE, MCDE_TVCRA_SDTVMODE_##__x) +#define MCDE_TVCRA_SDTVMODE(__x) \ + MCDE_VAL2REG(MCDE_TVCRA, SDTVMODE, __x) +#define MCDE_TVCRA_AVRGEN_SHIFT 8 +#define MCDE_TVCRA_AVRGEN_MASK 0x0100 +#define MCDE_TVCRA_AVRGEN(__x) \ + MCDE_VAL2REG(MCDE_TVCRA, AVRGEN, __x) +#define MCDE_TVCRA_CKINV_SHIFT 9 +#define MCDE_TVCRA_CKINV_MASK 0x0200 +#define MCDE_TVCRA_CKINV(__x) \ + MCDE_VAL2REG(MCDE_TVCRA, CKINV, __x) +#define MCDE_TVCRB 0x0A38 +#define MCDE_TVCRB_SEL_MOD_SHIFT 0 +#define MCDE_TVCRB_SEL_MOD_MASK 0x0001 +#define MCDE_TVCRB_SEL_MOD_LCD 0 +#define MCDE_TVCRB_SEL_MOD_TV 1 +#define MCDE_TVCRB_SEL_MOD_ENUM(__x) \ + MCDE_VAL2REG(MCDE_TVCRB, SEL_MOD, MCDE_TVCRB_SEL_MOD_##__x) +#define MCDE_TVCRB_SEL_MOD(__x) \ + MCDE_VAL2REG(MCDE_TVCRB, SEL_MOD, __x) +#define MCDE_TVCRB_INTEREN_SHIFT 1 +#define MCDE_TVCRB_INTEREN_MASK 0x0002 +#define MCDE_TVCRB_INTEREN(__x) \ + MCDE_VAL2REG(MCDE_TVCRB, INTEREN, __x) +#define MCDE_TVCRB_IFIELD_SHIFT 2 +#define MCDE_TVCRB_IFIELD_MASK 0x0004 +#define MCDE_TVCRB_IFIELD(__x) \ + MCDE_VAL2REG(MCDE_TVCRB, IFIELD, __x) +#define MCDE_TVCRB_TVMODE_SHIFT 3 +#define MCDE_TVCRB_TVMODE_MASK 0x0038 +#define MCDE_TVCRB_TVMODE_SDTV_656P 0 +#define MCDE_TVCRB_TVMODE_HDTV_480P 1 +#define MCDE_TVCRB_TVMODE_HDTV_720P 2 +#define MCDE_TVCRB_TVMODE_SDTV_656P_LE 3 +#define MCDE_TVCRB_TVMODE_SDTV_656P_BE 4 +#define MCDE_TVCRB_TVMODE_ENUM(__x) \ + MCDE_VAL2REG(MCDE_TVCRB, TVMODE, MCDE_TVCRB_TVMODE_##__x) +#define MCDE_TVCRB_TVMODE(__x) \ + MCDE_VAL2REG(MCDE_TVCRB, TVMODE, __x) +#define MCDE_TVCRB_SDTVMODE_SHIFT 6 +#define MCDE_TVCRB_SDTVMODE_MASK 0x00C0 +#define MCDE_TVCRB_SDTVMODE_Y0CBY1CR 0 +#define MCDE_TVCRB_SDTVMODE_CBY0CRY1 1 +#define MCDE_TVCRB_SDTVMODE_ENUM(__x) \ + MCDE_VAL2REG(MCDE_TVCRB, SDTVMODE, MCDE_TVCRB_SDTVMODE_##__x) +#define MCDE_TVCRB_SDTVMODE(__x) \ + MCDE_VAL2REG(MCDE_TVCRB, SDTVMODE, __x) +#define MCDE_TVCRB_AVRGEN_SHIFT 8 +#define MCDE_TVCRB_AVRGEN_MASK 0x0100 +#define MCDE_TVCRB_AVRGEN(__x) \ + MCDE_VAL2REG(MCDE_TVCRB, AVRGEN, __x) +#define MCDE_TVCRB_CKINV_SHIFT 9 +#define MCDE_TVCRB_CKINV_MASK 0x0200 +#define MCDE_TVCRB_CKINV(__x) \ + MCDE_VAL2REG(MCDE_TVCRB, CKINV, __x) +#define MCDE_TVBL1A 0x083C +#define MCDE_TVBL1A_GROUPOFFSET 0x200 +#define MCDE_TVBL1A_BEL1_SHIFT 0 +#define MCDE_TVBL1A_BEL1_MASK 0x07FF +#define MCDE_TVBL1A_BEL1(__x) \ + MCDE_VAL2REG(MCDE_TVBL1A, BEL1, __x) +#define MCDE_TVBL1A_BSL1_SHIFT 16 +#define MCDE_TVBL1A_BSL1_MASK 0x07FF +#define MCDE_TVBL1A_BSL1(__x) \ + MCDE_VAL2REG(MCDE_TVBL1A, BSL1, __x) +#define MCDE_TVBL1B 0x0A3C
[PATCH 00/10] MCDE: Add frame buffer device driver
These set of patches contains a display sub system framework (DSS) which is used to implement the frame buffer device interface and a display device framework that is used to add support for different type of displays such as LCD, HDMI and so on. The current implementation supports DSI command mode displays. Below is a short summary of the files in this patchset: mcde_fb.c Implements the frame buffer device driver. mcde_dss.c Contains the implementation of the display sub system framework (DSS). This API is used by the frame buffer device driver. mcde_display.c Contains default implementations of the functions in the display driver API. A display driver may override the necessary functions to function properly. A simple display driver is implemented in display-generic_dsi.c. display-generic_dsi.c Sample driver for a DSI command mode display. mcde_bus.c Implementation of the display bus. A display device is probed when both the display driver and display configuration have been registered with the display bus. mcde_hw.c Hardware abstraction layer of MCDE. All code that communicates directly with the hardware resides in this file. board-mop500-mcde.c The configuration of the display and the frame buffer device is handled in this file NOTE: These set of patches replaces the patches already sent out for review. RFC:[PATCH 1/2] Video: Add support for MCDE frame buffer driver RFC:[PATCH 2/2] Ux500: Add support for MCDE frame buffer driver The old patchset was to large to be handled by the mailing lists. Jimmy Rubin (10): MCDE: Add hardware abstraction layer MCDE: Add configuration registers MCDE: Add pixel processing registers MCDE: Add formatter registers MCDE: Add dsi link registers MCDE: Add generic display MCDE: Add display subsystem framework MCDE: Add frame buffer device driver MCDE: Add build files and bus ux500: MCDE: Add platform specific data arch/arm/mach-ux500/Kconfig|8 + arch/arm/mach-ux500/Makefile |1 + arch/arm/mach-ux500/board-mop500-mcde.c| 209 ++ arch/arm/mach-ux500/board-mop500-regulators.c | 28 + arch/arm/mach-ux500/board-mop500.c |3 + arch/arm/mach-ux500/devices-db8500.c | 68 + arch/arm/mach-ux500/include/mach/db8500-regs.h |7 + arch/arm/mach-ux500/include/mach/devices.h |1 + arch/arm/mach-ux500/include/mach/prcmu-regs.h |1 + arch/arm/mach-ux500/include/mach/prcmu.h |3 + arch/arm/mach-ux500/prcmu.c| 129 ++ drivers/video/Kconfig |2 + drivers/video/Makefile |1 + drivers/video/mcde/Kconfig | 39 + drivers/video/mcde/Makefile| 12 + drivers/video/mcde/display-generic_dsi.c | 152 ++ drivers/video/mcde/dsi_link_config.h | 1486 ++ drivers/video/mcde/mcde_bus.c | 259 +++ drivers/video/mcde/mcde_config.h | 2156 drivers/video/mcde/mcde_display.c | 427 drivers/video/mcde/mcde_dss.c | 353 drivers/video/mcde/mcde_fb.c | 697 +++ drivers/video/mcde/mcde_formatter.h| 782 drivers/video/mcde/mcde_hw.c | 2528 drivers/video/mcde/mcde_mod.c | 67 + drivers/video/mcde/mcde_pixelprocess.h | 1137 +++ include/video/mcde/mcde.h | 387 include/video/mcde/mcde_display-generic_dsi.h | 34 + include/video/mcde/mcde_display.h | 139 ++ include/video/mcde/mcde_dss.h | 78 + include/video/mcde/mcde_fb.h | 54 + 31 files changed, 11248 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-ux500/board-mop500-mcde.c create mode 100644 drivers/video/mcde/Kconfig create mode 100644 drivers/video/mcde/Makefile create mode 100644 drivers/video/mcde/display-generic_dsi.c create mode 100644 drivers/video/mcde/dsi_link_config.h create mode 100644 drivers/video/mcde/mcde_bus.c create mode 100644 drivers/video/mcde/mcde_config.h create mode 100644 drivers/video/mcde/mcde_display.c create mode 100644 drivers/video/mcde/mcde_dss.c create mode 100644 drivers/video/mcde/mcde_fb.c create mode 100644 drivers/video/mcde/mcde_formatter.h create mode 100644 drivers/video/mcde/mcde_hw.c create mode 100644 drivers/video/mcde/mcde_mod.c create mode 100644 drivers/video/mcde/mcde_pixelprocess.h create mode 100644 include/video/mcde/mcde.h create mode 100644 include/video/mcde/mcde_display-generic_dsi.h create mode 100644 include/video/mcde/mcde_display.h create mode 100644 include/video/mcde/mcde_dss.h create mode 100644 include/video/mcde/mcde_fb.h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at
[PATCH 06/10] MCDE: Add generic display
This patch adds support for MCDE, Memory-to-display controller
found in the ST-Ericsson ux500 products.
This patchs adds a generic DSI command display and a display framework
that can be used to add support for new types of displays.
Signed-off-by: Jimmy Rubin jimmy.ru...@stericsson.com
Acked-by: Linus Walleij linus.walleij.stericsson.com
---
drivers/video/mcde/display-generic_dsi.c | 152 +
drivers/video/mcde/mcde_display.c | 427 +
include/video/mcde/mcde_display-generic_dsi.h | 34 ++
include/video/mcde/mcde_display.h | 139
4 files changed, 752 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/mcde/display-generic_dsi.c
create mode 100644 drivers/video/mcde/mcde_display.c
create mode 100644 include/video/mcde/mcde_display-generic_dsi.h
create mode 100644 include/video/mcde/mcde_display.h
diff --git a/drivers/video/mcde/display-generic_dsi.c
b/drivers/video/mcde/display-generic_dsi.c
new file mode 100644
index 000..1c1d266
--- /dev/null
+++ b/drivers/video/mcde/display-generic_dsi.c
@@ -0,0 +1,152 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2010
+ *
+ * ST-Ericsson MCDE generic DCS display driver
+ *
+ * Author: Marcus Lorentzon marcus.xm.lorent...@stericsson.com
+ * for ST-Ericsson.
+ *
+ * License terms: GNU General Public License (GPL), version 2.
+ */
+
+#include linux/kernel.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/gpio.h
+#include linux/err.h
+
+#include video/mcde/mcde_display.h
+#include video/mcde/mcde_display-generic_dsi.h
+
+static int __devinit generic_probe(struct mcde_display_device *dev)
+{
+ int ret = 0;
+ struct mcde_display_generic_platform_data *pdata =
+ dev-dev.platform_data;
+
+ if (pdata == NULL) {
+ dev_err(dev-dev, %s:Platform data missing\n, __func__);
+ return -EINVAL;
+ }
+
+ if (dev-port-type != MCDE_PORTTYPE_DSI) {
+ dev_err(dev-dev,
+ %s:Invalid port type %d\n,
+ __func__, dev-port-type);
+ return -EINVAL;
+ }
+
+ if (!dev-platform_enable !dev-platform_disable) {
+ pdata-generic_platform_enable = true;
+ if (pdata-reset_gpio) {
+ ret = gpio_request(pdata-reset_gpio, NULL);
+ if (ret) {
+ dev_warn(dev-dev,
+ %s:Failed to request gpio %d\n,
+ __func__, pdata-reset_gpio);
+ return ret;
+ }
+ }
+ if (pdata-regulator_id) {
+ pdata-regulator = regulator_get(NULL,
+ pdata-regulator_id);
+ if (IS_ERR(pdata-regulator)) {
+ ret = PTR_ERR(pdata-regulator);
+ dev_warn(dev-dev,
+ %s:Failed to get regulator '%s'\n,
+ __func__, pdata-regulator_id);
+ pdata-regulator = NULL;
+ goto regulator_get_failed;
+ }
+ regulator_set_voltage(pdata-regulator,
+ pdata-min_supply_voltage,
+ pdata-max_supply_voltage);
+ }
+ }
+
+ /* TODO: Remove when DSI send command uses interrupts */
+ dev-prepare_for_update = NULL;
+ dev_info(dev-dev, Generic display probed\n);
+
+ return 0;
+
+regulator_get_failed:
+ if (pdata-generic_platform_enable pdata-reset_gpio)
+ gpio_free(pdata-reset_gpio);
+ return ret;
+}
+
+static int __devexit generic_remove(struct mcde_display_device *dev)
+{
+ struct mcde_display_generic_platform_data *pdata =
+ dev-dev.platform_data;
+
+ dev-set_power_mode(dev, MCDE_DISPLAY_PM_OFF);
+
+ if (!pdata-generic_platform_enable)
+ return 0;
+
+ if (pdata-regulator)
+ regulator_put(pdata-regulator);
+ if (pdata-reset_gpio) {
+ gpio_direction_input(pdata-reset_gpio);
+ gpio_free(pdata-reset_gpio);
+ }
+
+ return 0;
+}
+
+static int generic_resume(struct mcde_display_device *ddev)
+{
+ int ret;
+
+ /* set_power_mode will handle call platform_enable */
+ ret = ddev-set_power_mode(ddev, MCDE_DISPLAY_PM_STANDBY);
+ if (ret 0)
+ dev_warn(ddev-dev, %s:Failed to resume display\n
+ , __func__);
+ return ret;
+}
+
+static int generic_suspend(struct mcde_display_device *ddev, pm_message_t
state)
+{
+ int ret;
+
+ /* set_power_mode will handle call platform_disable */
+ ret = ddev-set_power_mode(ddev, MCDE_DISPLAY_PM_OFF);
+
Re: [PATCH 0/6] rc-core: ir-core to rc-core conversion
On Tue, 09 Nov 2010 23:50:17 -0200, Mauro Carvalho Chehab mche...@infradead.org wrote: Hi David, Em 02-11-2010 18:26, Jarod Wilson escreveu: On Tue, Nov 2, 2010 at 4:17 PM, David Härdeman da...@hardeman.nu wrote: This is my current patch queue, the main change is to make struct rc_dev the primary interface for rc drivers and to abstract away the fact that there's an input device lurking in there somewhere. In addition, the cx88 and winbond-cir drivers are converted to use rc-core. The patchset is now based on current linux-2.6 upstream git tree since it carries both the v4l patches from the staging/for_v2.6.37-rc1 branch, large scancode support and bugfixes. Given the changes, these patches touch every single driver. Obviously I haven't tested them all due to a lack of hardware (I have made sure that all drivers compile without any warnings and I have tested the end result on mceusb and winbond-cir hardware, Jarod Wilson has tested nuvoton-cir, imon and several mceusb devices). And streamzap! :) Mauro's at the kernel summit, but I had a brief moment to talk to him earlier today. He had a few issues he wanted to give feedback on, but I didn't get any specifics yet, other than him not liking the rc-map.c bits merged into rc-main.c, mainly because part of the plan is to remove in-kernel maps entirely in 2.6.38. It doesn't make a big difference to me either way, and rc-main.c is still only 1300-ish lines, and would be even less once rc-map.c bits are ripped out... Sorry for giving you a late feedback about those patches. I was busy the last two weeks, due to my trip to US for KS/LPC. I've applied patches 1 to 3 (in fact, I got the patches from the previous version - unfortunately, patchwork do a very bad job when someone sends a new series that superseeds the previous patches). Kinda makes it pointless to refresh patchsets, doesn't it? I didn't like patch 4 for some reasons: instead of just doing rename, it is a all-in-one patch, doing several things at the same time. It is hard to analyse it by just looking at the diffs, as it is not a pure rename patch. It was an almost pure merge + rename (it added only the things that follow from the merger...forward declarations and making functions static). The real problem is that, since it includes the removal of files, those files need to be identical. Also, it doesn't rename /drivers/media/IR into something else. No, of course not, that would have made the patch even larger for little gain. I see that you've included a renaming patch in your patchset sent to the list, but wouldn't it be easier to apply it after all the other patches rather than before? Btw, the patch is currently broken: $ quilt push Applying patch patches/lmml_298052_4_6_ir_core_merge_and_rename_to_rc_core.patch patching file drivers/media/IR/Makefile patching file drivers/media/IR/ir-core-priv.h patching file drivers/media/IR/ir-keytable.c Hunk #1 FAILED at 1. File drivers/media/IR/ir-keytable.c is not empty after patch, as expected 1 out of 1 hunk FAILED -- rejects in file drivers/media/IR/ir-keytable.c Not sure if you used the most recent version of patch 4/6 or not. If you used the most recent, it's based on 2.6.37-rc1 upstream which has both the large-input-scancodes patches as well as two important bugfixes to ir-keytable.c, so since your staging/for_v2.6.38 is based on 2.6.36 plus the staging/for_v2.6.37-rc1 branch, it won't apply. If you used to second most recent, then it's based on the input-large-scancodes being merged but not the two upstream bugfixes which followed it. Whichever way you choose, those two bugfixes should not get lost in the noise. patching file drivers/media/IR/ir-raw-event.c patching file drivers/media/IR/ir-sysfs.c patching file drivers/media/IR/rc-main.c patching file drivers/media/IR/rc-map.c patching file drivers/media/IR/rc-raw.c patching file include/media/ir-core.h Patch patches/lmml_298052_4_6_ir_core_merge_and_rename_to_rc_core.patch does not apply (enforce with -f) I think that the better is if I write a few patches doing the basic rename stuff, based on my current tip, and then we can discuss about merging things into a fewer number of files, as you're proposing, and apply patch 5/6 and 6/6. Not sure why, but patchwork didn't seem to catch patch 6/6. I suspect that it is because your name is not encoded with UTF-8 inside the driver. I've picked it manually here, and fixed the naming stuff, but it needs patch 5/6, in order to work. My name used to be UTF-8 encoded in winbond-cir, and it was changed upstream (not by me), so I'm not going to revert it. I'll be pushing the renaming stuff soon at ML. I'll try to use your naming convention and, if I do it well, maybe I can apply patches 5/6 and 6/6 on it without rebasing. Well, let's see. I'll wait for more feedback then? -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe
[GIT PATCHES FOR 2.6.38] gspca-stv06xx: support bandwidth changing
Hi, Here is a pull request the one patch which did not merge properly in my previous pull request. I based this on staging/for_v2.6.38, as that is where the patches from the previous pull request ended up. But these are all bug-fixes intended for 2.6.37. Do I need to do anything special (like a branch based on staging/for_v2.6.37-rc1 with all of them and a separate pull request) for this, or will you cherry pick them over later? The following changes since commit af9f14f7fc31f0d7b7cdf8f7f7f15a3c3794aea3: [media] IR: add tv power scancode to rc6 mce keymap (2010-11-10 00:58:49 -0200) are available in the git repository at: git://linuxtv.org/hgoede/gspca gspca-for_v2.6.38 Hans de Goede (1): gspca-stv06xx: support bandwidth changing drivers/media/video/gspca/stv06xx/stv06xx.c| 55 +++- drivers/media/video/gspca/stv06xx/stv06xx_hdcs.h | 11 - drivers/media/video/gspca/stv06xx/stv06xx_pb0100.c | 18 +-- drivers/media/video/gspca/stv06xx/stv06xx_pb0100.h |3 + drivers/media/video/gspca/stv06xx/stv06xx_sensor.h |4 ++ drivers/media/video/gspca/stv06xx/stv06xx_st6422.c | 17 +-- drivers/media/video/gspca/stv06xx/stv06xx_st6422.h |3 + drivers/media/video/gspca/stv06xx/stv06xx_vv6410.h |9 ++-- 8 files changed, 93 insertions(+), 27 deletions(-) Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mx2_camera: fix pixel clock polarity configuration
Hi linux-media,
On Wed, Oct 27, 2010 at 09:03:52AM +0200, Baruch Siach wrote:
When SOCAM_PCLK_SAMPLE_FALLING, just leave CSICR1_REDGE unset, otherwise we
get
the inverted behaviour.
Signed-off-by: Baruch Siach bar...@tkos.co.il
Trying my luck again. Now adding Guennadi to Cc.
This is a real bug fix, BTW.
baruch
---
drivers/media/video/mx2_camera.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index 3ea2ec0..02f144f 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -811,8 +811,6 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd,
if (common_flags SOCAM_PCLK_SAMPLE_RISING)
csicr1 |= CSICR1_REDGE;
- if (common_flags SOCAM_PCLK_SAMPLE_FALLING)
- csicr1 |= CSICR1_INV_PCLK;
if (common_flags SOCAM_VSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_SOF_POL;
if (common_flags SOCAM_HSYNC_ACTIVE_HIGH)
--
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] rc-core: ir-core to rc-core conversion
On Tue, 9 Nov 2010 22:25:56 -0500, Jarod Wilson ja...@wilsonet.com wrote: On Tue, Nov 9, 2010 at 8:50 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: ... Sorry for giving you a late feedback about those patches. I was busy the last two weeks, due to my trip to US for KS/LPC. I've applied patches 1 to 3 (in fact, I got the patches from the previous version - unfortunately, patchwork do a very bad job when someone sends a new series that superseeds the previous patches). I didn't like patch 4 for some reasons: instead of just doing rename, it is a all-in-one patch, doing several things at the same time. It is hard to analyse it by just looking at the diffs, as it is not a pure rename patch. Also, it doesn't rename /drivers/media/IR into something else. Btw, the patch is currently broken: Hm, the series applied cleanly against 2.6.37-rc1 a bit ago: http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=shortlog;h=refs/heads/staging Still does, and it's no wonder it doesn't apply to staging/for_v2.6.38 since it's a franken-branch of 2.6.36 + staging/for_v2.6.37 + some more patches. -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] ir-core: make struct rc_dev the primary interface
On Wed, 10 Nov 2010 02:31:24 -0200, Mauro Carvalho Chehab mche...@infradead.org wrote: Em 29-10-2010 17:08, David Härdeman escreveu: This patch merges the ir_input_dev and ir_dev_props structs into a single struct called rc_dev. The drivers and various functions in rc-core used by the drivers are also changed to use rc_dev as the primary interface when dealing with rc-core. This means that the input_dev is abstracted away from the drivers which is necessary if we ever want to support multiple input devs per rc device. The new API is similar to what the input subsystem uses, i.e: rc_device_alloc() rc_device_free() rc_device_register() rc_device_unregister() David, +struct rc_dev *rdev; ... +struct rc_dev *dev; /* pointer to the parent rc_dev */ +struct rc_dev *rc; A quick comment: try to call this struct with the same name on all places, avoiding to call it as just dev. It makes harder to understand the code, especially on complex devices that have several types of dev's. The better is to always call it as rc_dev. Fair enough. I can fix that in a separate patch, or in a respin of my original patch. But first I need to know what I should base a new patch on...I'm confused by now -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] MCDE: Add frame buffer device
This patch adds support for the MCDE, Memory-to-display controller,
found in the ST-Ericsson ux500 products.
This patch adds a frame buffer device driver that uses the DSS.
Signed-off-by: Jimmy Rubin jimmy.ru...@stericsson.com
Acked-by: Linus Walleij linus.walleij.stericsson.com
---
drivers/video/mcde/mcde_fb.c | 697 ++
include/video/mcde/mcde_fb.h | 54
2 files changed, 751 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/mcde/mcde_fb.c
create mode 100644 include/video/mcde/mcde_fb.h
diff --git a/drivers/video/mcde/mcde_fb.c b/drivers/video/mcde/mcde_fb.c
new file mode 100644
index 000..9486e33
--- /dev/null
+++ b/drivers/video/mcde/mcde_fb.c
@@ -0,0 +1,697 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2010
+ *
+ * ST-Ericsson MCDE frame buffer driver
+ *
+ * Author: Marcus Lorentzon marcus.xm.lorent...@stericsson.com
+ * for ST-Ericsson.
+ *
+ * License terms: GNU General Public License (GPL), version 2.
+ */
+
+#include linux/kernel.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/fb.h
+#include linux/mm.h
+#include linux/dma-mapping.h
+
+#include video/mcde/mcde_fb.h
+
+#define MCDE_FB_BPP_MAX16
+#define MCDE_FB_VXRES_MAX 1920
+#define MCDE_FB_VYRES_MAX 2160
+
+static struct fb_ops fb_ops;
+
+struct pix_fmt_info {
+ enum mcde_ovly_pix_fmt pix_fmt;
+
+ u32bpp;
+ struct fb_bitfield r;
+ struct fb_bitfield g;
+ struct fb_bitfield b;
+ struct fb_bitfield a;
+ u32nonstd;
+};
+
+struct pix_fmt_info pix_fmt_map[] = {
+ {
+ .pix_fmt = MCDE_OVLYPIXFMT_RGB565,
+ .bpp = 16,
+ .r = { .offset = 11, .length = 5 },
+ .g = { .offset = 5, .length = 6 },
+ .b = { .offset = 0, .length = 5 },
+ }, {
+ .pix_fmt = MCDE_OVLYPIXFMT_RGBA5551,
+ .bpp = 16,
+ .r = { .offset = 11, .length = 5 },
+ .g = { .offset = 6, .length = 5 },
+ .b = { .offset = 1, .length = 5 },
+ .a = { .offset = 0, .length = 1 },
+ }, {
+ .pix_fmt = MCDE_OVLYPIXFMT_RGBA,
+ .bpp = 16,
+ .r = { .offset = 12, .length = 4 },
+ .g = { .offset = 8, .length = 4 },
+ .b = { .offset = 4, .length = 4 },
+ .a = { .offset = 0, .length = 4 },
+ }, {
+ .pix_fmt = MCDE_OVLYPIXFMT_YCbCr422,
+ .bpp = 16,
+ .nonstd = MCDE_OVLYPIXFMT_YCbCr422,
+ }, {
+ .pix_fmt = MCDE_OVLYPIXFMT_RGB888,
+ .bpp = 24,
+ .r = { .offset = 16, .length = 8 },
+ .g = { .offset = 8, .length = 8 },
+ .b = { .offset = 0, .length = 8 },
+ }, {
+ .pix_fmt = MCDE_OVLYPIXFMT_RGBA,
+ .bpp = 32,
+ .r = { .offset = 16, .length = 8 },
+ .g = { .offset = 8, .length = 8 },
+ .b = { .offset = 0, .length = 8 },
+ .a = { .offset = 24, .length = 8 },
+ }, {
+ .pix_fmt = MCDE_OVLYPIXFMT_RGBX,
+ .bpp = 32,
+ .r = { .offset = 16, .length = 8 },
+ .g = { .offset = 8, .length = 8 },
+ .b = { .offset = 0, .length = 8 },
+ }
+
+};
+
+static struct platform_device mcde_fb_device = {
+ .name = mcde_fb,
+ .id = -1,
+};
+
+/* Helpers */
+
+static struct pix_fmt_info *find_pix_fmt_info(enum mcde_ovly_pix_fmt pix_fmt)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(pix_fmt_map); i++) {
+ if (pix_fmt_map[i].pix_fmt == pix_fmt)
+ return pix_fmt_map[i];
+ }
+ return NULL;
+}
+
+static bool bitfield_cmp(struct fb_bitfield *bf1, struct fb_bitfield *bf2)
+{
+ return bf1-offset == bf2-offset
+ bf1-length == bf2-length
+ bf1-msb_right == bf2-msb_right;
+}
+
+static struct pix_fmt_info *var_to_pix_fmt_info(struct fb_var_screeninfo *var)
+{
+ int i;
+ struct pix_fmt_info *info;
+
+ if (var-nonstd)
+ return find_pix_fmt_info(var-nonstd);
+
+ for (i = 0; i ARRAY_SIZE(pix_fmt_map); i++) {
+ info = pix_fmt_map[i];
+ if (info-bpp == var-bits_per_pixel
+ bitfield_cmp(info-r, var-red)
+ bitfield_cmp(info-g, var-green)
+ bitfield_cmp(info-b, var-blue)
+ bitfield_cmp(info-a, var-transp))
+ return info;
+ }
+
+ for (i = 0; i ARRAY_SIZE(pix_fmt_map); i++) {
+ info = pix_fmt_map[i];
+ if (var-bits_per_pixel == info-bpp)
+ return info;
+ }
+
+ return NULL;
+}
+
+static void
Re: [PATCH 0/6] rc-core: ir-core to rc-core conversion
Em 10-11-2010 07:24, David Härdeman escreveu: On Tue, 09 Nov 2010 23:50:17 -0200, Mauro Carvalho Chehab mche...@infradead.org wrote: Hi David, Em 02-11-2010 18:26, Jarod Wilson escreveu: On Tue, Nov 2, 2010 at 4:17 PM, David Härdeman da...@hardeman.nu wrote: This is my current patch queue, the main change is to make struct rc_dev the primary interface for rc drivers and to abstract away the fact that there's an input device lurking in there somewhere. In addition, the cx88 and winbond-cir drivers are converted to use rc-core. The patchset is now based on current linux-2.6 upstream git tree since it carries both the v4l patches from the staging/for_v2.6.37-rc1 branch, large scancode support and bugfixes. Given the changes, these patches touch every single driver. Obviously I haven't tested them all due to a lack of hardware (I have made sure that all drivers compile without any warnings and I have tested the end result on mceusb and winbond-cir hardware, Jarod Wilson has tested nuvoton-cir, imon and several mceusb devices). And streamzap! :) Mauro's at the kernel summit, but I had a brief moment to talk to him earlier today. He had a few issues he wanted to give feedback on, but I didn't get any specifics yet, other than him not liking the rc-map.c bits merged into rc-main.c, mainly because part of the plan is to remove in-kernel maps entirely in 2.6.38. It doesn't make a big difference to me either way, and rc-main.c is still only 1300-ish lines, and would be even less once rc-map.c bits are ripped out... Sorry for giving you a late feedback about those patches. I was busy the last two weeks, due to my trip to US for KS/LPC. I've applied patches 1 to 3 (in fact, I got the patches from the previous version - unfortunately, patchwork do a very bad job when someone sends a new series that superseeds the previous patches). Kinda makes it pointless to refresh patchsets, doesn't it? Yes. I didn't like patch 4 for some reasons: instead of just doing rename, it is a all-in-one patch, doing several things at the same time. It is hard to analyse it by just looking at the diffs, as it is not a pure rename patch. It was an almost pure merge + rename (it added only the things that follow from the merger...forward declarations and making functions static). The real problem is that, since it includes the removal of files, those files need to be identical. Also, it doesn't rename /drivers/media/IR into something else. No, of course not, that would have made the patch even larger for little gain. I see that you've included a renaming patch in your patchset sent to the list, but wouldn't it be easier to apply it after all the other patches rather than before? When such change is done as I did, git is smart enough to do the right thing. So, even if the file suffered changes, it is still a rename operation there, even if the file had changes. Btw, the patch is currently broken: $ quilt push Applying patch patches/lmml_298052_4_6_ir_core_merge_and_rename_to_rc_core.patch patching file drivers/media/IR/Makefile patching file drivers/media/IR/ir-core-priv.h patching file drivers/media/IR/ir-keytable.c Hunk #1 FAILED at 1. File drivers/media/IR/ir-keytable.c is not empty after patch, as expected 1 out of 1 hunk FAILED -- rejects in file drivers/media/IR/ir-keytable.c Not sure if you used the most recent version of patch 4/6 or not. If you used the most recent, it's based on 2.6.37-rc1 upstream which has both the large-input-scancodes patches as well as two important bugfixes to ir-keytable.c, so since your staging/for_v2.6.38 is based on 2.6.36 plus the staging/for_v2.6.37-rc1 branch, it won't apply. Gah! Yeah, my tree is based on 2.6.36, but we need to be based on .37-rc1. I'll merge .37-rc1. If you used to second most recent, then it's based on the input-large-scancodes being merged but not the two upstream bugfixes which followed it. Whichever way you choose, those two bugfixes should not get lost in the noise. Yeah, sure. The git renaming patches will probably do the right thing. I'll double check. patching file drivers/media/IR/ir-raw-event.c patching file drivers/media/IR/ir-sysfs.c patching file drivers/media/IR/rc-main.c patching file drivers/media/IR/rc-map.c patching file drivers/media/IR/rc-raw.c patching file include/media/ir-core.h Patch patches/lmml_298052_4_6_ir_core_merge_and_rename_to_rc_core.patch does not apply (enforce with -f) I think that the better is if I write a few patches doing the basic rename stuff, based on my current tip, and then we can discuss about merging things into a fewer number of files, as you're proposing, and apply patch 5/6 and 6/6. Not sure why, but patchwork didn't seem to catch patch 6/6. I suspect that it is because your name is not encoded with UTF-8 inside the driver. I've picked it manually here, and fixed the naming stuff, but it
[PATCH 07/10] MCDE: Add display subsystem framework
This patch adds support for the MCDE, Memory-to-display controller,
found in the ST-Ericsson ux500 products.
This patch adds a display subsystem framework that can be used
by a frame buffer device driver to control a display and MCDE.
Signed-off-by: Jimmy Rubin jimmy.ru...@stericsson.com
Acked-by: Linus Walleij linus.walleij.stericsson.com
---
drivers/video/mcde/mcde_dss.c | 353 +
include/video/mcde/mcde_dss.h | 78 +
2 files changed, 431 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/mcde/mcde_dss.c
create mode 100644 include/video/mcde/mcde_dss.h
diff --git a/drivers/video/mcde/mcde_dss.c b/drivers/video/mcde/mcde_dss.c
new file mode 100644
index 000..c5b3a96
--- /dev/null
+++ b/drivers/video/mcde/mcde_dss.c
@@ -0,0 +1,353 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2010
+ *
+ * ST-Ericsson MCDE display sub system driver
+ *
+ * Author: Marcus Lorentzon marcus.xm.lorent...@stericsson.com
+ * for ST-Ericsson.
+ *
+ * License terms: GNU General Public License (GPL), version 2.
+ */
+
+#include linux/kernel.h
+#include linux/device.h
+#include linux/err.h
+#include linux/slab.h
+
+#include video/mcde/mcde_dss.h
+
+#define to_overlay(x) container_of(x, struct mcde_overlay, kobj)
+
+void overlay_release(struct kobject *kobj)
+{
+ struct mcde_overlay *ovly = to_overlay(kobj);
+
+ kfree(ovly);
+}
+
+struct kobj_type ovly_type = {
+ .release = overlay_release,
+};
+
+static int apply_overlay(struct mcde_overlay *ovly,
+ struct mcde_overlay_info *info, bool force)
+{
+ int ret = 0;
+ if (ovly-ddev-invalidate_area) {
+ /* TODO: transform ovly coord to screen coords (vmode):
+* add offset
+*/
+ struct mcde_rectangle dirty = info-dirty;
+ ret = ovly-ddev-invalidate_area(ovly-ddev, dirty);
+ }
+
+ if (ovly-info.paddr != info-paddr || force)
+ mcde_ovly_set_source_buf(ovly-state, info-paddr);
+
+ if (ovly-info.stride != info-stride || ovly-info.fmt != info-fmt ||
+ force)
+ mcde_ovly_set_source_info(ovly-state, info-stride, info-fmt);
+ if (ovly-info.src_x != info-src_x ||
+ ovly-info.src_y != info-src_y ||
+ ovly-info.w != info-w ||
+ ovly-info.h != info-h || force)
+ mcde_ovly_set_source_area(ovly-state,
+ info-src_x, info-src_y, info-w, info-h);
+ if (ovly-info.dst_x != info-dst_x || ovly-info.dst_y != info-dst_y
+ || ovly-info.dst_z != info-dst_z ||
+ force)
+ mcde_ovly_set_dest_pos(ovly-state,
+ info-dst_x, info-dst_y, info-dst_z);
+
+ mcde_ovly_apply(ovly-state);
+ ovly-info = *info;
+
+ return ret;
+}
+
+/* MCDE DSS operations */
+
+int mcde_dss_enable_display(struct mcde_display_device *ddev)
+{
+ int ret;
+ struct mcde_chnl_state *chnl;
+
+ if (ddev-enabled)
+ return 0;
+
+ /* Acquire MCDE resources */
+ chnl = mcde_chnl_get(ddev-chnl_id, ddev-fifo, ddev-port);
+ if (IS_ERR(chnl)) {
+ ret = PTR_ERR(chnl);
+ dev_warn(ddev-dev, Failed to acquire MCDE channel\n);
+ return ret;
+ }
+ ddev-chnl_state = chnl;
+ /* Initiate display communication */
+ ret = ddev-set_power_mode(ddev, MCDE_DISPLAY_PM_STANDBY);
+ if (ret 0) {
+ dev_warn(ddev-dev, Failed to initialize display\n);
+ goto display_failed;
+ }
+
+ ret = ddev-set_synchronized_update(ddev, ddev-synchronized_update);
+ if (ret 0)
+ dev_warn(ddev-dev, Failed to set sync\n);
+
+ /* TODO: call driver for all defaults like sync_update above */
+
+ dev_dbg(ddev-dev, Display enabled, chnl=%d\n,
+ ddev-chnl_id);
+ ddev-enabled = true;
+ return 0;
+
+display_failed:
+ mcde_chnl_put(ddev-chnl_state);
+ ddev-chnl_state = NULL;
+ return ret;
+}
+EXPORT_SYMBOL(mcde_dss_enable_display);
+
+void mcde_dss_disable_display(struct mcde_display_device *ddev)
+{
+ if (!ddev-enabled)
+ return;
+
+ /* TODO: Disable overlays */
+
+ (void)ddev-set_power_mode(ddev, MCDE_DISPLAY_PM_OFF);
+ mcde_chnl_put(ddev-chnl_state);
+ ddev-chnl_state = NULL;
+
+ ddev-enabled = false;
+
+ dev_dbg(ddev-dev, Display disabled, chnl=%d\n, ddev-chnl_id);
+}
+EXPORT_SYMBOL(mcde_dss_disable_display);
+
+int mcde_dss_apply_channel(struct mcde_display_device *ddev)
+{
+ if (!ddev-apply_config)
+ return -EINVAL;
+
+ return
[PATCH 10/10] ux500: MCDE: Add platform specific data
This patch adds support for the MCDE, Memory-to-display controller,
found in the ST-Ericsson ux500 products.
The configuration of the MCDE hardware, the MCDE framebuffer device
and the display that is connected to ux500 is managed in this patch.
Signed-off-by: Jimmy Rubin jimmy.ru...@stericsson.com
Acked-by: Linus Walleij linus.walleij.stericsson.com
---
arch/arm/mach-ux500/Kconfig|8 +
arch/arm/mach-ux500/Makefile |1 +
arch/arm/mach-ux500/board-mop500-mcde.c| 209
arch/arm/mach-ux500/board-mop500-regulators.c | 28 +++
arch/arm/mach-ux500/board-mop500.c |3 +
arch/arm/mach-ux500/devices-db8500.c | 68
arch/arm/mach-ux500/include/mach/db8500-regs.h |7 +
arch/arm/mach-ux500/include/mach/devices.h |1 +
arch/arm/mach-ux500/include/mach/prcmu-regs.h |1 +
arch/arm/mach-ux500/include/mach/prcmu.h |3 +
arch/arm/mach-ux500/prcmu.c| 129 +++
11 files changed, 458 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-ux500/board-mop500-mcde.c
diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index 2dd44a0..a868629 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig
@@ -50,5 +50,13 @@ config U5500_MBOX
default y
help
Add support for U5500 mailbox communication with modem side
+#Configuration for MCDE setup
+config DISPLAY_GENERIC_DSI_PRIMARY
+bool Main display support
+ depends on MACH_U8500_MOP FB_MCDE REGULATOR
+ select MCDE_DISPLAY_GENERIC_DSI
+default y
+ help
+ Say yes here if main display exists
endif
diff --git a/arch/arm/mach-ux500/Makefile b/arch/arm/mach-ux500/Makefile
index 9e27a84..5562c85 100644
--- a/arch/arm/mach-ux500/Makefile
+++ b/arch/arm/mach-ux500/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_LOCAL_TIMERS)+= localtimer.o
obj-$(CONFIG_REGULATOR_AB8500) += board-mop500-regulators.o
obj-$(CONFIG_U5500_MODEM_IRQ) += modem_irq.o
obj-$(CONFIG_U5500_MBOX) += mbox.o
+obj-$(CONFIG_FB_MCDE) += board-mop500-mcde.o
diff --git a/arch/arm/mach-ux500/board-mop500-mcde.c
b/arch/arm/mach-ux500/board-mop500-mcde.c
new file mode 100644
index 000..3695746
--- /dev/null
+++ b/arch/arm/mach-ux500/board-mop500-mcde.c
@@ -0,0 +1,209 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2010
+ *
+ * Author: Marcus Lorentzon marcus.xm.lorent...@stericsson.com
+ * for ST-Ericsson.
+ *
+ * License terms: GNU General Public License (GPL), version 2.
+ */
+#include linux/platform_device.h
+#include linux/kernel.h
+#include linux/gpio.h
+#include linux/delay.h
+
+#include video/mcde/mcde_display.h
+#include video/mcde/mcde_display-generic_dsi.h
+#include video/mcde/mcde_fb.h
+#include video/mcde/mcde_dss.h
+
+#include mach/db8500-regs.h
+
+#include board-mop500.h
+
+#define DSI_UNIT_INTERVAL_00x9
+#define DSI_UNIT_INTERVAL_10x9
+#define DSI_UNIT_INTERVAL_20x6
+
+#define PRIMARY_DISPLAY_ID 0
+#define SECONDARY_DISPLAY_ID 1
+#define TERTIARY_DISPLAY_ID2
+
+static bool rotate_main = true;
+
+static int generic_platform_enable(struct mcde_display_device *dev)
+{
+ struct mcde_display_generic_platform_data *pdata =
+ dev-dev.platform_data;
+
+ dev_dbg(dev-dev, %s: Reset power on generic display\n, __func__);
+
+ if (pdata-regulator) {
+ if (regulator_enable(pdata-regulator) 0) {
+ dev_err(dev-dev, %s:Failed to enable regulator\n
+ , __func__);
+ return -EINVAL;
+ }
+ }
+
+ gpio_direction_output(pdata-reset_gpio,
+ !pdata-reset_high);
+ if (pdata-reset_gpio)
+ gpio_set_value(pdata-reset_gpio, pdata-reset_high);
+ mdelay(pdata-reset_delay);
+ if (pdata-reset_gpio)
+ gpio_set_value(pdata-reset_gpio, !pdata-reset_high);
+
+ return 0;
+}
+
+static int generic_platform_disable(struct mcde_display_device *dev)
+{
+ struct mcde_display_generic_platform_data *pdata =
+ dev-dev.platform_data;
+
+ dev_dbg(dev-dev, %s:Reset power off generic display\n, __func__);
+
+ if (pdata-regulator) {
+ if (regulator_disable(pdata-regulator) 0) {
+ dev_err(dev-dev, %s:Failed to disable regulator\n
+ , __func__);
+ return -EINVAL;
+ }
+ }
+ return 0;
+}
+
+#ifdef CONFIG_DISPLAY_GENERIC_DSI_PRIMARY
+static struct mcde_port port0 = {
+ .type = MCDE_PORTTYPE_DSI,
+ .mode = MCDE_PORTMODE_CMD,
+ .pixel_format = MCDE_PORTPIXFMT_DSI_24BPP,
+ .ifc = 1,
+ .link = 0,
+#ifdef CONFIG_DISPLAY_GENERIC_DSI_PRIMARY_AUTO_SYNC
+ .sync_src = MCDE_SYNCSRC_OFF,
+ .update_auto_trig = true,
+#else
+ .sync_src =
Re: [PATCH] i2c: Remove obsolete cleanup for clientdata
On Wed, 10 Nov 2010, Wolfram Sang wrote:
A few new i2c-drivers came into the kernel which clear the clientdata-pointer
on exit. This is obsolete meanwhile, so fix it and hope the word will spread.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
for imx074 and ov6650:
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Thanks
Guennadi
---
Like last time I suggest to collect acks from the driver authors and merge it
vie Jean's i2c-tree.
drivers/media/video/imx074.c |2 --
drivers/media/video/ov6650.c |2 --
drivers/misc/apds9802als.c|1 -
drivers/staging/olpc_dcon/olpc_dcon.c |3 ---
4 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/imx074.c b/drivers/media/video/imx074.c
index 380e459..27b5dfd 100644
--- a/drivers/media/video/imx074.c
+++ b/drivers/media/video/imx074.c
@@ -451,7 +451,6 @@ static int imx074_probe(struct i2c_client *client,
ret = imx074_video_probe(icd, client);
if (ret 0) {
icd-ops = NULL;
- i2c_set_clientdata(client, NULL);
kfree(priv);
return ret;
}
@@ -468,7 +467,6 @@ static int imx074_remove(struct i2c_client *client)
icd-ops = NULL;
if (icl-free_bus)
icl-free_bus(icl);
- i2c_set_clientdata(client, NULL);
client-driver = NULL;
kfree(priv);
diff --git a/drivers/media/video/ov6650.c b/drivers/media/video/ov6650.c
index b7cfeab..2dd5298 100644
--- a/drivers/media/video/ov6650.c
+++ b/drivers/media/video/ov6650.c
@@ -1176,7 +1176,6 @@ static int ov6650_probe(struct i2c_client *client,
if (ret) {
icd-ops = NULL;
- i2c_set_clientdata(client, NULL);
kfree(priv);
}
@@ -1187,7 +1186,6 @@ static int ov6650_remove(struct i2c_client *client)
{
struct ov6650 *priv = to_ov6650(client);
- i2c_set_clientdata(client, NULL);
kfree(priv);
return 0;
}
diff --git a/drivers/misc/apds9802als.c b/drivers/misc/apds9802als.c
index f9b91ba..abe3d21 100644
--- a/drivers/misc/apds9802als.c
+++ b/drivers/misc/apds9802als.c
@@ -251,7 +251,6 @@ static int apds9802als_probe(struct i2c_client *client,
return res;
als_error1:
- i2c_set_clientdata(client, NULL);
kfree(data);
return res;
}
diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c
b/drivers/staging/olpc_dcon/olpc_dcon.c
index 75aa7a36..f286a4c 100644
--- a/drivers/staging/olpc_dcon/olpc_dcon.c
+++ b/drivers/staging/olpc_dcon/olpc_dcon.c
@@ -733,7 +733,6 @@ static int dcon_probe(struct i2c_client *client, const
struct i2c_device_id *id)
edev:
platform_device_unregister(dcon_device);
dcon_device = NULL;
- i2c_set_clientdata(client, NULL);
eirq:
free_irq(DCON_IRQ, dcon_driver);
einit:
@@ -757,8 +756,6 @@ static int dcon_remove(struct i2c_client *client)
platform_device_unregister(dcon_device);
cancel_work_sync(dcon_work);
- i2c_set_clientdata(client, NULL);
-
return 0;
}
--
1.7.2.3
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mx2_camera: fix pixel clock polarity configuration
On Wed, 10 Nov 2010, Baruch Siach wrote:
Hi linux-media,
On Wed, Oct 27, 2010 at 09:03:52AM +0200, Baruch Siach wrote:
When SOCAM_PCLK_SAMPLE_FALLING, just leave CSICR1_REDGE unset, otherwise we
get
the inverted behaviour.
Signed-off-by: Baruch Siach bar...@tkos.co.il
Trying my luck again. Now adding Guennadi to Cc.
Trying again will not help, until you reply to my previous comment, and
you, probably, will not reply to it, until your mail-server stops
rejecting my mails, and it probably will reject this one too in a way
similar too
bar...@tkos.co.il:
62.219.50.35_does_not_like_recipient./Remote_host_said:_550_5.7.1_bar...@tkos.co.il..._Rejected_recent_spam_sourc
e_[mailout-de.gmx.net]_Reply_at_http://tk-open-systems.com/unblockme/index.php?id=tango/Giving_up_on_62.219.50.35./
Thanks
Guennadi
This is a real bug fix, BTW.
baruch
---
drivers/media/video/mx2_camera.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index 3ea2ec0..02f144f 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -811,8 +811,6 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd,
if (common_flags SOCAM_PCLK_SAMPLE_RISING)
csicr1 |= CSICR1_REDGE;
- if (common_flags SOCAM_PCLK_SAMPLE_FALLING)
- csicr1 |= CSICR1_INV_PCLK;
if (common_flags SOCAM_VSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_SOF_POL;
if (common_flags SOCAM_HSYNC_ACTIVE_HIGH)
--
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] rc-core: ir-core to rc-core conversion
On Wed, 10 Nov 2010 10:49:10 -0200, Mauro Carvalho Chehab mche...@infradead.org wrote: Em 10-11-2010 07:24, David Härdeman escreveu: Not sure if you used the most recent version of patch 4/6 or not. If you used the most recent, it's based on 2.6.37-rc1 upstream which has both the large-input-scancodes patches as well as two important bugfixes to ir-keytable.c, so since your staging/for_v2.6.38 is based on 2.6.36 plus the staging/for_v2.6.37-rc1 branch, it won't apply. Gah! Yeah, my tree is based on 2.6.36, but we need to be based on .37-rc1. I'll merge .37-rc1. I think/hope my patches will apply with little to no fuzz once you've done that. My name used to be UTF-8 encoded in winbond-cir, and it was changed upstream (not by me), so I'm not going to revert it. Patchwork handles very badly charset encodings, due to Python. I sent several patches for it to fix several problems I noticed there. Basically, Python kills any script if the an invalid character is inserted on a string. E. g., if your emailer says that the email is encoded as UTF-8, and a non-UTF-8 character is found on any part of the email, the script will die, as it will try to write the email contents on some vars. Due to that, a patch/email with an invalid character on his charset will be silently discarded by patchwork, as the script will die. Not much I can do there :) I suspect that your emailer might be doing some bad things also, as I need to manually fix your author's name every time. In general the SOB on your emails have one encoding, while the From: has another encoding. I didn't know that, I'll have a look. I'm guessing that both iso88591-1 and utf-8 encodings are used. So, I'll try to merge the pending patches from your tree. I'll let you know if I have any problems. Sounds good. Thanks. -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/6] davinci vpbe: V4L2 Display driver for DM644X
Murali, I will change the name order. Thanks and Regards, -manju On Wed, Nov 10, 2010 at 18:35:16, Muralidharan Karicheri wrote: Manjunath, Thank you for putting up this patch together. I didn't see the 1/6 of this series in the mailing list. Also it appears as if the patch came from me. Please add my sign-off as second, you being the first. Murali On Mon, Nov 8, 2010 at 9:54 AM, Manjunath Hadli manjunath.ha...@ti.com wrote: This driver is written for Texas Instruments's DM644X VPBE IP. This SoC supports 2 video planes and 2 OSD planes as part of its OSD (On Screen Display) block. The OSD lanes predminantly support RGB space and the Video planes support YUV data. Out of these 4, the 2 video planes are supported as part of the V4L2 driver. These would be enumerated as video2 and video3 dev nodes. The blending and video timing generator unit (VENC- for Video Encoder) is the unit which combines/blends the output of these 4 planes into a single stream and this output is given to Video input devices like TV and other digital LCDs. The software for VENC is designed as a subdevice with support for SD(NTSC and PAL) modes and 2 outputs. This SoC forms the iniial implementation of its later additions like DM355 and DM365. Muralidharan Karicheri (6): davinci vpbe: V4L2 display driver for DM644X SoC davinci vpbe: VPBE display driver davinci vpbe: OSD(On Screen Display ) block davinci vpbe: VENC( Video Encoder) implementation davinci vpbe: platform specific additions davinci vpbe: Build infrastructure for VPBE driver arch/arm/mach-davinci/board-dm644x-evm.c | 85 +- arch/arm/mach-davinci/dm644x.c | 181 ++- arch/arm/mach-davinci/include/mach/dm644x.h | 4 + drivers/media/video/davinci/Kconfig | 22 + drivers/media/video/davinci/Makefile | 2 + drivers/media/video/davinci/vpbe.c | 861 ++ drivers/media/video/davinci/vpbe_display.c | 2283 ++ drivers/media/video/davinci/vpbe_osd.c | 1208 ++ drivers/media/video/davinci/vpbe_osd_regs.h | 389 + drivers/media/video/davinci/vpbe_venc.c | 617 +++ drivers/media/video/davinci/vpbe_venc_regs.h | 189 +++ include/media/davinci/vpbe.h | 187 +++ include/media/davinci/vpbe_display.h | 144 ++ include/media/davinci/vpbe_osd.h | 397 + include/media/davinci/vpbe_types.h | 170 ++ include/media/davinci/vpbe_venc.h | 70 + 16 files changed, 6790 insertions(+), 19 deletions(-) create mode 100644 drivers/media/video/davinci/vpbe.c create mode 100644 drivers/media/video/davinci/vpbe_display.c create mode 100644 drivers/media/video/davinci/vpbe_osd.c create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h create mode 100644 drivers/media/video/davinci/vpbe_venc.c create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h create mode 100644 include/media/davinci/vpbe.h create mode 100644 include/media/davinci/vpbe_display.h create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 include/media/davinci/vpbe_types.h create mode 100644 include/media/davinci/vpbe_venc.h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Murali Karicheri mkarich...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] davinci vpbe: V4L2 Display driver for DM644X
Hans,
Is it possible to extend the sub device ops to include SoC ip sub
device specific ops? I remember I had posted this question some time
back and you had proposed to add something like this. Just want to
check if that is still valid. This would make this driver
implementation little more cleaner.
struct vpbe_osd_ops;
struct v4l2_subdev_ops {
const struct v4l2_subdev_core_ops *core;
const struct v4l2_subdev_tuner_ops *tuner;
const struct v4l2_subdev_audio_ops *audio;
const struct v4l2_subdev_video_ops *video;
const struct v4l2_subdev_vbi_ops*vbi;
const struct v4l2_subdev_ir_ops *ir;
const struct v4l2_subdev_sensor_ops *sensor;
/* SoC IP specific ops */
const struct vpbe_osd_ops *vpbe_osd;
};
The struct vpbe_osd_ops will be defined in the osd sub device header
file. This will allow the host/bridge driver to call osd specific
operations like standard sub dev ops.
Any comments?
On Wed, Nov 10, 2010 at 8:05 AM, Muralidharan Karicheri
mkarich...@gmail.com wrote:
Manjunath,
Thank you for putting up this patch together. I didn't see the 1/6 of
this series in the mailing list. Also it appears as if the patch came
from me. Please add my sign-off as second, you being the first.
Murali
On Mon, Nov 8, 2010 at 9:54 AM, Manjunath Hadli manjunath.ha...@ti.com
wrote:
This driver is written for Texas Instruments's DM644X VPBE IP.
This SoC supports 2 video planes and 2 OSD planes as part of its
OSD (On Screen Display) block. The OSD lanes predminantly support
RGB space and the Video planes support YUV data. Out of these 4,
the 2 video planes are supported as part of the V4L2 driver. These
would be enumerated as video2 and video3 dev nodes.
The blending and video timing generator unit (VENC- for Video Encoder)
is the unit which combines/blends the output of these 4 planes
into a single stream and this output is given to Video input devices
like TV and other digital LCDs. The software for VENC is designed as
a subdevice with support for SD(NTSC and PAL) modes and 2 outputs.
This SoC forms the iniial implementation of its later additions
like DM355 and DM365.
Muralidharan Karicheri (6):
davinci vpbe: V4L2 display driver for DM644X SoC
davinci vpbe: VPBE display driver
davinci vpbe: OSD(On Screen Display ) block
davinci vpbe: VENC( Video Encoder) implementation
davinci vpbe: platform specific additions
davinci vpbe: Build infrastructure for VPBE driver
arch/arm/mach-davinci/board-dm644x-evm.c | 85 +-
arch/arm/mach-davinci/dm644x.c | 181 ++-
arch/arm/mach-davinci/include/mach/dm644x.h | 4 +
drivers/media/video/davinci/Kconfig | 22 +
drivers/media/video/davinci/Makefile | 2 +
drivers/media/video/davinci/vpbe.c | 861 ++
drivers/media/video/davinci/vpbe_display.c | 2283
++
drivers/media/video/davinci/vpbe_osd.c | 1208 ++
drivers/media/video/davinci/vpbe_osd_regs.h | 389 +
drivers/media/video/davinci/vpbe_venc.c | 617 +++
drivers/media/video/davinci/vpbe_venc_regs.h | 189 +++
include/media/davinci/vpbe.h | 187 +++
include/media/davinci/vpbe_display.h | 144 ++
include/media/davinci/vpbe_osd.h | 397 +
include/media/davinci/vpbe_types.h | 170 ++
include/media/davinci/vpbe_venc.h | 70 +
16 files changed, 6790 insertions(+), 19 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe.c
create mode 100644 drivers/media/video/davinci/vpbe_display.c
create mode 100644 drivers/media/video/davinci/vpbe_osd.c
create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h
create mode 100644 drivers/media/video/davinci/vpbe_venc.c
create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
create mode 100644 include/media/davinci/vpbe.h
create mode 100644 include/media/davinci/vpbe_display.h
create mode 100644 include/media/davinci/vpbe_osd.h
create mode 100644 include/media/davinci/vpbe_types.h
create mode 100644 include/media/davinci/vpbe_venc.h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Murali Karicheri
mkarich...@gmail.com
--
Murali Karicheri
mkarich...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
mediabus enums
Hello Guennadi, Your media-bus enumerations capture the formats quite well. I needed the following for support on Davinci SOCs and liked to check with you if these are covered in some format in the list. 1. Parallel RGB 666 (18 data lines+ 5 sync lines) 2. YUYV16 (16 lines) (16 data lines + 4 or 5 sync lines) Thanks and Regards, -Manju -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/6] davinci vpbe: V4L2 display driver for DM644X SoC
Hans, Thank you for the review. I have taken care of the points you mentioned. The name comparison is unnecessary. I have also replaced the native struct definitions with those of v4l2. Request you to go through the rest of the patches so I can send the set once again. I won't have time for that until Friday at the earliest. More likely it will be the weekend. I hope that's OK. Regards, Hans Thanks and Regards, -Manju -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: Remove obsolete cleanup for clientdata
Hi Wolfram,
On Wed, 10 Nov 2010 13:28:19 +0100, Wolfram Sang wrote:
A few new i2c-drivers came into the kernel which clear the clientdata-pointer
on exit. This is obsolete meanwhile, so fix it and hope the word will spread.
Thanks for actively tracking these.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
Like last time I suggest to collect acks from the driver authors and merge it
vie Jean's i2c-tree.
drivers/media/video/imx074.c |2 --
drivers/media/video/ov6650.c |2 --
drivers/misc/apds9802als.c|1 -
drivers/staging/olpc_dcon/olpc_dcon.c |3 ---
4 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/imx074.c b/drivers/media/video/imx074.c
index 380e459..27b5dfd 100644
--- a/drivers/media/video/imx074.c
+++ b/drivers/media/video/imx074.c
@@ -451,7 +451,6 @@ static int imx074_probe(struct i2c_client *client,
ret = imx074_video_probe(icd, client);
if (ret 0) {
icd-ops = NULL;
- i2c_set_clientdata(client, NULL);
kfree(priv);
return ret;
}
@@ -468,7 +467,6 @@ static int imx074_remove(struct i2c_client *client)
icd-ops = NULL;
if (icl-free_bus)
icl-free_bus(icl);
- i2c_set_clientdata(client, NULL);
client-driver = NULL;
This statement seems equally unneeded, maybe you could remove it too?
Unless you want to provide a separate patch for this, as there are 5
other drivers doing the same.
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] davinci vpbe: V4L2 Display driver for DM644X
Hans,
Is it possible to extend the sub device ops to include SoC ip sub
device specific ops? I remember I had posted this question some time
back and you had proposed to add something like this. Just want to
check if that is still valid. This would make this driver
implementation little more cleaner.
struct vpbe_osd_ops;
struct v4l2_subdev_ops {
const struct v4l2_subdev_core_ops *core;
const struct v4l2_subdev_tuner_ops *tuner;
const struct v4l2_subdev_audio_ops *audio;
const struct v4l2_subdev_video_ops *video;
const struct v4l2_subdev_vbi_ops*vbi;
const struct v4l2_subdev_ir_ops *ir;
const struct v4l2_subdev_sensor_ops *sensor;
/* SoC IP specific ops */
const struct vpbe_osd_ops *vpbe_osd;
};
The struct vpbe_osd_ops will be defined in the osd sub device header
file. This will allow the host/bridge driver to call osd specific
operations like standard sub dev ops.
Any comments?
Almost right. You need to put the vpbe_osd into an anonymous union:
/* SoC IP specific ops */
const struct vpbe_osd_ops *vpbe_osd;
On Wed, Nov 10, 2010 at 8:05 AM, Muralidharan Karicheri
mkarich...@gmail.com wrote:
Manjunath,
Thank you for putting up this patch together. I didn't see the 1/6 of
this series in the mailing list. Also it appears as if the patch came
from me. Please add my sign-off as second, you being the first.
Murali
On Mon, Nov 8, 2010 at 9:54 AM, Manjunath Hadli manjunath.ha...@ti.com
wrote:
This driver is written for Texas Instruments's DM644X VPBE IP.
This SoC supports 2 video planes and 2 OSD planes as part of its
OSD (On Screen Display) block. The OSD lanes predminantly support
RGB space and the Video planes support YUV data. Out of these 4,
the 2 video planes are supported as part of the V4L2 driver. These
would be enumerated as video2 and video3 dev nodes.
The blending and video timing generator unit (VENC- for Video Encoder)
is the unit which combines/blends the output of these 4 planes
into a single stream and this output is given to Video input devices
like TV and other digital LCDs. The software for VENC is designed as
a subdevice with support for SD(NTSC and PAL) modes and 2 outputs.
This SoC forms the iniial implementation of its later additions
like DM355 and DM365.
Muralidharan Karicheri (6):
davinci vpbe: V4L2 display driver for DM644X SoC
davinci vpbe: VPBE display driver
davinci vpbe: OSD(On Screen Display ) block
davinci vpbe: VENC( Video Encoder) implementation
davinci vpbe: platform specific additions
davinci vpbe: Build infrastructure for VPBE driver
arch/arm/mach-davinci/board-dm644x-evm.c | 85 +-
arch/arm/mach-davinci/dm644x.c | 181 ++-
arch/arm/mach-davinci/include/mach/dm644x.h | 4 +
drivers/media/video/davinci/Kconfig | 22 +
drivers/media/video/davinci/Makefile | 2 +
drivers/media/video/davinci/vpbe.c | 861 ++
drivers/media/video/davinci/vpbe_display.c | 2283
++
drivers/media/video/davinci/vpbe_osd.c | 1208 ++
drivers/media/video/davinci/vpbe_osd_regs.h | 389 +
drivers/media/video/davinci/vpbe_venc.c | 617 +++
drivers/media/video/davinci/vpbe_venc_regs.h | 189 +++
include/media/davinci/vpbe.h | 187 +++
include/media/davinci/vpbe_display.h | 144 ++
include/media/davinci/vpbe_osd.h | 397 +
include/media/davinci/vpbe_types.h | 170 ++
include/media/davinci/vpbe_venc.h | 70 +
16 files changed, 6790 insertions(+), 19 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe.c
create mode 100644 drivers/media/video/davinci/vpbe_display.c
create mode 100644 drivers/media/video/davinci/vpbe_osd.c
create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h
create mode 100644 drivers/media/video/davinci/vpbe_venc.c
create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
create mode 100644 include/media/davinci/vpbe.h
create mode 100644 include/media/davinci/vpbe_display.h
create mode 100644 include/media/davinci/vpbe_osd.h
create mode 100644 include/media/davinci/vpbe_types.h
create mode 100644 include/media/davinci/vpbe_venc.h
--
To unsubscribe from this list: send the line unsubscribe linux-media
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Murali Karicheri
mkarich...@gmail.com
--
Murali Karicheri
mkarich...@gmail.com
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/6] davinci vpbe: V4L2 display driver for DM644X SoC
Will do. Thanks! -manju On Wed, Nov 10, 2010 at 18:54:12, Hans Verkuil wrote: Hans, Thank you for the review. I have taken care of the points you mentioned. The name comparison is unnecessary. I have also replaced the native struct definitions with those of v4l2. Request you to go through the rest of the patches so I can send the set once again. I won't have time for that until Friday at the earliest. More likely it will be the weekend. I hope that's OK. Regards, Hans Thanks and Regards, -Manju -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] davinci vpbe: V4L2 Display driver for DM644X
Hans,
Is it possible to extend the sub device ops to include SoC ip sub
device specific ops? I remember I had posted this question some time
back and you had proposed to add something like this. Just want to
check if that is still valid. This would make this driver
implementation little more cleaner.
struct vpbe_osd_ops;
struct v4l2_subdev_ops {
const struct v4l2_subdev_core_ops *core;
const struct v4l2_subdev_tuner_ops *tuner;
const struct v4l2_subdev_audio_ops *audio;
const struct v4l2_subdev_video_ops *video;
const struct v4l2_subdev_vbi_ops*vbi;
const struct v4l2_subdev_ir_ops *ir;
const struct v4l2_subdev_sensor_ops *sensor;
/* SoC IP specific ops */
const struct vpbe_osd_ops *vpbe_osd;
};
The struct vpbe_osd_ops will be defined in the osd sub device header
file. This will allow the host/bridge driver to call osd specific
operations like standard sub dev ops.
Any comments?
Almost right. You need to put the vpbe_osd into an anonymous union:
/* SoC IP specific ops */
union {
const struct vpbe_osd_ops *vpbe_osd;
};
This way other private ops can be added without increasing the size of the
struct.
This should work like a charm. I had this idea from the very beginning,
but nobody needed it until now.
Regards,
Hans
On Wed, Nov 10, 2010 at 8:05 AM, Muralidharan Karicheri
mkarich...@gmail.com wrote:
Manjunath,
Thank you for putting up this patch together. I didn't see the 1/6 of
this series in the mailing list. Also it appears as if the patch came
from me. Please add my sign-off as second, you being the first.
Murali
On Mon, Nov 8, 2010 at 9:54 AM, Manjunath Hadli manjunath.ha...@ti.com
wrote:
This driver is written for Texas Instruments's DM644X VPBE IP.
This SoC supports 2 video planes and 2 OSD planes as part of its
OSD (On Screen Display) block. The OSD lanes predminantly support
RGB space and the Video planes support YUV data. Out of these 4,
the 2 video planes are supported as part of the V4L2 driver. These
would be enumerated as video2 and video3 dev nodes.
The blending and video timing generator unit (VENC- for Video Encoder)
is the unit which combines/blends the output of these 4 planes
into a single stream and this output is given to Video input devices
like TV and other digital LCDs. The software for VENC is designed as
a subdevice with support for SD(NTSC and PAL) modes and 2 outputs.
This SoC forms the iniial implementation of its later additions
like DM355 and DM365.
Muralidharan Karicheri (6):
davinci vpbe: V4L2 display driver for DM644X SoC
davinci vpbe: VPBE display driver
davinci vpbe: OSD(On Screen Display ) block
davinci vpbe: VENC( Video Encoder) implementation
davinci vpbe: platform specific additions
davinci vpbe: Build infrastructure for VPBE driver
arch/arm/mach-davinci/board-dm644x-evm.c | 85 +-
arch/arm/mach-davinci/dm644x.c | 181 ++-
arch/arm/mach-davinci/include/mach/dm644x.h | 4 +
drivers/media/video/davinci/Kconfig | 22 +
drivers/media/video/davinci/Makefile | 2 +
drivers/media/video/davinci/vpbe.c | 861 ++
drivers/media/video/davinci/vpbe_display.c | 2283
++
drivers/media/video/davinci/vpbe_osd.c | 1208 ++
drivers/media/video/davinci/vpbe_osd_regs.h | 389 +
drivers/media/video/davinci/vpbe_venc.c | 617 +++
drivers/media/video/davinci/vpbe_venc_regs.h | 189 +++
include/media/davinci/vpbe.h | 187 +++
include/media/davinci/vpbe_display.h | 144 ++
include/media/davinci/vpbe_osd.h | 397 +
include/media/davinci/vpbe_types.h | 170 ++
include/media/davinci/vpbe_venc.h | 70 +
16 files changed, 6790 insertions(+), 19 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe.c
create mode 100644 drivers/media/video/davinci/vpbe_display.c
create mode 100644 drivers/media/video/davinci/vpbe_osd.c
create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h
create mode 100644 drivers/media/video/davinci/vpbe_venc.c
create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
create mode 100644 include/media/davinci/vpbe.h
create mode 100644 include/media/davinci/vpbe_display.h
create mode 100644 include/media/davinci/vpbe_osd.h
create mode 100644 include/media/davinci/vpbe_types.h
create mode 100644 include/media/davinci/vpbe_venc.h
--
To unsubscribe from this list: send the line unsubscribe linux-media
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Murali Karicheri
mkarich...@gmail.com
--
Murali Karicheri
mkarich...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-media
[PATCH] media: video: do not clear 'driver' from an i2c_client
The i2c-core does this already. Reported-by: Jean Delvare kh...@linux-fr.org Signed-off-by: Wolfram Sang w.s...@pengutronix.de --- Not sure if this should go via i2c or media? drivers/media/video/imx074.c |1 - drivers/media/video/mt9m001.c|1 - drivers/media/video/mt9m111.c|1 - drivers/media/video/mt9t031.c|1 - drivers/media/video/mt9v022.c|1 - drivers/media/video/rj54n1cb0c.c |1 - 6 files changed, 0 insertions(+), 6 deletions(-) diff --git a/drivers/media/video/imx074.c b/drivers/media/video/imx074.c index 27b5dfd..1a11691 100644 --- a/drivers/media/video/imx074.c +++ b/drivers/media/video/imx074.c @@ -467,7 +467,6 @@ static int imx074_remove(struct i2c_client *client) icd-ops = NULL; if (icl-free_bus) icl-free_bus(icl); - client-driver = NULL; kfree(priv); return 0; diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c index fcb4cd9..f7fc88d 100644 --- a/drivers/media/video/mt9m001.c +++ b/drivers/media/video/mt9m001.c @@ -798,7 +798,6 @@ static int mt9m001_remove(struct i2c_client *client) icd-ops = NULL; mt9m001_video_remove(icd); - client-driver = NULL; kfree(mt9m001); return 0; diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c index 525a16e..53fa2a7 100644 --- a/drivers/media/video/mt9m111.c +++ b/drivers/media/video/mt9m111.c @@ -1092,7 +1092,6 @@ static int mt9m111_remove(struct i2c_client *client) struct soc_camera_device *icd = client-dev.platform_data; icd-ops = NULL; - client-driver = NULL; kfree(mt9m111); return 0; diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c index 9bd44a8..7ce279c 100644 --- a/drivers/media/video/mt9t031.c +++ b/drivers/media/video/mt9t031.c @@ -896,7 +896,6 @@ static int mt9t031_remove(struct i2c_client *client) if (icd) icd-ops = NULL; - client-driver = NULL; kfree(mt9t031); return 0; diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c index b96171c..6a784c8 100644 --- a/drivers/media/video/mt9v022.c +++ b/drivers/media/video/mt9v022.c @@ -930,7 +930,6 @@ static int mt9v022_remove(struct i2c_client *client) icd-ops = NULL; mt9v022_video_remove(icd); - client-driver = NULL; kfree(mt9v022); return 0; diff --git a/drivers/media/video/rj54n1cb0c.c b/drivers/media/video/rj54n1cb0c.c index d2fa2d4..57e11b6 100644 --- a/drivers/media/video/rj54n1cb0c.c +++ b/drivers/media/video/rj54n1cb0c.c @@ -1460,7 +1460,6 @@ static int rj54n1_remove(struct i2c_client *client) icd-ops = NULL; if (icl-free_bus) icl-free_bus(icl); - client-driver = NULL; kfree(rj54n1); return 0; -- 1.7.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bounty for the first Open Source driver for Kinect
MS Kinect interfacing via libusb released http://www.youtube.com/watch?v=rKhW-cvpkks http://git.marcansoft.com/?p=libfreenect.git i -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: video: do not clear 'driver' from an i2c_client
On Wed, 10 Nov 2010, Wolfram Sang wrote: The i2c-core does this already. Reported-by: Jean Delvare kh...@linux-fr.org Signed-off-by: Wolfram Sang w.s...@pengutronix.de Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Not sure if this should go via i2c or media? drivers/media/video/imx074.c |1 - drivers/media/video/mt9m001.c|1 - drivers/media/video/mt9m111.c|1 - drivers/media/video/mt9t031.c|1 - drivers/media/video/mt9v022.c|1 - drivers/media/video/rj54n1cb0c.c |1 - 6 files changed, 0 insertions(+), 6 deletions(-) diff --git a/drivers/media/video/imx074.c b/drivers/media/video/imx074.c index 27b5dfd..1a11691 100644 --- a/drivers/media/video/imx074.c +++ b/drivers/media/video/imx074.c @@ -467,7 +467,6 @@ static int imx074_remove(struct i2c_client *client) icd-ops = NULL; if (icl-free_bus) icl-free_bus(icl); - client-driver = NULL; kfree(priv); return 0; diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c index fcb4cd9..f7fc88d 100644 --- a/drivers/media/video/mt9m001.c +++ b/drivers/media/video/mt9m001.c @@ -798,7 +798,6 @@ static int mt9m001_remove(struct i2c_client *client) icd-ops = NULL; mt9m001_video_remove(icd); - client-driver = NULL; kfree(mt9m001); return 0; diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c index 525a16e..53fa2a7 100644 --- a/drivers/media/video/mt9m111.c +++ b/drivers/media/video/mt9m111.c @@ -1092,7 +1092,6 @@ static int mt9m111_remove(struct i2c_client *client) struct soc_camera_device *icd = client-dev.platform_data; icd-ops = NULL; - client-driver = NULL; kfree(mt9m111); return 0; diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c index 9bd44a8..7ce279c 100644 --- a/drivers/media/video/mt9t031.c +++ b/drivers/media/video/mt9t031.c @@ -896,7 +896,6 @@ static int mt9t031_remove(struct i2c_client *client) if (icd) icd-ops = NULL; - client-driver = NULL; kfree(mt9t031); return 0; diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c index b96171c..6a784c8 100644 --- a/drivers/media/video/mt9v022.c +++ b/drivers/media/video/mt9v022.c @@ -930,7 +930,6 @@ static int mt9v022_remove(struct i2c_client *client) icd-ops = NULL; mt9v022_video_remove(icd); - client-driver = NULL; kfree(mt9v022); return 0; diff --git a/drivers/media/video/rj54n1cb0c.c b/drivers/media/video/rj54n1cb0c.c index d2fa2d4..57e11b6 100644 --- a/drivers/media/video/rj54n1cb0c.c +++ b/drivers/media/video/rj54n1cb0c.c @@ -1460,7 +1460,6 @@ static int rj54n1_remove(struct i2c_client *client) icd-ops = NULL; if (icl-free_bus) icl-free_bus(icl); - client-driver = NULL; kfree(rj54n1); return 0; -- 1.7.2.3 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] MCDE: Add frame buffer device driver
On Wed, Nov 10, 2010 at 7:04 AM, Jimmy Rubin jimmy.ru...@stericsson.com wrote: These set of patches contains a display sub system framework (DSS) which is used to implement the frame buffer device interface and a display device framework that is used to add support for different type of displays such as LCD, HDMI and so on. For complex display hardware, you may want to consider using the drm kms infrastructure rather than the kernel fb interface. It provides an API for complex display hardware (multiple encoders, display controllers, etc.) and also provides a legacy kernel fb interface for compatibility. See: Documentation/DocBook/drm.tmpl drivers/gpu/drm/ in the kernel tree. Alex The current implementation supports DSI command mode displays. Below is a short summary of the files in this patchset: mcde_fb.c Implements the frame buffer device driver. mcde_dss.c Contains the implementation of the display sub system framework (DSS). This API is used by the frame buffer device driver. mcde_display.c Contains default implementations of the functions in the display driver API. A display driver may override the necessary functions to function properly. A simple display driver is implemented in display-generic_dsi.c. display-generic_dsi.c Sample driver for a DSI command mode display. mcde_bus.c Implementation of the display bus. A display device is probed when both the display driver and display configuration have been registered with the display bus. mcde_hw.c Hardware abstraction layer of MCDE. All code that communicates directly with the hardware resides in this file. board-mop500-mcde.c The configuration of the display and the frame buffer device is handled in this file NOTE: These set of patches replaces the patches already sent out for review. RFC:[PATCH 1/2] Video: Add support for MCDE frame buffer driver RFC:[PATCH 2/2] Ux500: Add support for MCDE frame buffer driver The old patchset was to large to be handled by the mailing lists. Jimmy Rubin (10): MCDE: Add hardware abstraction layer MCDE: Add configuration registers MCDE: Add pixel processing registers MCDE: Add formatter registers MCDE: Add dsi link registers MCDE: Add generic display MCDE: Add display subsystem framework MCDE: Add frame buffer device driver MCDE: Add build files and bus ux500: MCDE: Add platform specific data arch/arm/mach-ux500/Kconfig | 8 + arch/arm/mach-ux500/Makefile | 1 + arch/arm/mach-ux500/board-mop500-mcde.c | 209 ++ arch/arm/mach-ux500/board-mop500-regulators.c | 28 + arch/arm/mach-ux500/board-mop500.c | 3 + arch/arm/mach-ux500/devices-db8500.c | 68 + arch/arm/mach-ux500/include/mach/db8500-regs.h | 7 + arch/arm/mach-ux500/include/mach/devices.h | 1 + arch/arm/mach-ux500/include/mach/prcmu-regs.h | 1 + arch/arm/mach-ux500/include/mach/prcmu.h | 3 + arch/arm/mach-ux500/prcmu.c | 129 ++ drivers/video/Kconfig | 2 + drivers/video/Makefile | 1 + drivers/video/mcde/Kconfig | 39 + drivers/video/mcde/Makefile | 12 + drivers/video/mcde/display-generic_dsi.c | 152 ++ drivers/video/mcde/dsi_link_config.h | 1486 ++ drivers/video/mcde/mcde_bus.c | 259 +++ drivers/video/mcde/mcde_config.h | 2156 drivers/video/mcde/mcde_display.c | 427 drivers/video/mcde/mcde_dss.c | 353 drivers/video/mcde/mcde_fb.c | 697 +++ drivers/video/mcde/mcde_formatter.h | 782 drivers/video/mcde/mcde_hw.c | 2528 drivers/video/mcde/mcde_mod.c | 67 + drivers/video/mcde/mcde_pixelprocess.h | 1137 +++ include/video/mcde/mcde.h | 387 include/video/mcde/mcde_display-generic_dsi.h | 34 + include/video/mcde/mcde_display.h | 139 ++ include/video/mcde/mcde_dss.h | 78 + include/video/mcde/mcde_fb.h | 54 + 31 files changed, 11248 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-ux500/board-mop500-mcde.c create mode 100644 drivers/video/mcde/Kconfig create mode 100644 drivers/video/mcde/Makefile create mode 100644 drivers/video/mcde/display-generic_dsi.c create mode 100644 drivers/video/mcde/dsi_link_config.h create mode 100644 drivers/video/mcde/mcde_bus.c create mode 100644 drivers/video/mcde/mcde_config.h create mode 100644 drivers/video/mcde/mcde_display.c create mode 100644 drivers/video/mcde/mcde_dss.c create mode 100644 drivers/video/mcde/mcde_fb.c create mode 100644 drivers/video/mcde/mcde_formatter.h create mode 100644 drivers/video/mcde/mcde_hw.c create
Re: [PATCH] mx2_camera: fix pixel clock polarity configuration
Guennadi Liakhovetski g.liakhovetski at gmx.de writes: On Wed, 27 Oct 2010, Baruch Siach wrote: When SOCAM_PCLK_SAMPLE_FALLING, just leave CSICR1_REDGE unset, otherwise we get the inverted behaviour. Seems logical to me, that if this is true, then you need the inverse: if (!(common_flags SOCAM_PCLK_SAMPLE_FALLING)) csicr1 |= CSICR1_INV_PCLK; No. Doing so you'll get the inverted behaviour of SAMPLE_RISING. When common_flags have SAMPLE_RISING set and SAMPLE_FALLING unset you get CSICR1_REDGE set, which triggers on the rising edge, and then also CSICR1_INV_PCLK set, which invert this. Thus you get the expected behaviour of SAMPLE_FALLING. Currently you get the inverted behaviour only for SAMPLE_FALLING. IMO, we should just use CSICR1_REDGE to set the sample timing, and leave CSICR1_INV_PCLK alone. baruch if (common_flags SOCAM_PCLK_SAMPLE_RISING) csicr1 |= CSICR1_REDGE; - if (common_flags SOCAM_PCLK_SAMPLE_FALLING) - csicr1 |= CSICR1_INV_PCLK; if (common_flags SOCAM_VSYNC_ACTIVE_HIGH) csicr1 |= CSICR1_SOF_POL; if (common_flags SOCAM_HSYNC_ACTIVE_HIGH) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bounty for the first Open Source driver for Kinect
On Wed, 10 Nov 2010 15:20:40 +0100 Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: MS Kinect interfacing via libusb released http://www.youtube.com/watch?v=rKhW-cvpkks http://git.marcansoft.com/?p=libfreenect.git Good, if anyone is willing to provide the hardware I think I can help with a proper gspca driver (I helped with the PS3 Eye already). Are there other RGB-Depth cams supported in linux? Are they usually exposed just as two distinct cameras? Regards, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpmNsNGSjo2d.pgp Description: PGP signature
Re: Bounty for the first Open Source driver for Kinect
On 11/10/10 10:54 AM, Antonio Ospite wrote: On Wed, 10 Nov 2010 15:20:40 +0100 Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: MS Kinect interfacing via libusb released http://www.youtube.com/watch?v=rKhW-cvpkks http://git.marcansoft.com/?p=libfreenect.git Good, if anyone is willing to provide the hardware I think I can help with a proper gspca driver (I helped with the PS3 Eye already). Are there other RGB-Depth cams supported in linux? Are they usually exposed just as two distinct cameras? Antonio, Excellent! If you are willing to donate your personal time freely to Linux then Kernel Labs are willing to assist by shipping a Kinect unit to you. Let me be clear, Kernel Labs have no commercial interest in this project. We simply like to encourage Linux media projects where possible. Projects like this are good for Linux and thus good for the community. My only requirement is that you post regular project status emails to this mailing list so we can all benefit from your thoughts, rants, any problems or comments on the project! :) Drop me a private email if you're interested. Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bounty for the first Open Source driver for Kinect
Thanks for your interest. The developers are connected to #openkinect channel on Freenode. The one who shipped this code is marcan on that channel. i -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] rc-core: ir-core to rc-core conversion
Em 10-11-2010 11:06, David Härdeman escreveu: On Wed, 10 Nov 2010 10:49:10 -0200, Mauro Carvalho Chehab mche...@infradead.org wrote: So, I'll try to merge the pending patches from your tree. I'll let you know if I have any problems. Sounds good. Thanks. David/Jarod, I pushed the merged patches at the tmp_rc tree: http://git.linuxtv.org/mchehab/tmp_rc.git Please test and give me some feedback. It ended that the rc function renaming patch (6/7) broke both mceusb (due to TX changes) and cx231xx-input (a new driver from me, for some devices that uses a crappy i2c uP, instead of the excellent in-cx231xx IR support). I did no tests at all, except for compilation. So, I need your feedback if the patches didn't actually break anything. I'll do some tests with cx231xx-input/mceusb probably later today. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bounty for the first Open Source driver for Kinect
IFixit has a tear down mentioning all the chips and a reference design
http://www.ifixit.com/Teardown/Microsoft-Kinect-Teardown/4066/1
There's two camera sensors, an ir illuminator, four microphones, a motor, and
apparently a built in usb hub.
It supposedly consumes more power than a standard usb port can supply, so you
may need an external power supply.
Have fun.
Andy
Antonio Ospite osp...@studenti.unina.it wrote:
On Wed, 10 Nov 2010 15:20:40 +0100
Mohamed Ikbel Boulabiar boulab...@gmail.com wrote:
MS Kinect interfacing via libusb released
http://www.youtube.com/watch?v=rKhW-cvpkks
http://git.marcansoft.com/?p=libfreenect.git
Good, if anyone is willing to provide the hardware I think I can help
with a proper gspca driver (I helped with the PS3 Eye already). Are
there other RGB-Depth cams supported in linux? Are they usually exposed
just as two distinct cameras?
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: [PATCH 01/10] MCDE: Add hardware abstraction layer
On Wed, 2010-11-10 at 13:04 +0100, Jimmy Rubin wrote:
This patch adds support for MCDE, Memory-to-display controller
found in the ST-Ericsson ux500 products.
Just trivia:
diff --git a/drivers/video/mcde/mcde_hw.c b/drivers/video/mcde/mcde_hw.c
[]
+#define dsi_rfld(__i, __reg, __fld) \
+ ((dsi_rreg(__i, __reg) __reg##_##__fld##_MASK) \
+ __reg##_##__fld##_SHIFT)
+#define dsi_wfld(__i, __reg, __fld, __val) \
+ dsi_wreg(__i, __reg, (dsi_rreg(__i, __reg) \
+ ~__reg##_##__fld##_MASK) | (((__val) __reg##_##__fld##_SHIFT) \
+ __reg##_##__fld##_MASK))
These macros are not particularly readable.
Perhaps use statement expression macros like:
#define dsi_rfld(__i, __reg, __fld) \
({ \
const u32 mask = __reg##_#__fld##_MASK; \
const u32 shift = __reg##_##__fld##_SHIFT; \
((dsi_rreg(__i, __reg) mask) shift;\
})
#define dsi_wfld(__i, __reg, __fld, __val) \
({ \
const u32 mask = __reg##_#__fld##_MASK; \
const u32 shift = __reg##_##__fld##_SHIFT; \
dsi_wreg(__i, __reg,\
(dsi_rreg(__i, __reg) ~mask) | (((__val) shift) mask));\
})
+static struct mcde_chnl_state channels[] = {
Should more static structs be static const?
[]
+ dev_vdbg(mcde_dev-dev, %s\n, __func__);
If your dev_level logging messages use %s, __func__
I suggest you use a set of local macros to preface this.
I don't generally find the function name useful.
Maybe only use the %s __func__ pair when you are also
setting verbose debugging.
#ifdef VERBOSE_DEBUG
#define mcde_printk(level, dev, fmt, args) \
dev_printk(level, dev, %s: fmt, __func__, ##args)
#else
#define mcde_printk(level, dev, fmt, args) \
dev_printk(level, dev, fmt, args)
#endif
#ifdef VERBOSE_DEBUG
#define mcde_vdbg(dev, fmt, args) \
mcde_printk(KERN_DEBUG, dev, fmt, ##args)
#else
#define mcde_vdbg(dev, fmt, args) \
do { if (0) mcde_printk(KERN_DEBUG, dev, fmt, ##args); } while (0)
#endif
#ifdef DEBUG
#define mcde_dbg(dev, fmt, args) \
mcde_printk(KERN_DEBUG, dev, fmt, ##args)
#else
#define mcde_dbg(dev, fmt, args) \
do { if (0) mcde_printk(KERN_DEBUG, dev, fmt, ##args); } while (0)
#endif
#define mcde_ERR(dev, fmt, args) \
mcde_printk(KERN_ERR, dev, fmt, ##args)
#define mcde_warn(dev, fmt, args) \
mcde_printk(KERN_WARNING, dev, fmt, ##args)
#define mcde_info(dev, fmt, args) \
mcde_printk(KERN_INFO, dev, fmt, ##args)
+static void disable_channel(struct mcde_chnl_state *chnl)
+{
+ int i;
+ const struct mcde_port *port = chnl-port;
+
+ dev_vdbg(mcde_dev-dev, %s\n, __func__);
+
+ if (hardware_version == MCDE_CHIP_VERSION_3_0_8
+ !is_channel_enabled(chnl)) {
+ chnl-continous_running = false;
It'd be nice to change to continuous_running
+int mcde_dsi_dcs_write(struct mcde_chnl_state *chnl, u8 cmd, u8* data, int
len)
+{
+ int i;
+ u32 wrdat[4] = { 0, 0, 0, 0 };
+ u32 settings;
+ u8 link = chnl-port.link;
+ u8 virt_id = chnl-port.phy.dsi.virt_id;
+
+ /* REVIEW: One command at a time */
+ /* REVIEW: Allow read/write on unreserved ports */
+ if (len MCDE_MAX_DCS_WRITE || chnl-port.type != MCDE_PORTTYPE_DSI)
+ return -EINVAL;
+
+ wrdat[0] = cmd;
+ for (i = 1; i = len; i++)
+ wrdat[i2] |= ((u32)data[i-1] ((i 3) * 8));
Ever overrun wrdat?
Maybe WARN_ON(len 16, oops?)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Nov 10 19:00:18 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15167:abd3aac6644e git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: a348e9110ddb5d494e060d989b35dd1f35359d58 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.37] Use modaliases to load I2C modules (part 2)
Hi Mauro, Here are the last two patches that complete the removal of the module_name argument from the v4l2_i2c_new_subdev* functions. They are identical to the patches I've posted to the list yesterday with the exception of a typo fix in one of the commit comments. I've based the patches on top of your linux-next master branch. The following changes since commit 6b101926f98b54549128db4d34f4a73b5f03fecc: [media] soc-camera: Compile fixes for mx2-camera (2010-11-09 15:16:31 -0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git i2c-module-name Laurent Pinchart (2): v4l: Remove hardcoded module names passed to v4l2_i2c_new_subdev* (2) v4l: Remove module_name argument to the v4l2_i2c_new_subdev* functions drivers/media/radio/radio-si4713.c|2 +- drivers/media/video/au0828/au0828-cards.c |4 ++-- drivers/media/video/bt8xx/bttv-cards.c| 22 +++--- drivers/media/video/cafe_ccic.c |3 +-- drivers/media/video/cx18/cx18-i2c.c |8 drivers/media/video/cx231xx/cx231xx-cards.c |4 ++-- drivers/media/video/cx23885/cx23885-cards.c |2 +- drivers/media/video/cx23885/cx23885-video.c |4 ++-- drivers/media/video/cx88/cx88-cards.c |9 - drivers/media/video/cx88/cx88-video.c |7 +++ drivers/media/video/davinci/vpfe_capture.c|1 - drivers/media/video/davinci/vpif_capture.c|1 - drivers/media/video/davinci/vpif_display.c|2 +- drivers/media/video/em28xx/em28xx-cards.c | 18 +- drivers/media/video/fsl-viu.c |2 +- drivers/media/video/ivtv/ivtv-i2c.c | 22 +- drivers/media/video/mxb.c | 12 ++-- drivers/media/video/pvrusb2/pvrusb2-hdw.c |6 ++ drivers/media/video/s5p-fimc/fimc-capture.c |2 +- drivers/media/video/saa7134/saa7134-cards.c |8 drivers/media/video/saa7134/saa7134-core.c|4 ++-- drivers/media/video/sh_vou.c |2 +- drivers/media/video/soc_camera.c |2 +- drivers/media/video/usbvision/usbvision-i2c.c |6 +++--- drivers/media/video/v4l2-common.c | 15 +-- drivers/media/video/via-camera.c |2 +- drivers/media/video/vino.c|4 ++-- drivers/media/video/zoran/zoran_card.c|5 ++--- drivers/staging/go7007/go7007-driver.c|2 +- drivers/staging/tm6000/tm6000-cards.c |4 ++-- include/media/v4l2-common.h | 16 ++-- 31 files changed, 90 insertions(+), 111 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IX2505V: i2c transfer error code ignored
On Sunday 07 November 2010, Malcolm Priestley wrote: On Sun, 2010-11-07 at 14:57 +0100, Matthias Schwarzott wrote: Hello Malcolm! It seems that ix2505v driver ignores a i2c error in ix2505v_read_status_reg. This looks like a typing error using (ret = 1) instead of correct (ret == 1). The attached patch fixes this. Hi Matthias, Thanks for picking that up. Acked-by: Malcolm Priestley tvbox...@gmail.com I forgot the SOB, so here it is: Signed-off-by: Matthias Schwarzott z...@gentoo.org Regards Matthias -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bounty for the first Open Source driver for Kinect
The bounty is already taken by that developer. But now, the Kinect thing is supported like a GPL userspace library. Maybe still need more work to be rewritten as a kernel module. The device has also a microphone (still need to be hacked), an accelerometer and even a motor/engine. The design should be similar to the ps3eye (but 2 video output). The engine controller and the accelerometer needs to be adressed to which place ? Linux-input ?. i -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bounty for the first Open Source driver for Kinect
On Wed, 10 Nov 2010 11:11:59 -0500 Steven Toth st...@kernellabs.com wrote: On 11/10/10 10:54 AM, Antonio Ospite wrote: On Wed, 10 Nov 2010 15:20:40 +0100 Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: [...] http://git.marcansoft.com/?p=libfreenect.git Good, if anyone is willing to provide the hardware I think I can help with a proper gspca driver (I helped with the PS3 Eye already). [...] Excellent! If you are willing to donate your personal time freely to Linux then Kernel Labs are willing to assist by shipping a Kinect unit to you. Let me be clear, Kernel Labs have no commercial interest in this project. We simply like to encourage Linux media projects where possible. Projects like this are good for Linux and thus good for the community. We share the same view then. My only requirement is that you post regular project status emails to this mailing list so we can all benefit from your thoughts, rants, any problems or comments on the project! :) That sounds fair, emails will be. I stepped forward because even if I don't want to invest too much time in the protocol analysis phase I can do the integration work, so that we can get a gspca_kinect driver eventually; if eventually is a good enough deadline for you as a sponsor then we are set. Obviously with some collaboration the driver will be delivered sooner than eventually, and I am pretty sure that is going to come ;) Drop me a private email if you're interested. On its way. Regards, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpTv8WYllpbN.pgp Description: PGP signature
Re: Bounty for the first Open Source driver for Kinect
On Wed, 10 Nov 2010 21:54:58 +0100 Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: The bounty is already taken by that developer. Which surely deserves it :) But now, the Kinect thing is supported like a GPL userspace library. Maybe still need more work to be rewritten as a kernel module. The device has also a microphone (still need to be hacked), an accelerometer and even a motor/engine. The design should be similar to the ps3eye (but 2 video output). PS3 Eye uses bulk transfers while I see Kinect uses iso transfers, anyway gspca handles both so in the end, yes, the driver could be quite similar, and the packet scanning routine could be taken from the userspace library if the license allows that. The engine controller and the accelerometer needs to be adressed to which place ? Linux-input ?. I think so, exposing the accelerometer as an event device sounds natural, about the motor I still don't know. Do those show up as usb HID devices somehow? About integrating the audio part (which has not even been guessed yet) is where I shamelessly show my ignorance :) Regards, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpfJ4Cp5l1uz.pgp Description: PGP signature
Re: Bounty for the first Open Source driver for Kinect
On Wed, Nov 10, 2010 at 9:54 PM, Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: The bounty is already taken by that developer. But now, the Kinect thing is supported like a GPL userspace library. Maybe still need more work to be rewritten as a kernel module. This should better remain in userspace and interface libv4l/libv4l2 no need to make things more complicated than they have to be. Markus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bounty for the first Open Source driver for Kinect
On Wed, 10 Nov 2010 22:14:36 +0100 Markus Rechberger mrechber...@gmail.com wrote: On Wed, Nov 10, 2010 at 9:54 PM, Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: The bounty is already taken by that developer. But now, the Kinect thing is supported like a GPL userspace library. Maybe still need more work to be rewritten as a kernel module. This should better remain in userspace and interface libv4l/libv4l2 no need to make things more complicated than they have to be. I can see at least two reasons for a kernel driver: 1. performance 2. out-of-the-box experience: the casual user who wants to just use kinect as a normal webcam doesn't have to care about installing some library If there are arguments against a kernel driver I can't see them yet. Ciao, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpEemSYgQhq8.pgp Description: PGP signature
Re: Bounty for the first Open Source driver for Kinect
On Wed, Nov 10, 2010 at 10:24 PM, Antonio Ospite osp...@studenti.unina.it wrote: On Wed, 10 Nov 2010 22:14:36 +0100 Markus Rechberger mrechber...@gmail.com wrote: On Wed, Nov 10, 2010 at 9:54 PM, Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: The bounty is already taken by that developer. But now, the Kinect thing is supported like a GPL userspace library. Maybe still need more work to be rewritten as a kernel module. This should better remain in userspace and interface libv4l/libv4l2 no need to make things more complicated than they have to be. I can see at least two reasons for a kernel driver: 1. performance 2. out-of-the-box experience: the casual user who wants to just use kinect as a normal webcam doesn't have to care about installing some library out of the box experience libusb works everywhere, ARM/MIPS/PPC/etc. Kerneldrivers are usually not installed with those systems. Higher backward compatibility as well (shall go down to 2.6.15) with one compiled driver, relevant endusers do not want to compile believe me. Developers might want but that's another story. Markus If there are arguments against a kernel driver I can't see them yet. Ciao, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] rc-core: ir-core to rc-core conversion
On Wed, Nov 10, 2010 at 02:24:16PM -0200, Mauro Carvalho Chehab wrote: Em 10-11-2010 11:06, David Härdeman escreveu: On Wed, 10 Nov 2010 10:49:10 -0200, Mauro Carvalho Chehab mche...@infradead.org wrote: So, I'll try to merge the pending patches from your tree. I'll let you know if I have any problems. Sounds good. Thanks. David/Jarod, I pushed the merged patches at the tmp_rc tree: http://git.linuxtv.org/mchehab/tmp_rc.git Please test and give me some feedback. It ended that the rc function renaming patch (6/7) broke both mceusb (due to TX changes) and cx231xx-input (a new driver from me, for some devices that uses a crappy i2c uP, instead of the excellent in-cx231xx IR support). I did no tests at all, except for compilation. So, I need your feedback if the patches didn't actually break anything. So far I've noticed that this patch: [media] rc-core: convert winbond-cir removed the old winbond-cir.c file but doesn't add one in the drivers/media/rc/ directory. -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bounty for the first Open Source driver for Kinect
On Wed, Nov 10, 2010 at 10:24 PM, Antonio Ospite osp...@studenti.unina.it wrote: If there are arguments against a kernel driver I can't see them yet. +1 This device is a webcam+(other things), it should be handled similar to other webcams already supported inside the kernel. If we make an exception now, we should make many special hacks for this only case to support it through the other libraries and layers of the system. If I want to use this device, I will add many userspace code to create the skeleton model and that need much computation. Kernel Module adds performance to my other code. i -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bounty for the first Open Source driver for Kinect
On Thu, 11 Nov 2010 00:13:09 +0100 Markus Rechberger mrechber...@gmail.com wrote: On Wed, Nov 10, 2010 at 11:48 PM, Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: On Wed, Nov 10, 2010 at 10:24 PM, Antonio Ospite osp...@studenti.unina.it wrote: If there are arguments against a kernel driver I can't see them yet. [...] If I want to use this device, I will add many userspace code to create the skeleton model and that need much computation. Kernel Module adds performance to my other code. just some experience from our side, we do have fully working video4linux1/2 drivers in userspace, the only exception we have is a very thin layered kernelmodule in order to improve the datatransfer. Markus, can you point to some example so I can get a clearer picture? Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpCipLDMAliO.pgp Description: PGP signature
Re: Bounty for the first Open Source driver for Kinect
On Thu, Nov 11, 2010 at 12:29 AM, Antonio Ospite osp...@studenti.unina.it wrote: On Thu, 11 Nov 2010 00:13:09 +0100 Markus Rechberger mrechber...@gmail.com wrote: On Wed, Nov 10, 2010 at 11:48 PM, Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: On Wed, Nov 10, 2010 at 10:24 PM, Antonio Ospite osp...@studenti.unina.it wrote: If there are arguments against a kernel driver I can't see them yet. [...] If I want to use this device, I will add many userspace code to create the skeleton model and that need much computation. Kernel Module adds performance to my other code. just some experience from our side, we do have fully working video4linux1/2 drivers in userspace, the only exception we have is a very thin layered kernelmodule in order to improve the datatransfer. Markus, can you point to some example so I can get a clearer picture? unfortunately we're closed source (and much more advanced) but you can have a look at other projects: * libv4l2 * freebsd has webcamd or something like that to emulate analog tv/webcams and dvb (they are even reusing linux kernel drivers with a userspace wrapper - so everything works in userspace for them). aside of that you can just debug userspace drivers with gdb, valgrind etc. if issues come up it will only affect your work not the entire system, kernel is seriously something critical. Markus Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bounty for the first Open Source driver for Kinect
On Thu, Nov 11, 2010 at 12:36 AM, Markus Rechberger mrechber...@gmail.com wrote: I've seen alot projects failing due not having enough users If it should mainly remain a hacker only project then a kernel module should be fine. sorry ? aside of that you can just debug userspace drivers with gdb, valgrind etc. if issues come up it will only affect your work not the entire system, kernel is seriously something critical. So you think that most of actual drivers which are inside the kernel are bad ? if it is inside the kernel it will be better maintained and fixed. External dependencies will break many things and add exceptions. You already got an answer for an issue similar to this from Linus Torvalds and Andrew Morton http://lkml.org/lkml/2007/10/10/244 Most of people want to download a kernel that just has all things inside. not search for other dependencies somewhere. If it is inside the kernel, many licensing problems will disappear. What if I want to develop something based on that userspace GPL library, should I search which license should I use (and there are many MIT/BSD/LGPL/...)? i -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: Remove obsolete cleanup for clientdata
On Wed, Nov 10, 2010 at 01:28:19PM +0100, Wolfram Sang wrote: A few new i2c-drivers came into the kernel which clear the clientdata-pointer on exit. This is obsolete meanwhile, so fix it and hope the word will spread. Signed-off-by: Wolfram Sang w.s...@pengutronix.de --- Like last time I suggest to collect acks from the driver authors and merge it vie Jean's i2c-tree. drivers/media/video/imx074.c |2 -- drivers/media/video/ov6650.c |2 -- drivers/misc/apds9802als.c|1 - drivers/staging/olpc_dcon/olpc_dcon.c |3 --- 4 files changed, 0 insertions(+), 8 deletions(-) For the staging driver: Acked-by: Greg Kroah-Hartman gre...@suse.de thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bounty for the first Open Source driver for Kinect
Am Donnerstag, den 11.11.2010, 00:36 +0100 schrieb Markus Rechberger: On Thu, Nov 11, 2010 at 12:29 AM, Antonio Ospite osp...@studenti.unina.it wrote: On Thu, 11 Nov 2010 00:13:09 +0100 Markus Rechberger mrechber...@gmail.com wrote: On Wed, Nov 10, 2010 at 11:48 PM, Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: On Wed, Nov 10, 2010 at 10:24 PM, Antonio Ospite osp...@studenti.unina.it wrote: If there are arguments against a kernel driver I can't see them yet. [...] If I want to use this device, I will add many userspace code to create the skeleton model and that need much computation. Kernel Module adds performance to my other code. just some experience from our side, we do have fully working video4linux1/2 drivers in userspace, the only exception we have is a very thin layered kernelmodule in order to improve the datatransfer. Markus, can you point to some example so I can get a clearer picture? unfortunately we're closed source (and much more advanced) but you can have a look at other projects: Markus, please go away with such. Despite of all previously, this is _not_ a place for any closed source to discuss. There is nothing to discuss on that, please stop it. Either try to come back with open source in a new round, or at least don't try to hide what you have. Without all the code and hardware specific stuff _previously_ developed/hacked on v4l-dvb, you don't exist. I still admit, overall, you did a very good job previously, but all others are _not_ just your captives after some clashes. With unfortunately we're closed source, you deliberately declare, that you have nothing to do with open source at all anymore. ? So, what is the remaining interest for you, except that you can continue easier in userspace, instead of getting a hard block in the kernel, if some enough have enough of your closed source ? Cheers, Hermann * libv4l2 * freebsd has webcamd or something like that to emulate analog tv/webcams and dvb (they are even reusing linux kernel drivers with a userspace wrapper - so everything works in userspace for them). aside of that you can just debug userspace drivers with gdb, valgrind etc. if issues come up it will only affect your work not the entire system, kernel is seriously something critical. Markus Thanks, Antonio -- Antonio Ospite http://ao2.it -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
