[PATCH] media:adv7180: Use dev_pm_ops
Use dev_pm_ops instead of the deprecated legacy suspend/resume callbacks.
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
---
drivers/media/i2c/adv7180.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 34f39d3..3d75423 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -612,9 +612,10 @@ static const struct i2c_device_id adv7180_id[] = {
{},
};
-#ifdef CONFIG_PM
-static int adv7180_suspend(struct i2c_client *client, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int adv7180_suspend(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
int ret;
ret = i2c_smbus_write_byte_data(client, ADV7180_PWR_MAN_REG,
@@ -624,8 +625,9 @@ static int adv7180_suspend(struct i2c_client *client,
pm_message_t state)
return 0;
}
-static int adv7180_resume(struct i2c_client *client)
+static int adv7180_resume(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
struct v4l2_subdev *sd = i2c_get_clientdata(client);
struct adv7180_state *state = to_state(sd);
int ret;
@@ -639,6 +641,12 @@ static int adv7180_resume(struct i2c_client *client)
return ret;
return 0;
}
+
+static SIMPLE_DEV_PM_OPS(adv7180_pm_ops, adv7180_suspend, adv7180_resume);
+#define ADV7180_PM_OPS (adv7180_pm_ops)
+
+#else
+#define ADV7180_PM_OPS NULL
#endif
MODULE_DEVICE_TABLE(i2c, adv7180_id);
@@ -647,13 +655,10 @@ static struct i2c_driver adv7180_driver = {
.driver = {
.owner = THIS_MODULE,
.name = KBUILD_MODNAME,
+ .pm = ADV7180_PM_OPS,
},
.probe = adv7180_probe,
.remove = adv7180_remove,
-#ifdef CONFIG_PM
- .suspend = adv7180_suspend,
- .resume = adv7180_resume,
-#endif
.id_table = adv7180_id,
};
--
1.8.0
--
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] [media] media: info leak in __media_device_enum_links()
These structs have holes and reserved struct members which aren't
cleared. I've added a memset() so we don't leak stack information.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 99b80b6..450c0d1 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -139,6 +139,8 @@ static long __media_device_enum_links(struct media_device
*mdev,
for (p = 0; p entity-num_pads; p++) {
struct media_pad_desc pad;
+
+ memset(pad, 0, sizeof(pad));
media_device_kpad_to_upad(entity-pads[p], pad);
if (copy_to_user(links-pads[p], pad, sizeof(pad)))
return -EFAULT;
@@ -156,6 +158,7 @@ static long __media_device_enum_links(struct media_device
*mdev,
if (entity-links[l].source-entity != entity)
continue;
+ memset(link, 0, sizeof(link));
media_device_kpad_to_upad(entity-links[l].source,
link.source);
media_device_kpad_to_upad(entity-links[l].sink,
--
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 0/3] em28xx: clean up end extend the GPIO port handling
Patch 1 removes the unneeded and broken gpio register caching code. Patch 2 adds the gpio register defintions for the em25xx/em276x/7x/8x and patch 3 finally adds a new helper function for gpio ports with separate registers for read and write access. Frank Schäfer (3): em28xx: give up GPIO register tracking/caching em28xx: add register defines for em25xx/em276x/7x/8x GPIO registers em28xx: add helper function for handling the GPIO registers of newer devices drivers/media/usb/em28xx/em28xx-cards.c | 12 drivers/media/usb/em28xx/em28xx-core.c | 50 --- drivers/media/usb/em28xx/em28xx-reg.h |8 + drivers/media/usb/em28xx/em28xx.h | 11 ++- 4 Dateien geändert, 30 Zeilen hinzugefügt(+), 51 Zeilen entfernt(-) -- 1.7.10.4 -- 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 2/3] em28xx: add register defines for em25xx/em276x/7x/8x GPIO registers
em25xx/em276x/7x/8x provides 3 GPIO register sets, each of them consisting of separate read and a write registers. Signed-off-by: Frank Schäfer fschaefer@googlemail.com --- drivers/media/usb/em28xx/em28xx-reg.h |8 1 Datei geändert, 8 Zeilen hinzugefügt(+) diff --git a/drivers/media/usb/em28xx/em28xx-reg.h b/drivers/media/usb/em28xx/em28xx-reg.h index 622871d..ebc5663 100644 --- a/drivers/media/usb/em28xx/em28xx-reg.h +++ b/drivers/media/usb/em28xx/em28xx-reg.h @@ -195,6 +195,14 @@ #define EM2874_R5F_TS_ENABLE0x5f #define EM2874_R80_GPIO 0x80 +/* em25xx, em276x/7x/8x GPIO registers */ +#define EM25XX_R80_GPIO_P0_W0x80 +#define EM25XX_R81_GPIO_P1_W0x81 +#define EM25XX_R83_GPIO_P3_W0x83 +#define EM25XX_R84_GPIO_P0_R0x84 +#define EM25XX_R85_GPIO_P1_R0x85 +#define EM25XX_R87_GPIO_P3_R0x87 + /* em2874 IR config register (0x50) */ #define EM2874_IR_NEC 0x00 #define EM2874_IR_NEC_NO_PARITY 0x01 -- 1.7.10.4 -- 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 1/3] em28xx: give up GPIO register tracking/caching
The GPIO register tracking/caching code is partially broken, because newer
devices provide more than one GPIO register and some of them are even using
separate registers for read and write access.
Making it work would be too complicated.
It is also used nowhere and doesn't make sense in cases where input lines are
connected to buttons etc.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c | 12
drivers/media/usb/em28xx/em28xx-core.c | 27 ++-
drivers/media/usb/em28xx/em28xx.h |6 --
3 Dateien geändert, 2 Zeilen hinzugefügt(+), 43 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index bec604f..e328159 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2880,10 +2880,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
em28xx_set_model(dev);
- /* Set the default GPO/GPIO for legacy devices */
- dev-reg_gpo_num = EM2880_R04_GPO;
- dev-reg_gpio_num = EM28XX_R08_GPIO;
-
dev-wait_after_write = 5;
/* Based on the Chip ID, set the device configuration */
@@ -2930,13 +2926,11 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
break;
case CHIP_ID_EM2874:
chip_name = em2874;
- dev-reg_gpio_num = EM2874_R80_GPIO;
dev-wait_after_write = 0;
dev-eeprom_addrwidth_16bit = 1;
break;
case CHIP_ID_EM28174:
chip_name = em28174;
- dev-reg_gpio_num = EM2874_R80_GPIO;
dev-wait_after_write = 0;
dev-eeprom_addrwidth_16bit = 1;
break;
@@ -2946,7 +2940,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
break;
case CHIP_ID_EM2884:
chip_name = em2884;
- dev-reg_gpio_num = EM2874_R80_GPIO;
dev-wait_after_write = 0;
dev-eeprom_addrwidth_16bit = 1;
break;
@@ -2975,11 +2968,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
return 0;
}
- /* Prepopulate cached GPO register content */
- retval = em28xx_read_reg(dev, dev-reg_gpo_num);
- if (retval = 0)
- dev-reg_gpo = retval;
-
em28xx_pre_card_setup(dev);
if (!dev-board.is_em2800) {
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index a802128..fc157af 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -193,23 +193,7 @@ int em28xx_write_regs_req(struct em28xx *dev, u8 req, u16
reg, char *buf,
int em28xx_write_regs(struct em28xx *dev, u16 reg, char *buf, int len)
{
- int rc;
-
- rc = em28xx_write_regs_req(dev, USB_REQ_GET_STATUS, reg, buf, len);
-
- /* Stores GPO/GPIO values at the cache, if changed
- Only write values should be stored, since input on a GPIO
- register will return the input bits.
- Not sure what happens on reading GPO register.
-*/
- if (rc = 0) {
- if (reg == dev-reg_gpo_num)
- dev-reg_gpo = buf[0];
- else if (reg == dev-reg_gpio_num)
- dev-reg_gpio = buf[0];
- }
-
- return rc;
+ return em28xx_write_regs_req(dev, USB_REQ_GET_STATUS, reg, buf, len);
}
EXPORT_SYMBOL_GPL(em28xx_write_regs);
@@ -231,14 +215,7 @@ int em28xx_write_reg_bits(struct em28xx *dev, u16 reg, u8
val,
int oldval;
u8 newval;
- /* Uses cache for gpo/gpio registers */
- if (reg == dev-reg_gpo_num)
- oldval = dev-reg_gpo;
- else if (reg == dev-reg_gpio_num)
- oldval = dev-reg_gpio;
- else
- oldval = em28xx_read_reg(dev, reg);
-
+ oldval = em28xx_read_reg(dev, reg);
if (oldval 0)
return oldval;
diff --git a/drivers/media/usb/em28xx/em28xx.h
b/drivers/media/usb/em28xx/em28xx.h
index a9323b6..e070de0 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -636,12 +636,6 @@ struct em28xx {
enum em28xx_mode mode;
- /* register numbers for GPO/GPIO registers */
- u16 reg_gpo_num, reg_gpio_num;
-
- /* Caches GPO and GPIO registers */
- unsigned char reg_gpo, reg_gpio;
-
/* Snapshot button */
char snapshot_button_path[30]; /* path of the input dev */
struct input_dev *sbutton_input_dev;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe
[PATCH 3/3] em28xx: add helper function for handling the GPIO registers of newer devices
The current code provides a helper function em28xx_write_reg_bits() that reads
the current state/value of a GPIO register, modifies only the bits specified
with the value and bitmask parmaters and writes the new value back to the
register.
Newer devices (em25xx, em276x/7x/8x) are using separate registers for reading
and changing the states of the GPIO ports/lines, for which this helper function
cannot be used.
Introduce a new function em28xx_write_regs_bits() that uses two register
parameters reg_r (register for reading the current value) and
reg_w (register for writing the new value).
Make em28xx_write_reg_bits() a wrapper function calling this new function with
the same value for both registers.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-core.c | 26 +++---
drivers/media/usb/em28xx/em28xx.h |5 +++--
2 Dateien geändert, 22 Zeilen hinzugefügt(+), 9 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index fc157af..293dc31 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -205,23 +205,35 @@ int em28xx_write_reg(struct em28xx *dev, u16 reg, u8 val)
EXPORT_SYMBOL_GPL(em28xx_write_reg);
/*
- * em28xx_write_reg_bits()
- * sets only some bits (specified by bitmask) of a register, by first reading
- * the actual value
+ * em28xx_write_regs_bits()
+ * reads value from a register, modifies only the bits specified with the value
+ * and bitmask parameters and writes the new value two a second register.
*/
-int em28xx_write_reg_bits(struct em28xx *dev, u16 reg, u8 val,
-u8 bitmask)
+int em28xx_write_regs_bits(struct em28xx *dev, u16 reg_r, u16 reg_w, u8 val,
+ u8 bitmask)
{
int oldval;
u8 newval;
- oldval = em28xx_read_reg(dev, reg);
+ oldval = em28xx_read_reg(dev, reg_r);
if (oldval 0)
return oldval;
newval = (((u8) oldval) ~bitmask) | (val bitmask);
- return em28xx_write_regs(dev, reg, newval, 1);
+ return em28xx_write_regs(dev, reg_w, newval, 1);
+}
+EXPORT_SYMBOL_GPL(em28xx_write_regs_bits);
+
+/*
+ * em28xx_write_reg_bits()
+ * modifies only the bits specified with the value and bitmask parameters of
+ * a register
+ */
+int em28xx_write_reg_bits(struct em28xx *dev, u16 reg, u8 val,
+u8 bitmask)
+{
+ return em28xx_write_regs_bits(dev, reg, reg, val, bitmask);
}
EXPORT_SYMBOL_GPL(em28xx_write_reg_bits);
diff --git a/drivers/media/usb/em28xx/em28xx.h
b/drivers/media/usb/em28xx/em28xx.h
index e070de0..a817c3d 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -667,8 +667,9 @@ int em28xx_write_regs_req(struct em28xx *dev, u8 req, u16
reg, char *buf,
int len);
int em28xx_write_regs(struct em28xx *dev, u16 reg, char *buf, int len);
int em28xx_write_reg(struct em28xx *dev, u16 reg, u8 val);
-int em28xx_write_reg_bits(struct em28xx *dev, u16 reg, u8 val,
-u8 bitmask);
+int em28xx_write_regs_bits(struct em28xx *dev, u16 reg_r, u16 reg_w,
+ u8 val, u8 bitmask);
+int em28xx_write_reg_bits(struct em28xx *dev, u16 reg, u8 val, u8 bitmask);
int em28xx_read_ac97(struct em28xx *dev, u8 reg);
int em28xx_write_ac97(struct em28xx *dev, u8 reg, u16 val);
--
1.7.10.4
--
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] em28xx: add basic support for the SpeedLink Vicious And Devine Laplace webcam
The SpeedLink Vicious And Devine Laplace webcam uses an EM2765 bridge and an
OV2640 sensor which allows capturing at a max. resoultion of 1600x1200 at
max. 7-8 fps. It has a built-in microphone (USB standard device class) and
provides 3 buttons (snapshot, mute, illumination) and 2 LEDs (capturing/mute and
illumination/flash). It is also equipped with an eeprom.
The device is available in two colors: white (1ae7:9003) and black (1ae7:9004).
This patch adds only basic support for this device, the limitations are:
- resolution limited to max. 640x480
- image quality needs to be improved
- support for the 3 buttons (snapshot, mute, illumination) is missing
- illumination/flash LED support is missing (capturing LED is functional)
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c | 34 ++-
drivers/media/usb/em28xx/em28xx-video.c | 14 +
drivers/media/usb/em28xx/em28xx.h |1 +
3 Dateien geändert, 48 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index e328159..c5d3fa56 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -411,6 +411,19 @@ static struct em28xx_reg_seq pctv_520e[] = {
{ -1, -1, -1, -1},
};
+/* 1ae7:9003/9004 SpeedLink Vicious And Devine Laplace webcam
+ * reg 0x80/0x84:
+ * GPIO_0: capturing LED, 0=on, 1=off
+ * GPIO_2: mute button, 0=pressed, 1=unpressed
+ * GPIO 3: illumination button, 0=pressed, 1=unpressed
+ * GPIO_6: illumination/flash LED, 0=on, 1=off
+ */
+static struct em28xx_reg_seq speedlink_vad_laplace_reg_seq[] = {
+ {EM28XX_R08_GPIO, 0xf7, 0xff, 10},
+ {EM25XX_R80_GPIO_P0_W, 0xff, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
/*
* Board definitions
*/
@@ -1787,7 +1800,6 @@ struct em28xx_board em28xx_boards[] = {
.type = EM28XX_VMUX_TELEVISION,
.vmux = TVP5150_COMPOSITE0,
.amux = EM28XX_AMUX_VIDEO,
-
}, {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = TVP5150_COMPOSITE1,
@@ -2016,6 +2028,22 @@ struct em28xx_board em28xx_boards[] = {
.i2c_speed= EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_400_KHZ,
},
+ /* 1ae7:9003/9004 SpeedLink Vicious And Devine Laplace webcam
+* Empia EM2765 + OmniVision OV2640 */
+ [EM2765_BOARD_SPEEDLINK_VAD_LAPLACE] = {
+ .name = SpeedLink Vicious And Devine Laplace webcam,
+ .xclk = EM28XX_XCLK_FREQUENCY_24MHZ,
+ .i2c_speed= EM28XX_I2C_CLK_WAIT_ENABLE |
+ EM28XX_I2C_FREQ_100_KHZ,
+ .def_i2c_bus = 1,
+ .tuner_type = TUNER_ABSENT,
+ .is_webcam= 1,
+ .input= { {
+ .type = EM28XX_VMUX_COMPOSITE1,
+ .amux = EM28XX_AMUX_VIDEO,
+ .gpio = speedlink_vad_laplace_reg_seq,
+ } },
+ },
};
const unsigned int em28xx_bcount = ARRAY_SIZE(em28xx_boards);
@@ -2177,6 +2205,10 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2884_BOARD_PCTV_510E },
{ USB_DEVICE(0x2013, 0x0251),
.driver_info = EM2884_BOARD_PCTV_520E },
+ { USB_DEVICE(0x1ae7, 0x9003),
+ .driver_info = EM2765_BOARD_SPEEDLINK_VAD_LAPLACE },
+ { USB_DEVICE(0x1ae7, 0x9004),
+ .driver_info = EM2765_BOARD_SPEEDLINK_VAD_LAPLACE },
{ },
};
MODULE_DEVICE_TABLE(usb, em28xx_id_table);
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 792ead1..f949cdc 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -660,6 +660,13 @@ int em28xx_start_analog_streaming(struct vb2_queue *vq,
unsigned int count)
if (rc 0)
goto fail;
+ /* Switch on capturing LED */
+ if (dev-model == EM2765_BOARD_SPEEDLINK_VAD_LAPLACE)
+ em28xx_write_regs_bits(dev,
+ EM25XX_R84_GPIO_P0_R,
+ EM25XX_R80_GPIO_P0_W,
+ 0x00, 0x01);
+
/*
* djh: it's not clear whether this code is still needed. I'm
* leaving it in here for now entirely out of concern for
@@ -693,6 +700,13 @@ static int em28xx_stop_streaming(struct vb2_queue *vq)
if (dev-streaming_users-- == 1) {
/* Last active user, so shutdown all the
Re: [PATCH 0/3] em28xx: clean up end extend the GPIO port handling
On 04/13/2013 12:48 PM, Frank Schäfer wrote: Patch 1 removes the unneeded and broken gpio register caching code. Patch 2 adds the gpio register defintions for the em25xx/em276x/7x/8x and patch 3 finally adds a new helper function for gpio ports with separate registers for read and write access. I have nothing to say directly about those patches - they looked good at the quick check. But I wonder if you have any idea if it is possible to use some existing Kernel GPIO functionality in order to provide standard interface (interface like I2C). I did some work last summer in order to use GPIOLIB and it is used between em28xx-dvb and cxd2820r for LNA control. Anyhow, I was a little bit disappointed as GPIOLIB is disabled by default and due to that there is macros to disable LNA when GPIOLIB is not compiled. I noticed recently there is some ongoing development for Kernel GPIO. I haven't looked yet if it makes use of GPIO interface more common... regards Antti -- 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
[PATCH 6/7] backports: add media subsystem drivers
From: Luis R. Rodriguez mcg...@do-not-panic.com This adds backport support for all media subsystem drivers. This is enabled only for = 3.2. Some media drivers rely on the new probe deferrral mechanism (-EPROBE_DEFER see commit d1c3414c), those are only enabled for kernels = 3.4. Some media drivers only depend on the regulatory but since we only support backporting the regulatory on kernels = 3.4 we only enable those media drivers for = 3.4. This backports 433 media drivers. 1 2.6.24 [ OK ] 2 2.6.25 [ OK ] 3 2.6.26 [ OK ] 4 2.6.27 [ OK ] 5 2.6.28 [ OK ] 6 2.6.29 [ OK ] 7 2.6.30 [ OK ] 8 2.6.31 [ OK ] 9 2.6.32 [ OK ] 10 2.6.33 [ OK ] 11 2.6.34 [ OK ] 12 2.6.35 [ OK ] 13 2.6.36 [ OK ] 14 2.6.37 [ OK ] 15 2.6.38 [ OK ] 16 2.6.39 [ OK ] 17 3.0.65 [ OK ] 18 3.1.10 [ OK ] 19 3.2.38 [ OK ] 20 3.3.8 [ OK ] 21 3.4.32 [ OK ] 22 3.5.7 [ OK ] 23 3.6.11 [ OK ] 24 3.7.9 [ OK ] 25 3.8.0 [ OK ] 26 3.9-rc1 [ OK ] real39m35.615s user1068m47.428s sys 155m55.657s Cc: linux-media@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Mauro Carvalho Chehab mche...@redhat.com Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com --- backport/.blacklist.map|1 + backport/Kconfig |1 + backport/Makefile.kernel |1 + backport/defconfigs/media | 506 copy-list | 17 + dependencies | 44 ++ .../collateral-evolutions/media/0001-pr_fmt.patch | 493 +++ .../media/0002-dma_mmap_coherent-revert.patch | 58 +++ .../media/0003-technisat-usb2-led-rename.patch | 83 9 files changed, 1204 insertions(+) create mode 100644 backport/defconfigs/media create mode 100644 patches/collateral-evolutions/media/0001-pr_fmt.patch create mode 100644 patches/collateral-evolutions/media/0002-dma_mmap_coherent-revert.patch create mode 100644 patches/collateral-evolutions/media/0003-technisat-usb2-led-rename.patch diff --git a/backport/.blacklist.map b/backport/.blacklist.map index dd58203..c1bdcfc 100644 --- a/backport/.blacklist.map +++ b/backport/.blacklist.map @@ -8,3 +8,4 @@ # new-driver old-driver iwlwifiiwlagn iwl4965iwlagn +videodev v4l2-compat-ioctl32 diff --git a/backport/Kconfig b/backport/Kconfig index 6088bfe..2c75cd8 100644 --- a/backport/Kconfig +++ b/backport/Kconfig @@ -40,3 +40,4 @@ source drivers/gpu/drm/Kconfig source net/nfc/Kconfig source drivers/regulator/Kconfig +source drivers/media/Kconfig diff --git a/backport/Makefile.kernel b/backport/Makefile.kernel index 2741cc9..27b44da 100644 --- a/backport/Makefile.kernel +++ b/backport/Makefile.kernel @@ -32,3 +32,4 @@ obj-$(CPTCFG_DRM) += drivers/gpu/drm/ obj-$(CPTCFG_NFC) += net/nfc/ obj-$(CPTCFG_NFC) += drivers/nfc/ obj-$(CPTCFG_REGULATOR) += drivers/regulator/ +obj-$(CPTCFG_MEDIA_SUPPORT) += drivers/media/ diff --git a/backport/defconfigs/media b/backport/defconfigs/media new file mode 100644 index 000..cbaf99f --- /dev/null +++ b/backport/defconfigs/media @@ -0,0 +1,506 @@ +CPTCFG_DVB_A8293=y +CPTCFG_DVB_AF9013=y +CPTCFG_DVB_AF9033=y +CPTCFG_DVB_ATBM8830=y +CPTCFG_DVB_AU8522=y +CPTCFG_DVB_AU8522_DTV=y +CPTCFG_DVB_AU8522_V4L=y +CPTCFG_DVB_AV7110=y +CPTCFG_DVB_B2C2_FLEXCOP=y +CPTCFG_DVB_B2C2_FLEXCOP_PCI=y +CPTCFG_DVB_B2C2_FLEXCOP_USB=y +CPTCFG_DVB_BCM3510=y +CPTCFG_DVB_BT8XX=y +CPTCFG_DVB_BUDGET=y +CPTCFG_DVB_BUDGET_AV=y +CPTCFG_DVB_BUDGET_CI=y +CPTCFG_DVB_BUDGET_CORE=y +CPTCFG_DVB_BUDGET_PATCH=y +CPTCFG_DVB_CORE=y +CPTCFG_DVB_CX22700=y +CPTCFG_DVB_CX22702=y +CPTCFG_DVB_CX24110=y +CPTCFG_DVB_CX24116=y +CPTCFG_DVB_CX24123=y +CPTCFG_DVB_CXD2820R=y +CPTCFG_DVB_DDBRIDGE=y +CPTCFG_DVB_DIB3000MB=y +CPTCFG_DVB_DIB3000MC=y +CPTCFG_DVB_DIB7000M=y +CPTCFG_DVB_DIB7000P=y +CPTCFG_DVB_DIB8000=y +CPTCFG_DVB_DIB9000=y +CPTCFG_DVB_DM1105=y +CPTCFG_DVB_DRXD=y +CPTCFG_DVB_DRXK=y +CPTCFG_DVB_DS3000=y +CPTCFG_DVB_DUMMY_FE=y +CPTCFG_DVB_EC100=y +CPTCFG_DVB_FIREDTV=y +CPTCFG_DVB_FIREDTV_INPUT=y +CPTCFG_DVB_HD29L2=y +CPTCFG_DVB_HOPPER=y +CPTCFG_DVB_ISL6405=y +CPTCFG_DVB_ISL6421=y +CPTCFG_DVB_ISL6423=y +CPTCFG_DVB_IT913X_FE=y +CPTCFG_DVB_IX2505V=y +CPTCFG_DVB_L64781=y +CPTCFG_DVB_LG2160=y +CPTCFG_DVB_LGDT3305=y +CPTCFG_DVB_LGDT330X=y +CPTCFG_DVB_LGS8GL5=y +CPTCFG_DVB_LGS8GXX=y +CPTCFG_DVB_LNBP21=y +CPTCFG_DVB_LNBP22=y +CPTCFG_DVB_M88RS2000=y +CPTCFG_DVB_MANTIS=y +CPTCFG_DVB_MB86A16=y +CPTCFG_DVB_MB86A20S=y +CPTCFG_DVB_MT312=y +CPTCFG_DVB_MT352=y
Re: [PATCH 0/3] em28xx: clean up end extend the GPIO port handling
Em Sat, 13 Apr 2013 16:15:39 +0300 Antti Palosaari cr...@iki.fi escreveu: On 04/13/2013 12:48 PM, Frank Schäfer wrote: Patch 1 removes the unneeded and broken gpio register caching code. Patch 2 adds the gpio register defintions for the em25xx/em276x/7x/8x and patch 3 finally adds a new helper function for gpio ports with separate registers for read and write access. I have nothing to say directly about those patches - they looked good at the quick check. But I wonder if you have any idea if it is possible to use some existing Kernel GPIO functionality in order to provide standard interface (interface like I2C). I did some work last summer in order to use GPIOLIB and it is used between em28xx-dvb and cxd2820r for LNA control. Anyhow, I was a little bit disappointed as GPIOLIB is disabled by default and due to that there is macros to disable LNA when GPIOLIB is not compiled. I noticed recently there is some ongoing development for Kernel GPIO. I haven't looked yet if it makes use of GPIO interface more common... I have conflicting opinions myself weather we should use gpiolib or not. I don't mind with the fact that GPIOLIB is disabled by default. If all media drivers start depending on it, distros will enable it to keep media support on it. I never took the time to take a look on what methods gpiolib provides. Maybe it will bring some benefits. I dunno. Just looking at the existing drivers (almost all has some sort of GPIO config), GPIO is just a single register bitmask read/write. Most drivers need already bitmask read/write operations. So, in principle, I can't foresee any code simplification by using a library. Also, from a very pragmatic view, changing (almost) all existing drivers to use gpiolib is a big effort. However, for that to happen, one question should be answered: what benefits would be obtained by using gpiolib? Regards, 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: [PATCH 0/3] em28xx: clean up end extend the GPIO port handling
On 04/13/2013 05:25 PM, Mauro Carvalho Chehab wrote: Em Sat, 13 Apr 2013 16:15:39 +0300 Antti Palosaari cr...@iki.fi escreveu: On 04/13/2013 12:48 PM, Frank Schäfer wrote: Patch 1 removes the unneeded and broken gpio register caching code. Patch 2 adds the gpio register defintions for the em25xx/em276x/7x/8x and patch 3 finally adds a new helper function for gpio ports with separate registers for read and write access. I have nothing to say directly about those patches - they looked good at the quick check. But I wonder if you have any idea if it is possible to use some existing Kernel GPIO functionality in order to provide standard interface (interface like I2C). I did some work last summer in order to use GPIOLIB and it is used between em28xx-dvb and cxd2820r for LNA control. Anyhow, I was a little bit disappointed as GPIOLIB is disabled by default and due to that there is macros to disable LNA when GPIOLIB is not compiled. I noticed recently there is some ongoing development for Kernel GPIO. I haven't looked yet if it makes use of GPIO interface more common... I have conflicting opinions myself weather we should use gpiolib or not. I don't mind with the fact that GPIOLIB is disabled by default. If all media drivers start depending on it, distros will enable it to keep media support on it. I never took the time to take a look on what methods gpiolib provides. Maybe it will bring some benefits. I dunno. Compare to benefits of I2C bus. It offers standard interface. Also it offers userspace debug interface - like I2C also does. Just looking at the existing drivers (almost all has some sort of GPIO config), GPIO is just a single register bitmask read/write. Most drivers need already bitmask read/write operations. So, in principle, I can't foresee any code simplification by using a library. Use of lib interface is not very practical inside of module, however it could be used. Again, as compared to I2C there is some bridge drivers which do some I2C access using I2C interface, even bridge could do it directly (as it offers I2C adapter). I think it is most common to do it directly to simplify things. Also, from a very pragmatic view, changing (almost) all existing drivers to use gpiolib is a big effort. It is not needed to implement for all driver as one go. However, for that to happen, one question should be answered: what benefits would be obtained by using gpiolib? Obtain GPIO access between modules using standard interface and offer handy debug interface to switch GPIOs from userspace. You could ask why we use Kernel I2C library as we could do it directly :) Or clock framework. Or SPI, is there SPI bus modeled yet? regards Antti -- 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
Re: [PATCH 1/3] em28xx: give up GPIO register tracking/caching
Em Sat, 13 Apr 2013 11:48:39 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: The GPIO register tracking/caching code is partially broken, because newer devices provide more than one GPIO register and some of them are even using separate registers for read and write access. Making it work would be too complicated. It is also used nowhere and doesn't make sense in cases where input lines are connected to buttons etc. Signed-off-by: Frank Schäfer fschaefer@googlemail.com --- drivers/media/usb/em28xx/em28xx-cards.c | 12 drivers/media/usb/em28xx/em28xx-core.c | 27 ++- drivers/media/usb/em28xx/em28xx.h |6 -- 3 Dateien geändert, 2 Zeilen hinzugefügt(+), 43 Zeilen entfernt(-) ... @@ -231,14 +215,7 @@ int em28xx_write_reg_bits(struct em28xx *dev, u16 reg, u8 val, int oldval; u8 newval; - /* Uses cache for gpo/gpio registers */ - if (reg == dev-reg_gpo_num) - oldval = dev-reg_gpo; - else if (reg == dev-reg_gpio_num) - oldval = dev-reg_gpio; - else - oldval = em28xx_read_reg(dev, reg); - + oldval = em28xx_read_reg(dev, reg); if (oldval 0) return oldval; That's plain wrong, as it will break GPIO input. With GPIO, you can write either 0 or 1 to a GPIO output port. So, your code works for output ports. However, an input port requires an specific value (either 1 or 0 depending on the GPIO circuitry). If the wrong value is written there, the input port will stop working. So, you can't simply read a value from a GPIO input and write it. You need to shadow the GPIO write values instead. Regards, 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
[PATCH] Add support for Delock 61959 and its remote control
This time for real with all bells and whistles: Delock 61959 is a relabeled MexMedia UB-425TC with a different USB ID and a different remote. Patch 1 adds the keytable for the remote control and patch 2 adds support for the device itself. I'm reusing maxmedia_ub425_tc as I didn't want to duplicate it without need. DVB-T is not working (yet) because of the DRX-K firmware issue. -- 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 1/2] rc: Add rc-delock-61959
This adds the keytable for the remote that comes with the Delock 61959.
NEC protocol with address 0x866b.
Signed-off-by: Jakob Haufe su...@sur5r.net
---
drivers/media/rc/keymaps/Makefile |1 +
drivers/media/rc/keymaps/rc-delock-61959.c | 83
include/media/rc-map.h |1 +
3 files changed, 85 insertions(+)
create mode 100644 drivers/media/rc/keymaps/rc-delock-61959.c
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index 7786619..e2b7ddb 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-budget-ci-old.o \
rc-cinergy-1400.o \
rc-cinergy.o \
+ rc-delock-61959.o \
rc-dib0700-nec.o \
rc-dib0700-rc5.o \
rc-digitalnow-tinytwin.o \
diff --git a/drivers/media/rc/keymaps/rc-delock-61959.c
b/drivers/media/rc/keymaps/rc-delock-61959.c
new file mode 100644
index 000..01bed86
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-delock-61959.c
@@ -0,0 +1,83 @@
+/* rc-delock-61959.c - Keytable for Delock
+ *
+ * Copyright (c) 2013 by Jakob Haufe su...@sur5r.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include media/rc-map.h
+#include linux/module.h
+
+/*
+ * Keytable for remote provided with Delock 61959
+ */
+static struct rc_map_table delock_61959[] = {
+ { 0x866b16, KEY_POWER2 }, /* Power */
+ { 0x866b0c, KEY_POWER },/* Shut Down */
+
+ { 0x866b00, KEY_1},
+ { 0x866b01, KEY_2},
+ { 0x866b02, KEY_3},
+ { 0x866b03, KEY_4},
+ { 0x866b04, KEY_5},
+ { 0x866b05, KEY_6},
+ { 0x866b06, KEY_7},
+ { 0x866b07, KEY_8},
+ { 0x866b08, KEY_9},
+ { 0x866b14, KEY_0},
+
+ { 0x866b0a, KEY_ZOOM}, /* Full Screen */
+ { 0x866b10, KEY_CAMERA},/* Photo */
+ { 0x866b0e, KEY_CHANNEL}, /* circular arrow / Recall */
+ { 0x866b13, KEY_ESC}, /* Back */
+
+ { 0x866b20, KEY_UP},
+ { 0x866b21, KEY_DOWN},
+ { 0x866b42, KEY_LEFT},
+ { 0x866b43, KEY_RIGHT},
+ { 0x866b0b, KEY_OK},
+
+ { 0x866b11, KEY_CHANNELUP},
+ { 0x866b1b, KEY_CHANNELDOWN},
+
+ { 0x866b12, KEY_VOLUMEUP},
+ { 0x866b48, KEY_VOLUMEDOWN},
+ { 0x866b44, KEY_MUTE},
+
+ { 0x866b1a, KEY_RECORD},
+ { 0x866b41, KEY_PLAY},
+ { 0x866b40, KEY_STOP},
+ { 0x866b19, KEY_PAUSE},
+ { 0x866b1c, KEY_FASTFORWARD}, /* / FWD */
+ { 0x866b1e, KEY_REWIND},/* / REW */
+
+};
+
+static struct rc_map_list delock_61959_map = {
+ .map = {
+ .scan= delock_61959,
+ .size= ARRAY_SIZE(delock_61959),
+ .rc_type = RC_TYPE_NEC,
+ .name= RC_MAP_DELOCK_61959,
+ }
+};
+
+static int __init init_rc_map_delock_61959(void)
+{
+ return rc_map_register(delock_61959_map);
+}
+
+static void __exit exit_rc_map_delock_61959(void)
+{
+ rc_map_unregister(delock_61959_map);
+}
+
+module_init(init_rc_map_delock_61959)
+module_exit(exit_rc_map_delock_61959)
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Jakob Haufe su...@sur5r.net);
+MODULE_DESCRIPTION(Delock 61959 remote keytable);
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index f74ee6f..46326ab 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -111,6 +111,7 @@ void rc_map_init(void);
#define RC_MAP_BUDGET_CI_OLD rc-budget-ci-old
#define RC_MAP_CINERGY_1400 rc-cinergy-1400
#define RC_MAP_CINERGY rc-cinergy
+#define RC_MAP_DELOCK_61959 rc-delock-61959
#define RC_MAP_DIB0700_NEC_TABLE rc-dib0700-nec
#define RC_MAP_DIB0700_RC5_TABLE rc-dib0700-rc5
#define RC_MAP_DIGITALNOW_TINYTWIN rc-digitalnow-tinytwin
--
1.7.10.4
--
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 2/2] em28xx: Add support for 1b80:e1cc Delock 61959
Hardware is the same as MaxMedia UB425-TC but ships with a different
remote.
Signed-off-by: Jakob Haufe su...@sur5r.net
---
drivers/media/usb/em28xx/em28xx-cards.c | 16
drivers/media/usb/em28xx/em28xx-dvb.c |5 +++--
drivers/media/usb/em28xx/em28xx.h |1 +
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 1d3866f..f625907 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -374,6 +374,7 @@ static struct em28xx_reg_seq hauppauge_930c_digital[] = {
#endif
/* 1b80:e425 MaxMedia UB425-TC
+ * 1b80:e1cc Delock 61959
* GPIO_6 - demod reset, 0=active
* GPIO_7 - LED, 0=active
*/
@@ -2016,6 +2017,19 @@ struct em28xx_board em28xx_boards[] = {
.i2c_speed= EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_400_KHZ,
},
+ /* 1b80:e1cc Delock 61959
+* Empia EM2874B + Micronas DRX 3913KA2 + NXP TDA18271HDC2
+ * mostly the same as MaxMedia UB-425-TC but different remote */
+ [EM2874_BOARD_DELOCK_61959] = {
+ .name = Delock 61959,
+ .tuner_type= TUNER_ABSENT,
+ .tuner_gpio= maxmedia_ub425_tc,
+ .has_dvb = 1,
+ .ir_codes = RC_MAP_DELOCK_61959,
+ .def_i2c_bus = 1,
+ .i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE |
+ EM28XX_I2C_FREQ_400_KHZ,
+ },
};
const unsigned int em28xx_bcount = ARRAY_SIZE(em28xx_boards);
@@ -2177,6 +2191,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2884_BOARD_PCTV_510E },
{ USB_DEVICE(0x2013, 0x0251),
.driver_info = EM2884_BOARD_PCTV_520E },
+ { USB_DEVICE(0x1b80, 0xe1cc),
+ .driver_info = EM2874_BOARD_DELOCK_61959 },
{ },
};
MODULE_DEVICE_TABLE(usb, em28xx_id_table);
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 42a6a26..663c998 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1213,6 +1213,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
dvb_attach(a8293_attach, dvb-fe[0],
dev-i2c_adap[dev-def_i2c_bus],
em28xx_a8293_config);
break;
+ case EM2874_BOARD_DELOCK_61959:
case EM2874_BOARD_MAXMEDIA_UB425_TC:
/* attach demodulator */
dvb-fe[0] = dvb_attach(drxk_attach, maxmedia_ub425_tc_drxk,
@@ -1232,8 +1233,8 @@ static int em28xx_dvb_init(struct em28xx *dev)
}
/* TODO: we need drx-3913k firmware in order to support DVB-T */
- em28xx_info(MaxMedia UB425-TC: only DVB-C supported by that \
- driver version\n);
+ em28xx_info(MaxMedia UB425-TC/Delock 61959: only DVB-C \
+ supported by that driver version\n);
break;
case EM2884_BOARD_PCTV_510E:
diff --git a/drivers/media/usb/em28xx/em28xx.h
b/drivers/media/usb/em28xx/em28xx.h
index a9323b6..59a9580 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -130,6 +130,7 @@
#define EM2884_BOARD_PCTV_520E 86
#define EM2884_BOARD_TERRATEC_HTC_USB_XS 87
#define EM2884_BOARD_C3TECH_DIGITAL_DUO 88
+#define EM2874_BOARD_DELOCK_6195989
/* Limits minimum and default number of buffers */
#define EM28XX_MIN_BUF 4
--
1.7.10.4
--
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/3] em28xx: clean up end extend the GPIO port handling
Am 13.04.2013 16:25, schrieb Mauro Carvalho Chehab: Em Sat, 13 Apr 2013 16:15:39 +0300 Antti Palosaari cr...@iki.fi escreveu: On 04/13/2013 12:48 PM, Frank Schäfer wrote: Patch 1 removes the unneeded and broken gpio register caching code. Patch 2 adds the gpio register defintions for the em25xx/em276x/7x/8x and patch 3 finally adds a new helper function for gpio ports with separate registers for read and write access. I have nothing to say directly about those patches - they looked good at the quick check. But I wonder if you have any idea if it is possible to use some existing Kernel GPIO functionality in order to provide standard interface (interface like I2C). I did some work last summer in order to use GPIOLIB and it is used between em28xx-dvb and cxd2820r for LNA control. Anyhow, I was a little bit disappointed as GPIOLIB is disabled by default and due to that there is macros to disable LNA when GPIOLIB is not compiled. I noticed recently there is some ongoing development for Kernel GPIO. I haven't looked yet if it makes use of GPIO interface more common... I have conflicting opinions myself weather we should use gpiolib or not. I don't mind with the fact that GPIOLIB is disabled by default. If all media drivers start depending on it, distros will enable it to keep media support on it. Right. I never took the time to take a look on what methods gpiolib provides. Maybe it will bring some benefits. I dunno. Just looking at the existing drivers (almost all has some sort of GPIO config), GPIO is just a single register bitmask read/write. Most drivers need already bitmask read/write operations. So, in principle, I can't foresee any code simplification by using a library. ... However, for that to happen, one question should be answered: what benefits would be obtained by using gpiolib? I've checked the documentation about the gpio and led frameworks a few weeks ago to find out if it makes sense to use them for the gpio/buttons/led stuff of the VAD Laplace webcam. AFAICS, there are no benfits as long as you are dealing with these things internally. It just increases the code size and adds an additional dependency in this case. Of course, the situation is different when there is an interaction with other modules or userspace. In that case using gpiolib could make sense. I don't know which case applies to the LAN stuff, but for the buttons/leds it's the first case. Regards, Frank -- 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/3] em28xx: give up GPIO register tracking/caching
Am 13.04.2013 16:41, schrieb Mauro Carvalho Chehab: Em Sat, 13 Apr 2013 11:48:39 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: The GPIO register tracking/caching code is partially broken, because newer devices provide more than one GPIO register and some of them are even using separate registers for read and write access. Making it work would be too complicated. It is also used nowhere and doesn't make sense in cases where input lines are connected to buttons etc. Signed-off-by: Frank Schäfer fschaefer@googlemail.com --- drivers/media/usb/em28xx/em28xx-cards.c | 12 drivers/media/usb/em28xx/em28xx-core.c | 27 ++- drivers/media/usb/em28xx/em28xx.h |6 -- 3 Dateien geändert, 2 Zeilen hinzugefügt(+), 43 Zeilen entfernt(-) ... @@ -231,14 +215,7 @@ int em28xx_write_reg_bits(struct em28xx *dev, u16 reg, u8 val, int oldval; u8 newval; -/* Uses cache for gpo/gpio registers */ -if (reg == dev-reg_gpo_num) -oldval = dev-reg_gpo; -else if (reg == dev-reg_gpio_num) -oldval = dev-reg_gpio; -else -oldval = em28xx_read_reg(dev, reg); - +oldval = em28xx_read_reg(dev, reg); if (oldval 0) return oldval; That's plain wrong, as it will break GPIO input. With GPIO, you can write either 0 or 1 to a GPIO output port. So, your code works for output ports. However, an input port requires an specific value (either 1 or 0 depending on the GPIO circuitry). If the wrong value is written there, the input port will stop working. So, you can't simply read a value from a GPIO input and write it. You need to shadow the GPIO write values instead. I don't understand what you mean. Why can I not read the value of a GPIO input and write it ? Regards, Frank Regards, 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: [PATCH 0/3] em28xx: clean up end extend the GPIO port handling
On Sat, Apr 13, 2013 at 11:30 AM, Frank Schäfer fschaefer@googlemail.com wrote: I've checked the documentation about the gpio and led frameworks a few weeks ago to find out if it makes sense to use them for the gpio/buttons/led stuff of the VAD Laplace webcam. AFAICS, there are no benfits as long as you are dealing with these things internally. It just increases the code size and adds an additional dependency in this case. Of course, the situation is different when there is an interaction with other modules or userspace. In that case using gpiolib could make sense. I don't know which case applies to the LAN stuff, but for the buttons/leds it's the first case. IMHO, it would be a bad idea to expose the actual GPIOs to userspace. Improperly setting the GPIOs can cause damage to the board, and all of the functionality that the GPIOs control are exposed through other much better supported interfaces. It's a nice debug feature for driver developers who want to hack at the driver, but you really don't want any situation where end users or applications are making direct use of the GPIOs. Devin -- Devin J. Heitmueller - 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: [PATCH 0/3] em28xx: clean up end extend the GPIO port handling
On 04/13/2013 06:34 PM, Devin Heitmueller wrote: On Sat, Apr 13, 2013 at 11:30 AM, Frank Schäfer fschaefer@googlemail.com wrote: I've checked the documentation about the gpio and led frameworks a few weeks ago to find out if it makes sense to use them for the gpio/buttons/led stuff of the VAD Laplace webcam. AFAICS, there are no benfits as long as you are dealing with these things internally. It just increases the code size and adds an additional dependency in this case. Of course, the situation is different when there is an interaction with other modules or userspace. In that case using gpiolib could make sense. I don't know which case applies to the LAN stuff, but for the buttons/leds it's the first case. IMHO, it would be a bad idea to expose the actual GPIOs to userspace. Improperly setting the GPIOs can cause damage to the board, and all of the functionality that the GPIOs control are exposed through other much better supported interfaces. It's a nice debug feature for driver developers who want to hack at the driver, but you really don't want any situation where end users or applications are making direct use of the GPIOs. Existing userspace sysfs interface is clearly debug interface. You will need root privileges to mount it and IIRC it was not even compiled by default (needs Kconfig debug option?). regards Antti -- 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
Re: [PATCH] Add support for Delock 61959 and its remote control
On 04/13/2013 06:03 PM, Jakob Haufe wrote: This time for real with all bells and whistles: Delock 61959 is a relabeled MexMedia UB-425TC with a different USB ID and a different remote. Patch 1 adds the keytable for the remote control and patch 2 adds support for the device itself. I'm reusing maxmedia_ub425_tc as I didn't want to duplicate it without need. DVB-T is not working (yet) because of the DRX-K firmware issue. Patches seems to be correct. Thank you! regards Antti -- 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
Re: [PATCH 1/2] rc: Add rc-delock-61959
On 04/13/2013 06:03 PM, Jakob Haufe wrote: This adds the keytable for the remote that comes with the Delock 61959. NEC protocol with address 0x866b. Signed-off-by: Jakob Haufe su...@sur5r.net Reviewed-by: Antti Palosaari cr...@iki.fi -- 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
Re: [PATCH 2/2] em28xx: Add support for 1b80:e1cc Delock 61959
On 04/13/2013 06:03 PM, Jakob Haufe wrote: Hardware is the same as MaxMedia UB425-TC but ships with a different remote. Signed-off-by: Jakob Haufe su...@sur5r.net Reviewed-by: Antti Palosaari cr...@iki.fi -- 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
Re: [PATCH 0/3] em28xx: clean up end extend the GPIO port handling
On Sat, Apr 13, 2013 at 12:21 PM, Antti Palosaari cr...@iki.fi wrote: Existing userspace sysfs interface is clearly debug interface. You will need root privileges to mount it and IIRC it was not even compiled by default (needs Kconfig debug option?). You would like to think that. Tell Mauro then, since he wanted to rely on sysfs to associate V4L2 video devices with ALSA devices (rather than just adding a simple call to the V4L2 API). Devin -- Devin J. Heitmueller - 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: [PATCH 1/3] em28xx: give up GPIO register tracking/caching
Em Sat, 13 Apr 2013 17:33:28 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: Am 13.04.2013 16:41, schrieb Mauro Carvalho Chehab: Em Sat, 13 Apr 2013 11:48:39 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: The GPIO register tracking/caching code is partially broken, because newer devices provide more than one GPIO register and some of them are even using separate registers for read and write access. Making it work would be too complicated. It is also used nowhere and doesn't make sense in cases where input lines are connected to buttons etc. Signed-off-by: Frank Schäfer fschaefer@googlemail.com --- drivers/media/usb/em28xx/em28xx-cards.c | 12 drivers/media/usb/em28xx/em28xx-core.c | 27 ++- drivers/media/usb/em28xx/em28xx.h |6 -- 3 Dateien geändert, 2 Zeilen hinzugefügt(+), 43 Zeilen entfernt(-) ... @@ -231,14 +215,7 @@ int em28xx_write_reg_bits(struct em28xx *dev, u16 reg, u8 val, int oldval; u8 newval; - /* Uses cache for gpo/gpio registers */ - if (reg == dev-reg_gpo_num) - oldval = dev-reg_gpo; - else if (reg == dev-reg_gpio_num) - oldval = dev-reg_gpio; - else - oldval = em28xx_read_reg(dev, reg); - + oldval = em28xx_read_reg(dev, reg); if (oldval 0) return oldval; That's plain wrong, as it will break GPIO input. With GPIO, you can write either 0 or 1 to a GPIO output port. So, your code works for output ports. However, an input port requires an specific value (either 1 or 0 depending on the GPIO circuitry). If the wrong value is written there, the input port will stop working. So, you can't simply read a value from a GPIO input and write it. You need to shadow the GPIO write values instead. I don't understand what you mean. Why can I not read the value of a GPIO input and write it ? Because, depending on the value you write, it can transform the input into an output port. If you don't understand why, I suggest you to take a look on how the GPIO circuits are implemented. A very quick explanation could be find here: http://www.mcc-us.com/Open-collectorFAQ.htm A more detailed one could be find here: http://www.coactionos.com/embedded-design/28-using-pull-ups-and-pull-downs.html So, looking at the picture at http://www.coactionos.com/images/pullup.png and assuming that a 0 means that the MOSFET gate is open, 1 means it is closed, for a pull-up GPIO input pin to work, driver needs to write 1 on it, so that it will have VCC there. This way, when MOSFEG goes to 1, the GPIO will be short-ciruited with GND, and the driver will read a 0. Note, however, that, if the driver writes a 0 to GPIO, no matter if the MOSFET is opened or closed, it will read 0 every time. Just the opposite logic applies for the pull-down logic. -- 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: [PATCH 1/3] em28xx: give up GPIO register tracking/caching
Am 13.04.2013 19:04, schrieb Mauro Carvalho Chehab: Em Sat, 13 Apr 2013 17:33:28 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: Am 13.04.2013 16:41, schrieb Mauro Carvalho Chehab: Em Sat, 13 Apr 2013 11:48:39 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: The GPIO register tracking/caching code is partially broken, because newer devices provide more than one GPIO register and some of them are even using separate registers for read and write access. Making it work would be too complicated. It is also used nowhere and doesn't make sense in cases where input lines are connected to buttons etc. Signed-off-by: Frank Schäfer fschaefer@googlemail.com --- drivers/media/usb/em28xx/em28xx-cards.c | 12 drivers/media/usb/em28xx/em28xx-core.c | 27 ++- drivers/media/usb/em28xx/em28xx.h |6 -- 3 Dateien geändert, 2 Zeilen hinzugefügt(+), 43 Zeilen entfernt(-) ... @@ -231,14 +215,7 @@ int em28xx_write_reg_bits(struct em28xx *dev, u16 reg, u8 val, int oldval; u8 newval; - /* Uses cache for gpo/gpio registers */ - if (reg == dev-reg_gpo_num) - oldval = dev-reg_gpo; - else if (reg == dev-reg_gpio_num) - oldval = dev-reg_gpio; - else - oldval = em28xx_read_reg(dev, reg); - + oldval = em28xx_read_reg(dev, reg); if (oldval 0) return oldval; That's plain wrong, as it will break GPIO input. With GPIO, you can write either 0 or 1 to a GPIO output port. So, your code works for output ports. However, an input port requires an specific value (either 1 or 0 depending on the GPIO circuitry). If the wrong value is written there, the input port will stop working. So, you can't simply read a value from a GPIO input and write it. You need to shadow the GPIO write values instead. I don't understand what you mean. Why can I not read the value of a GPIO input and write it ? Because, depending on the value you write, it can transform the input into an output port. I don't get it. We always write to the GPIO register. That's why these functions are called em28xx_write_* ;) Whether the write operation is sane or not (e.g. because it modifies the bit corresponding to an input line) is not subject of these functions. Frank -- 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/3] em28xx: give up GPIO register tracking/caching
Em Sat, 13 Apr 2013 19:46:20 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 13.04.2013 19:04, schrieb Mauro Carvalho Chehab:
Em Sat, 13 Apr 2013 17:33:28 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 13.04.2013 16:41, schrieb Mauro Carvalho Chehab:
Em Sat, 13 Apr 2013 11:48:39 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
The GPIO register tracking/caching code is partially broken, because
newer
devices provide more than one GPIO register and some of them are even
using
separate registers for read and write access.
Making it work would be too complicated.
It is also used nowhere and doesn't make sense in cases where input
lines are
connected to buttons etc.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c | 12
drivers/media/usb/em28xx/em28xx-core.c | 27
++-
drivers/media/usb/em28xx/em28xx.h |6 --
3 Dateien geändert, 2 Zeilen hinzugefügt(+), 43 Zeilen entfernt(-)
...
@@ -231,14 +215,7 @@ int em28xx_write_reg_bits(struct em28xx *dev, u16
reg, u8 val,
int oldval;
u8 newval;
-/* Uses cache for gpo/gpio registers */
-if (reg == dev-reg_gpo_num)
-oldval = dev-reg_gpo;
-else if (reg == dev-reg_gpio_num)
-oldval = dev-reg_gpio;
-else
-oldval = em28xx_read_reg(dev, reg);
-
+oldval = em28xx_read_reg(dev, reg);
if (oldval 0)
return oldval;
That's plain wrong, as it will break GPIO input.
With GPIO, you can write either 0 or 1 to a GPIO output port. So, your
code works for output ports.
However, an input port requires an specific value (either 1 or 0 depending
on the GPIO circuitry). If the wrong value is written there, the input
port
will stop working.
So, you can't simply read a value from a GPIO input and write it. You need
to shadow the GPIO write values instead.
I don't understand what you mean.
Why can I not read the value of a GPIO input and write it ?
Because, depending on the value you write, it can transform the input into
an
output port.
I don't get it.
We always write to the GPIO register. That's why these functions are
called em28xx_write_* ;)
Whether the write operation is sane or not (e.g. because it modifies the
bit corresponding to an input line) is not subject of these functions.
Writing is sane: GPIO input lines requires writing as well, in order to
set it to either pull-up or pull-down mode (not sure if em28xx supports
both ways).
So, the driver needs to know if it will write there a 0 or 1, and this is part
of its GPIO configuration.
Let's assume that, on a certain device, you need to write 1 to enable that
input.
A read I/O to that port can return either 0 or 1.
Giving an hypothetical example, please assume this code:
static int write_gpio_bits(u32 out, u32 mask)
{
u32 gpio = (read_gpio_ports() ~mask) | (out mask);
write_gpio_ports(gpio);
}
...
/* Use bit 1 as input GPIO */
write_gpio_bits(1, 1);
/* send a reset via bit 2 GPIO */
write_gpio_bits(2, 2);
write_gpio_bits(0, 2);
write_gpio_bits(2, 2);
If, at the time the above code runs, the input bit 1 is at 0 state,
the subsequent calls will disable the input.
If, instead, only the write operations are cached like:
static int write_gpio_bits(u32 out, u32 mask)
{
static u32 shadow_cache;
shadow_cache = (shadow_cache ~mask) | (out mask);
write_gpio_ports(gpio);
}
there's no such risk, as it will keep using 1 for the input bit.
See the difference?
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: [PATCH 1/3] em28xx: give up GPIO register tracking/caching
Am 13.04.2013 19:46, schrieb Frank Schäfer: Am 13.04.2013 19:04, schrieb Mauro Carvalho Chehab: Em Sat, 13 Apr 2013 17:33:28 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: Am 13.04.2013 16:41, schrieb Mauro Carvalho Chehab: Em Sat, 13 Apr 2013 11:48:39 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: The GPIO register tracking/caching code is partially broken, because newer devices provide more than one GPIO register and some of them are even using separate registers for read and write access. Making it work would be too complicated. It is also used nowhere and doesn't make sense in cases where input lines are connected to buttons etc. Signed-off-by: Frank Schäfer fschaefer@googlemail.com --- drivers/media/usb/em28xx/em28xx-cards.c | 12 drivers/media/usb/em28xx/em28xx-core.c | 27 ++- drivers/media/usb/em28xx/em28xx.h |6 -- 3 Dateien geändert, 2 Zeilen hinzugefügt(+), 43 Zeilen entfernt(-) ... @@ -231,14 +215,7 @@ int em28xx_write_reg_bits(struct em28xx *dev, u16 reg, u8 val, int oldval; u8 newval; - /* Uses cache for gpo/gpio registers */ - if (reg == dev-reg_gpo_num) - oldval = dev-reg_gpo; - else if (reg == dev-reg_gpio_num) - oldval = dev-reg_gpio; - else - oldval = em28xx_read_reg(dev, reg); - + oldval = em28xx_read_reg(dev, reg); if (oldval 0) return oldval; That's plain wrong, as it will break GPIO input. With GPIO, you can write either 0 or 1 to a GPIO output port. So, your code works for output ports. However, an input port requires an specific value (either 1 or 0 depending on the GPIO circuitry). If the wrong value is written there, the input port will stop working. So, you can't simply read a value from a GPIO input and write it. You need to shadow the GPIO write values instead. I don't understand what you mean. Why can I not read the value of a GPIO input and write it ? Because, depending on the value you write, it can transform the input into an output port. I don't get it. We always write to the GPIO register. That's why these functions are called em28xx_write_* ;) Whether the write operation is sane or not (e.g. because it modifies the bit corresponding to an input line) is not subject of these functions. Hmm... that's actually not true for em28xx_write_regs(). The current/old code never writes the value to GPIO registers, it just saves it to the device struct. IMHO, this is plain wrong and yet antoher reason for applying this patch. ;) It just didn't cause any trouble (hopefully) because for the GPIO registers em28xx_write_reg_bits() is usually used instead (which works correctly). After checking the whole GPIO stuff again, I noticed a different potential problem: Register 0x04 seems to be a pure GPO register, so it is possible that reading the current value from this register doesn't work. The note in em28xx_write_regs() implies that noone has ever tested if it works correctly. Anyway, the current code reads register 0x04, too, to get the initial value for caching. ;) Regards, Frank Frank -- 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/3] em28xx: give up GPIO register tracking/caching
Am 13.04.2013 20:19, schrieb Frank Schäfer: Am 13.04.2013 19:46, schrieb Frank Schäfer: ... We always write to the GPIO register. That's why these functions are called em28xx_write_* ;) Whether the write operation is sane or not (e.g. because it modifies the bit corresponding to an input line) is not subject of these functions. Hmm... that's actually not true for em28xx_write_regs(). The current/old code never writes the value to GPIO registers, it just saves it to the device struct. Arghh... no ... please disregard this paragraph, I simply overlooked the register write. I have to stop for today, will try to get back to this tomorrow. Regards, Frank -- 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 RFC v6] [media] Add common video interfaces OF bindings documentation
On Wed, 20 Mar 2013 17:19:53 +0100, Sylwester Nawrocki s.nawro...@samsung.com wrote: On 01/31/2013 07:41 PM, Sylwester Nawrocki wrote: From: Guennadi Liakhovetski g.liakhovet...@gmx.de This patch adds a document describing common OF bindings for video capture, output and video processing devices. It is curently mainly focused on video capture devices, with data busses defined by standards like ITU-R BT.656 or MIPI-CSI2. It also documents a method of describing data links between devices. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com --- Changes since v5: - added 'ports' node documentation Hi Rob, Grant, there was no more comments on this patch for a relatively long time now. Would you apply it to your tree or could I send it for inclusion in the media tree with your Ack ? For the binding: Acked-by: Grant Likely grant.lik...@secretlab.ca -- 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] backports: add media subsystem drivers
On Sat, 2013-04-13 at 07:13 -0700, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@do-not-panic.com This adds backport support for all media subsystem drivers. This is enabled only for = 3.2. Some media drivers rely on the new probe deferrral mechanism (-EPROBE_DEFER see commit d1c3414c), those are only enabled for kernels = 3.4. Some media drivers only depend on the regulatory but since we only support backporting the regulatory on kernels = 3.4 we only enable those media drivers for = 3.4. This backports 433 media drivers. Heh. Applied. Good thing I can kill the pr_fmt patches again soon. johannes -- 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 v9 15/20] sh-mobile-ceu-driver: support max width and height in DT
Hello. On 12-04-2013 19:40, Guennadi Liakhovetski wrote: Some CEU implementations have non-standard (larger) maximum supported width and height values. Add two OF properties to specify them. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Minor grammar nitpicking. diff --git a/Documentation/devicetree/bindings/media/sh_mobile_ceu.txt b/Documentation/devicetree/bindings/media/sh_mobile_ceu.txt new file mode 100644 index 000..1ce4e46 --- /dev/null +++ b/Documentation/devicetree/bindings/media/sh_mobile_ceu.txt @@ -0,0 +1,18 @@ +Bindings, specific for the sh_mobile_ceu_camera.c driver: + - compatible: Should be renesas,sh-mobile-ceu + - reg: register base and size + - interrupts: the interrupt number + - interrupt-parent: the interrupt controller + - renesas,max-width: maximum image width, supported on this SoC + - renesas,max-height: maximum image height, supported on this SoC Commas not needed above. WBR, Sergei -- 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] [media] cx88: Fix unsafe locking in suspend-resume
Legacy PCI suspend-resume handlers are called with interrupts enabled.
But cx8800_suspend/cx8800_resume and cx8802_suspend_common/cx8802_resume_common
use spin_lock/spin_unlock functions to acquire dev-slock, while the same lock
is acquired in
the corresponding irq-handlers: cx8800_irq and cx8802_irq.
That means a deadlock is possible if an interrupt happens while suspend or
resume owns the lock.
The patch replaces spin_lock/spin_unlock with
spin_lock_irqsave/spin_unlock_irqrestore.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/media/pci/cx88/cx88-mpeg.c | 10 ++
drivers/media/pci/cx88/cx88-video.c | 10 ++
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/media/pci/cx88/cx88-mpeg.c
b/drivers/media/pci/cx88/cx88-mpeg.c
index c9d3182..c6cdbdb 100644
--- a/drivers/media/pci/cx88/cx88-mpeg.c
+++ b/drivers/media/pci/cx88/cx88-mpeg.c
@@ -532,16 +532,17 @@ static int cx8802_suspend_common(struct pci_dev *pci_dev,
pm_message_t state)
{
struct cx8802_dev *dev = pci_get_drvdata(pci_dev);
struct cx88_core *core = dev-core;
+ unsigned long flags;
/* stop mpeg dma */
- spin_lock(dev-slock);
+ spin_lock_irqsave(dev-slock,flags);
if (!list_empty(dev-mpegq.active)) {
dprintk( 2, suspend\n );
printk(%s: suspend mpeg\n, core-name);
cx8802_stop_dma(dev);
del_timer(dev-mpegq.timeout);
}
- spin_unlock(dev-slock);
+ spin_unlock_irqrestore(dev-slock,flags);
/* FIXME -- shutdown device */
cx88_shutdown(dev-core);
@@ -558,6 +559,7 @@ static int cx8802_resume_common(struct pci_dev *pci_dev)
{
struct cx8802_dev *dev = pci_get_drvdata(pci_dev);
struct cx88_core *core = dev-core;
+ unsigned long flags;
int err;
if (dev-state.disabled) {
@@ -584,12 +586,12 @@ static int cx8802_resume_common(struct pci_dev *pci_dev)
cx88_reset(dev-core);
/* restart video+vbi capture */
- spin_lock(dev-slock);
+ spin_lock_irqsave(dev-slock,flags);
if (!list_empty(dev-mpegq.active)) {
printk(%s: resume mpeg\n, core-name);
cx8802_restart_queue(dev,dev-mpegq);
}
- spin_unlock(dev-slock);
+ spin_unlock_irqrestore(dev-slock,flags);
return 0;
}
diff --git a/drivers/media/pci/cx88/cx88-video.c
b/drivers/media/pci/cx88/cx88-video.c
index bc78354..d72b403 100644
--- a/drivers/media/pci/cx88/cx88-video.c
+++ b/drivers/media/pci/cx88/cx88-video.c
@@ -1957,9 +1957,10 @@ static int cx8800_suspend(struct pci_dev *pci_dev,
pm_message_t state)
{
struct cx8800_dev *dev = pci_get_drvdata(pci_dev);
struct cx88_core *core = dev-core;
+ unsigned long flags;
/* stop video+vbi capture */
- spin_lock(dev-slock);
+ spin_lock_irqsave(dev-slock,flags);
if (!list_empty(dev-vidq.active)) {
printk(%s/0: suspend video\n, core-name);
stop_video_dma(dev);
@@ -1970,7 +1971,7 @@ static int cx8800_suspend(struct pci_dev *pci_dev,
pm_message_t state)
cx8800_stop_vbi_dma(dev);
del_timer(dev-vbiq.timeout);
}
- spin_unlock(dev-slock);
+ spin_unlock_irqrestore(dev-slock,flags);
if (core-ir)
cx88_ir_stop(core);
@@ -1989,6 +1990,7 @@ static int cx8800_resume(struct pci_dev *pci_dev)
{
struct cx8800_dev *dev = pci_get_drvdata(pci_dev);
struct cx88_core *core = dev-core;
+ unsigned long flags;
int err;
if (dev-state.disabled) {
@@ -2019,7 +2021,7 @@ static int cx8800_resume(struct pci_dev *pci_dev)
cx_set(MO_PCI_INTMSK, core-pci_irqmask);
/* restart video+vbi capture */
- spin_lock(dev-slock);
+ spin_lock_irqsave(dev-slock,flags);
if (!list_empty(dev-vidq.active)) {
printk(%s/0: resume video\n, core-name);
restart_video_queue(dev,dev-vidq);
@@ -2028,7 +2030,7 @@ static int cx8800_resume(struct pci_dev *pci_dev)
printk(%s/0: resume vbi\n, core-name);
cx8800_restart_vbi_queue(dev,dev-vbiq);
}
- spin_unlock(dev-slock);
+ spin_unlock_irqrestore(dev-slock,flags);
return 0;
}
--
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
Re: [PATCH 0/3] em28xx: clean up end extend the GPIO port handling
Em Sat, 13 Apr 2013 17:37:26 +0300 Antti Palosaari cr...@iki.fi escreveu: On 04/13/2013 05:25 PM, Mauro Carvalho Chehab wrote: Em Sat, 13 Apr 2013 16:15:39 +0300 Antti Palosaari cr...@iki.fi escreveu: On 04/13/2013 12:48 PM, Frank Schäfer wrote: Patch 1 removes the unneeded and broken gpio register caching code. Patch 2 adds the gpio register defintions for the em25xx/em276x/7x/8x and patch 3 finally adds a new helper function for gpio ports with separate registers for read and write access. I have nothing to say directly about those patches - they looked good at the quick check. But I wonder if you have any idea if it is possible to use some existing Kernel GPIO functionality in order to provide standard interface (interface like I2C). I did some work last summer in order to use GPIOLIB and it is used between em28xx-dvb and cxd2820r for LNA control. Anyhow, I was a little bit disappointed as GPIOLIB is disabled by default and due to that there is macros to disable LNA when GPIOLIB is not compiled. I noticed recently there is some ongoing development for Kernel GPIO. I haven't looked yet if it makes use of GPIO interface more common... I have conflicting opinions myself weather we should use gpiolib or not. I don't mind with the fact that GPIOLIB is disabled by default. If all media drivers start depending on it, distros will enable it to keep media support on it. I never took the time to take a look on what methods gpiolib provides. Maybe it will bring some benefits. I dunno. Compare to benefits of I2C bus. It offers standard interface. Also it offers userspace debug interface - like I2C also does. I2C benefit is that the same I2C driver can be used by several different drivers. GPIO code, on the other hand, is on most cases[1] specific to a given device. [1] Ok, if you're using a GPIO pin to carry some protocol inside it, like UART, RC, etc, then I can see a benefit on using a bus type of solution. Just looking at the existing drivers (almost all has some sort of GPIO config), GPIO is just a single register bitmask read/write. Most drivers need already bitmask read/write operations. So, in principle, I can't foresee any code simplification by using a library. Use of lib interface is not very practical inside of module, however it could be used. Again, as compared to I2C there is some bridge drivers which do some I2C access using I2C interface, even bridge could do it directly (as it offers I2C adapter). I think it is most common to do it directly to simplify things. Also, from a very pragmatic view, changing (almost) all existing drivers to use gpiolib is a big effort. It is not needed to implement for all driver as one go. However, for that to happen, one question should be answered: what benefits would be obtained by using gpiolib? Obtain GPIO access between modules using standard interface and offer handy debug interface to switch GPIOs from userspace. It is known that enabling both analog and digital demods at the same time can melt some devices. So, it is risky to allow userspace to touch the GPIOs that enable such chips. (ok, there are also other forms to melt such devices in userspace if the user has CAP_SYS_ADMIN) You could ask why we use Kernel I2C library as we could do it directly :) Or clock framework. Or SPI, is there SPI bus modeled yet? As I said, i2c allowed code re-usage. Probably, the clock framework and SPI also can be used for that. With regards to GPIO, at least currently, I can only see its usage justified, in terms of code reuse, for remote controllers. 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
