Re: [linux-dvb] [PATCH] Userspace tuner

[Mauro Carvalho Chehab]

> > - The hybrid tuner support, that where your requirement, when all those
> > discussions started, were already added to the subsystem. So now, an
> > hybrid tuner can be accessed by both DVB and V4L devices;
> >
> 
> It's far more complex as the thing which is implemented there.
> The only thing that has been implemented is that one moduleformat
> can be loaded by the v4l and by the dvb framework nothing else at the
> moment. I told you at the kernel summit about that and I think you
> knew about that before.
> 
> Just to quote some text:
> "Right now, a separate instance of the driver is used for analog /
> digital tuning.  In order to use a single instance, we will have to
> store a pointer to the dvb_frontend structure on the bridge level, but
> there are various other prerequisites that must be dealt with before we
> get to that point.
> 
> We _will_ get there though, eventually."

Maybe it is still not perfect. Feel free to improve it. Several people
from the community, including me, already offered you help to add your
driver, reworking on the 5% of the stuff that aren't compatible with the
V4L/DVB core API design.

> > - Audio standard selection is already possible via S_STD (it is already
> > working for a few standards, like NTSC/M JP and NTSC/M KR). Maybe more
> > standards should be needed, but hey, we still have 34 bits available at
> > std mask.
> >
> 
> Let me quote some text where you've been in CC and which didn't get
> far enough to get a solution implemented.
> 
> (Michael Schimek)
> 
> "> xc3028_BG_PAL_A2_A.i2c FW_78 > B/G PAL A2
> >   Group delay: See RecITU-R BT.470-6 p.21 Response "A"
> > xc3028_BG_PAL_A2_A_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON
> > xc3028_BG_PAL_A2_B.i2c FW_78 B/G PAL A2
> >   Group delay: See RecITU-R BT.470-6 p.21 Response "B"
> > xc3028_BG_PAL_A2_B_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON
> 
> > xc3028_BG_PAL_NICAM_A.i2c FW_78 B/G PAL NICAM
> >   Group delay: See RecITU-R BT.470-6 p.21 Response "A"
> > xc3028_BG_PAL_NICAM_A_MTS.i2c FW_78_MTS B/G PAL FM
> > xc3028_BG_PAL_NICAM_B.i2c FW_78 B/G PAL NICAM
> >   Group delay: See RecITU-R BT.470-6 p.21 Response "B"
> > xc3028_BG_PAL_NICAM_B_MTS.i2c FW_78_MTS B/G PAL FM
> 
> We cannot add new standards for each of these files because only six
> bits are unassigned in the lower half of v4l2_std_id. It seems
> unecessary too, please correct me if I'm wrong.
We can use the full 64 bits of v4l2_std_id. We just need to take some
care. 

Due to the lack of __ucmpdi2 on ppc32 architecture, with some gcc
versions, a hack were added at v4l2-common.c, that truncates it to 32
bits, at the function v4l2_norm_to_name():

http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git;a=commit;h=412297d31d439ba56cd4faeb3a49a6f569f40702

So, using more than 32 bits is possible, providing that we change the
implementation of v4l2_norm_to_name() or find a way for it to work with
ppc32.

Instead of just adding a standard for each possible combination, we may
just add bits for the supported audio formats. For example, we can use
the bitmask as:

#define V4L2_STD_AUDIO_NICAM_A  ((v4l2_std_id)0x04000000)
#define V4L2_STD_AUDIO_A2_A     ((v4l2_std_id)0x08000000)

Since for all other chipsets but xc3028, all audio standards are
supported, maybe we can, instead, use a negate bitmap logic for the
non-supported audio standards. Something like:

#define V4L2_STD_AUDIO_NOT_NICAM_A  ((v4l2_std_id)0x04000000)
#define V4L2_STD_AUDIO_NOT_A2_A     ((v4l2_std_id)0x08000000)

And define some macros for the specific standards you need. For example:

#define V4L2_STD_AUDIO_NOT_ALL	V4L2_STD_AUDIO_NOT_A2_A | V4L2_STD_AUDIO_NOT_NICAM_A

#define V4L2_STD_PAL_BG_A2 	V4L2_STD_PAL_BG | (V4L2_STD_AUDIO_NOT_ALL & !V4L2_STD_AUDIO_NOT_A2_A)

This way, V4L2_STD_PAL_BG will mean that this PAL/BG accepts all
possible audio standards (being binary compatible), while
V4L2_STD_PAL_BG_A2_A will mean that only A2 response 'A' audio format is
supported for PAL/BG.

-- 
Cheers,
Mauro

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/