Re: Patch update notification: 5 patches updated
On 12/26/2012 06:03 PM, Patchwork wrote: > Hello, > > The following patches (submitted by you) have been updated in patchwork: > > * [05/14,media] atmel-isi: Update error check for unsigned variables > - http://patchwork.linuxtv.org/patch/15475/ > was: New > now: Under Review > > * [01/14,media] ivtv: Remove redundant check on unsigned variable > - http://patchwork.linuxtv.org/patch/15479/ > was: New > now: Under Review > > * [04/14,media] tlg2300: Remove redundant check on unsigned variable > - http://patchwork.linuxtv.org/patch/15476/ > was: New > now: Under Review > > * [02/14,media] meye: Remove redundant check on unsigned variable > - http://patchwork.linuxtv.org/patch/15478/ > was: New > now: Under Review > > * [03/14,media] saa7134: Remove redundant check on unsigned variable > - http://patchwork.linuxtv.org/patch/15477/ > was: New > now: Under Review > > This email is a notification only - you do not need to respond. > The above 5 patches may please be marked as "Obsolete" as a similar patches have already been merged to 3.8-rc1. -- Tushar Behera -- 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 0/5] Common Display Framework
On 27 December 2012 20:13, Tomasz Figa wrote: > Hi Laurent, > > On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: >> Hi Tomasz, >> >> On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: >> > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: >> > > On 17 December 2012 20:55, Laurent Pinchart wrote: >> > > > Hi Vikas, >> > > > >> > > > Sorry for the late reply. I now have more time to work on CDF, so >> > > > delays should be much shorter. >> > > > >> > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: >> > > > > Hi Laurent, >> > > > > >> > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, >> > > > > what >> > > > > I found is that, the exynos display controller is MIPI DSI based >> > > > > controller. >> > > > > >> > > > > But if I look at CDF patches, it has only support for MIPI DBI >> > > > > based >> > > > > Display controller. >> > > > > >> > > > > So my question is, do we have any generic framework for MIPI DSI >> > > > > based display controller? basically I wanted to know, how to go >> > > > > about >> > > > > porting CDF for such kind of display controller. >> > > > >> > > > MIPI DSI support is not available yet. The only reason for that is >> > > > that I don't have any MIPI DSI hardware to write and test the code >> > > > with :-) >> > > > >> > > > The common display framework should definitely support MIPI DSI. I >> > > > think the existing MIPI DBI code could be used as a base, so the >> > > > implementation shouldn't be too high. >> > > > >> > > > Yeah, i was also thinking in similar lines, below is my though for >> > > > MIPI DSI support in CDF. >> > > >> > > o MIPI DSI support as part of CDF framework will expose >> > > § mipi_dsi_register_device(mpi_device) (will be called >> > > mach-xxx-dt.c >> > > file ) >> > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called >> > > from >> > > platform specific init driver call ) >> > > ·bus ops will be >> > > o read data >> > > o write data >> > > o write command >> > > § MIPI DSI will be registered as bus_register() >> > > >> > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) >> > > will >> > > initialize the MIPI DSI HW IP. >> > > >> > > This probe will also parse the DT file for MIPI DSI based panel, add >> > > the panel device (device_add() ) to kernel and register the display >> > > entity with its control and video ops with CDF. >> > > >> > > I can give this a try. >> > >> > I am currently in progress of reworking Exynos MIPI DSIM code and >> > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I >> > have most of the work done, I have just to solve several remaining >> > problems. >> Do you already have code that you can publish ? I'm particularly >> interested (and I think Tomi Valkeinen would be as well) in looking at >> the DSI operations you expose to DSI sinks (panels, transceivers, ...). > > Well, I'm afraid this might be little below your expectations, but here's > an initial RFC of the part defining just the DSI bus. I need a bit more > time for patches for Exynos MIPI DSI master and s6e8ax0 LCD. > > The implementation is very simple and heavily based on your MIPI DBI > support and existing Exynos MIPI DSIM framework. Provided operation set is > based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately > this is my only source of information about MIPI DSI. > > Best regards, > -- > Tomasz Figa > Samsung Poland R&D Center > SW Solution Development, Linux Platform > > From bad07d8bdce0ff76cbc81a9da597c0d01e5244f7 Mon Sep 17 00:00:00 2001 > From: Tomasz Figa > Date: Thu, 27 Dec 2012 12:36:15 +0100 > Subject: [RFC] video: display: Add generic MIPI DSI bus > > Signed-off-by: Tomasz Figa > --- > drivers/video/display/Kconfig| 4 + > drivers/video/display/Makefile | 1 + > drivers/video/display/mipi-dsi-bus.c | 214 > +++ > include/video/display.h | 1 + > include/video/mipi-dsi-bus.h | 98 > 5 files changed, 318 insertions(+) > create mode 100644 drivers/video/display/mipi-dsi-bus.c > create mode 100644 include/video/mipi-dsi-bus.h > > diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig > index 13b6aaf..dbaff9d 100644 > --- a/drivers/video/display/Kconfig > +++ b/drivers/video/display/Kconfig > @@ -9,6 +9,10 @@ config DISPLAY_MIPI_DBI > tristate > default n > > +config DISPLAY_MIPI_DSI > + tristate > + default n > + > config DISPLAY_PANEL_DPI > tristate "DPI (Parallel) Display Panels" > ---help--- > diff --git a/drivers/video/display/Makefile > b/drivers/video/display/Makefile > index 482bec7..429b3ac8 100644 > --- a/drivers/video/display/Makefile > +++ b/drivers/video/display/Makefile > @@ -1,5 +1,6 @@ > obj-$(CONFIG_DISPLAY_CORE) += display-core.o > obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o > +obj-$(CONFIG_DISPLAY_MIPI_DSI) += mipi-dsi-
Re: [PATCH 01/23] uvc: Replace memcpy with struct assignment
Em Thu, 27 Dec 2012 18:12:46 -0300 Ezequiel Garcia escreveu: > Mauro, > > On Tue, Oct 23, 2012 at 4:57 PM, Ezequiel Garcia > wrote: > > This kind of memcpy() is error-prone. Its replacement with a struct > > assignment is prefered because it's type-safe and much easier to read. > > > > Found by coccinelle. Hand patched and reviewed. > > Tested by compilation only. > > > > A simplified version of the semantic match that finds this problem is as > > follows: (http://coccinelle.lip6.fr/) > > > > // > > @@ > > identifier struct_name; > > struct struct_name to; > > struct struct_name from; > > expression E; > > @@ > > -memcpy(&(to), &(from), E); > > +to = from; > > // > > > > Cc: Laurent Pinchart > > Signed-off-by: Peter Senna Tschudin > > Signed-off-by: Ezequiel Garcia > > --- > > drivers/media/usb/uvc/uvc_v4l2.c |6 +++--- > > 1 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/media/usb/uvc/uvc_v4l2.c > > b/drivers/media/usb/uvc/uvc_v4l2.c > > index f00db30..4fc8737 100644 > > --- a/drivers/media/usb/uvc/uvc_v4l2.c > > +++ b/drivers/media/usb/uvc/uvc_v4l2.c > > @@ -314,7 +314,7 @@ static int uvc_v4l2_set_format(struct uvc_streaming > > *stream, > > goto done; > > } > > > > - memcpy(&stream->ctrl, &probe, sizeof probe); > > + stream->ctrl = probe; > > stream->cur_format = format; > > stream->cur_frame = frame; > > > > @@ -386,7 +386,7 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming > > *stream, > > return -EBUSY; > > } > > > > - memcpy(&probe, &stream->ctrl, sizeof probe); > > + probe = stream->ctrl; > > probe.dwFrameInterval = > > uvc_try_frame_interval(stream->cur_frame, interval); > > > > @@ -397,7 +397,7 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming > > *stream, > > return ret; > > } > > > > - memcpy(&stream->ctrl, &probe, sizeof probe); > > + stream->ctrl = probe; > > mutex_unlock(&stream->mutex); > > > > /* Return the actual frame period. */ > > -- > > 1.7.4.4 > > > > It seems you've marked this one as "Changes requested" [1]. > However, Laurent didn't request any change, > but just pointed out we missed one memcpy replacement candidate. > > I believe it's safe to apply the patch (together with the other 20 patches) > and we can fix the missing spot in another patch. The other patches got applied already. Well just do whatever Laurent asked you and re-submit this one ;) 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: [RFC v2 0/5] Common Display Framework
On Thu, Dec 27, 2012 at 01:57:56PM -0600, Rob Clark wrote:
> On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer wrote:
> > On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote:
> >> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
> >
> > This implies that the master driver knows all potential subdevices,
> > something which is not true for SoCs which have external i2c encoders
> > attached to unrelated i2c controllers.
>
> well, it can be brute-forced.. ie. drm driver calls common
> register_all_panels() fxn, which, well, registers all the
> panel/display subdev's based on their corresponding CONFIG_FOO_PANEL
> defines. If you anyways aren't building the panels as separate
> modules, that would work. Maybe not the most *elegant* approach, but
> simple and functional.
>
> I guess it partly depends on the structure in devicetree. If you are
> assuming that the i2c encoder belongs inside the i2c bus, like:
>
> &i2cN {
> foo-i2c-encoder {
>
> };
> };
>
> and you are letting devicetree create the devices, then it doesn't
> quite work. I'm not entirely convinced you should do it that way.
> Really any device like that is going to be hooked up to at least a
> couple busses.. i2c, some sort of bus carrying pixel data, maybe some
> gpio's, etc. So maybe makes more sense for a virtual drm/kms bus, and
> then use phandle stuff to link it to the various other busses it
> needs:
>
> mydrmdev {
> foo-i2c-encoder {
>i2c = <&i2cN>;
>gpio = <&gpioM 2 3>
>...
> };
> };
This seems to shift initialization order problem to another place.
Here we have to make sure the controller is initialized before the drm
driver. Same with suspend/resume.
It's not only i2c devices, also platform devices. On i.MX for example we
have a hdmi transmitter which is somewhere on the physical address
space.
I think grouping the different units together in a devicetree blob
because we think they might form a logical virtual device is not going
to work. It might make it easier from a drm perspective, but I think
doing this will make for a lot of special cases. What will happen for
example if you have two encoder devices in a row to configure? The
foo-i2c-encoder would then get another child node.
Right now the devicetree is strictly ordered by (control-, not data-)
bus topology. Linux has great helper code to support this model. Giving
up this help to brute force a different topology and then trying to fit
the result back into the Linux Bus hierarchy doesn't sound like a good
idea to me.
>
> ok, admittedly that is a bit different from other proposals about how
> this all fits in devicetree.. but otoh, I'm not a huge believer in
> letting something that is supposed to make life easier (DT), actually
> make things harder or more complicated. Plus this CDF stuff all needs
> to also work on platforms not using OF/DT.
Right, but every other platform I know of is also described by its bus
topology, be it platform device based or PCI or maybe even USB based.
CDF has to solve the same problem as ASoC and soc-camera: subdevices for
a virtual device can come from many different corners of the system. BTW
one example for a i2c encoder would be the SiI9022 which could not only
be part of a drm device, but also of an ASoC device.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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] blackfin Kconfig: select is evil; use, instead depends on
Select is evil as it has issues with dependencies. Better to convert it to use depends on. That fixes a breakage with out-of-tree compilation of the media tree. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/platform/blackfin/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/blackfin/Kconfig b/drivers/media/platform/blackfin/Kconfig index 519990e..cc23997 100644 --- a/drivers/media/platform/blackfin/Kconfig +++ b/drivers/media/platform/blackfin/Kconfig @@ -2,7 +2,6 @@ config VIDEO_BLACKFIN_CAPTURE tristate "Blackfin Video Capture Driver" depends on VIDEO_V4L2 && BLACKFIN && I2C select VIDEOBUF2_DMA_CONTIG - select VIDEO_BLACKFIN_PPI help V4L2 bridge driver for Blackfin video capture device. Choose PPI or EPPI as its interface. @@ -12,3 +11,5 @@ config VIDEO_BLACKFIN_CAPTURE config VIDEO_BLACKFIN_PPI tristate + depends on VIDEO_BLACKFIN_CAPTURE + default VIDEO_BLACKFIN_CAPTURE -- 1.7.11.7 -- 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 5/6] em28xx: IR RC: move assignment of get_key functions from *_change_protocol() functions to em28xx_ir_init()
The get_key functions are independent from the selected protocol, so assign
them once only at device initialization.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-input.c |6 ++
1 Datei geändert, 2 Zeilen hinzugefügt(+), 4 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-input.c
b/drivers/media/usb/em28xx/em28xx-input.c
index 62b6cb7..186820a 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -360,7 +360,6 @@ static int em2860_ir_change_protocol(struct rc_dev *rc_dev,
u64 *rc_type)
*rc_type = ir->rc_type;
return -EINVAL;
}
- ir->get_key = default_polling_getkey;
em28xx_write_reg_bits(dev, EM28XX_R0F_XCLK, dev->board.xclk,
EM28XX_XCLK_IR_RC5_MODE);
@@ -396,10 +395,7 @@ static int em2874_ir_change_protocol(struct rc_dev
*rc_dev, u64 *rc_type)
*rc_type = ir->rc_type;
return -EINVAL;
}
-
- ir->get_key = em2874_polling_getkey;
em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 1);
-
em28xx_write_reg_bits(dev, EM28XX_R0F_XCLK, dev->board.xclk,
EM28XX_XCLK_IR_RC5_MODE);
@@ -618,11 +614,13 @@ static int em28xx_ir_init(struct em28xx *dev)
switch (dev->chip_id) {
case CHIP_ID_EM2860:
case CHIP_ID_EM2883:
+ ir->get_key = default_polling_getkey;
rc->allowed_protos = RC_BIT_RC5 | RC_BIT_NEC;
break;
case CHIP_ID_EM2884:
case CHIP_ID_EM2874:
case CHIP_ID_EM28174:
+ ir->get_key = em2874_polling_getkey;
rc->allowed_protos = RC_BIT_RC5 | RC_BIT_NEC |
RC_BIT_RC6_0;
break;
default:
--
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 6/6] ir-kbd-i2c: fix get_key_knc1()
- return valid key code when button is hold - debug: print key code only when a button is pressed Tested with device "Terratec Cinergy 200 USB" (em28xx). Signed-off-by: Frank Schäfer --- drivers/media/i2c/ir-kbd-i2c.c | 15 +-- 1 Datei geändert, 5 Zeilen hinzugefügt(+), 10 Zeilen entfernt(-) diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c index 08ae067..2984b7d 100644 --- a/drivers/media/i2c/ir-kbd-i2c.c +++ b/drivers/media/i2c/ir-kbd-i2c.c @@ -184,18 +184,13 @@ static int get_key_knc1(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw) return -EIO; } - /* it seems that 0xFE indicates that a button is still hold - down, while 0xff indicates that no button is hold - down. 0xfe sequences are sometimes interrupted by 0xFF */ - - dprintk(2,"key %02x\n", b); - - if (b == 0xff) + if (b == 0xff) /* no button */ return 0; - if (b == 0xfe) - /* keep old data */ - return 1; + if (b == 0xfe) /* button is still hold */ + b = ir->rc->last_scancode; /* keep old data */ + + dprintk(2,"key %02x\n", b); *ir_key = b; *ir_raw = b; -- 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 4/6] em28xx: IR RC: get rid of function em28xx_get_key_terratec()
Module "ir-kbd-i2c" already provides this function as IR_KBD_GET_KEY_KNC1.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-input.c | 30 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 29 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-input.c
b/drivers/media/usb/em28xx/em28xx-input.c
index 631e252..62b6cb7 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -85,34 +85,6 @@ struct em28xx_IR {
I2C IR based get keycodes - should be used with ir-kbd-i2c
**/
-static int em28xx_get_key_terratec(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
-{
- unsigned char b;
-
- /* poll IR chip */
- if (1 != i2c_master_recv(ir->c, &b, 1)) {
- i2cdprintk("read error\n");
- return -EIO;
- }
-
- /* it seems that 0xFE indicates that a button is still hold
- down, while 0xff indicates that no button is hold
- down. 0xfe sequences are sometimes interrupted by 0xFF */
-
- i2cdprintk("key %02x\n", b);
-
- if (b == 0xff)
- return 0;
-
- if (b == 0xfe)
- /* keep old data */
- return 1;
-
- *ir_key = b;
- *ir_raw = b;
- return 1;
-}
-
static int em28xx_get_key_em_haup(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
{
unsigned char buf[2];
@@ -476,7 +448,7 @@ static int em28xx_register_i2c_ir(struct em28xx *dev,
struct rc_dev *rc_dev)
case EM2820_BOARD_TERRATEC_CINERGY_250:
dev->init_data.name = "i2c IR (EM28XX Terratec)";
dev->init_data.type = RC_BIT_OTHER;
- dev->init_data.get_key = em28xx_get_key_terratec;
+ dev->init_data.internal_get_key_func = IR_KBD_GET_KEY_KNC1;
break;
case EM2820_BOARD_PINNACLE_USB_2:
dev->init_data.name = "i2c IR (EM28XX Pinnacle PCTV)";
--
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 3/6] em28xx: make remote controls of devices with external IR IC working again
Tested with device "Terratec Cinergy 200 USB".
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-cards.c |9 +-
drivers/media/usb/em28xx/em28xx-i2c.c |1 +
drivers/media/usb/em28xx/em28xx-input.c | 142 +--
3 Dateien geändert, 83 Zeilen hinzugefügt(+), 69 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 40c3e45..3b226b1 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -488,6 +488,7 @@ struct em28xx_board em28xx_boards[] = {
.name = "Terratec Cinergy 250 USB",
.tuner_type = TUNER_LG_PAL_NEW_TAPC,
.has_ir_i2c = 1,
+ .ir_codes = RC_MAP_EM_TERRATEC,
.tda9887_conf = TDA9887_PRESENT,
.decoder = EM28XX_SAA711X,
.input= { {
@@ -508,6 +509,7 @@ struct em28xx_board em28xx_boards[] = {
.name = "Pinnacle PCTV USB 2",
.tuner_type = TUNER_LG_PAL_NEW_TAPC,
.has_ir_i2c = 1,
+ .ir_codes = RC_MAP_PINNACLE_GREY,
.tda9887_conf = TDA9887_PRESENT,
.decoder = EM28XX_SAA711X,
.input= { {
@@ -533,6 +535,7 @@ struct em28xx_board em28xx_boards[] = {
.decoder = EM28XX_TVP5150,
.has_msp34xx = 1,
.has_ir_i2c = 1,
+ .ir_codes = RC_MAP_HAUPPAUGE,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = TVP5150_COMPOSITE0,
@@ -629,6 +632,7 @@ struct em28xx_board em28xx_boards[] = {
.valid= EM28XX_BOARD_NOT_VALIDATED,
.tuner_type = TUNER_PHILIPS_FM1216ME_MK3,
.has_ir_i2c = 1,
+ .ir_codes = RC_MAP_WINFAST_USBII_DELUXE,
.tvaudio_addr = 0x58,
.tda9887_conf = TDA9887_PRESENT |
TDA9887_PORT2_ACTIVE |
@@ -1222,6 +1226,7 @@ struct em28xx_board em28xx_boards[] = {
.name = "Terratec Cinergy 200 USB",
.is_em2800= 1,
.has_ir_i2c = 1,
+ .ir_codes = RC_MAP_EM_TERRATEC,
.tuner_type = TUNER_LG_TALN,
.tda9887_conf = TDA9887_PRESENT,
.decoder = EM28XX_SAA711X,
@@ -2912,7 +2917,7 @@ static void request_module_async(struct work_struct *work)
if (dev->board.has_dvb)
request_module("em28xx-dvb");
- if (dev->board.ir_codes && !disable_ir)
+ if ((dev->board.ir_codes || dev->board.has_ir_i2c) && !disable_ir)
request_module("em28xx-rc");
#endif /* CONFIG_MODULES */
}
@@ -2935,8 +2940,6 @@ static void flush_request_modules(struct em28xx *dev)
*/
void em28xx_release_resources(struct em28xx *dev)
{
- /*FIXME: I2C IR should be disconnected */
-
em28xx_release_analog_resources(dev);
em28xx_i2c_unregister(dev);
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 44533e4..39c5a3e 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -470,6 +470,7 @@ static struct i2c_client em28xx_client_template = {
static char *i2c_devs[128] = {
[0x4a >> 1] = "saa7113h",
[0x52 >> 1] = "drxk",
+ [0x3e >> 1] = "remote IR sensor",
[0x60 >> 1] = "remote IR sensor",
[0x8e >> 1] = "remote IR sensor",
[0x86 >> 1] = "tda9887",
diff --git a/drivers/media/usb/em28xx/em28xx-input.c
b/drivers/media/usb/em28xx/em28xx-input.c
index 3598221..631e252 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -5,6 +5,7 @@
Markus Rechberger
Mauro Carvalho Chehab
Sascha Sommer
+ Copyright (C) 2012 Frank Schäfer
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
@@ -34,6 +35,8 @@
#define EM28XX_SBUTTON_QUERY_INTERVAL 500
#define EM28XX_R0C_USBSUSP_SNAPSHOT 0x20
+#define EM28XX_RC_QUERY_INTERVAL 100
+
static unsigned int ir_debug;
module_param(ir_debug, int, 0644);
MODULE_PARM_DESC(ir_debug, "enable debug messages [IR]");
@@ -67,13 +70,14 @@ struct em28xx_IR {
char name[32];
char phys[32];
- /* poll external decoder */
int polling;
struct delayed_work work;
unsigned int full_code:1;
unsigned int last_readcount;
u64 rc_type;
+ struct i2c_client *i2c_dev; /* external i2c IR receiver/decoder */
+
int (*get_key)(struct em28xx_IR *, struct em28xx_ir_poll_result *);
};
@@ -452,7 +456,7 @@ static int em28xx_ir_change_protocol(struc
[PATCH 1/6] em28xx: simplify device state tracking
DEV_INITIALIZED of enum em28xx_dev_state state is used nowhere and there is no
need for DEV_MISCONFIGURED, so remove this enum and use a boolean field
'disconnected' in the device struct instead.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-cards.c |5 ++---
drivers/media/usb/em28xx/em28xx-core.c |4 ++--
drivers/media/usb/em28xx/em28xx-dvb.c |4 ++--
drivers/media/usb/em28xx/em28xx-video.c | 12 +++-
drivers/media/usb/em28xx/em28xx.h | 12 ++--
5 Dateien geändert, 11 Zeilen hinzugefügt(+), 26 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index f5cac47..8496a06 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3501,11 +3501,10 @@ static void em28xx_usb_disconnect(struct usb_interface
*interface)
"deallocation are deferred on close.\n",
video_device_node_name(dev->vdev));
- dev->state |= DEV_MISCONFIGURED;
em28xx_uninit_usb_xfer(dev, dev->mode);
- dev->state |= DEV_DISCONNECTED;
+ dev->disconnected = 1;
} else {
- dev->state |= DEV_DISCONNECTED;
+ dev->disconnected = 1;
em28xx_release_resources(dev);
}
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index b10d959..6916e87 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -77,7 +77,7 @@ int em28xx_read_reg_req_len(struct em28xx *dev, u8 req, u16
reg,
int ret;
int pipe = usb_rcvctrlpipe(dev->udev, 0);
- if (dev->state & DEV_DISCONNECTED)
+ if (dev->disconnected)
return -ENODEV;
if (len > URB_MAX_CTRL_SIZE)
@@ -153,7 +153,7 @@ int em28xx_write_regs_req(struct em28xx *dev, u8 req, u16
reg, char *buf,
int ret;
int pipe = usb_sndctrlpipe(dev->udev, 0);
- if (dev->state & DEV_DISCONNECTED)
+ if (dev->disconnected)
return -ENODEV;
if ((len < 1) || (len > URB_MAX_CTRL_SIZE))
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index a70b19e..e206c2b 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -133,7 +133,7 @@ static inline int em28xx_dvb_urb_data_copy(struct em28xx
*dev, struct urb *urb)
if (!dev)
return 0;
- if ((dev->state & DEV_DISCONNECTED) || (dev->state & DEV_MISCONFIGURED))
+ if (dev->disconnected)
return 0;
if (urb->status < 0)
@@ -1320,7 +1320,7 @@ static int em28xx_dvb_fini(struct em28xx *dev)
if (dev->dvb) {
struct em28xx_dvb *dvb = dev->dvb;
- if (dev->state & DEV_DISCONNECTED) {
+ if (dev->disconnected) {
/* We cannot tell the device to sleep
* once it has been unplugged. */
if (dvb->fe[0])
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 4c1726d..824f298 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -442,7 +442,7 @@ static inline int em28xx_urb_data_copy(struct em28xx *dev,
struct urb *urb)
if (!dev)
return 0;
- if ((dev->state & DEV_DISCONNECTED) || (dev->state & DEV_MISCONFIGURED))
+ if (dev->disconnected)
return 0;
if (urb->status < 0)
@@ -790,16 +790,10 @@ handle:
static int check_dev(struct em28xx *dev)
{
- if (dev->state & DEV_DISCONNECTED) {
+ if (dev->disconnected) {
em28xx_errdev("v4l2 ioctl: device not present\n");
return -ENODEV;
}
-
- if (dev->state & DEV_MISCONFIGURED) {
- em28xx_errdev("v4l2 ioctl: device is misconfigured; "
- "close and open it again\n");
- return -EIO;
- }
return 0;
}
@@ -2068,7 +2062,7 @@ static int em28xx_v4l2_close(struct file *filp)
if (dev->users == 1) {
/* the device is already disconnect,
free the remaining resources */
- if (dev->state & DEV_DISCONNECTED) {
+ if (dev->disconnected) {
em28xx_release_resources(dev);
kfree(dev->alt_max_pkt_size_isoc);
mutex_unlock(&dev->lock);
diff --git a/drivers/media/usb/em28xx/em28xx.h
b/drivers/media/usb/em28xx/em28xx.h
index 062841e..7a40b92 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -437,13 +437,6 @@ struct em28xx_eeprom {
u8 string_idx_table;
};
-/* device states */
-enum em28xx_dev_state {
- DEV_INITIALIZED = 0x01,
- DEV_DISCONNE
[PATCH 2/6] em28xx: refactor the code in em28xx_usb_disconnect()
The main purpose of this patch is to move the call of em28xx_release_resources()
after the call of em28xx_close_extension().
This is necessary, because some resources might be needed/used by the extensions
fini() functions when they get closed.
Also mark the device as disconnected earlier in this function and unify the
em28xx_uninit_usb_xfer() calls for analog and digital mode.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-cards.c | 26 +++---
1 Datei geändert, 11 Zeilen hinzugefügt(+), 15 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 8496a06..40c3e45 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3478,6 +3478,8 @@ static void em28xx_usb_disconnect(struct usb_interface
*interface)
if (!dev)
return;
+ dev->disconnected = 1;
+
if (dev->is_audio_only) {
mutex_lock(&dev->lock);
em28xx_close_extension(dev);
@@ -3489,32 +3491,26 @@ static void em28xx_usb_disconnect(struct usb_interface
*interface)
flush_request_modules(dev);
- /* wait until all current v4l2 io is finished then deallocate
- resources */
mutex_lock(&dev->lock);
v4l2_device_disconnect(&dev->v4l2_dev);
if (dev->users) {
- em28xx_warn
- ("device %s is open! Deregistration and memory "
-"deallocation are deferred on close.\n",
-video_device_node_name(dev->vdev));
+ em28xx_warn("device %s is open! Deregistration and memory
deallocation are deferred on close.\n",
+ video_device_node_name(dev->vdev));
- em28xx_uninit_usb_xfer(dev, dev->mode);
- dev->disconnected = 1;
- } else {
- dev->disconnected = 1;
- em28xx_release_resources(dev);
+ em28xx_uninit_usb_xfer(dev, EM28XX_ANALOG_MODE);
+ em28xx_uninit_usb_xfer(dev, EM28XX_DIGITAL_MODE);
}
- /* free DVB isoc buffers */
- em28xx_uninit_usb_xfer(dev, EM28XX_DIGITAL_MODE);
+ em28xx_close_extension(dev);
+ /* NOTE: must be called BEFORE the resources are released */
+
+ if (!dev->users)
+ em28xx_release_resources(dev);
mutex_unlock(&dev->lock);
- em28xx_close_extension(dev);
-
if (!dev->users) {
kfree(dev->alt_max_pkt_size_isoc);
kfree(dev);
--
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 0/6] em28xx: make remote controls of devices with external IR IC working again
Support for remote controls of em28xx devices with external IR receiver/decoder IC are broken since a long time. This patch series makes them working again and fixes+improves several parts of the code. Frank Schäfer (6): em28xx: simplify device state tracking em28xx: refactor the code in em28xx_usb_disconnect() em28xx: make remote controls of devices with external IR IC working again em28xx: IR RC: get rid of function em28xx_get_key_terratec() em28xx: IR RC: move assignment of get_key functions from *_change_protocol() functions to em28xx_ir_init() ir-kbd-i2c: fix get_key_knc1() drivers/media/i2c/ir-kbd-i2c.c | 15 +-- drivers/media/usb/em28xx/em28xx-cards.c | 38 --- drivers/media/usb/em28xx/em28xx-core.c |4 +- drivers/media/usb/em28xx/em28xx-dvb.c |4 +- drivers/media/usb/em28xx/em28xx-i2c.c |1 + drivers/media/usb/em28xx/em28xx-input.c | 176 ++- drivers/media/usb/em28xx/em28xx-video.c | 12 +-- drivers/media/usb/em28xx/em28xx.h | 12 +-- 8 Dateien geändert, 111 Zeilen hinzugefügt(+), 151 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
Re: [PATCH] [media] coda: Fix build due to iram.h rename
Em Mon, 17 Dec 2012 10:37:14 +0100 Sascha Hauer escreveu: > On Wed, Nov 14, 2012 at 11:04:42AM -0200, Fabio Estevam wrote: > > commit c045e3f13 (ARM: imx: include iram.h rather than mach/iram.h) changed > > the > > location of iram.h, which causes the following build error when building > > the coda > > driver: > > > > drivers/media/platform/coda.c:27:23: error: mach/iram.h: No such file or > > directory > > drivers/media/platform/coda.c: In function 'coda_probe': > > drivers/media/platform/coda.c:2000: error: implicit declaration of function > > 'iram_alloc' > > drivers/media/platform/coda.c:2001: warning: assignment makes pointer from > > integer without a cast > > drivers/media/platform/coda.c: In function 'coda_remove': > > drivers/media/platform/coda.c:2024: error: implicit declaration of function > > 'iram_free > > > > Since the content of iram.h is not imx specific, move it to > > include/linux/iram.h > > instead. > > Generally we need a fix for this, but: > > > diff --git a/arch/arm/mach-imx/iram.h b/include/linux/iram.h > > similarity index 100% > > rename from arch/arm/mach-imx/iram.h > > rename to include/linux/iram.h > > We shouldn't introduce a file include/linux/iram.h which is purely i.MX > specific. The name is far too generic. I would rather suggest > include/linux/platform_data/imx-iram.h (Although it's not exactly > platform_data, so I'm open for better suggestions). > > As a side note this i.MX specific iram stuff (hopefully) is obsolete > after the next merge window as Philip already has patches for a generic > iram allocator which didn't make it into this merge window. Hi Sasha, This compilation breakage seems to still be happening. Just tested here with arm32 "allmodconfig", on a tree based on Linus one, with -next and -media patches applied on it: drivers/media//platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory compilation terminated. I don't mind how this would be named, but this should be fixed somehow ;) 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: [GIT PULL FOR v3.9] separate Montage ts2020 from ds3000 and rs2000, support for new TeVii cards
Hi Igor, Em Mon, 24 Dec 2012 11:23:56 +0300 "Igor M. Liplianin" escreveu: > The following changes since commit 8b2aea7878f64814544d0527c659011949d52358: > > [media] em28xx: prefer bulk mode on webcams (2012-12-23 17:24:30 -0200) > > are available in the git repository at: > > git://git.linuxtv.org/liplianin/media_tree.git ts2020_v3.9 > > for you to fetch changes up to 2ff52e6f487c2ee841f3df9709d1b4e4416a1b15: > > ts2020: separate from m88rs2000 (2012-12-24 01:26:12 +0300) > > > Igor M. Liplianin (4): > Tevii S421 and S632 support > m88rs2000: SNR BER implemented > ds3000: lock led procedure added > ts2020: separate from m88rs2000 You forgot to add your SOB and patch descriptions on the above patches. > > Konstantin Dimitrov (3): > ds3000: remove ts2020 tuner related code > ts2020: add ts2020 tuner driver > make the other drivers take use of the new ts2020 driver Those now looks correct. So, I'm applying them. 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 01/23] uvc: Replace memcpy with struct assignment
Mauro, On Tue, Oct 23, 2012 at 4:57 PM, Ezequiel Garcia wrote: > This kind of memcpy() is error-prone. Its replacement with a struct > assignment is prefered because it's type-safe and much easier to read. > > Found by coccinelle. Hand patched and reviewed. > Tested by compilation only. > > A simplified version of the semantic match that finds this problem is as > follows: (http://coccinelle.lip6.fr/) > > // > @@ > identifier struct_name; > struct struct_name to; > struct struct_name from; > expression E; > @@ > -memcpy(&(to), &(from), E); > +to = from; > // > > Cc: Laurent Pinchart > Signed-off-by: Peter Senna Tschudin > Signed-off-by: Ezequiel Garcia > --- > drivers/media/usb/uvc/uvc_v4l2.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/usb/uvc/uvc_v4l2.c > b/drivers/media/usb/uvc/uvc_v4l2.c > index f00db30..4fc8737 100644 > --- a/drivers/media/usb/uvc/uvc_v4l2.c > +++ b/drivers/media/usb/uvc/uvc_v4l2.c > @@ -314,7 +314,7 @@ static int uvc_v4l2_set_format(struct uvc_streaming > *stream, > goto done; > } > > - memcpy(&stream->ctrl, &probe, sizeof probe); > + stream->ctrl = probe; > stream->cur_format = format; > stream->cur_frame = frame; > > @@ -386,7 +386,7 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming > *stream, > return -EBUSY; > } > > - memcpy(&probe, &stream->ctrl, sizeof probe); > + probe = stream->ctrl; > probe.dwFrameInterval = > uvc_try_frame_interval(stream->cur_frame, interval); > > @@ -397,7 +397,7 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming > *stream, > return ret; > } > > - memcpy(&stream->ctrl, &probe, sizeof probe); > + stream->ctrl = probe; > mutex_unlock(&stream->mutex); > > /* Return the actual frame period. */ > -- > 1.7.4.4 > It seems you've marked this one as "Changes requested" [1]. However, Laurent didn't request any change, but just pointed out we missed one memcpy replacement candidate. I believe it's safe to apply the patch (together with the other 20 patches) and we can fix the missing spot in another patch. Thanks, -- Ezequiel [1] http://patchwork.linuxtv.org/patch/15142/ -- 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] omap3isp: Add support for interlaced input data
Em Tue, 25 Dec 2012 22:05:48 +0100
Laurent Pinchart escreveu:
> Hi William,
>
> Thanks for the patch.
Btw, you missed to add a Signed-off-by: line on it.
>
> On Monday 17 December 2012 18:12:19 William Swanson wrote:
> > If the remote video sensor reports an interlaced video mode, the CCDC block
> > should configure itself appropriately.
>
> What will the CCDC do in that case ? Will it capture fields or frames to
> memory ? If frames, what's the field layout ? You will most likely need to
> modify ispvideo.c as well, to support interlacing in the V4L2 API, and
> possibly add interlaced formats support to the media bus API.
>
> > ---
> > drivers/media/platform/omap3isp/ispccdc.c | 16 ++--
> > include/media/omap3isp.h |3 +++
> > 2 files changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/omap3isp/ispccdc.c
> > b/drivers/media/platform/omap3isp/ispccdc.c index 60e60aa..5443ef4 100644
> > --- a/drivers/media/platform/omap3isp/ispccdc.c
> > +++ b/drivers/media/platform/omap3isp/ispccdc.c
> > @@ -970,10 +970,11 @@ void omap3isp_ccdc_max_rate(struct isp_ccdc_device
> > *ccdc, * @ccdc: Pointer to ISP CCDC device.
> > * @pdata: Parallel interface platform data (may be NULL)
> > * @data_size: Data size
> > + * @interlaced: Use interlaced mode instead of progressive mode
> > */
> > static void ccdc_config_sync_if(struct isp_ccdc_device *ccdc,
> > struct isp_parallel_platform_data *pdata,
> > - unsigned int data_size)
> > + unsigned int data_size, bool interlaced)
> > {
> > struct isp_device *isp = to_isp_device(ccdc);
> > const struct v4l2_mbus_framefmt *format;
> > @@ -1004,9 +1005,15 @@ static void ccdc_config_sync_if(struct
> > isp_ccdc_device *ccdc, break;
> > }
> >
> > + if (interlaced)
> > + syn_mode |= ISPCCDC_SYN_MODE_FLDMODE;
> > +
> > if (pdata && pdata->data_pol)
> > syn_mode |= ISPCCDC_SYN_MODE_DATAPOL;
> >
> > + if (pdata && pdata->fld_pol)
> > + syn_mode |= ISPCCDC_SYN_MODE_FLDPOL;
> > +
> > if (pdata && pdata->hs_pol)
> > syn_mode |= ISPCCDC_SYN_MODE_HDPOL;
> >
> > @@ -,6 +1118,7 @@ static void ccdc_configure(struct isp_ccdc_device
> > *ccdc) const struct v4l2_rect *crop;
> > const struct isp_format_info *fmt_info;
> > struct v4l2_subdev_format fmt_src;
> > + bool src_interlaced = false;
> > unsigned int depth_out;
> > unsigned int depth_in = 0;
> > struct media_pad *pad;
> > @@ -1132,6 +1140,10 @@ static void ccdc_configure(struct isp_ccdc_device
> > *ccdc) fmt_src.pad = pad->index;
> > fmt_src.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> > if (!v4l2_subdev_call(sensor, pad, get_fmt, NULL, &fmt_src)) {
> > + if (fmt_src.format.field == V4L2_FIELD_INTERLACED ||
> > + fmt_src.format.field == V4L2_FIELD_INTERLACED_TB ||
> > + fmt_src.format.field == V4L2_FIELD_INTERLACED_BT)
> > + src_interlaced = true;
> > fmt_info = omap3isp_video_format_info(fmt_src.format.code);
> > depth_in = fmt_info->width;
> > }
> > @@ -1150,7 +1162,7 @@ static void ccdc_configure(struct isp_ccdc_device
> > *ccdc)
> >
> > omap3isp_configure_bridge(isp, ccdc->input, pdata, shift, bridge);
> >
> > - ccdc_config_sync_if(ccdc, pdata, depth_out);
> > + ccdc_config_sync_if(ccdc, pdata, depth_out, src_interlaced);
> >
> > syn_mode = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
> >
> > diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
> > index 9584269..32d85c2 100644
> > --- a/include/media/omap3isp.h
> > +++ b/include/media/omap3isp.h
> > @@ -57,6 +57,8 @@ enum {
> > * ISP_LANE_SHIFT_6 - CAMEXT[13:6] -> CAM[7:0]
> > * @clk_pol: Pixel clock polarity
> > * 0 - Sample on rising edge, 1 - Sample on falling edge
> > + * @fld_pol: Field identification signal polarity
> > + * 0 - Active high, 1 - Active low
> > * @hs_pol: Horizontal synchronization polarity
> > * 0 - Active high, 1 - Active low
> > * @vs_pol: Vertical synchronization polarity
> > @@ -67,6 +69,7 @@ enum {
> > struct isp_parallel_platform_data {
> > unsigned int data_lane_shift:2;
> > unsigned int clk_pol:1;
> > + unsigned int fld_pol:1;
> > unsigned int hs_pol:1;
> > unsigned int vs_pol:1;
> > unsigned int data_pol:1;
--
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 V3 01/15] [media] marvell-ccic: use internal variable replace global frame stats variable
Em Sun, 16 Dec 2012 08:36:59 -0700 Jonathan Corbet escreveu: > On Sat, 15 Dec 2012 17:57:50 +0800 > Albert Wang wrote: > > > This patch replaces the global frame stats variables by using > > internal variables in mcam_camera structure. > > This one seems fine. Someday it might be nice to have proper stats > rather than my debugging hack, complete with a nice sysfs interface and > all that. > > Acked-by: Jonathan Corbet While I understand that a v4 will popup, due to some comments done on the other patches on this v3, this patch seems pretty much independent. So, I'll just apply it right now, and tag the others as "changes_requested" at patchwork. 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: [RFC v2 0/5] Common Display Framework
On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer wrote:
> On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote:
>> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
>> wrote:
>> > Hi Rob,
>> >
>> > On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
>> >> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote:
>> >> >> Many developers showed interest in the first RFC, and I've had the
>> >> >> opportunity to discuss it with most of them. I would like to thank (in
>> >> >> no particular order) Tomi Valkeinen for all the time he spend helping
>> >> >> me
>> >> >> to draft v2, Marcus Lorentzon for his useful input during Linaro
>> >> >> Connect
>> >> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to
>> >> >> discuss this topic.
>> >> >
>> >> > So this might be a bit off topic but this whole CDF triggered me
>> >> > looking at stuff I generally avoid:
>> >> >
>> >> > The biggest problem I'm having currently with the whole ARM graphics
>> >> > and output world is the proliferation of platform drivers for every
>> >> > little thing. The whole ordering of operations with respect to things
>> >> > like suspend/resume or dynamic power management is going to be a real
>> >> > nightmare if there are dependencies between the drivers. How do you
>> >> > enforce ordering of s/r operations between all the various components?
>> >>
>> >> I tend to think that sub-devices are useful just to have a way to probe hw
>> >> which may or may not be there, since on ARM we often don't have any
>> >> alternative.. but beyond that, suspend/resume, and other life-cycle
>> >> aspects,
>> >> they should really be treated as all one device. Especially to avoid
>> >> undefined suspend/resume ordering.
>> >
>> > I tend to agree, except that I try to reuse the existing PM infrastructure
>> > when possible to avoid reinventing the wheel. So far handling
>> > suspend/resume
>> > ordering related to data busses in early suspend/late resume operations and
>> > allowing the Linux PM core to handle control busses using the Linux device
>> > tree worked pretty well.
>> >
>> >> CDF or some sort of mechanism to share panel drivers between drivers is
>> >> useful. Keeping it within drm, is probably a good idea, if nothing else
>> >> to
>> >> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and
>> >> avoid dealing with merging changes across multiple trees. Treating them
>> >> more
>> >> like shared libraries and less like sub-devices which can be dynamically
>> >> loaded/unloaded (ie. they should be not built as separate modules or
>> >> suspend/resumed or probed/removed independently of the master driver) is a
>> >> really good idea to avoid uncovering nasty synchronization issues later
>> >> (remove vs modeset or pageflip) or surprising userspace in bad ways.
>> >
>> > We've tried that in V4L2 years ago and realized that the approach led to a
>> > dead-end, especially when OF/DT got involved. With DT-based device probing,
>> > I2C camera sensors started getting probed asynchronously to the main camera
>> > device, as they are children of the I2C bus master. We will have similar
>> > issues with I2C HDMI transmitters or panels, so we should be prepared for
>> > it.
>>
>> What I've done to avoid that so far is that the master device
>> registers the drivers for it's output sub-devices before registering
>> it's own device. At least this way I can control that they are probed
>> first. Not the prettiest thing, but avoids even uglier problems.
>
> This implies that the master driver knows all potential subdevices,
> something which is not true for SoCs which have external i2c encoders
> attached to unrelated i2c controllers.
well, it can be brute-forced.. ie. drm driver calls common
register_all_panels() fxn, which, well, registers all the
panel/display subdev's based on their corresponding CONFIG_FOO_PANEL
defines. If you anyways aren't building the panels as separate
modules, that would work. Maybe not the most *elegant* approach, but
simple and functional.
I guess it partly depends on the structure in devicetree. If you are
assuming that the i2c encoder belongs inside the i2c bus, like:
&i2cN {
foo-i2c-encoder {
};
};
and you are letting devicetree create the devices, then it doesn't
quite work. I'm not entirely convinced you should do it that way.
Really any device like that is going to be hooked up to at least a
couple busses.. i2c, some sort of bus carrying pixel data, maybe some
gpio's, etc. So maybe makes more sense for a virtual drm/kms bus, and
then use phandle stuff to link it to the various other busses it
needs:
mydrmdev {
foo-i2c-encoder {
i2c = <&i2cN>;
gpio = <&gpioM 2 3>
...
};
};
ok, admittedly that is a bit different from other proposals about how
this all fits in devicetree.. but otoh, I'm not a huge believer in
letting something that is supposed to make life easier (DT), actually
make things harder or mo
Re: [RFC v2 0/5] Common Display Framework
On Thu, Dec 27, 2012 at 10:04:22AM -0600, Rob Clark wrote: > On Mon, Dec 24, 2012 at 11:27 AM, Laurent Pinchart > wrote: > > On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote: > >> It just seems to me that, at least from a DRM/KMS perspective, adding > >> another layer (=CDF) for HDMI or DP (or legacy outputs) would be > >> overengineering it. They are pretty well standardized, and I don't see > >> there > >> would be a need to write multiple display drivers for them. Each display > >> controller has one, and can easily handle any chip specific requirements > >> right there. It's my gut feeling that an additional framework would just > >> get > >> in the way. Perhaps there could be more common HDMI/DP helper style code in > >> DRM to reduce overlap across KMS drivers, but that's another thing. > >> > >> So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM > >> perspective? Or, put another way, is it more of an alternative to using > >> DRM? > >> Please enlighten me if there's some real benefit here that I fail to see! > > > > As Rob pointed out, you can have external HDMI/DP encoders, and even > > internal > > HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at > > sharing a single driver between SoCs and boards for a given HDMI/DP encoder. > > just fwiw, drm already has something a bit like this.. the i2c > encoder-slave. With support for a couple external i2c encoders which > could in theory be shared between devices. The problem with this code is that it only works when the i2c device is registered by a master driver. Once the i2c device comes from the devicetree there is no possibility to find it. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 0/5] Common Display Framework
On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote: > On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart > wrote: > > Hi Rob, > > > > On Tuesday 18 December 2012 00:21:32 Rob Clark wrote: > >> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote: > >> >> Many developers showed interest in the first RFC, and I've had the > >> >> opportunity to discuss it with most of them. I would like to thank (in > >> >> no particular order) Tomi Valkeinen for all the time he spend helping me > >> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect > >> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to > >> >> discuss this topic. > >> > > >> > So this might be a bit off topic but this whole CDF triggered me > >> > looking at stuff I generally avoid: > >> > > >> > The biggest problem I'm having currently with the whole ARM graphics > >> > and output world is the proliferation of platform drivers for every > >> > little thing. The whole ordering of operations with respect to things > >> > like suspend/resume or dynamic power management is going to be a real > >> > nightmare if there are dependencies between the drivers. How do you > >> > enforce ordering of s/r operations between all the various components? > >> > >> I tend to think that sub-devices are useful just to have a way to probe hw > >> which may or may not be there, since on ARM we often don't have any > >> alternative.. but beyond that, suspend/resume, and other life-cycle > >> aspects, > >> they should really be treated as all one device. Especially to avoid > >> undefined suspend/resume ordering. > > > > I tend to agree, except that I try to reuse the existing PM infrastructure > > when possible to avoid reinventing the wheel. So far handling suspend/resume > > ordering related to data busses in early suspend/late resume operations and > > allowing the Linux PM core to handle control busses using the Linux device > > tree worked pretty well. > > > >> CDF or some sort of mechanism to share panel drivers between drivers is > >> useful. Keeping it within drm, is probably a good idea, if nothing else to > >> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and > >> avoid dealing with merging changes across multiple trees. Treating them > >> more > >> like shared libraries and less like sub-devices which can be dynamically > >> loaded/unloaded (ie. they should be not built as separate modules or > >> suspend/resumed or probed/removed independently of the master driver) is a > >> really good idea to avoid uncovering nasty synchronization issues later > >> (remove vs modeset or pageflip) or surprising userspace in bad ways. > > > > We've tried that in V4L2 years ago and realized that the approach led to a > > dead-end, especially when OF/DT got involved. With DT-based device probing, > > I2C camera sensors started getting probed asynchronously to the main camera > > device, as they are children of the I2C bus master. We will have similar > > issues with I2C HDMI transmitters or panels, so we should be prepared for > > it. > > What I've done to avoid that so far is that the master device > registers the drivers for it's output sub-devices before registering > it's own device. At least this way I can control that they are probed > first. Not the prettiest thing, but avoids even uglier problems. This implies that the master driver knows all potential subdevices, something which is not true for SoCs which have external i2c encoders attached to unrelated i2c controllers. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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] m920x: Fix CodingStyle issues
Fix CodingStyle issues introduced by the last patch Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/m920x.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/media/usb/dvb-usb/m920x.c b/drivers/media/usb/dvb-usb/m920x.c index bddd763..a70c5ea 100644 --- a/drivers/media/usb/dvb-usb/m920x.c +++ b/drivers/media/usb/dvb-usb/m920x.c @@ -191,10 +191,14 @@ static int m920x_rc_query(struct dvb_usb_device *d, u32 *event, int *state) if (!rc_state) return -ENOMEM; - if ((ret = m920x_read(d->udev, M9206_CORE, 0x0, M9206_RC_STATE, rc_state, 1)) != 0) + ret = m920x_read(d->udev, M9206_CORE, 0x0, M9206_RC_STATE, +rc_state, 1); + if (ret != 0) goto out; - if ((ret = m920x_read(d->udev, M9206_CORE, 0x0, M9206_RC_KEY, rc_state + 1, 1)) != 0) + ret = m920x_read(d->udev, M9206_CORE, 0x0, M9206_RC_KEY, +rc_state + 1, 1); + if (ret != 0) goto out; m920x_parse_rc_state(d, rc_state[0], state); -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: 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:Thu Dec 27 19:00:30 CET 2012 git hash:30ad64b8ac539459f8975aa186421ef3db0bb5cb gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-i686: OK linux-git-m32r: ERRORS linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: ERRORS linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: ERRORS linux-3.4-i686: ERRORS linux-3.5-i686: ERRORS linux-3.6-i686: ERRORS linux-3.7-i686: ERRORS linux-3.8-rc1-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: ERRORS linux-3.4-x86_64: ERRORS linux-3.5-x86_64: ERRORS linux-3.6-x86_64: ERRORS linux-3.7-x86_64: ERRORS linux-3.8-rc1-x86_64: ERRORS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] ttpci: Fix a missing Kconfig dependency
Fix a Kconfig warning that appears with allmodconfig on arm: warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C) Signed-off-by: Mauro Carvalho Chehab --- drivers/media/Kconfig | 6 ++ drivers/media/pci/ttpci/Kconfig | 5 - 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 4ef0d80..4d9b4c2 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -135,6 +135,12 @@ config DVB_NET You may want to disable the network support on embedded devices. If unsure say Y. +# This Kconfig option is used by both PCI and USB drivers +config TTPCI_EEPROM +tristate +depends on I2C +default n + source "drivers/media/dvb-core/Kconfig" comment "Media drivers" diff --git a/drivers/media/pci/ttpci/Kconfig b/drivers/media/pci/ttpci/Kconfig index 314e417..0dcb8cd 100644 --- a/drivers/media/pci/ttpci/Kconfig +++ b/drivers/media/pci/ttpci/Kconfig @@ -1,8 +1,3 @@ -config TTPCI_EEPROM - tristate - depends on I2C - default n - config DVB_AV7110 tristate "AV7110 cards" depends on DVB_CORE && PCI && I2C -- 1.7.11.7 -- 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] [media] omap: Fix Kconfig dependencies on OMAP2
Resolves the following warning that appears with allmodconfig on -arm: warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS) Signed-off-by: Mauro Carvalho Chehab --- drivers/media/platform/omap/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/omap/Kconfig b/drivers/media/platform/omap/Kconfig index 390ab09..37ad446 100644 --- a/drivers/media/platform/omap/Kconfig +++ b/drivers/media/platform/omap/Kconfig @@ -6,7 +6,7 @@ config VIDEO_OMAP2_VOUT depends on ARCH_OMAP2 || ARCH_OMAP3 select VIDEOBUF_GEN select VIDEOBUF_DMA_CONTIG - select OMAP2_DSS + select OMAP2_DSS if HAS_IOMEM && ARCH_OMAP2PLUS select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3 select VIDEO_OMAP2_VOUT_VRFB if VIDEO_OMAP2_VOUT && OMAP2_VRFB default n -- 1.7.11.7 -- 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 0/5] Common Display Framework
On Mon, Dec 24, 2012 at 11:35 AM, Laurent Pinchart wrote: > On Wednesday 19 December 2012 09:26:40 Rob Clark wrote: >> And, there are also external HDMI encoders (for example connected over >> i2c) that can also be shared between boards. So I think there will be >> a number of cases where CDF is appropriate for HDMI drivers. Although >> trying to keep this all independent of DRM (as opposed to just >> something similar to what drivers/gpu/i2c is today) seems a bit >> overkill for me. Being able to use the helpers in drm and avoiding an >> extra layer of translation seems like the better option to me. So my >> vote would be drivers/gpu/cdf. > > I don't think there will be any need for translation (except perhaps between > the DRM mode structures and the common video mode structure that is being > discussed). Add a drm_ prefix to the existing CDF functions and structures, > and there you go :-) well, and translation for any properties that we'd want to expose to userspace, etc, etc.. I see there being a big potential for a lot of needless glue BR, -R > The reason why I'd like to keep CDF separate from DRM (or at least not > requiring a drm_device) is that HDMI/DP encoders can be used by pure V4L2 > drivers. > >> > For DSI panels (or DSI-to-whatever bridges) it's of course another >> > story. You typically need a panel specific driver. And here I see the >> > main point of the whole CDF: decoupling display controllers and the >> > panel drivers, and sharing panel (and converter chip) specific drivers >> > across display controllers. Making it easy to write new drivers, as >> > there would be a model to follow. I'm definitely in favour of coming up >> > with some framework that would tackle that. > > -- > Regards, > > Laurent Pinchart > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 0/5] Common Display Framework
On Mon, Dec 24, 2012 at 11:27 AM, Laurent Pinchart wrote: > On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote: >> It just seems to me that, at least from a DRM/KMS perspective, adding >> another layer (=CDF) for HDMI or DP (or legacy outputs) would be >> overengineering it. They are pretty well standardized, and I don't see there >> would be a need to write multiple display drivers for them. Each display >> controller has one, and can easily handle any chip specific requirements >> right there. It's my gut feeling that an additional framework would just get >> in the way. Perhaps there could be more common HDMI/DP helper style code in >> DRM to reduce overlap across KMS drivers, but that's another thing. >> >> So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM >> perspective? Or, put another way, is it more of an alternative to using DRM? >> Please enlighten me if there's some real benefit here that I fail to see! > > As Rob pointed out, you can have external HDMI/DP encoders, and even internal > HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at > sharing a single driver between SoCs and boards for a given HDMI/DP encoder. just fwiw, drm already has something a bit like this.. the i2c encoder-slave. With support for a couple external i2c encoders which could in theory be shared between devices. BR, -R -- 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 0/5] Common Display Framework
On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart wrote: > On the topic of discussions, would anyone be interested in a > BoF/brainstorming/whatever session during the FOSDEM ? I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it looks like at least Daniel will be there. If enough others are, it could be a good idea. BR, -R -- 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 0/5] Common Display Framework
On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart wrote: > Hi Rob, > > On Tuesday 18 December 2012 00:21:32 Rob Clark wrote: >> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote: >> >> Many developers showed interest in the first RFC, and I've had the >> >> opportunity to discuss it with most of them. I would like to thank (in >> >> no particular order) Tomi Valkeinen for all the time he spend helping me >> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect >> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to >> >> discuss this topic. >> > >> > So this might be a bit off topic but this whole CDF triggered me >> > looking at stuff I generally avoid: >> > >> > The biggest problem I'm having currently with the whole ARM graphics >> > and output world is the proliferation of platform drivers for every >> > little thing. The whole ordering of operations with respect to things >> > like suspend/resume or dynamic power management is going to be a real >> > nightmare if there are dependencies between the drivers. How do you >> > enforce ordering of s/r operations between all the various components? >> >> I tend to think that sub-devices are useful just to have a way to probe hw >> which may or may not be there, since on ARM we often don't have any >> alternative.. but beyond that, suspend/resume, and other life-cycle aspects, >> they should really be treated as all one device. Especially to avoid >> undefined suspend/resume ordering. > > I tend to agree, except that I try to reuse the existing PM infrastructure > when possible to avoid reinventing the wheel. So far handling suspend/resume > ordering related to data busses in early suspend/late resume operations and > allowing the Linux PM core to handle control busses using the Linux device > tree worked pretty well. > >> CDF or some sort of mechanism to share panel drivers between drivers is >> useful. Keeping it within drm, is probably a good idea, if nothing else to >> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and >> avoid dealing with merging changes across multiple trees. Treating them more >> like shared libraries and less like sub-devices which can be dynamically >> loaded/unloaded (ie. they should be not built as separate modules or >> suspend/resumed or probed/removed independently of the master driver) is a >> really good idea to avoid uncovering nasty synchronization issues later >> (remove vs modeset or pageflip) or surprising userspace in bad ways. > > We've tried that in V4L2 years ago and realized that the approach led to a > dead-end, especially when OF/DT got involved. With DT-based device probing, > I2C camera sensors started getting probed asynchronously to the main camera > device, as they are children of the I2C bus master. We will have similar > issues with I2C HDMI transmitters or panels, so we should be prepared for it. What I've done to avoid that so far is that the master device registers the drivers for it's output sub-devices before registering it's own device. At least this way I can control that they are probed first. Not the prettiest thing, but avoids even uglier problems. > On PC hardware the I2C devices are connected to an I2C master provided by the > GPU, but on embedded devices they are usually connected to an independent I2C > master. We thus can't have a single self-contained driver that controls > everything internally, and need to interface with the rest of the SoC drivers. > > I agree that probing/removing devices independently of the master driver can > lead to bad surprises, which is why I want to establish clear rules in CDF > regarding what can and can't be done with display entities. Reference counting > will be one way to make sure that devices don't disappear all of a sudden. That at least helps cover some issues.. although it doesn't really help userspace confusion. Anyways, with enough work perhaps all problems could be solved.. otoh, there are plenty of other important problems to solve in the world of gpus and kms, so my preference is always not to needlessly over-complicate CDF and instead leave some time for other things BR, -R >> > The other thing I'd like you guys to do is kill the idea of fbdev and >> > v4l drivers that are "shared" with the drm codebase, really just >> > implement fbdev and v4l on top of the drm layer, some people might >> > think this is some sort of maintainer thing, but really nothing else >> > makes sense, and having these shared display frameworks just to avoid >> > having using drm/kms drivers seems totally pointless. Fix the drm >> > fbdev emulation if an fbdev interface is needed. But creating a fourth >> > framework because our previous 3 frameworks didn't work out doesn't >> > seem like a situation I want to get behind too much. >> >> yeah, let's not have multiple frameworks to do the same thing.. For fbdev, >> it is pretty clear that it is a dead end. For v4l2 (subdev+mcf), it is >> perha
Re: [RFC v2 0/5] Common Display Framework
Hi Laurent, On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote: > Hi Tomasz, > > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: > > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: > > > On 17 December 2012 20:55, Laurent Pinchart wrote: > > > > Hi Vikas, > > > > > > > > Sorry for the late reply. I now have more time to work on CDF, so > > > > delays should be much shorter. > > > > > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > > > > Hi Laurent, > > > > > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, > > > > > what > > > > > I found is that, the exynos display controller is MIPI DSI based > > > > > controller. > > > > > > > > > > But if I look at CDF patches, it has only support for MIPI DBI > > > > > based > > > > > Display controller. > > > > > > > > > > So my question is, do we have any generic framework for MIPI DSI > > > > > based display controller? basically I wanted to know, how to go > > > > > about > > > > > porting CDF for such kind of display controller. > > > > > > > > MIPI DSI support is not available yet. The only reason for that is > > > > that I don't have any MIPI DSI hardware to write and test the code > > > > with :-) > > > > > > > > The common display framework should definitely support MIPI DSI. I > > > > think the existing MIPI DBI code could be used as a base, so the > > > > implementation shouldn't be too high. > > > > > > > > Yeah, i was also thinking in similar lines, below is my though for > > > > MIPI DSI support in CDF. > > > > > > o MIPI DSI support as part of CDF framework will expose > > > § mipi_dsi_register_device(mpi_device) (will be called > > > mach-xxx-dt.c > > > file ) > > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called > > > from > > > platform specific init driver call ) > > > ·bus ops will be > > > o read data > > > o write data > > > o write command > > > § MIPI DSI will be registered as bus_register() > > > > > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) > > > will > > > initialize the MIPI DSI HW IP. > > > > > > This probe will also parse the DT file for MIPI DSI based panel, add > > > the panel device (device_add() ) to kernel and register the display > > > entity with its control and video ops with CDF. > > > > > > I can give this a try. > > > > I am currently in progress of reworking Exynos MIPI DSIM code and > > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I > > have most of the work done, I have just to solve several remaining > > problems. > Do you already have code that you can publish ? I'm particularly > interested (and I think Tomi Valkeinen would be as well) in looking at > the DSI operations you expose to DSI sinks (panels, transceivers, ...). Well, I'm afraid this might be little below your expectations, but here's an initial RFC of the part defining just the DSI bus. I need a bit more time for patches for Exynos MIPI DSI master and s6e8ax0 LCD. The implementation is very simple and heavily based on your MIPI DBI support and existing Exynos MIPI DSIM framework. Provided operation set is based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately this is my only source of information about MIPI DSI. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform >From bad07d8bdce0ff76cbc81a9da597c0d01e5244f7 Mon Sep 17 00:00:00 2001 From: Tomasz Figa Date: Thu, 27 Dec 2012 12:36:15 +0100 Subject: [RFC] video: display: Add generic MIPI DSI bus Signed-off-by: Tomasz Figa --- drivers/video/display/Kconfig| 4 + drivers/video/display/Makefile | 1 + drivers/video/display/mipi-dsi-bus.c | 214 +++ include/video/display.h | 1 + include/video/mipi-dsi-bus.h | 98 5 files changed, 318 insertions(+) create mode 100644 drivers/video/display/mipi-dsi-bus.c create mode 100644 include/video/mipi-dsi-bus.h diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig index 13b6aaf..dbaff9d 100644 --- a/drivers/video/display/Kconfig +++ b/drivers/video/display/Kconfig @@ -9,6 +9,10 @@ config DISPLAY_MIPI_DBI tristate default n +config DISPLAY_MIPI_DSI + tristate + default n + config DISPLAY_PANEL_DPI tristate "DPI (Parallel) Display Panels" ---help--- diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile index 482bec7..429b3ac8 100644 --- a/drivers/video/display/Makefile +++ b/drivers/video/display/Makefile @@ -1,5 +1,6 @@ obj-$(CONFIG_DISPLAY_CORE) += display-core.o obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o +obj-$(CONFIG_DISPLAY_MIPI_DSI) += mipi-dsi-bus.o obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o diff --git a/drivers/video/display/mipi-d
Re: HD-PVR fails consistently on Linux, works on Windows
On 17 Oct 2012, at 18:54, Keith Pyle wrote: > On 09/26/12 21:42, Keith Pyle wrote: > > I recently purchased a Hauppauge HD-PVR (the 1212 version, label on bottom > > 49001LF, Rev F2). I have consistent capture failures on Linux where data > > from > > the device simply stops, generally within a few minutes of starting a > > capture. > > Yet, the device works flawlessly on Windows with the same USB and component > > cables, same power supply, and same physical position. This suggests that > > the > > device itself has acceptable power, is not overheating, etc. I'll detail > > below > > the testing I've done thus far and would appreciate any suggestions on how > > to > > further test or address the problem. > > Here's some interesting new information. On noticing that the 3.6 kernel > included several USB related commits, I updated the kernel of my test system > (MSI X58 Pro-E) from 3.5.4 to 3.6.2. I ran a series of capture tests with > firmware 0x1e and all other variables exactly as before - same USB cable, > port, > physical position, etc. I have 20 successful 1-hour captures and 1 failure. We have run extensive tests comparing the HD PVR's stability on kernel 3.6.6 vs. kernel <3.6; having a single HD PVR connected to the PC vs. multiple HD PVRs on the same USB controller; adding better heatsinks; running irqbalance. None of these made any difference. The only significant improvement we found was from removing the lid and adding fans pointing directly at the circuit board. Even this didn't cure the problem completely, it only increased the time-to-failure. For details, including the time-to-failure measurements and the shell script we used, see http://stb-tester.com/hardware.html#hauppauge-hd-pvr Note that our workload is quite different from yours: An individual recording typically lasts 2-10 minutes, but as soon as it has finished we start another one, so we are stopping and starting all day. Hauppauge have hinted that under these conditions the HD PVR is unreliable on Windows too, which implies a problem in the hardware or firmware, rather than the Linux hdpvr driver. Dave. -- 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: [PATCHv2 0/9] dvb-usb/m920x: support VP-7049 DVB-T USB Stick and other fixes
On Mon, 10 Dec 2012 22:37:08 +0100 Antonio Ospite wrote: > Hi, > Ping. > Here is a second iteration of the patchset to add support for the > Twinhan VP7049 DVB-T USB Stick, v1 is at: > http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/56714 > > Patches from 1 to 7 are small fixes or refactorings to make the addition > of the new device easier. > > Patches 8 and 9 are specific to the device. > > Changes since v1: > - Patches 1-7: more refactorings > > - Patch 9: don't add a .pre_init callback to dvb-usb, Antti convinced > me that the initialization is better done just before the frontend > attach is called. > > - Patch 9: use the RC core infrastructure, the keymap I needed was > already here: I could reuse the rc-twinhan1027 driver without > touching anything in it. > > Again I deliberately ignored some checkpatch.pl warnings and errors > because I preferred to stick with the code style in use in the > dvb-usb/m920x files, let me know if you want me to do otherwise. > > Thanks, >Antonio > > Antonio Ospite (9): > [media] dvb-usb: fix indentation of a for loop > [media] m920x: fix a typo in a comment > [media] m920x: factor out a m920x_write_seq() function > [media] m920x: factor out a m920x_parse_rc_state() function > [media] m920x: avoid repeating RC state parsing at each keycode > [media] m920x: introduce m920x_rc_core_query() > [media] m920x: send the RC init sequence also when rc.core is used > [media] get_dvb_firmware: add entry for the vp7049 firmware > [media] m920x: add support for the VP-7049 Twinhan DVB-T USB Stick > > Documentation/dvb/get_dvb_firmware | 15 +- > drivers/media/dvb-core/dvb-usb-ids.h |1 + > drivers/media/usb/dvb-usb/dvb-usb-init.c | 60 +++ > drivers/media/usb/dvb-usb/m920x.c| 269 > -- > 4 files changed, 266 insertions(+), 79 deletions(-) > > -- > Antonio Ospite > http://ao2.it > > A: Because it messes up the order in which people normally read text. >See http://en.wikipedia.org/wiki/Posting_style > Q: Why is top-posting such a bad thing? > -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] uvcvideo: Set error_idx properly for extended controls API failures
Hi Hans,
On Thursday 27 December 2012 12:59:15 Hans Verkuil wrote:
> On Wed December 26 2012 12:33:58 Laurent Pinchart wrote:
> > On Tuesday 25 December 2012 12:50:51 Hans Verkuil wrote:
> > > On Tue December 25 2012 12:23:00 Laurent Pinchart wrote:
> > > > On Tuesday 25 December 2012 12:15:25 Hans Verkuil wrote:
> > > > > On Mon December 24 2012 13:27:08 Laurent Pinchart wrote:
> > > > > > On Thursday 27 September 2012 17:16:15 Laurent Pinchart wrote:
> > > > > > > When one of the requested controls doesn't exist the error_idx
> > > > > > > field must reflect that situation. For G_EXT_CTRLS and
> > > > > > > S_EXT_CTRLS, error_idx must be set to the control count. For
> > > > > > > TRY_EXT_CTRLS, it must be set to the index of the unexisting
> > > > > > > control.
> > > > > > >
> > > > > > > This issue was found by the v4l2-compliance tool.
> > > > > >
> > > > > > I'm revisiting this patch as it has been reverted in v3.8-rc1.
> > > > > >
> > > > > > > Signed-off-by: Laurent Pinchart
> > > > > > >
> > > > > > > ---
> > > > > > >
> > > > > > > drivers/media/usb/uvc/uvc_ctrl.c | 17 ++---
> > > > > > > drivers/media/usb/uvc/uvc_v4l2.c | 19 ---
> > > > > > > 2 files changed, 22 insertions(+), 14 deletions(-)
> > > > > >
> > > > > > [snip]
> > > > > >
> > > > > > > diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
> > > > > > > b/drivers/media/usb/uvc/uvc_v4l2.c index f00db30..e5817b9 100644
> > > > > > > --- a/drivers/media/usb/uvc/uvc_v4l2.c
> > > > > > > +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> > > > > > > @@ -591,8 +591,10 @@ static long uvc_v4l2_do_ioctl(struct file
> > > > > > > *file,
> > > > > >
> > > > > > [snip]
> > > > > >
> > > > > > > @@ -637,8 +639,9 @@ static long uvc_v4l2_do_ioctl(struct file
> > > > > > > *file,
> > > > > > > unsigned int cmd, void *arg) ret = uvc_ctrl_get(chain, ctrl);
> > > > > > >
> > > > > > > if (ret < 0) {
> > > > > > >
> > > > > > > uvc_ctrl_rollback(handle);
> > > > > > >
> > > > > > > - ctrls->error_idx = i;
> > > > > > > - return ret;
> > > > > > > + ctrls->error_idx = ret == -ENOENT
> > > > > > > + ? ctrls->count : i;
> > > > > > > + return ret == -ENOENT ? -EINVAL : ret;
> > > > > > >
> > > > > > > }
> > > > > > >
> > > > > > > }
> > > > > > > ctrls->error_idx = 0;
> > > > > > >
> > > > > > > @@ -661,8 +664,10 @@ static long uvc_v4l2_do_ioctl(struct file
> > > > > > > *file,
> > > > > > > unsigned int cmd, void *arg) ret = uvc_ctrl_set(chain, ctrl);
> > > > > > >
> > > > > > > if (ret < 0) {
> > > > > > >
> > > > > > > uvc_ctrl_rollback(handle);
> > > > > > >
> > > > > > > - ctrls->error_idx = i;
> > > > > > > - return ret;
> > > > > > > + ctrls->error_idx = (ret == -ENOENT &&
> > > > > > > + cmd ==
> > > > > > > VIDIOC_S_EXT_CTRLS)
> > > > > > > + ? ctrls->count : i;
> > > > > > > + return ret == -ENOENT ? -EINVAL : ret;
> > > > > > >
> > > > > > > }
> > > > > > >
> > > > > > > }
> > > > > >
> > > > > > I've reread the V4L2 specification, and the least I can say is
> > > > > > that
> > > > > > the text is pretty ambiguous. Let's clarify it.
> > > > > >
> > > > > > Is there a reason to differentiate between invalid control IDs and
> > > > > > other errors as far as error_idx is concerned ? It would be
> > > > > > simpler if error_idx was set to the index of the first error for
> > > > > > get and try operations, regardless of the error type. What do you
> > > > > > think ?
> > > > >
> > > > > There is a good reason for doing this: the G/S_EXT_CTRLS ioctls have
> > > > > to be as atomic as possible, i.e. it should try hard to prevent
> > > > > leaving the hardware in an inconsistent state because not all
> > > > > controls could be set. It can never be fully atomic since writing
> > > > > multiple registers over usb or i2c can always return errors for one
> > > > > of those writes, but it should certainly check for all the obvious
> > > > > errors first that do not require actually writing to the hardware,
> > > > > such as whether all the controls in the control list actually exist.
> > > > >
> > > > > And for such errors error_idx should be set to the number of
> > > > > controls to indicate that none of the controls were actually set but
> > > > > that there was a problem with the list of controls itself.
> > > >
> > > > For S_EXT_CTRLS, sure, but G_EXT_CTRLS doesn't modify the hardware
> > > > state, so it could get all controls up to the erroneous one.
> > >
> > > I have thought about t
Re: [PATCH 1/6] uvcvideo: Set error_idx properly for extended controls API failures
On Wed December 26 2012 12:33:58 Laurent Pinchart wrote:
> Hi Hans,
>
> On Tuesday 25 December 2012 12:50:51 Hans Verkuil wrote:
> > On Tue December 25 2012 12:23:00 Laurent Pinchart wrote:
> > > On Tuesday 25 December 2012 12:15:25 Hans Verkuil wrote:
> > > > On Mon December 24 2012 13:27:08 Laurent Pinchart wrote:
> > > > > On Thursday 27 September 2012 17:16:15 Laurent Pinchart wrote:
> > > > > > When one of the requested controls doesn't exist the error_idx field
> > > > > > must reflect that situation. For G_EXT_CTRLS and S_EXT_CTRLS,
> > > > > > error_idx must be set to the control count. For TRY_EXT_CTRLS, it
> > > > > > must be set to the index of the unexisting control.
> > > > > >
> > > > > > This issue was found by the v4l2-compliance tool.
> > > > >
> > > > > I'm revisiting this patch as it has been reverted in v3.8-rc1.
> > > > >
> > > > > > Signed-off-by: Laurent Pinchart
> > > > > > ---
> > > > > >
> > > > > > drivers/media/usb/uvc/uvc_ctrl.c | 17 ++---
> > > > > > drivers/media/usb/uvc/uvc_v4l2.c | 19 ---
> > > > > > 2 files changed, 22 insertions(+), 14 deletions(-)
> > > > >
> > > > > [snip]
> > > > >
> > > > > > diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
> > > > > > b/drivers/media/usb/uvc/uvc_v4l2.c index f00db30..e5817b9 100644
> > > > > > --- a/drivers/media/usb/uvc/uvc_v4l2.c
> > > > > > +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> > > > > > @@ -591,8 +591,10 @@ static long uvc_v4l2_do_ioctl(struct file
> > > > > > *file,
> > > > >
> > > > > [snip]
> > > > >
> > > > > > @@ -637,8 +639,9 @@ static long uvc_v4l2_do_ioctl(struct file *file,
> > > > > > unsigned int cmd, void *arg) ret = uvc_ctrl_get(chain, ctrl);
> > > > > > if (ret < 0) {
> > > > > > uvc_ctrl_rollback(handle);
> > > > > >
> > > > > > - ctrls->error_idx = i;
> > > > > > - return ret;
> > > > > > + ctrls->error_idx = ret == -ENOENT
> > > > > > +? ctrls->count : i;
> > > > > > + return ret == -ENOENT ? -EINVAL : ret;
> > > > > > }
> > > > > > }
> > > > > > ctrls->error_idx = 0;
> > > > > > @@ -661,8 +664,10 @@ static long uvc_v4l2_do_ioctl(struct file
> > > > > > *file,
> > > > > > unsigned int cmd, void *arg) ret = uvc_ctrl_set(chain, ctrl);
> > > > > > if (ret < 0) {
> > > > > > uvc_ctrl_rollback(handle);
> > > > > >
> > > > > > - ctrls->error_idx = i;
> > > > > > - return ret;
> > > > > > + ctrls->error_idx = (ret == -ENOENT &&
> > > > > > + cmd ==
> > > > > > VIDIOC_S_EXT_CTRLS)
> > > > > > +? ctrls->count : i;
> > > > > > + return ret == -ENOENT ? -EINVAL : ret;
> > > > > > }
> > > > > > }
> > > > >
> > > > > I've reread the V4L2 specification, and the least I can say is that
> > > > > the text is pretty ambiguous. Let's clarify it.
> > > > >
> > > > > Is there a reason to differentiate between invalid control IDs and
> > > > > other errors as far as error_idx is concerned ? It would be simpler if
> > > > > error_idx was set to the index of the first error for get and try
> > > > > operations, regardless of the error type. What do you think ?
> > > >
> > > > There is a good reason for doing this: the G/S_EXT_CTRLS ioctls have to
> > > > be as atomic as possible, i.e. it should try hard to prevent leaving the
> > > > hardware in an inconsistent state because not all controls could be set.
> > > > It can never be fully atomic since writing multiple registers over usb
> > > > or i2c can always return errors for one of those writes, but it should
> > > > certainly check for all the obvious errors first that do not require
> > > > actually writing to the hardware, such as whether all the controls in
> > > > the control list actually exist.
> > > >
> > > > And for such errors error_idx should be set to the number of controls to
> > > > indicate that none of the controls were actually set but that there was
> > > > a problem with the list of controls itself.
> > >
> > > For S_EXT_CTRLS, sure, but G_EXT_CTRLS doesn't modify the hardware state,
> > > so it could get all controls up to the erroneous one.
> >
> > I have thought about that but I decided against it. One reason is to have
> > get and set behave the same since both access the hardware. The other
> > reason is that even getting a control value might change the hardware
> > state, for example by resetting some internal hardware counter when a
> > register is read (it's rare but there is hardware like that). Furthermore,
> > reading hardware registers can be slow so why not do the sanity check
> > first?
>
> Ge
Re: [PATCH] [media] vivi: Constify structures
On Wed December 26 2012 16:29:43 Kirill Smelkov wrote:
> Most of *_ops and other structures in vivi.c were already declared const
> but some have not. Constify and code/data will take less space:
>
> $ size drivers/media/platform/vivi.o
> textdata bss dec hex filename
> before: 12569 248 8 128253219
> drivers/media/platform/vivi.o
> after: 12308 20 8 123363030
> drivers/media/platform/vivi.o
>
> i.e. vivi.o is now ~500 bytes less.
>
> Signed-off-by: Kirill Smelkov
> ---
> drivers/media/platform/vivi.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
> index ec65089..bed04e1 100644
> --- a/drivers/media/platform/vivi.c
> +++ b/drivers/media/platform/vivi.c
> @@ -91,13 +91,13 @@ static const struct v4l2_fract
> --*/
>
> struct vivi_fmt {
> - char *name;
> + const char *name;
Just use one space before '*' since it no longer lines up to anything.
> u32 fourcc; /* v4l2 format id */
> u8depth;
> bool is_yuv;
> };
>
> -static struct vivi_fmt formats[] = {
> +static const struct vivi_fmt formats[] = {
> {
> .name = "4:2:2, packed, YUYV",
> .fourcc = V4L2_PIX_FMT_YUYV,
> @@ -164,9 +164,9 @@ static struct vivi_fmt formats[] = {
> },
> };
>
> -static struct vivi_fmt *__get_format(u32 pixelformat)
> +static const struct vivi_fmt *__get_format(u32 pixelformat)
> {
> - struct vivi_fmt *fmt;
> + const struct vivi_fmt *fmt;
> unsigned int k;
>
> for (k = 0; k < ARRAY_SIZE(formats); k++) {
> @@ -181,7 +181,7 @@ static struct vivi_fmt *__get_format(u32 pixelformat)
> return &formats[k];
> }
>
> -static struct vivi_fmt *get_format(struct v4l2_format *f)
> +static const struct vivi_fmt *get_format(struct v4l2_format *f)
> {
> return __get_format(f->fmt.pix.pixelformat);
> }
> @@ -191,7 +191,7 @@ struct vivi_buffer {
> /* common v4l buffer stuff -- must be first */
> struct vb2_buffer vb;
> struct list_headlist;
> - struct vivi_fmt*fmt;
> + struct vivi_fmt const *fmt;
> };
>
> struct vivi_dmaqueue {
> @@ -250,7 +250,7 @@ struct vivi_dev {
> intinput;
>
> /* video capture */
> - struct vivi_fmt*fmt;
> + struct vivi_fmt const *fmt;
'const' should be before 'struct' for consistency reasons.
> struct v4l2_fract timeperframe;
> unsigned int width, height;
> struct vb2_queue vb_vidq;
> @@ -297,7 +297,7 @@ struct bar_std {
>
> /* Maximum number of bars are 10 - otherwise, the input print code
> should be modified */
> -static struct bar_std bars[] = {
> +static const struct bar_std bars[] = {
> { /* Standard ITU-R color bar sequence */
> { COLOR_WHITE, COLOR_AMBER, COLOR_CYAN, COLOR_GREEN,
> COLOR_MAGENTA, COLOR_RED, COLOR_BLUE, COLOR_BLACK,
> COLOR_BLACK }
> @@ -926,7 +926,7 @@ static void vivi_unlock(struct vb2_queue *vq)
> }
>
>
> -static struct vb2_ops vivi_video_qops = {
> +static const struct vb2_ops vivi_video_qops = {
> .queue_setup= queue_setup,
> .buf_prepare= buffer_prepare,
> .buf_queue = buffer_queue,
> @@ -957,7 +957,7 @@ static int vidioc_querycap(struct file *file, void *priv,
> static int vidioc_enum_fmt_vid_cap(struct file *file, void *priv,
> struct v4l2_fmtdesc *f)
> {
> - struct vivi_fmt *fmt;
> + struct vivi_fmt const *fmt;
Ditto.
>
> if (f->index >= ARRAY_SIZE(formats))
> return -EINVAL;
> @@ -993,7 +993,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void
> *priv,
> struct v4l2_format *f)
> {
> struct vivi_dev *dev = video_drvdata(file);
> - struct vivi_fmt *fmt;
> + struct vivi_fmt const *fmt;
Ditto.
>
> fmt = get_format(f);
> if (!fmt) {
> @@ -1102,7 +1102,7 @@ static int vidioc_s_input(struct file *file, void
> *priv, unsigned int i)
> static int vidioc_enum_frameintervals(struct file *file, void *priv,
>struct v4l2_frmivalenum *fival)
> {
> - struct vivi_fmt *fmt;
> + struct vivi_fmt const *fmt;
Ditto.
>
> if (fival->index)
> return -EINVAL;
> @@ -1330,7 +1330,7 @@ static const struct v4l2_ioctl_ops vivi_ioctl_ops = {
> .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
> };
>
> -static struct video_device vivi_template = {
> +static const struct video_device vivi_template = {
> .name = "vivi",
> .fops = &vivi_fops,
> .ioctl_ops = &vivi_ioctl_ops,
>
Regards,
Re: DVB-T Scan File Update Required for au-Darwin
Just a minor modification... # Darwin Digital Television (UHF 33) T 564625 7Mhz 3/4 NONE QAM64 8k 1/16 NONE Cheers Ben On Thu, Dec 27, 2012 at 7:47 PM, Ben Manfield wrote: > Could you please include the following channel in your scan file for > au-Darwin? > > # Darwin Digital Television (UHF 33) > T 564625 7Mhz 3/4 QAM64 8k 1/16 None > > Cheers, > Ben -- 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
