Re: [PATCH] [media] rtl28xxu: Add USB IDs for Compro VideoMate U620F.
On 02/13/2013 03:58 AM, Alistair Buxton wrote:
Signed-off-by: Alistair Buxton a.j.bux...@gmail.com
Acked-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index a4c302d..d8a8a88 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1352,6 +1352,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
rtl2832u_props, Dexatek DK mini DVB-T Dongle, NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC, 0x00d7,
rtl2832u_props, TerraTec Cinergy T Stick+, NULL) },
+ { DVB_USB_DEVICE(USB_VID_COMPRO, 0x0620,
+ rtl2832u_props, Compro VideoMate U620F, NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
--
http://palosaari.fi/
--
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
[RFC v2 0/3] Support Common Display Framework on Exynos5 SoC
changes since v1: Since v1 was not tested when I posted it, now that I have the s6e8aa0 panel, I tested the same on Exynos5 SoC. Needed to make below mentioned changes to make it work. In exynos mipi driver: 1 added enable_hs as part of dsi_video_source_ops, as this function needs to be called from the s6e8aa0 panel probe after LCD power_on. 2 moved the call exynos_mipi_dsi_set_hs_enable() out of the exynos_mipi_update_cfg() function as it needs to be called only after the LCD power_on. hence in s6e8aa0 probe added call enable_hs after power_on. otherwise DSI COMMAND TIME OUT error occurs, after sending WRITE COMMAND. Prior to CDF changes, things used to work fine, as the panel used to register with MIPI DSIM driver and in the MIPI DSI probe used to call LCD power_on first and then exynos_mipi_dsi_set_hs_enable. Since the CDF support is introduced, the both panel and mipi dsi probe happens independently and DSI COMMAND TIME OUT error used to occurs, after sending WRITE COMMAND. by making above mentioned changes it started working. In s6e8ax0 driver: 1 added call enable_hs in probe after power_on, to over come above mentioned error. 2 addd init_lcd(), the missing sequence to initialise the lcd. This patch series contains 3 patches with the following changes is based on CDF-T proposed by Tomi Valkeinen tomi.valkei...@ti.com http://lwn.net/Articles/529489/ [PATCH 1/3] video: display: Adding frame related ops to MIPI DSI video source struct Adds the frame related ops to the MIPI DSI video source struct [PATCH 2/3] video: exynos: mipi dsi: Making Exynos MIPI Compliant with CDF Makes the Exynos MIPI DSI driver compliant with CDF. [PATCH 3/3] video: exynos: Making s6e8ax0 panel driver compliant with CDF Makes the Exynos s6e8ax0 panel driver compliant with CDF. Have made necessary changes in s6e8ax0 panel driver, made an effort to remove dependency on backlight and lcd framework, but its NOT fully done. s6e8ax0_get_brightness() and s6e8ax0_set_brightness() functionalities have NOT been modified. as backlight support in CDF are _NOT_ implemented yet. Thought of adding these get and set as part of display_entity_control_ops(), but didn't modify as of now. Any thoughts on the same will be helpful. removed the lcd_ops set_power and get_power and added as part of panel_set_state. Testing: Tested on Exynos5 SoC with s6e8aa0 panel connected, by applying some of the dependent patches Could see the linux logo and ran modetest application and saw the test pattern on display panel. Vikas Sajjan (3): video: display: Adding frame related ops to MIPI DSI video source struct video: exynos: mipi dsi: Making Exynos MIPI Compliant with CDF video: exynos: Making s6e8ax0 panel driver compliant with CDF drivers/video/exynos/exynos_mipi_dsi.c| 197 ++ drivers/video/exynos/exynos_mipi_dsi_common.c | 22 +- drivers/video/exynos/exynos_mipi_dsi_common.h | 12 +- drivers/video/exynos/s6e8ax0.c| 848 + include/video/display.h |6 + include/video/exynos_mipi_dsim.h |5 +- 6 files changed, 519 insertions(+), 571 deletions(-) -- 1.7.9.5 -- 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
[RFC v2 1/3] video: display: Adding frame related ops to MIPI DSI video source struct
Adds the frame related ops to MIPI DSI video source struct
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
include/video/display.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/include/video/display.h b/include/video/display.h
index b639fd0..fb2f437 100644
--- a/include/video/display.h
+++ b/include/video/display.h
@@ -117,6 +117,12 @@ struct dsi_video_source_ops {
void (*enable_hs)(struct video_source *src, bool enable);
+ /* frame related */
+ int (*get_frame_done)(struct video_source *src);
+ int (*clear_frame_done)(struct video_source *src);
+ int (*set_early_blank_mode)(struct video_source *src, int power);
+ int (*set_blank_mode)(struct video_source *src, int power);
+
/* data transfer */
int (*dcs_write)(struct video_source *src, int channel,
u8 *data, size_t len);
--
1.7.9.5
--
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
[RFC v2 2/3] video: exynos: mipi dsi: Making Exynos MIPI Compliant with CDF
Modifies the exynos mipi dsi driver as per the CDF-T.
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/video/exynos/exynos_mipi_dsi.c| 197 ++---
drivers/video/exynos/exynos_mipi_dsi_common.c | 22 ++-
drivers/video/exynos/exynos_mipi_dsi_common.h | 12 +-
include/video/exynos_mipi_dsim.h |5 +-
4 files changed, 69 insertions(+), 167 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c
b/drivers/video/exynos/exynos_mipi_dsi.c
index 32dde44..c4eca0a 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -32,14 +32,13 @@
#include linux/notifier.h
#include linux/regulator/consumer.h
#include linux/pm_runtime.h
-
+#include video/display.h
#include video/exynos_mipi_dsim.h
#include plat/fb.h
#include exynos_mipi_dsi_common.h
#include exynos_mipi_dsi_lowlevel.h
-
struct mipi_dsim_ddi {
int bus_id;
struct list_headlist;
@@ -97,8 +96,6 @@ static void exynos_mipi_update_cfg(struct mipi_dsim_device
*dsim)
exynos_mipi_dsi_init_dsim(dsim);
exynos_mipi_dsi_init_link(dsim);
- exynos_mipi_dsi_set_hs_enable(dsim);
-
/* set display timing. */
exynos_mipi_dsi_set_display_mode(dsim, dsim-dsim_config);
@@ -111,12 +108,13 @@ static void exynos_mipi_update_cfg(struct
mipi_dsim_device *dsim)
exynos_mipi_dsi_stand_by(dsim, 1);
}
-static int exynos_mipi_dsi_early_blank_mode(struct mipi_dsim_device *dsim,
+static int exynos_mipi_dsi_early_blank_mode(struct video_source *video_source,
int power)
{
+ struct mipi_dsim_device *dsim = container_of(video_source,
+ struct mipi_dsim_device, video_source);
struct mipi_dsim_lcd_driver *client_drv = dsim-dsim_lcd_drv;
struct mipi_dsim_lcd_device *client_dev = dsim-dsim_lcd_dev;
-
switch (power) {
case FB_BLANK_POWERDOWN:
if (dsim-suspended)
@@ -139,12 +137,13 @@ static int exynos_mipi_dsi_early_blank_mode(struct
mipi_dsim_device *dsim,
return 0;
}
-static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int power)
+static int exynos_mipi_dsi_blank_mode(struct video_source *video_source, int
power)
{
+ struct mipi_dsim_device *dsim = container_of(video_source,
+ struct mipi_dsim_device, video_source);
struct platform_device *pdev = to_platform_device(dsim-dev);
struct mipi_dsim_lcd_driver *client_drv = dsim-dsim_lcd_drv;
struct mipi_dsim_lcd_device *client_dev = dsim-dsim_lcd_dev;
-
switch (power) {
case FB_BLANK_UNBLANK:
if (!dsim-suspended)
@@ -164,6 +163,8 @@ static int exynos_mipi_dsi_blank_mode(struct
mipi_dsim_device *dsim, int power)
exynos_mipi_update_cfg(dsim);
+ exynos_mipi_dsi_set_hs_enable(dsim);
+
/* set lcd panel sequence commands. */
if (client_drv client_drv-set_sequence)
client_drv-set_sequence(client_dev);
@@ -205,134 +206,31 @@ int exynos_mipi_dsi_register_lcd_device(struct
mipi_dsim_lcd_device *lcd_dev)
return 0;
}
-static struct mipi_dsim_ddi *exynos_mipi_dsi_find_lcd_device(
- struct mipi_dsim_lcd_driver *lcd_drv)
+static void exynos_mipi_dsi_panel_release(struct video_source *src)
{
- struct mipi_dsim_ddi *dsim_ddi, *next;
- struct mipi_dsim_lcd_device *lcd_dev;
-
- mutex_lock(mipi_dsim_lock);
-
- list_for_each_entry_safe(dsim_ddi, next, dsim_ddi_list, list) {
- if (!dsim_ddi)
- goto out;
-
- lcd_dev = dsim_ddi-dsim_lcd_dev;
- if (!lcd_dev)
- continue;
-
- if ((strcmp(lcd_drv-name, lcd_dev-name)) == 0) {
- /**
-* bus_id would be used to identify
-* connected bus.
-*/
- dsim_ddi-bus_id = lcd_dev-bus_id;
- mutex_unlock(mipi_dsim_lock);
-
- return dsim_ddi;
- }
-
- list_del(dsim_ddi-list);
- kfree(dsim_ddi);
- }
-
-out:
- mutex_unlock(mipi_dsim_lock);
-
- return NULL;
+ pr_info(dsi entity release\n);
}
-int exynos_mipi_dsi_register_lcd_driver(struct mipi_dsim_lcd_driver *lcd_drv)
+void exynos_mipi_set_hs_enable(struct video_source *video_source, bool enable)
{
- struct mipi_dsim_ddi *dsim_ddi;
-
- if (!lcd_drv-name) {
- pr_err(dsim_lcd_driver name is NULL.\n);
- return -EFAULT;
- }
-
- dsim_ddi = exynos_mipi_dsi_find_lcd_device(lcd_drv);
- if (!dsim_ddi) {
- pr_err(v mipi_dsim_ddi object not found.\n);
- return -EFAULT;
[RFC v2 3/3] video: exynos: Making s6e8ax0 panel driver compliant with CDF
Made necessary changes in s6e8ax0 panel driver as per the CDF-T.
It also removes the dependency on backlight and lcd framework
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/video/exynos/s6e8ax0.c | 848 +---
1 file changed, 444 insertions(+), 404 deletions(-)
diff --git a/drivers/video/exynos/s6e8ax0.c b/drivers/video/exynos/s6e8ax0.c
index 7f7b25f..5a17e3c 100644
--- a/drivers/video/exynos/s6e8ax0.c
+++ b/drivers/video/exynos/s6e8ax0.c
@@ -25,6 +25,7 @@
#include linux/backlight.h
#include linux/regulator/consumer.h
+#include video/display.h
#include video/mipi_display.h
#include video/exynos_mipi_dsim.h
@@ -38,8 +39,7 @@
#define POWER_IS_OFF(pwr) ((pwr) == FB_BLANK_POWERDOWN)
#define POWER_IS_NRM(pwr) ((pwr) == FB_BLANK_NORMAL)
-#define lcd_to_master(a) (a-dsim_dev-master)
-#define lcd_to_master_ops(a) ((lcd_to_master(a))-master_ops)
+#define to_panel(p) container_of(p, struct s6e8ax0, entity)
enum {
DSIM_NONE_STATE = 0,
@@ -47,20 +47,34 @@ enum {
DSIM_FRAME_DONE = 2,
};
+/* This structure defines all the properties of a backlight */
+struct backlight_prop {
+ /* Current User requested brightness (0 - max_brightness) */
+ int brightness;
+ /* Maximal value for brightness (read-only) */
+ int max_brightness;
+};
+
+struct panel_platform_data {
+ unsigned intreset_delay;
+ unsigned intpower_on_delay;
+ unsigned intpower_off_delay;
+ const char *video_source_name;
+};
+
struct s6e8ax0 {
- struct device *dev;
- unsigned intpower;
- unsigned intid;
- unsigned intgamma;
- unsigned intacl_enable;
- unsigned intcur_acl;
-
- struct lcd_device *ld;
- struct backlight_device *bd;
-
- struct mipi_dsim_lcd_device *dsim_dev;
- struct lcd_platform_data*ddi_pd;
+ struct platform_device *pdev;
+ struct video_source *src;
+ struct display_entity entity;
+ unsigned intpower;
+ unsigned intid;
+ unsigned intgamma;
+ unsigned intacl_enable;
+ unsigned intcur_acl;
+ boolpanel_reverse;
+ struct lcd_platform_data*plat_data;
struct mutexlock;
+ struct backlight_prop bl_prop;
bool enabled;
};
@@ -70,192 +84,194 @@ static struct regulator_bulk_data supplies[] = {
{ .supply = vci, },
};
-static void s6e8ax0_regulator_enable(struct s6e8ax0 *lcd)
+static void s6e8ax0_regulator_enable(struct s6e8ax0 *panel)
{
int ret = 0;
- struct lcd_platform_data *pd = NULL;
+ struct lcd_platform_data *plat_data = NULL;
- pd = lcd-ddi_pd;
- mutex_lock(lcd-lock);
- if (!lcd-enabled) {
+ plat_data = panel-plat_data;
+
+ mutex_lock(panel-lock);
+
+ if (!panel-enabled) {
ret = regulator_bulk_enable(ARRAY_SIZE(supplies), supplies);
if (ret)
goto out;
-
- lcd-enabled = true;
+ panel-enabled = true;
}
- msleep(pd-power_on_delay);
+ msleep(plat_data-power_on_delay);
out:
- mutex_unlock(lcd-lock);
+ mutex_unlock(panel-lock);
}
-static void s6e8ax0_regulator_disable(struct s6e8ax0 *lcd)
+static void s6e8ax0_regulator_disable(struct s6e8ax0 *panel)
{
int ret = 0;
- mutex_lock(lcd-lock);
- if (lcd-enabled) {
+ mutex_lock(panel-lock);
+
+ if (panel-enabled) {
ret = regulator_bulk_disable(ARRAY_SIZE(supplies), supplies);
if (ret)
goto out;
- lcd-enabled = false;
+ panel-enabled = false;
}
out:
- mutex_unlock(lcd-lock);
+ mutex_unlock(panel-lock);
}
-static const unsigned char s6e8ax0_22_gamma_30[] = {
+static unsigned char s6e8ax0_22_gamma_30[] = {
0xfa, 0x01, 0x60, 0x10, 0x60, 0xf5, 0x00, 0xff, 0xad, 0xaf,
0xbA, 0xc3, 0xd8, 0xc5, 0x9f, 0xc6, 0x9e, 0xc1, 0xdc, 0xc0,
0x00, 0x61, 0x00, 0x5a, 0x00, 0x74,
};
-static const unsigned char s6e8ax0_22_gamma_50[] = {
+static unsigned char s6e8ax0_22_gamma_50[] = {
0xfa, 0x01, 0x60, 0x10, 0x60, 0xe8, 0x1f, 0xf7, 0xad, 0xc0,
0xb5, 0xc4, 0xdc, 0xc4, 0x9e, 0xc6, 0x9c, 0xbb, 0xd8, 0xbb,
0x00, 0x70, 0x00, 0x68, 0x00, 0x86,
};
-static const unsigned char s6e8ax0_22_gamma_60[] = {
+static unsigned char s6e8ax0_22_gamma_60[] = {
0xfa, 0x01, 0x60, 0x10, 0x60, 0xde, 0x1f, 0xef, 0xad, 0xc4,
0xb3, 0xc3, 0xdd, 0xc4, 0x9e, 0xc6, 0x9c, 0xbc, 0xd6, 0xba,
0x00, 0x75, 0x00, 0x6e, 0x00, 0x8d,
};
-static const unsigned char s6e8ax0_22_gamma_70[] = {
+static unsigned char
Re: [PATCH] MAINTAINERS: Remove Jarod Wilson and orphan LIRC drivers
On Tue, Feb 12, 2013 at 10:15 PM, thomas schorpp thomas.scho...@gmail.com wrote: You can also try Jarod Wilson on freenode irc in #lirc. He is usually there. What for? Bothering him with issues from blocklisting mailhosters' RFC violations? Who said anything about that? Nobody, so why are you making it up? Obviously to communicate with him about someone trying to remove him from the maintainers list and declare the lirc drivers orphaned. I don't know why I even have to point that out. -- 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 v3] media: ths7353: add support for ths7353 video amplifier
Em Thu, 7 Feb 2013 11:10:28 +0530
Prabhakar lad prabhakar.cse...@gmail.com escreveu:
From: Lad, Prabhakar prabhakar@ti.com
The patch adds support for THS7353 video amplifier.
The the THS7353 amplifier is very much similar to the
existing THS7303 video amplifier driver.
This patch appropriately makes changes to the existing
ths7303 driver and adds support for the THS7353.
This patch also adds V4L2_IDENT_THS7353 for the THS7353
chip and appropriate changes to Kconfig file for building.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Martin Bugge marbu...@cisco.com
Cc: Chaithrika U S chaithr...@ti.com
---
Changes for v3:
1: Fixed review comments pointed out by Hans.
Changes for v2:
1: Merged the driver in existing ths7303 driver.
2: Merged the patch which adds the chip indent in same patch.
drivers/media/i2c/Kconfig |6 +-
drivers/media/i2c/ths7303.c | 353
---
include/media/ths7303.h | 42 +
include/media/v4l2-chip-ident.h |3 +
4 files changed, 343 insertions(+), 61 deletions(-)
create mode 100644 include/media/ths7303.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index ecdf7e3..bd08541 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -576,10 +576,10 @@ config VIDEO_UPD64083
comment Miscelaneous helper chips
config VIDEO_THS7303
- tristate THS7303 Video Amplifier
- depends on I2C
+ tristate THS7303/53 Video Amplifier
+ depends on VIDEO_V4L2 I2C
help
- Support for TI THS7303 video amplifier
+ Support for TI THS7303/53 video amplifier
To compile this driver as a module, choose M here: the
module will be called ths7303.
diff --git a/drivers/media/i2c/ths7303.c b/drivers/media/i2c/ths7303.c
index e747524..7300abc 100644
--- a/drivers/media/i2c/ths7303.c
+++ b/drivers/media/i2c/ths7303.c
@@ -1,7 +1,15 @@
/*
- * ths7303- THS7303 Video Amplifier driver
+ * ths7303/53- THS7303/53 Video Amplifier driver
*
* Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright 2013 Cisco Systems, Inc. and/or its affiliates.
+ *
+ * Author: Chaithrika U S chaithr...@ti.com
+ *
+ * Contributors:
+ * Lad, Prabhakar prabhakar@ti.com
+ * Hans Verkuil hans.verk...@cisco.com
+ * Martin Bugge marbu...@cisco.com
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -13,25 +21,27 @@
* GNU General Public License for more details.
*/
-#include linux/kernel.h
-#include linux/init.h
-#include linux/ctype.h
-#include linux/slab.h
#include linux/i2c.h
-#include linux/device.h
-#include linux/delay.h
#include linux/module.h
-#include linux/uaccess.h
-#include linux/videodev2.h
+#include linux/slab.h
-#include media/v4l2-device.h
-#include media/v4l2-subdev.h
+#include media/ths7303.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-device.h
#define THS7303_CHANNEL_11
#define THS7303_CHANNEL_22
#define THS7303_CHANNEL_33
+struct ths7303_state {
+ struct v4l2_subdev sd;
+ struct ths7303_platform_datapdata;
+ struct v4l2_bt_timings bt;
+ int std_id;
+ int stream_on;
+ int driver_data;
+};
+
enum ths7303_filter_mode {
THS7303_FILTER_MODE_480I_576I,
THS7303_FILTER_MODE_480P_576P,
@@ -48,64 +58,84 @@ static int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, Debug level 0-1);
+static inline struct ths7303_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ths7303_state, sd);
+}
+
+static int ths7303_read(struct v4l2_subdev *sd, u8 reg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return i2c_smbus_read_byte_data(client, reg);
+}
+
+static int ths7303_write(struct v4l2_subdev *sd, u8 reg, u8 val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ int ret;
+ int i;
+
+ for (i = 0; i 3; i++) {
+ ret = i2c_smbus_write_byte_data(client, reg, val);
+ if (ret == 0)
+ return 0;
+ }
+ return ret;
+}
+
/* following function is used to set ths7303 */
int ths7303_setval(struct v4l2_subdev *sd, enum ths7303_filter_mode mode)
{
- u8 input_bias_chroma = 3;
- u8 input_bias_luma = 3;
- int disable = 0;
- int err = 0;
- u8 val = 0;
- u8 temp;
-
struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ths7303_state *state = to_state(sd);
+ struct ths7303_platform_data *pdata = state-pdata;
+ u8 val, sel = 0;
+ int err, disable = 0;
if (!client)
return -EINVAL;
switch (mode) {
case
Re: [PATCH v4 02/10] s5p-fimc: Add device tree support for FIMC devices
On 02/12/2013 03:39 PM, Sylwester Nawrocki wrote: On 02/11/2013 10:50 PM, Stephen Warren wrote: On 02/09/2013 03:29 PM, Sylwester Nawrocki wrote: On 02/09/2013 01:32 AM, Stephen Warren wrote: On 02/08/2013 05:05 PM, Sylwester Nawrocki wrote: On 02/09/2013 12:21 AM, Stephen Warren wrote: On 02/08/2013 04:16 PM, Sylwester Nawrocki wrote: On 02/07/2013 12:40 AM, Stephen Warren wrote: diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt +Samsung S5P/EXYNOS SoC Camera Subsystem (FIMC) +-- ... +For every fimc node a numbered alias should be present in the aliases node. +Aliases are of the form fimcn, wheren is an integer (0...N) specifying +the IP's instance index. ... Different compatible values might not work, when for example there are 3 IPs out of 4 of one type and the fourth one of another type. It wouldn't even by really different types, just quirks/little differences between them, e.g. no data path routed to one of other IPs. I was thinking of using feature-/quirk-oriented properties. For example, if there's a port on 3 of the 4 devices to connect to some other IP block, simply include a boolean property to indicate whether that port is present. It would be in 3 of the nodes but not the 4th. Yes, I could add several properties corresponding to all members of this [3] data structure. But still it is needed to clearly identify the IP block in a set of the hardware instances. Why? What decisions will be made based on the identify of the IP block instance that wouldn't be covered by DT properties that describe which features/bugs/... the IP block instance has? The whole subsystem topology is exposed to user space through the Media Controller API. OK, stable user-visible names are a reasonable use for device tree. I still don't think you should use those user-visible IDs for making any other kind of decision though. Then to connect e.g. MIPI-CSIS.0 to FIMC.2 at run time an index of the MIPI-CSIS needs to be written to the FIMC.2 data input control register. Even though MIPI-CSIS.N are same in terms of hardware structure they still need to be distinguished as separate instances. Oh, so you're using the alias ID as the value to write into the FIMC.2 register for that. I'm not 100% familiar with aliases, but they seem like a more user-oriented naming thing to me, whereas values for hooking up intra-SoC routing are an unrelated namespace semantically, even if the values happen to line up right now. Perhaps rather than a Boolean property I mentioned above, use a custom property to indicate the ID that the FIMC.2 object knows the MIPI-CSIS.0 object as? While this seems That could be 'reg' property in the MIPI-CSIS.0 'port' subnode that links it to the image sensor node ([4], line 165). Because MIPI-CSIS IP blocks are immutably connected to the SoC camera physical MIPI CSI-2 interfaces, and the physical camera ports have fixed assignment to the MIPI-CSIS devices.. This way we could drop alias ID for the MIPI-CSIS nodes. And their instance index that is required for the top level driver which exposes topology and the routing capabilities to user space could be restored from the reg property value by subtracting a fixed offset. I suppose that would work. It feels a little indirect, and I think means that the driver needs to go find some child node defining its end of some link, then find the node representing the other end of the link, then read properties out of that other node to find the value. That seems a little unusual, but I guess it would work. I'm not sure of the long-term implications of doing that kind of thing. You'd want to run the idea past some DT maintainers/experts. It's a bit simpler than that. We would need only to look for the reg property in a local port subnode. MIPI-CSIS correspond to physical MIPI CSI-2 bus interface of an SoC, hence it has to have specific reg values that identify each camera input interface. Oh I see. I guess if a device is using its own node to determine its own identify, that's reasonable. I thought you were talking about a situation like: FIMC -- XXX where FIMC wanted to determine what ID XXX knew that particular FIMC as. I can see aliases used in bindings of multiple devices: uart, spi, sound interfaces, gpio, ... And all bindings seem to impose some rules on how their aliases are created. Do you have specific examples? I really don't think the bindings should be dictating the alias values. I just grepped through the existing bindings documentation: ... I think correctly numbered in the above statements means there are some specific rules on how the aliases are created, however those seem not clearly communicated. A binding specifying that an alias must (or even should) exist for each node seems odd to me. In the absence of an explicit
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Feb 13 19:00:19 CET 2013 git branch: for_v3.9 git hash: 4880f56438ef56457edd5548b257382761591998 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8.03-marune linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: ERRORS linux-git-arm-omap: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-rc4-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-rc4-x86_64: WARNINGS apps: 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 Media Infrastructure API 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
Re: Chipset change for CX88_BOARD_PINNACLE_PCTV_HD_800i
Devin Heitmueller dheitmueller at kernellabs.com writes: On Fri, Jun 22, 2012 at 11:55 AM, Mack Stanley mcs1937 at gmail.com wrote: So, keeping all of the configuration settings exactly the same and simply using s5h1411_attach instead of s5h1409_attach works perfectly. Maybe the easiest path is just to have the driver try one, if it fails, try the other. I actually don't have a sample of the new board, so if you wanted to submit a patch upstream which does the following, that would be great: 1. in cx88-dvb.c, do the dvb_attach() call against the s5h1409 just as it was before 2. If the dvb_attach() call returns NULL for the 1409, make the attach call against the s5h1411. Submit it to the linux-media mailing list to to solicit people willing to test. This is mostly to make sure that it doesn't break the 1409 based boards. By doing the 1409 attach first, there is a high likelihood that it won't cause a regression (if you did the 1411 attach first, there is greater risk that you will cause breakage for the 1409 boards). Be sure to include the Signed-Off-By line which is a requirement for it to be accepted upstream. I'll eyeball the patch and put a Reviewed-by line on it. Devin Hi, Was there any progress on including the support for PCTV 800i S5H1411 based? I have two such boards, both using S5H1411 and up until recently I was patching the driver as instructed here: http://forums.fedoraforum.org/showpost.php?s=3e6dd6214edd1145b5df6336d10ff941p=1586999postcount=9 A week ago, openSUSE 12.2 updated the kernel to 3.4.28-2.20 and now building the v4l drivers from git results in kernel panic.(I had to restore the system from an image backup). Even before, there was always a problem with building from source; when doing that the kernel reports /lib/modules/3.x.x-desktop is inconsistent and this prevents other drivers from installing (i.e. nvidia). This happens on a few different systems when using the instructions from here: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers Any suggestion appreciated. Thank you, Lucian -- 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: ddbridge v0.8
On 02/11/13 23:20, Martin Vidovic wrote: Hi, Is there any plan to include ddbridge driver version 0.8 in mainline kernel (currently it's 0.5). I really see no reason it's in the vacuum like now for almost a year. No sign of pushing it into mainline. Why is that so? It's a good driver. You should ask Ralph Metzler (added to CC) as he wrote the driver I think or atleast maintains it. Thanks. Best regards, Martin -- 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 -- 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 PULL] Timestamp API update for mem-to-mem devices
Hi Mauro, This change set includes a two patches I missed out in my last pull request which introduce V4L2_BUF_FLAG_TIMESTAMP_COPY buffer flag to indicate the timestamps are, in case of the mem-to-mem devices, copied from output to capture buffer queue. The other two patches is a fix for s3c-camif driver and a patch adding device tree support to the s5p-g2d driver. Please pull for 3.9 if still possible. There are already some patches queued for 3.9 improving the timestamps handling and it would be especially useful to have the below two patches from Kamil together in same kernel release. The following changes since commit ed72d37a33fdf43dc47787fe220532cdec9da528: [media] media: Add 0x3009 USB PID to ttusb2 driver (fixed diff) (2013-02-13 18:05:29 -0200) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git for_v3.9_2 Kamil Debski (2): v4l: Define video buffer flag for the COPY timestamp type vb2: Add support for non monotonic timestamps Sachin Kamat (1): s5p-g2d: Add DT based discovery support Sylwester Nawrocki (1): s3c-camif: Fail on insufficient number of allocated buffers Documentation/DocBook/media/v4l/io.xml |6 drivers/media/platform/blackfin/bfin_capture.c |1 + drivers/media/platform/davinci/vpbe_display.c |1 + drivers/media/platform/davinci/vpif_capture.c |1 + drivers/media/platform/davinci/vpif_display.c |1 + drivers/media/platform/s3c-camif/camif-capture.c | 16 +++-- drivers/media/platform/s5p-fimc/fimc-capture.c |1 + drivers/media/platform/s5p-fimc/fimc-lite.c|1 + drivers/media/platform/s5p-g2d/g2d.c | 31 ++- drivers/media/platform/s5p-mfc/s5p_mfc.c |2 + drivers/media/platform/soc_camera/atmel-isi.c |1 + drivers/media/platform/soc_camera/mx2_camera.c |1 + drivers/media/platform/soc_camera/mx3_camera.c |1 + .../platform/soc_camera/sh_mobile_ceu_camera.c |1 + drivers/media/platform/vivi.c |1 + drivers/media/usb/pwc/pwc-if.c |1 + drivers/media/usb/stk1160/stk1160-v4l.c|1 + drivers/media/usb/uvc/uvc_queue.c |1 + drivers/media/v4l2-core/videobuf2-core.c |8 - include/media/videobuf2-core.h |1 + include/uapi/linux/videodev2.h |1 + 21 files changed, 71 insertions(+), 8 deletions(-) The corresponding pwclient commands: pwclient update -s accepted 16650 pwclient update -s accepted 16470 pwclient update -s accepted 16471 pwclient update -s accepted 16733 pwclient update -s superseded 16247 pwclient update -s superseded 16248 pwclient update -s superseded 16246 pwclient update -s superseded 16447 pwclient update -s superseded 16448 pwclient update -s superseded 16449 --- Thanks, Sylwester -- 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 v2 1/2] [media] s5p-g2d: Add DT based discovery support
On 02/12/2013 06:30 PM, Sachin Kamat wrote:
Hi Sylwester,
On Wednesday, 6 February 2013, Sachin Kamat sachin.ka...@linaro.org wrote:
This patch adds device tree based discovery support to G2D driver
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Based on for_v3.9 branch of below tree:
git://linuxtv.org/snawrocki/samsung.git
Changes since v1:
* Addressed review comments from Sylwester s.nawro...@samsung.com.
* Modified the compatible string as per the discussions at [1].
[1] https://patchwork1.kernel.org/patch/2045821/
Does this patch look good?
It looks OK to me. I've sent a pull request including it, but it may
happen it ends up only in 3.10.
I tried to test this patch today and I had to correct some clock
definitions in the common clock API driver [1]. And we already have
quite a few fixes to that patch series.
Shouldn't you also provide a patch adding related OF_DEV_AUXDATA entry ?
How did you test this one ?
When the new clocks driver gets merged (I guess it happens only in 3.10)
I'd like to have the media devices' clock names cleaned up, instead of
names like: {sclk_fimg2d, fimg2d}, {sclk_fimc, fimc},
{sclk_fimd/fimd}, in clock-names property we could have common names,
e.g. { sclk, gate }. This could simplify a bit subsystems like devfreq.
Also I noticed there are some issues caused by splitting mux + div + gate
clocks into 3 different clocks. One solution to this might be to use the
new composite clock type.
[1] http://www.spinics.net/lists/arm-kernel/msg214149.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
Re: [RFC v2 3/3] video: exynos: Making s6e8ax0 panel driver compliant with CDF
On Wed, Feb 13, 2013 at 19:01, Vikas Sajjan wrote:
Made necessary changes in s6e8ax0 panel driver as per the CDF-T.
It also removes the dependency on backlight and lcd framework
Signed-off-by: Vikas Sajjanvikas.saj...@linaro.org
---
drivers/video/exynos/s6e8ax0.c | 848 +---
1 file changed, 444 insertions(+), 404 deletions(-)
diff --git a/drivers/video/exynos/s6e8ax0.c b/drivers/video/exynos/s6e8ax0.c
index 7f7b25f..5a17e3c 100644
--- a/drivers/video/exynos/s6e8ax0.c
+++ b/drivers/video/exynos/s6e8ax0.c
@@ -25,6 +25,7 @@
#include linux/backlight.h
#include linux/regulator/consumer.h
+#include video/display.h
#include video/mipi_display.h
#include video/exynos_mipi_dsim.h
@@ -38,8 +39,7 @@
#define POWER_IS_OFF(pwr) ((pwr) == FB_BLANK_POWERDOWN)
#define POWER_IS_NRM(pwr) ((pwr) == FB_BLANK_NORMAL)
-#define lcd_to_master(a) (a-dsim_dev-master)
-#define lcd_to_master_ops(a) ((lcd_to_master(a))-master_ops)
+#define to_panel(p) container_of(p, struct s6e8ax0, entity)
enum {
DSIM_NONE_STATE = 0,
@@ -47,20 +47,34 @@ enum {
DSIM_FRAME_DONE = 2,
};
+/* This structure defines all the properties of a backlight */
+struct backlight_prop {
+ /* Current User requested brightness (0 - max_brightness) */
+ int brightness;
+ /* Maximal value for brightness (read-only) */
+ int max_brightness;
+};
+
+struct panel_platform_data {
+ unsigned intreset_delay;
+ unsigned intpower_on_delay;
+ unsigned intpower_off_delay;
+ const char *video_source_name;
+};
+
struct s6e8ax0 {
- struct device *dev;
- unsigned intpower;
- unsigned intid;
- unsigned intgamma;
- unsigned intacl_enable;
- unsigned intcur_acl;
-
- struct lcd_device *ld;
- struct backlight_device *bd;
-
- struct mipi_dsim_lcd_device *dsim_dev;
- struct lcd_platform_data*ddi_pd;
+ struct platform_device *pdev;
+ struct video_source *src;
+ struct display_entity entity;
+ unsigned intpower;
+ unsigned intid;
+ unsigned intgamma;
+ unsigned intacl_enable;
+ unsigned intcur_acl;
+ boolpanel_reverse;
+ struct lcd_platform_data*plat_data;
struct mutexlock;
+ struct backlight_prop bl_prop;
bool enabled;
};
Could this panel driver use only CDF?
Does not consider the compatibility with backlight and lcd framework?
-static const unsigned char s6e8ax0_22_gamma_30[] = {
+static unsigned char s6e8ax0_22_gamma_30[] = {
0xfa, 0x01, 0x60, 0x10, 0x60, 0xf5, 0x00, 0xff, 0xad, 0xaf,
0xbA, 0xc3, 0xd8, 0xc5, 0x9f, 0xc6, 0x9e, 0xc1, 0xdc, 0xc0,
0x00, 0x61, 0x00, 0x5a, 0x00, 0x74,
};
In all case, you had changed data type to 'static unsigned char'.
Is it need to change all case? Otherwise, for the unity of the code?
Thank you,
Donghwa Lee
--
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: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
On Tue February 12 2013 09:28:55 Hans Verkuil wrote: On Mon February 11 2013 16:32:58 Arvydas Sidorenko wrote: On Mon, Feb 11, 2013 at 2:21 PM, Hans Verkuil hverk...@xs4all.nl wrote: That doesn't make sense either. Arvydas, it worked fine for you before, right? That is, if you use e.g. v3.8-rc7 then your picture is the right side up. It is upside down using any v3.7.x or v3.8-rc7. I didn't pay attention in the older versions, but I am aware of this issue since pre-v3. On Mon, Feb 11, 2013 at 2:41 PM, Hans de Goede hdego...@redhat.com wrote: Arvydas, can you please run sudo dmidecode dmi.log, and send me or Hans V. the generated dmi.log file? Then we can add your laptop to the upside-down model list. $ sudo dmidecode Thanks! I've updated my stkwebcam git branch (note: it was rebased, so you can't just do a git pull). If you can do a final test? Arvydas, can you please test this? I'd like to do a git pull tomorrow and I'd like to know if the upside-down changes are now OK. Thanks, 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: [RFC PATCHv2 01/18] tlg2300: use correct device parent.
On Thu February 7 2013 13:36:25 Hans Verkuil wrote:
Set the correct parent for v4l2_device_register and don't set the name
anymore (that's now deduced from the parent). Also remove an unnecessary
forward reference and fix two weird looking log messages.
Changes since v1: don't set v4l2_dev.name anymore as per Huang's suggestion.
Huang: can you Ack this?
Huang Shijie, can you please Ack this patch and the
[RFC PATCHv2 18/18] tlg2300: update MAINTAINERS file. patch I posted?
I'd like to do a post a pull request for this tomorrow and it would be nice
if these two patches had your Acked-by as well.
Thanks!
Hans
Regards,
Hans
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/usb/tlg2300/pd-main.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/media/usb/tlg2300/pd-main.c
b/drivers/media/usb/tlg2300/pd-main.c
index 7b1f6eb..247d6ac 100644
--- a/drivers/media/usb/tlg2300/pd-main.c
+++ b/drivers/media/usb/tlg2300/pd-main.c
@@ -55,7 +55,6 @@ MODULE_PARM_DESC(debug_mode, 0 = disable, 1 = enable, 2 =
verbose);
#define TLG2300_FIRMWARE tlg2300_firmware.bin
static const char *firmware_name = TLG2300_FIRMWARE;
-static struct usb_driver poseidon_driver;
static LIST_HEAD(pd_device_list);
/*
@@ -316,7 +315,7 @@ static int poseidon_suspend(struct usb_interface *intf,
pm_message_t msg)
if (get_pm_count(pd) = 0 !in_hibernation(pd)) {
pd-msg.event = PM_EVENT_AUTO_SUSPEND;
pd-pm_resume = NULL; /* a good guard */
- printk(KERN_DEBUG \n\t+ TLG2300 auto suspend +\n\n);
+ printk(KERN_DEBUG TLG2300 auto suspend\n);
}
return 0;
}
@@ -331,7 +330,7 @@ static int poseidon_resume(struct usb_interface *intf)
if (!pd)
return 0;
- printk(KERN_DEBUG \n\t ++ TLG2300 resume ++\n\n);
+ printk(KERN_DEBUG TLG2300 resume\n);
if (!is_working(pd)) {
if (PM_EVENT_AUTO_SUSPEND == pd-msg.event)
@@ -431,15 +430,11 @@ static int poseidon_probe(struct usb_interface
*interface,
usb_set_intfdata(interface, pd);
if (new_one) {
- struct device *dev = interface-dev;
-
logpm(pd);
mutex_init(pd-lock);
/* register v4l2 device */
- snprintf(pd-v4l2_dev.name, sizeof(pd-v4l2_dev.name), %s %s,
- dev-driver-name, dev_name(dev));
- ret = v4l2_device_register(NULL, pd-v4l2_dev);
+ ret = v4l2_device_register(interface-dev, pd-v4l2_dev);
/* register devices in directory /dev */
ret = pd_video_init(pd);
@@ -530,7 +525,7 @@ module_init(poseidon_init);
module_exit(poseidon_exit);
MODULE_AUTHOR(Telegent Systems);
-MODULE_DESCRIPTION(For tlg2300-based USB device );
+MODULE_DESCRIPTION(For tlg2300-based USB device);
MODULE_LICENSE(GPL);
MODULE_VERSION(0.0.2);
MODULE_FIRMWARE(TLG2300_FIRMWARE);
--
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: [DTV-TABLE] lu-all
On 13-02-13 14:56, Michael Stilmant wrote: Hello, On Mon, Jan 28, 2013 at 4:12 PM, Oliver Schinagl oliver+l...@schinagl.nl wrote: send a git-patch to the mailing list In attachment what I think is a patch for Luxembourg DVB-T initial scan (git diff origin master lux-all.diff) Adding Channel 21 broadcasting 'Air' since 28/02/2011 Applied in c57839aad2260306e6adecc0058fb683a8b34bc4 I'm not sure if it is the diff format you expect. I used git://linuxtv.org/dtv-scan-tables.git but I can't do a push or I don't know how to do. If everybody could push to the repo, it would become a huge mess ;) If a scanfile would needed to be updated on a regular basis (very unlikely) someone could maintain it of course. For now it is based on user contributions. isn't expected/easier that I would push the change to some branch and you would commit on master if accepted? or similar? You can always do this to your local clone and have a pull request to your branch. But it's much easier to review on the mailing list using a patch. btw, git send-email or git format-patch help greatly in that regard. Indeed in dvb-apps scan /util/scan/dvb-t folder there is still a fr-Bordeaux files. In July 2011 Christoph Pfister removed all France regional initial scan files. http://linuxtv.org/hg/dvb-apps/rev/0b1e26f79698 with commit message: remove outdated scan files fr-* submitted by mossroy free.fr use auto-Default or auto-With167kHzOffsets instead I don't know why but Bordeaux escaped from the genocide. IF you have accurate details of fr-Bordeaux (most have those values online, check some of the scanfiles, like nl-All for here in the NL) you'll see that they where actually hand-made from the available resources. I don't have accurate scan for Bordeaux, I believe fr-Bordeaux should been deleted like all region was deleted in July 2011 in one batch by Christoph Pfister. this if all region should have been deleted.. it is strange that decision was made. it is like initial scan files are not needed in fact. (why not needed for france?) I have no clue what the current situation is in France and why certain decisions where made. If anybody has accurate information to fix things, we can happily fix things. best regards, Michael -- 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
