Re: [PATCH]Medion 95700 analog video support
Em 02-10-2011 16:12, Maciej Szmigiero escreveu: > Updated patch with Andy's suggestion to make changes to cx25840 driver > conditional on platform_data flag and fixed few typos. > Reverted changes to cx25840 driver VBI code - will think of them when > we have VBI implemented in cxusb and, by extension, a way to test them. > > Also fixed small chroma bug with S-Video input. > > This still needs the patch for v4l2-device.c::v4l2_device_unregister > applied first. > > Signed-off-by: Maciej Szmigiero This patch is stil on my queue, not sure why it wasn't applied (probably because I was waiting for Andy/Michael's ack): http://patchwork.linuxtv.org/patch/8048/ Is it ok to apply? If so, could you please rebase it. It doesn't apply anymore, due to the MFE changes at dvb-usb. It shouldn't be hard to fix, as it should be just parameter names. 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]Medion 95700 analog video support
W dniu 14.08.2012 01:35, Mauro Carvalho Chehab pisze: > Em 02-10-2011 16:12, Maciej Szmigiero escreveu: >> Updated patch with Andy's suggestion to make changes to cx25840 driver >> conditional on platform_data flag and fixed few typos. >> Reverted changes to cx25840 driver VBI code - will think of them when >> we have VBI implemented in cxusb and, by extension, a way to test them. >> >> Also fixed small chroma bug with S-Video input. >> >> This still needs the patch for v4l2-device.c::v4l2_device_unregister >> applied first. >> >> Signed-off-by: Maciej Szmigiero > > > This patch is stil on my queue, not sure why it wasn't applied (probably > because I was waiting for Andy/Michael's ack): > http://patchwork.linuxtv.org/patch/8048/ > > Is it ok to apply? If so, could you please rebase it. It doesn't apply > anymore, due to the MFE changes at dvb-usb. It shouldn't be hard to fix, > as it should be just parameter names. > > Regards, > Mauro > Hello Mauro, I will dust off the device, rebase and retest the patch as soon as have some spare time (should happen in 2-3 weeks). Best regards, Maciej Szmigiero -- 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]Medion 95700 analog video support
W dniu 04.09.2011 21:05, Arnaud Lacombe pisze: > Hi, > > On Sun, Sep 4, 2011 at 2:51 PM, Maciej Szmigiero wrote: >> This patch adds support for analog part of Medion 95700 in the cxusb driver. >> > For what reason am I CC'ed on this ? Most of the relevant changes I > ever made in the media tree were only mechanical. > > Thanks, > - Arnaud Hi, get_maintainer.pl script output on this patch returned your name, thats why it was included. If thats a mistake I'm sorry for spamming you. Best regards, Maciej Szmigiero -- 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]Medion 95700 analog video support
W dniu 04.09.2011 21:46, Michael Krufky pisze: > Maciej, > > I'm excited to see some success getting analog to work in the dvb-usb > framework. Some people have been asking for this support in the cxusb > driver for a long time. > > I have a device (DViCO FusionHDTV5 usb) that should work with this > patch with some small modifications -- i will try it out. > > I see that this patch adds analog support to cxusb... have you thought > at all about adding generic analog support callbacks to the dvb-usb > framework? There are some other dvb-usb devices based on the dib0700 > chipset that also also use the cx25840 decoder for analog -- it would > be great if this can be done in a way to benefit both the dib0700 and > cxusb drivers. > > I will let you know how things go after I try this code on my own device, > here. > > Thanks for your patch. > > -Mike Krufky Hi and thanks for reply, I think whether the code should be moved to dvb-usb framework really depends on how much the devices have in common - Medion uses a generic Cypress FX2 USB bridge which is programmed (by firmware) to post an ISO buffer once there is exactly 1010 bytes received on its parallel interface. This parallel interface is 8-bit wide and has data inputs connected to cx25840 video interface data output and clock input to cx25840 pixel clock output. USB bridge does not modify this data in any way, nor it does any alignment. So we have a raw BT.656 (or VESA VIP) stream coming from the device. Because there are 3 such 1010-byte packets per (micro)frame the URB frame descriptor has to be 3030 bytes in length (or more) or data will be truncated, which will result in parts of field being all-green. If your device has similar characteristics then it is just matter of substituting a few commands in code (and maybe changing CXUSB_VIDEO_PKT_SIZE to different value if it does not use 3*1010 byte frames). Otherwise, for example if device outputs simple YUV data without any framing, the code will pretty much be different - other than a bit of V4L2 driver glue code which can be shared. Best regards and hope this helps, Maciej Szmigiero -- 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]Medion 95700 analog video support
Michael Krufky wrote: >On Fri, Sep 23, 2011 at 3:32 PM, Mauro Carvalho Chehab > wrote: >> Em 04-09-2011 16:46, Michael Krufky escreveu: >>> Maciej, >>> >>> I'm excited to see some success getting analog to work in the >dvb-usb >>> framework. Some people have been asking for this support in the >cxusb >>> driver for a long time. >>> >>> I have a device (DViCO FusionHDTV5 usb) that should work with this >>> patch with some small modifications -- i will try it out. >>> >>> I see that this patch adds analog support to cxusb... have you >thought >>> at all about adding generic analog support callbacks to the dvb-usb >>> framework? There are some other dvb-usb devices based on the >dib0700 >>> chipset that also also use the cx25840 decoder for analog -- it >would >>> be great if this can be done in a way to benefit both the dib0700 >and >>> cxusb drivers. >>> >>> I will let you know how things go after I try this code on my own >device, here. >> >> Any news on that? >> >> Thanks! >> Mauro > >Didn't have a chance to test it yet, but I am quite excited for this, >and perhaps porting support to dib0700 as well. I hope to try this >out *before* the Kernel Summit in Prague. I apologize for delays, the >dvb-usb-mfe refactoring has been higher on the priority list lately. > >I'll get back to you when I can :-) > >Cheers, > >Mike > > > >>> >>> Thanks for your patch. >>> >>> -Mike Krufky >>> >>> On Sun, Sep 4, 2011 at 2:51 PM, Maciej Szmigiero wrote: This patch adds support for analog part of Medion 95700 in the >cxusb driver. What works: * Video capture at various sizes with sequential fields, * Input switching (TV Tuner, Composite, S-Video), * TV tuning, * Video standard switching and auto detection, * Unplugging while capturing, * DVB/analog coexistence, * Raw BT.656 stream support. What does not work yet: * Audio, * Radio, * VBI, * Picture controls. Note that this patch needs >https://patchwork.kernel.org/patch/1110982/ to be applied first. Signed-off-by: Maciej Szmigiero diff --git a/drivers/media/dvb/dvb-usb/Kconfig >b/drivers/media/dvb/dvb-usb/Kconfig index 6e97bb3..afecb9d 100644 --- a/drivers/media/dvb/dvb-usb/Kconfig +++ b/drivers/media/dvb/dvb-usb/Kconfig @@ -108,6 +108,8 @@ config DVB_USB_UMT_010 config DVB_USB_CXUSB tristate "Conexant USB2.0 hybrid reference design support" depends on DVB_USB + select VIDEO_CX25840 + select VIDEOBUF2_VMALLOC select DVB_PLL if !DVB_FE_CUSTOMISE select DVB_CX22702 if !DVB_FE_CUSTOMISE select DVB_LGDT330X if !DVB_FE_CUSTOMISE diff --git a/drivers/media/dvb/dvb-usb/Makefile >b/drivers/media/dvb/dvb-usb/Makefile index 03ae657..b57600b 100644 --- a/drivers/media/dvb/dvb-usb/Makefile +++ b/drivers/media/dvb/dvb-usb/Makefile @@ -42,7 +42,7 @@ obj-$(CONFIG_DVB_USB_AU6610) += dvb-usb-au6610.o dvb-usb-digitv-objs = digitv.o obj-$(CONFIG_DVB_USB_DIGITV) += dvb-usb-digitv.o -dvb-usb-cxusb-objs = cxusb.o +dvb-usb-cxusb-objs = cxusb.o cxusb-analog.o obj-$(CONFIG_DVB_USB_CXUSB) += dvb-usb-cxusb.o dvb-usb-ttusb2-objs = ttusb2.o diff --git a/drivers/media/dvb/dvb-usb/cxusb-analog.c >b/drivers/media/dvb/dvb-usb/cxusb-analog.c new file mode 100644 index 000..89c9335 --- /dev/null +++ b/drivers/media/dvb/dvb-usb/cxusb-analog.c @@ -0,0 +1,1738 @@ +/* DVB USB compliant linux driver for Conexant USB reference >design - + * (analog part). + * + * Copyright (C) 2011 Maciej Szmigiero (m...@o2.pl) + * + * TODO: + * * audio support, + * * radio support (requires audio of course), + * * VBI support, + * * controls support + * + * 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public >License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + * 02110-1301, USA. + */ + +#include +#include +#include + +#include "cxusb.h" + +static int cxusb_medion_v_queue_setup(struct vb2_queue *q, + unsigned int *num_buffers, + unsigned int *num_planes, +
Re: [PATCH]Medion 95700 analog video support
W dniu 23.09.2011 23:06, Andy Walls pisze: > Michael Krufky wrote: > > The cx25840 part of the patch breaks ivtv, IIRC. The patch really need to > add board specific configuration and behavior to cx25840. I'll have time > tomorrow late afternoon to properly reviw and comment. > > Regards, > Andy Have you already narrowed it down which part of the cx25840 patch breaks ivtv - maybe it is setting the defaults at init or change to check for plain I2C instead of SMBus? Best regards, Maciej Szmigiero -- 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]Medion 95700 analog video support
W dniu 24.09.2011 22:21, Andy Walls pisze:
> Hi Maciej,
>
> I'll try and comment on the specific areas below, but overall the
> problem is this:
>
> 1. The default setup and behavior of the cx25840 module was written
> around hardware designs supported by the ivtv driver: i.e. interfacing
> to a CX23416 MPEG encoder.
>
> 2. The ivtv and pvrusb2 drivers rely on that default setup and behavior
> of the cx25840 module.
>
> 3. The PVR-150 and PVR-500 are very popular cards supported by ivtv that
> use a CX25843 and CX23416. Many MythTV users still have these cards in
> service.
>
> 4. The ivtv driver also supports other hardware designs that use
> different encoders, so trying fix ivtv to match new changes in the
> cx25840 will ripples along to other analog video decoder drivers. This
> would result in a lot of time to perform regression testing with as many
> different ivtv supported capture cards as possible.
>
>
> What I recommend is that you rework your changes so that the cx25840
> module is provided information by the bridge driver as to the board
> model, and then have the cx25840 module behave appropriately based on
> the board information passed in by the bridge driver.
>
> 1. Add whatever data fields you think you need to the "struct
> cx25840_platform_data" structure in include/media/cx25840.h. Maybe
> something as simple as "bool is_medion95700"
>
> 2. In cxusb-analog.c you instantiate the cx25840 sub-device with
> v4l2_i2c_new_subdev_board() with the cx25840 platform data filled in as
> needed for the Medion 95700. Look at
> drivers/media/video/ivtv/ivtv-i2c.c:ivtv_i2c_register() for an example
> of how this is done for the cx25840 module.
>
> 3. Modify the cx25840 module to behave as you need it if the platform
> data indicates a Medion 95700; otherwise, leave the default cx25840
> setup and behavior.
>
Hi Andy,
Thanks for you detailed explanation, I did not know that ivtv boards are that
quirky with regard to VBI capture.
I will do as you wrote above, make my changes to cx25840 driver conditional,
so ivtv won't be affected.
> Any specific comments I have are in-line below:
>
>> @@ -18,6 +18,9 @@
>> * CX2388[578] IRQ handling, IO Pin mux configuration and other small fixes
>> are
>> * Copyright (C) 2010 Andy Walls
>> *
>> + * CX2384x pin to pad mapping and output format configuration support are
> ^^^
> CX2584x?
>> if ((fmt->width * 16 < Hsrc) || (Hsrc < fmt->width) ||
>> (Vlines * 8 < Vsrc) || (Vsrc < Vlines)) {
>> @@ -1403,6 +1695,112 @@ static void log_audio_status(struct i2c_client
>> *client)
>> }
>> }
>>
>> +#define CX25480_VCONFIG_OPTION(option_mask) \
>^^
> CX25840?
>
>> +if (config_in & option_mask) { \
>> +state->vid_config &= ~(option_mask); \
>> +state->vid_config |= config_in & option_mask; \
>> +} \
>> +
>> +#define CX25480_VCONFIG_SET_BIT(optionmask, reg, bit, oneval) \
>^^
> CX25840?
>
You mean here that it should be named consistently either as CX2584x or CX25840?
>> return set_input(client, input, state->aud_input);
>> }
>>
>> @@ -1877,7 +2278,7 @@ static int cx25840_probe(struct i2c_client *client,
>> u16 device_id;
>>
>> /* Check if the adapter supports the needed features */
>> -if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
>> +if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
>> return -EIO;
>
> On the surface, this change doesn't appear to adversely affect the ivtv,
> pvrusb2, cx23885, and cx231xx bridge drivers.
>
> I would need to take a hard look at the CX2584[0123], CX2583[67],
> CX2388[578], and CX2310[12] datasheets to see why, and if, all the Mako
> core variants require I2C_FUNC_SMBUS_BYTE_DATA.
>
> However, if the cxusb bridge has a full I2C master, shouldn't the cxusb
> driver be specifying (I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL) as its
> functionality? See Documentation/i2c/functionality.
Adding I2C_FUNC_SMBUS_EMUL flag to cxusb i2c host seems to be a right thing to
do for now,
but I would be very surprised if any of Conexant video decoders actually used
SMBus instead
of plain I2C.
Best regards,
Maciej Szmigiero
--
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]Medion 95700 analog video support
On Mon, 2011-09-26 at 23:37 +0200, Maciej Szmigiero wrote:
> W dniu 24.09.2011 22:21, Andy Walls pisze:
> > Hi Maciej,
> >
> > I'll try and comment on the specific areas below, but overall the
> > problem is this:
> >
> > 1. The default setup and behavior of the cx25840 module was written
> > around hardware designs supported by the ivtv driver: i.e. interfacing
> > to a CX23416 MPEG encoder.
> >
> > 2. The ivtv and pvrusb2 drivers rely on that default setup and behavior
> > of the cx25840 module.
> >
> > 3. The PVR-150 and PVR-500 are very popular cards supported by ivtv that
> > use a CX25843 and CX23416. Many MythTV users still have these cards in
> > service.
> >
> > 4. The ivtv driver also supports other hardware designs that use
> > different encoders, so trying fix ivtv to match new changes in the
> > cx25840 will ripples along to other analog video decoder drivers. This
> > would result in a lot of time to perform regression testing with as many
> > different ivtv supported capture cards as possible.
> >
> >
> > What I recommend is that you rework your changes so that the cx25840
> > module is provided information by the bridge driver as to the board
> > model, and then have the cx25840 module behave appropriately based on
> > the board information passed in by the bridge driver.
> >
> > 1. Add whatever data fields you think you need to the "struct
> > cx25840_platform_data" structure in include/media/cx25840.h. Maybe
> > something as simple as "bool is_medion95700"
> >
> > 2. In cxusb-analog.c you instantiate the cx25840 sub-device with
> > v4l2_i2c_new_subdev_board() with the cx25840 platform data filled in as
> > needed for the Medion 95700. Look at
> > drivers/media/video/ivtv/ivtv-i2c.c:ivtv_i2c_register() for an example
> > of how this is done for the cx25840 module.
> >
> > 3. Modify the cx25840 module to behave as you need it if the platform
> > data indicates a Medion 95700; otherwise, leave the default cx25840
> > setup and behavior.
> >
>
> Hi Andy,
>
> Thanks for you detailed explanation, I did not know that ivtv boards are that
> quirky with regard to VBI capture.
> I will do as you wrote above, make my changes to cx25840 driver conditional,
> so ivtv won't be affected.
Thanks!
> > Any specific comments I have are in-line below:
> >
> >> @@ -18,6 +18,9 @@
> >> * CX2388[578] IRQ handling, IO Pin mux configuration and other small
> >> fixes are
> >> * Copyright (C) 2010 Andy Walls
> >> *
> >> + * CX2384x pin to pad mapping and output format configuration support are
> > ^^^
> > CX2584x?
> >>if ((fmt->width * 16 < Hsrc) || (Hsrc < fmt->width) ||
> >>(Vlines * 8 < Vsrc) || (Vsrc < Vlines)) {
> >> @@ -1403,6 +1695,112 @@ static void log_audio_status(struct i2c_client
> >> *client)
> >>}
> >> }
> >>
> >> +#define CX25480_VCONFIG_OPTION(option_mask) \
> >^^
> > CX25840?
> >
> >> + if (config_in & option_mask) { \
> >> + state->vid_config &= ~(option_mask); \
> >> + state->vid_config |= config_in & option_mask; \
> >> + } \
> >> +
> >> +#define CX25480_VCONFIG_SET_BIT(optionmask, reg, bit, oneval) \
> >^^
> > CX25840?
> >
>
> You mean here that it should be named consistently either as CX2584x or
> CX25840?
No. You simply appear to have transposed the 8 with the 4.
> >>return set_input(client, input, state->aud_input);
> >> }
> >>
> >> @@ -1877,7 +2278,7 @@ static int cx25840_probe(struct i2c_client *client,
> >>u16 device_id;
> >>
> >>/* Check if the adapter supports the needed features */
> >> - if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
> >> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
> >>return -EIO;
> >
> > On the surface, this change doesn't appear to adversely affect the ivtv,
> > pvrusb2, cx23885, and cx231xx bridge drivers.
> >
> > I would need to take a hard look at the CX2584[0123], CX2583[67],
> > CX2388[578], and CX2310[12] datasheets to see why, and if, all the Mako
> > core variants require I2C_FUNC_SMBUS_BYTE_DATA.
> >
> > However, if the cxusb bridge has a full I2C master, shouldn't the cxusb
> > driver be specifying (I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL) as its
> > functionality? See Documentation/i2c/functionality.
>
> Adding I2C_FUNC_SMBUS_EMUL flag to cxusb i2c host seems to be a right thing
> to do for now,
> but I would be very surprised if any of Conexant video decoders actually used
> SMBus instead
> of plain I2C.
I'm confident they use plain I2C as well.
Hans added this particular i2c_check_functionality() call to the cx25840
module in 2007. It appears to be a cut and paste of what many I2C chip
drivers in drivers/media/video do.
The check might have its origin in some example code from Greg K-H in
2003 for a Tiny I2C chip driver:
http://www.linuxjournal.com/article/7252?page=0,0
ftp://ftp.linuxjournal.com/pub/lj/listings/issue118/7252.tgz
Regards
