[patch 2/2] [media] Staging: dt3155v4l: probe() always fails
There were some curly braces missing so the probe() function always
failed.
Signed-off-by: Dan Carpenter
diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c
b/drivers/staging/media/dt3155v4l/dt3155v4l.c
index 25c6025..280c84e 100644
--- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
+++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
@@ -908,9 +908,10 @@ dt3155_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
if (err)
goto err_req_region;
pd->regs = pci_iomap(pdev, 0, pci_resource_len(pd->pdev, 0));
- if (!pd->regs)
+ if (!pd->regs) {
err = -ENOMEM;
goto err_pci_iomap;
+ }
err = dt3155_init_board(pdev);
if (err)
goto err_init_board;
--
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] Staging: dt3155v4l: update to newer API
I changed the function definitions for dt3155_queue_setup() to match the
newer API. The dt3155_start_streaming() function didn't do anything so
I just removed it.
This silences the following gcc warnings:
drivers/staging/media/dt3155v4l/dt3155v4l.c:307:2: warning: initialization from
incompatible pointer type [enabled by default]
drivers/staging/media/dt3155v4l/dt3155v4l.c:307:2: warning: (near
initialization for ‘q_ops.queue_setup’) [enabled by default]
drivers/staging/media/dt3155v4l/dt3155v4l.c:311:2: warning: initialization from
incompatible pointer type [enabled by default]
drivers/staging/media/dt3155v4l/dt3155v4l.c:311:2: warning: (near
initialization for ‘q_ops.start_streaming’) [enabled by default]
Signed-off-by: Dan Carpenter
---
Please double check that this is sufficient. I'm not very familiar with
this code.
diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c
b/drivers/staging/media/dt3155v4l/dt3155v4l.c
index 04e93c4..25c6025 100644
--- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
+++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
@@ -218,9 +218,10 @@ dt3155_start_acq(struct dt3155_priv *pd)
* driver-specific callbacks (vb2_ops)
*/
static int
-dt3155_queue_setup(struct vb2_queue *q, unsigned int *num_buffers,
- unsigned int *num_planes, unsigned long sizes[],
- void *alloc_ctxs[])
+dt3155_queue_setup(struct vb2_queue *q, const struct v4l2_format *fmt,
+ unsigned int *num_buffers, unsigned int *num_planes,
+ unsigned int sizes[], void *alloc_ctxs[])
+
{
struct dt3155_priv *pd = vb2_get_drv_priv(q);
void *ret;
@@ -262,12 +263,6 @@ dt3155_buf_prepare(struct vb2_buffer *vb)
}
static int
-dt3155_start_streaming(struct vb2_queue *q)
-{
- return 0;
-}
-
-static int
dt3155_stop_streaming(struct vb2_queue *q)
{
struct dt3155_priv *pd = vb2_get_drv_priv(q);
@@ -308,7 +303,6 @@ const struct vb2_ops q_ops = {
.wait_prepare = dt3155_wait_prepare,
.wait_finish = dt3155_wait_finish,
.buf_prepare = dt3155_buf_prepare,
- .start_streaming = dt3155_start_streaming,
.stop_streaming = dt3155_stop_streaming,
.buf_queue = dt3155_buf_queue,
};
--
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: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?
Hi Laurent, On Wed, Dec 21, 2011 at 6:55 PM, Laurent Pinchart wrote: > Hi James, > > On Wednesday 21 December 2011 04:06:33 James wrote: >> On Wed, Dec 21, 2011 at 10:50 AM, James wrote: >> > On Thu, Dec 15, 2011 at 6:10 PM, Michael Jones wrote: >> >> Hi James, >> >> >> >> Laurent has a program 'media-ctl' to set up the pipeline (see >> >> http://git.ideasonboard.org/?p=media-ctl.git). You will find many >> >> examples of its usage in the archives of this mailing list. It will >> >> look something like: >> >> media-ctl -r >> >> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]' >> >> media-ctl -l '"your-sensor-name":0 -> "OMAP3 ISP CCDC":0 [1]' >> >> >> >> you will also need to set the formats through the pipeline with >> >> 'media-ctl --set-format'. >> >> >> >> After you use media-ctl to set up the pipeline, you can use yavta to >> >> capture the data from the CCDC output (for me, this is /dev/video2). >> >> >> >> >> >> -Michael >> > >> > I encountered some obstacles with the driver testing of my monochrome >> > sensor on top of Steve's 3.0-pm branch. An NXP SC16IS750 I2C-UART >> > bridge is used to 'transform' the sensor into a I2C device. >> > >> > The PCLK, VSYNC, HSYNC (640x512, 30Hz, fixed output format) are free >> > running upon power-on the sensor unlike MT9V032 which uses the XCLKA >> > to 'power-on/off' it. >> > >> > My steps, >> > >> > 1) media-ctl -r -l '"mono640":0->"OMAP3 ISP CCDC":0:[1], "OMAP3 ISP >> > CCDC":1->"OMAP3 ISP CCDC output":0[1]' >> > >> > Resetting all links to inactive >> > Setting up link 16:0 -> 5:0 [1] >> > Setting up link 5:1 -> 6:0 [1] >> > >> > 2) media-ctl -f '"mono640":0[Y12 640x512]", "OMAP3 ISP CCDC":1[Y12 >> > 640x512]' >> > >> > Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/0 >> > Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/1 >> > >> > 3) yavta -p -f Y12 -s 640x512 -n 4 --capture=61 --skip 1 -F `media-ctl >> > -e "OMAP3 ISP CCDC output"` --file=./DCIM/Y12 >> > >> > Unsupported video format 'Y12' >> > >> > Did I missed something? > > I've just pushed a patch to the yavta repository to support Y10 and Y12. > Please update. > >> > What parameters did you supplied to yavta to test the Y10/Y12 >> > >> > Many thanks in adv. >> > Sorry if duplicated emails received. >> >> I changed the parameters for yavta from "-f Y12" to "-f Y16" >> >> yavta -p -f Y16 -s 640x512 -n 2 --capture=10 --skip 5 -F `media-ctl -e >> "OMAP3 ISP CCDC output"` --file=./DCIM/Y16 >> >> and there are 2 chunks of message at the console now and it ended with >> "Unable to request buffers: Invalid argument (22).". >> >> I've attached the logfile here. (mono640.log) >> >> Hope you can assist me to grab the raw Y12 data to file. > > -- > Regards, > > Laurent Pinchart Tried the new yavta but encountered a different situation. yavta -p -f Y12 -s 640x512 -n 2 --capture=10 --skip 5 -F `media-ctl -e "OMAP3 ISP CCDC output"` --file=./DCIM/Y12 yavta will hang for infinite time and only Ctrl+C will break out of the wait and a new error message appears. yavta: video_do_capture: calling ioctl.. ^C omap3isp omap3isp: CCDC stop timeout! I placed some debugging printf() and yavta wait at ret = ioctl(dev->fd, VIDIOC_DQBUF, &buf); Attached is the logfile (mono640.yavta-y12.1.log) What should be the remedies? Many thanks in adv. -- Regards, James root@overo:~# lsmod Module Size Used by bufferclass_ti 4976 0 omaplfb 8280 0 pvrsrvkm 155471 2 bufferclass_ti,omaplfb ipv6 229162 18 mono64010309 1 libertas_sdio 14851 0 libertas 92190 1 libertas_sdio omap3_isp 106957 0 cfg80211 161767 1 libertas v4l2_common 8885 2 mono640,omap3_isp videodev 78776 3 mono640,omap3_isp,v4l2_common media 12192 3 mono640,omap3_isp,videodev lib802115435 1 libertas firmware_class 6327 2 libertas_sdio,libertas ads784610524 0 root@overo:~# media-ctl -r -v -l '"mono640":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Resetting all links to inactive Setting up link 16:0 -> 5:0 [1] Setting up link 5:1 -> 6:0 [1] root@overo:~# media-ctl -v -f '"mono640":0[Y12 640x512], "OMAP3 ISP CCDC":1[Y12 640x512]' Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Setting up format Y12 640x512 on pad mono640 3-004d/0 overo: setting xclk to 2500 hz Format set: Y12 640x512 Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/0 Format set: Y12 640x512 overo: setting xclk to 0 hz Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/1 Format set: Y12 640x512 root@overo:~# yavta -p -f Y12 -s 640x512 -n 2 --capture=10 --skip 5 -F `media-ct l -e "OMAP3 ISP CCDC output"` --file=./DCIM/Y12 overo: setting xclk to 2500 h
Re: Add tuner_type to zl10353 config and use it for reporting signal directly from tuner.
I forgot to add that this patch depends on my previous patch "Add signal information to xc4000 tuner", without it it will not work. XC4000 tuner can measure signal level in both analog and digital and in analog mode also noise level. M. 2011/12/22 Miroslav Slugeň : > Hi, I tested it with Leadtek DTV 1800H (xc4000 version), Leadtek DTV > 2000H PLUS (xc4000) and Leadtek DVR3200H (xc4000), all have same > issue, register of AGC is always 0x3f 0xff and only if I disconect > input from card it will change for short time like it is trying to > tune AGC, but after that it will always return to 0x3 value, so > signal reporting from zl10353 demodulator register can't work. Also i > think it is bad idea to measure signal from AGC control which can't > say anything about real signal level. I tested also older cards with > xc3028 tuners and there is signal information but always about 60% > even when i change antena system gain, but for XC2028 there is no such > think like signal monitoring register, it is present only on XC4000 > and XC5000 tuners. If you want e can do some testing together, i can > give you access to my testing server. > > Dne 21. prosince 2011 22:29 Devin Heitmueller > napsal(a): >> 2011/12/21 Miroslav Slugeň : >>> XC4000 based cards are not using AGC control in normal way, so it is >>> not possible to get signal level from AGC registres of zl10353 >>> demodulator, instead of this i send previous patch to implement signal >>> level directly in xc4000 tuner and now sending patch for zl10353 to >>> implement this future for digital mode. Signal reporting is very >>> accurate and was well tested on 3 different Leadtek XC4000 cards. >> >> For what it's worth, something seems very wrong with this patch. All >> the docs I've ever seen for the Xceive components were pretty clear >> that the signal level registers are for analog only. And even in te >> case of Xceive it's a bit unusual, since most analog tuner designs >> don't have an onboard analog demodulator. >> >> If this patch really works then I guess I don't have anything against >> it. I just strongly believe that it's the wrong fix and there is >> probably some other problem this is obscuring. >> >> Devin >> >> -- >> Devin J. Heitmueller - Kernel Labs >> http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Add tuner_type to zl10353 config and use it for reporting signal directly from tuner.
Hi, I tested it with Leadtek DTV 1800H (xc4000 version), Leadtek DTV 2000H PLUS (xc4000) and Leadtek DVR3200H (xc4000), all have same issue, register of AGC is always 0x3f 0xff and only if I disconect input from card it will change for short time like it is trying to tune AGC, but after that it will always return to 0x3 value, so signal reporting from zl10353 demodulator register can't work. Also i think it is bad idea to measure signal from AGC control which can't say anything about real signal level. I tested also older cards with xc3028 tuners and there is signal information but always about 60% even when i change antena system gain, but for XC2028 there is no such think like signal monitoring register, it is present only on XC4000 and XC5000 tuners. If you want e can do some testing together, i can give you access to my testing server. Dne 21. prosince 2011 22:29 Devin Heitmueller napsal(a): > 2011/12/21 Miroslav Slugeň : >> XC4000 based cards are not using AGC control in normal way, so it is >> not possible to get signal level from AGC registres of zl10353 >> demodulator, instead of this i send previous patch to implement signal >> level directly in xc4000 tuner and now sending patch for zl10353 to >> implement this future for digital mode. Signal reporting is very >> accurate and was well tested on 3 different Leadtek XC4000 cards. > > For what it's worth, something seems very wrong with this patch. All > the docs I've ever seen for the Xceive components were pretty clear > that the signal level registers are for analog only. And even in te > case of Xceive it's a bit unusual, since most analog tuner designs > don't have an onboard analog demodulator. > > If this patch really works then I guess I don't have anything against > it. I just strongly believe that it's the wrong fix and there is > probably some other problem this is obscuring. > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] v4l2: add new pixel formats supported on dm365
On Wed, 21 Dec 2011, Laurent Pinchart wrote:
> Hi Manju,
>
> On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote:
> > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
> > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format
> > > > > > frames compressed by A-LAW alogorithm.
> > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved)
> > > > > > only.
> > > > > >
> > > > > > Signed-off-by: Manjunath Hadli
> > > > > > Cc: Laurent Pinchart
> > > > > > ---
> > > > > >
> > > > > > include/linux/videodev2.h |6 ++
> > > > > > 1 files changed, 6 insertions(+), 0 deletions(-)
> > > > >
> > > > > Could you please also document these formats in
> > > > > Documentation/DocBook/media/v4l ?
> > > >
> > > > I will. Sorry to have missed that out.
> > > >
> > > > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > > > > > index 4b752d5..969112d 100644
> > > > > > --- a/include/linux/videodev2.h
> > > > > > +++ b/include/linux/videodev2.h
> > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > > > >
> > > > > > #define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2') /* 8
> > > > > > YUV
> > > > > >
> > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
> > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line
> > > > > > uv interleaved */
> > > > > >
> > > > > > +/* Chrominance formats */
> > > > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /*
> > > > > > 8 UV 4:4 */ +
> > > > > >
> > > > > > /* two planes -- one Y, one Cr + Cb interleaved */
> > > > > > #define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12
> > > > > > Y/CbCr
> > > > > >
> > > > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V', '2',
> > > > > > '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct
> > > > > > v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R',
> > > > > > 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM
> > > > > > compressed to 8 bits */ #define V4L2_PIX_FMT_SGRBG10DPCM8
> > > > > > v4l2_fourcc('B', 'D', '1', '0')
> > > > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > > > > +
> > > > >
> > > > > That's not very future-proof, how would you describe SGBRG10ALAW8
> > > > > for instance ?
> > > > >
> > > > > Maybe it's time to standardize FOURCCs for Bayer new formats. We
> > > > > have 4 characters, we could start with 'B' to denote Bayer, followed
> > > > > by one character for the order, one for the compression, and one for
> > > > > the number of bits.
> > > >
> > > > I agree.
> > > > May be ('B', 'G', 'A', '8') is fine for the above?
> > >
> > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B',
> > > 'g', 'G' and 'R' respectively for the second character. The third
> > > character would be 'A' for A-law and 'D' for DPCM, and the fourth
> > > character could describe the bus width in bits from 0 to 15 with '0' -
> > > '9', 'A' - 'F'. However, I suspect that we will need 16-bit wide busses
> > > for raw Bayer at some point, and a 0 width is definitely not useful. We
> > > could thus offset the width by some value.
> > >
> > > This is just a preliminary idea, I'm open to suggestions.
> >
> > I think it is a very good suggestion that we can go with.
> > B : BGGR
> > g : GBRG
> > G : GRBG
> > R : RGGB
> >
> > and 0-F can signify 1-16.
>
> Hans, Guennadi, Sakari, any opinion on that as well ?
Is there any risk of confusion, if we don't reserve the first character
for 'B'? I'm just trying to avoid mixed cases, I'm not a great fan of
those;-) What if we use the first two characters for the order like "GR",
"GB",... AFAICS, 'G' so far only also occurs in GREY and various RGB* /
BGR* / ... formats, which we wouldn't be confusing with. We could further
reduce confusion, if we use some other character for A-law ('L' or 'W'?)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 v4] v4l: Add driver for Micron MT9M032 camera sensor
Hi Martin, On Wednesday 21 December 2011 08:43:47 mar...@neutronstar.dyndns.org wrote: > On Wed, Dec 21, 2011 at 02:06:20AM +0100, Laurent Pinchart wrote: > > On Saturday 17 December 2011 11:10:55 Martin Hostettler wrote: > > > The MT9M032 is a parallel 1.6MP sensor from Micron controlled through > > > I2C. > > > > > > The driver creates a V4L2 subdevice. It currently supports cropping, > > > gain, exposure and v/h flipping controls in monochrome mode with an > > > external pixel clock. > > > > There are still several small issues with this driver. Things like not > > using the module_i2c_driver() macro, some indentation, magic values in > > registers (I'm trying to get more documentation), PLL setup (although > > that can be fixed later, it's not a requirement for the driver to be > > mainlined), ... > > > > Would you be fine if I took the patch in my tree, fixed the remaining > > issues and pushed it to mainline for v3.4 (the time frame is too short > > for v3.3) ? > > Sure, Thank you. > that would be much appreciated. Thanks for reviewing and takeing these > patches! You're welcome. > > Authorship will of course be preserved. The alternative would be to go > > through review/modification cycles, and I don't want to waste too much > > of your time > > > > :-) -- 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
Re: [PATCH 2/2] v4l2: add new pixel formats supported on dm365
Hi Manju,
On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote:
> On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
> > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format
> > > > > frames compressed by A-LAW alogorithm.
> > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved)
> > > > > only.
> > > > >
> > > > > Signed-off-by: Manjunath Hadli
> > > > > Cc: Laurent Pinchart
> > > > > ---
> > > > >
> > > > > include/linux/videodev2.h |6 ++
> > > > > 1 files changed, 6 insertions(+), 0 deletions(-)
> > > >
> > > > Could you please also document these formats in
> > > > Documentation/DocBook/media/v4l ?
> > >
> > > I will. Sorry to have missed that out.
> > >
> > > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > > > > index 4b752d5..969112d 100644
> > > > > --- a/include/linux/videodev2.h
> > > > > +++ b/include/linux/videodev2.h
> > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > > >
> > > > > #define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2') /* 8
> > > > > YUV
> > > > >
> > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
> > > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line
> > > > > uv interleaved */
> > > > >
> > > > > +/* Chrominance formats */
> > > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /*
> > > > > 8 UV 4:4 */ +
> > > > >
> > > > > /* two planes -- one Y, one Cr + Cb interleaved */
> > > > > #define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12
> > > > > Y/CbCr
> > > > >
> > > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V', '2',
> > > > > '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct
> > > > > v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R',
> > > > > 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM
> > > > > compressed to 8 bits */ #define V4L2_PIX_FMT_SGRBG10DPCM8
> > > > > v4l2_fourcc('B', 'D', '1', '0')
> > > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > > > +
> > > >
> > > > That's not very future-proof, how would you describe SGBRG10ALAW8
> > > > for instance ?
> > > >
> > > > Maybe it's time to standardize FOURCCs for Bayer new formats. We
> > > > have 4 characters, we could start with 'B' to denote Bayer, followed
> > > > by one character for the order, one for the compression, and one for
> > > > the number of bits.
> > >
> > > I agree.
> > > May be ('B', 'G', 'A', '8') is fine for the above?
> >
> > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B',
> > 'g', 'G' and 'R' respectively for the second character. The third
> > character would be 'A' for A-law and 'D' for DPCM, and the fourth
> > character could describe the bus width in bits from 0 to 15 with '0' -
> > '9', 'A' - 'F'. However, I suspect that we will need 16-bit wide busses
> > for raw Bayer at some point, and a 0 width is definitely not useful. We
> > could thus offset the width by some value.
> >
> > This is just a preliminary idea, I'm open to suggestions.
>
> I think it is a very good suggestion that we can go with.
> B : BGGR
> g : GBRG
> G : GRBG
> R : RGGB
>
> and 0-F can signify 1-16.
Hans, Guennadi, Sakari, any opinion on that as well ?
--
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
Re: [PATCH 1/2] media: add new mediabus format enums for dm365
Hi Manju,
On Wednesday 21 December 2011 14:54:18 Hadli, Manjunath wrote:
> On Wed, Dec 21, 2011 at 05:28:31, Laurent Pinchart wrote:
> > On Friday 16 December 2011 15:20:24 Hadli, Manjunath wrote:
> > > On Thu, Dec 15, 2011 at 18:32:44, Laurent Pinchart wrote:
> > > > On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote:
> > > > > add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into
> > > > > mbus_pixel_code to represent A-LAW compressed Bayer format. This
> > > > > corresponds to pixel format - V4L2_PIX_FMT_SGRBG10ALAW8.
> > > > > add UV8 and NV12 ( Y and C separate with UV interleaved) which are
> > > > > supported on dm365.
> > > > >
> > > > > Signed-off-by: Manjunath Hadli
> > > > > Cc: Laurent Pinchart
> > > > > ---
> > > > >
> > > > > include/linux/v4l2-mediabus.h | 10 --
> > > > > 1 files changed, 8 insertions(+), 2 deletions(-)
> > > >
> > > > Please also update the documentation in
> > > > Documentation/DocBook/media/v4l.
> > > >
> > > > > diff --git a/include/linux/v4l2-mediabus.h
> > > > > b/include/linux/v4l2-mediabus.h index 5ea7f75..d408654 100644
> > > > > --- a/include/linux/v4l2-mediabus.h
> > > > > +++ b/include/linux/v4l2-mediabus.h
> > > > > @@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode {
> > > > >
> > > > > V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
> > > > > V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
> > > > >
> > > > > - /* YUV (including grey) - next is 0x2014 */
> > > > > + /* YUV (including grey) - next is 0x2016 */
> > > > >
> > > > > V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
> > > > > V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
> > > > > V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
> > > > >
> > > > > @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode {
> > > > >
> > > > > V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
> > > > > V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
> > > > > V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
> > > > >
> > > > > + V4L2_MBUS_FMT_NV12_1X20 = 0x2014,
> > > > > + V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
> > > >
> > > > NV12, on the bus ? How does that work ? (The documentation should
> > > > answer my question :-))
> > >
> > > Well, this is on the internal bus not exposed outside, but
> > > nevertheless bus between two subdevs or two independent hardware
> > > blocks. For example Resizer supports NV12 on its pad. Is there any
> > > other way to treat this?
> >
> > How is NV12 transferred on the bus in that case ? Are all luma samples
> > transferred first, followed by all chroma samples ?
>
> It uses parallel bus of 16 bits, where Y and C are transmitted
> simultaneously on 8 bits each. NV12 uses a dummy C byte for every valid
> one.
> So I guess we call it V4L2_MBUS_FMT_YDYC_1X16 or V4L2_MBUS_FMT_YCYD_1X16?
> That way we will be able to document the format in the documentation also.
That sounds good (YDYC8_1X16 to be precise). Hans, Guennadi, Sakari, any
opinion ?
--
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
Re: [PATCH] [media] hdpvr: update picture controls to support firmware versions > 0.15
On Mon, Nov 7, 2011 at 7:54 PM, Taylor Ralph wrote: > On Mon, Nov 7, 2011 at 7:21 AM, Mauro Carvalho Chehab > wrote: >> Em 21-10-2011 01:33, Taylor Ralph escreveu: >>> On Thu, Oct 20, 2011 at 3:26 PM, Taylor Ralph >>> wrote: On Thu, Oct 20, 2011 at 2:14 PM, Devin Heitmueller wrote: > On Thu, Oct 20, 2011 at 1:08 PM, Janne Grunau wrote: >> I think such scenario is unlikely but I don't know it for sure and >> I don't want to force anyone to test every firmware version. >> Ignoring them for firmware version < 16 should be safe since we assume >> they had no effect. Returning -EINVAL might break API-ignoring >> applications written with the HD PVR in mind but I think it's a better >> approach than silently ignoring those controls. > > At this point, let's just make it so that the old behavior is > unchanged for old firmwares, meaning from both an API standpoint as > well as what the values are. At some point if somebody cares enough > to go back and fix the support so that the controls actually work with > old firmwares, they can take that up as a separate task. In reality, > it is likely that nobody will ever do that, as the "easy answer" is > just to upgrade to firmware 16. > > Taylor, could you please tweak your patch to that effect and resubmit? > Sure, I'll try to get to it tonight and have it tested. >>> >>> OK, I've updated the patch per your requests. I made this patch >>> against the latest kernel source but I'm unable to test since my >>> 2.6.32 kernel has symbol issues with the new v4l code. >> >> Please, add your Signed-off-by: to the patch. This is a requirement for >> it to be accepted upstream[1]. >> >> Thanks, >> Mauro >> >> [1] See: >> http://linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Developer.27s_Certificate_of_Origin_1.1 >> >>> >>> Regards. >>> -- >>> Taylor >> >> > > Sorry about that. The updated patch is attached. > > Thanks. > -- > Taylor Ping. Has this patch been committed yet? Thanks. -- Taylor -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Fixed detection of EMP202 audio chip. Some versions have an id of 0x83847650 instead of 0xffffffff.
On Wednesday 21 Dec 2011 15:24:43 you wrote:
> On Wednesday 21 Dec 2011 11:54:33 you wrote:
> > On 20-12-2011 19:45, Gareth Williams wrote:
> > > Signed-off-by: Gareth Williams
> > >
> > > Honestech Vidbox NW03 has a EMP202 audio chip with a different
> > > Vendor
> > > ID.
> > >
> > > Apparently, it is the same with the Gadmei ITV380:
> > > http://linuxtv.org/wiki/index.php/Gadmei_USB_TVBox_UTV380
> > >
> > > ---
> > >
> > > linux/drivers/media/video/em28xx/em28xx-core.c |2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/linux/drivers/media/video/em28xx/em28xx-core.c
> > > b/linux/drivers/media/video/em28xx/em28xx-core.c index
> > > 804a4ab..2982a06
> > > 100644
> > > --- a/linux/drivers/media/video/em28xx/em28xx-core.c
> > > +++ b/linux/drivers/media/video/em28xx/em28xx-core.c
> > > @@ -568,7 +568,7 @@ int em28xx_audio_setup(struct em28xx *dev)
> > >
> > > em28xx_warn("AC97 features = 0x%04x\n", feat);
> > >
> > > /* Try to identify what audio processor we have */
> > >
> > > - if ((vid == 0x) && (feat == 0x6a90))
> > > + if (((vid == 0x) || (vid == 0x83847650)) && (feat ==
> > > 0x6a90))
> >
> > Are you sure you don't have, instead a STAC9750? 0x83647650 is the code
> > for this chip. Did you open your device to be sure it is really an
> > em202?
> >
> > Vendors are free to put whatever AC97 chip they want. Each of them have
> > their own differences (different sample rate, different volume controls,
> > etc).
> >
> > While miss-identifying it may work for your usecase, it will fail for
> > other usecases. The good news is that, in general, the datasheets for
> > AC97 mixers are generally easy to find on Google. Most vendors release
> > them publicly.
> >
> > Regards,
> > Mauro
>
> I opened the box in order to check the chip.
>
> I've opened it again now and can confirm that the chip has the following
> markings:-
>
> eMPIA
> TECHNOLOGY
> EMP202
> T10189
> 1110
>
> I've read the EMP202 datasheet and also noticed that it should have
> for the vendor id which is what the driver was originally looking for.
>
> According to the LinuxTV Wiki entry, the Gadmei ITV380 also has the same
> issue in that it also has an EMP202 inside and a vendor Id of the STAC9750.
>
> Regards,
>
> Gareth
Appologies for double-posting!
I've looked through the datasheets for both devices and the STAC9750 returns a
0x6990 when reading the RESET register (0x00) whereas the EMP202 returns
0x6a90. The driver checks for 0x6a90 in order to decide whether the audio
chip is an EMP202 therefore there should be no issues with the identical
Vendor IDs.
Regards,
Gareth
--
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: Add tuner_type to zl10353 config and use it for reporting signal directly from tuner.
2011/12/21 Miroslav Slugeň : > XC4000 based cards are not using AGC control in normal way, so it is > not possible to get signal level from AGC registres of zl10353 > demodulator, instead of this i send previous patch to implement signal > level directly in xc4000 tuner and now sending patch for zl10353 to > implement this future for digital mode. Signal reporting is very > accurate and was well tested on 3 different Leadtek XC4000 cards. For what it's worth, something seems very wrong with this patch. All the docs I've ever seen for the Xceive components were pretty clear that the signal level registers are for analog only. And even in te case of Xceive it's a bit unusual, since most analog tuner designs don't have an onboard analog demodulator. If this patch really works then I guess I don't have anything against it. I just strongly believe that it's the wrong fix and there is probably some other problem this is obscuring. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Add tuner_type to zl10353 config and use it for reporting signal directly from tuner.
XC4000 based cards are not using AGC control in normal way, so it is
not possible to get signal level from AGC registres of zl10353
demodulator, instead of this i send previous patch to implement signal
level directly in xc4000 tuner and now sending patch for zl10353 to
implement this future for digital mode. Signal reporting is very
accurate and was well tested on 3 different Leadtek XC4000 cards.
From 76af396e53c1dcf499f5c016ab8ddd95a4856992 Mon Sep 17 00:00:00 2001
From: Miroslav
Date: Wed, 21 Dec 2011 21:55:58 +0100
Subject: [PATCH] This patch adds tuner_type config value for zl10353 demodulator and
fill it for Leadtek based xc4000 tuners. Extra value should be used
in future for tuner specific functions in zl10353 demodulator, first
usage is now for directly reading signal strength from xc4000 tuner
which is very accurate instead of reading signal from AGC registers.
---
drivers/media/dvb/frontends/zl10353.c | 12 +---
drivers/media/dvb/frontends/zl10353.h |3 +++
drivers/media/video/cx23885/cx23885-dvb.c | 10 +-
drivers/media/video/cx88/cx88-dvb.c |9 -
4 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb/frontends/zl10353.c b/drivers/media/dvb/frontends/zl10353.c
index adbbf6d..7ea3a2e 100644
--- a/drivers/media/dvb/frontends/zl10353.c
+++ b/drivers/media/dvb/frontends/zl10353.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "dvb_frontend.h"
#include "zl10353_priv.h"
@@ -521,10 +522,15 @@ static int zl10353_read_signal_strength(struct dvb_frontend *fe, u16 *strength)
{
struct zl10353_state *state = fe->demodulator_priv;
- u16 signal = zl10353_read_register(state, AGC_GAIN_1) << 10 |
- zl10353_read_register(state, AGC_GAIN_0) << 2 | 3;
+ /* for XC4000 we can read exact signal value directly */
+ if (state->config.tuner_type == TUNER_XC4000) {
+ fe->ops.tuner_ops.get_rf_strength(fe, strength);
+ } else {
+ u16 signal = zl10353_read_register(state, AGC_GAIN_1) << 10 |
+ zl10353_read_register(state, AGC_GAIN_0) << 2 | 3;
- *strength = ~signal;
+ *strength = ~signal;
+ }
return 0;
}
diff --git a/drivers/media/dvb/frontends/zl10353.h b/drivers/media/dvb/frontends/zl10353.h
index 6e3ca9e..64ecbae 100644
--- a/drivers/media/dvb/frontends/zl10353.h
+++ b/drivers/media/dvb/frontends/zl10353.h
@@ -45,6 +45,9 @@ struct zl10353_config
/* clock control registers (0x51-0x54) */
u8 clock_ctl_1; /* default: 0x46 */
u8 pll_0;/* default: 0x15 */
+
+ /* for tuner specific functions */
+ u8 tuner_type;
};
#if defined(CONFIG_DVB_ZL10353) || (defined(CONFIG_DVB_ZL10353_MODULE) && defined(MODULE))
diff --git a/drivers/media/video/cx23885/cx23885-dvb.c b/drivers/media/video/cx23885/cx23885-dvb.c
index f0482b2..98015fe 100644
--- a/drivers/media/video/cx23885/cx23885-dvb.c
+++ b/drivers/media/video/cx23885/cx23885-dvb.c
@@ -408,6 +408,14 @@ static struct zl10353_config dvico_fusionhdtv_xc3028 = {
.disable_i2c_gate_ctrl = 1,
};
+static struct zl10353_config leadtek_xc4000_config = {
+ .demod_address = 0x0f,
+ .if2 = 45600,
+ .no_tuner = 1,
+ .disable_i2c_gate_ctrl = 1,
+ .tuner_type= TUNER_XC4000,
+};
+
static struct stv0900_reg stv0900_ts_regs[] = {
{ R0900_TSGENERAL, 0x00 },
{ R0900_P1_TSSPEED, 0x40 },
@@ -926,7 +934,7 @@ static int dvb_register(struct cx23885_tsport *port)
i2c_bus = &dev->i2c_bus[0];
fe0->dvb.frontend = dvb_attach(zl10353_attach,
- &dvico_fusionhdtv_xc3028,
+ &leadtek_xc4000_config,
&i2c_bus->i2c_adap);
if (fe0->dvb.frontend != NULL) {
struct dvb_frontend *fe;
diff --git a/drivers/media/video/cx88/cx88-dvb.c b/drivers/media/video/cx88/cx88-dvb.c
index 592f3aa..a62ca76 100644
--- a/drivers/media/video/cx88/cx88-dvb.c
+++ b/drivers/media/video/cx88/cx88-dvb.c
@@ -540,6 +540,13 @@ static const struct zl10353_config cx88_pinnacle_hybrid_pctv = {
.if2 = 45600,
};
+static const struct zl10353_config leadtek_xc4000_config = {
+ .demod_address = (0x1e >> 1),
+ .no_tuner = 1,
+ .if2 = 45600,
+ .tuner_type= TUNER_XC4000,
+};
+
static const struct zl10353_config cx88_geniatech_x8000_mt = {
.demod_address = (0x1e >> 1),
.no_tuner = 1,
@@ -1342,7 +1349,7 @@ static int dvb_register(struct cx8802_dev *dev)
case CX88_BOARD_WINFAST_DTV1800H_XC4000:
case CX88_BOARD_WINFAST_DTV2000H_PLUS:
fe0->dvb.frontend = dvb_attach(zl10353_attach,
- &cx88_pinnacle_hybrid_pctv,
+ &leadtek_xc4000_config,
&core->i2c_adap);
if (fe0->dvb.frontend) {
struct xc4000_config cfg = {
--
1.7.2.3
Re: [RFC PATCH v1 5/7] media: v4l2: introduce two IOCTLs for face detection
Hi Ming,
On 12/14/2011 04:57 PM, Ming Lei wrote:
> Hi,
>
> On Wed, Dec 14, 2011 at 11:34 PM, Sakari Ailus wrote:
>
>>> + case VIDIOC_G_FD_RESULT:
>>> + {
>>> + struct v4l2_fd_result *fr = arg;
>>> +
>>> + if (!ops->vidioc_g_fd_result)
>>> + break;
>>> +
>>> + ret = ops->vidioc_g_fd_result(file, fh, fr);
>>> +
>>> + dbgarg(cmd, "index=%d", fr->buf_index);
>>> + break;
>>> + }
>>> + case VIDIOC_G_FD_COUNT:
>>> + {
>>> + struct v4l2_fd_count *fc = arg;
>>> +
>>> + if (!ops->vidioc_g_fd_count)
>>> + break;
>>> +
>>> + ret = ops->vidioc_g_fd_count(file, fh, fc);
>>> +
>>> + dbgarg(cmd, "index=%d", fc->buf_index);
>>> + break;
>>> + }
>>
>> The patch description tells these ioctls may be called between... what? I'd
>
> In fact, these ioctls should be called after return from poll.
>
>> think such information could be better provided as events.
>
> Yes, I still think so, but the length of returned data is variant, also
> event has the 64 byte length's limitation.
Right, I'm afraid it's not even enough for single object description.
I have been thinking about adding variable payload support to v4l2 event API.
>> How is face detection enabled or disabled?
>
> Currently, streaming on will trigger detection enabling, and streaming off
> will trigger detection disabling.
We would need to develop a boolean control for this I think, this seems one of
the basic features for the configuration interface.
>> Could you detect other objects than faces?
>
> The -v2 has been extended to detect objects, not limited to faces.
>
>> Would events be large enough to deliver you the necessary data? We could
>
> Looks like event(64 bytes) is not large enough to deliver the data.
>
>> also consider delivering the information as a data structure on a separate
>> plane.
>
> Could you let me know how to do it?
You would have to use multi-planar interface for that, which would introduce
additional complexity at user interface. Moreover variable plane count is not
supported in vb2. Relatively significant effort is required to add this IMHO.
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Wed, Dec 21, 2011 at 05:27:16PM +, Arnd Bergmann wrote: > On Tuesday 20 December 2011, Daniel Vetter wrote: > > It also sounds like that at least for proper userspace mmap support we'd > > need some dma api extensions on at least arm, and that might take a while > > ... > > I think it's actually the opposite -- you'd need dma api extensions on > everything else other than arm, which already has dma_mmap_coherent() > and dma_mmap_writecombine() for this purpose. Yeah, that's actually what I wanted to say, but failed at ... Another thing is that at least for i915, _writecombine isn't what we want actually because: - It won't work anyway cause i915 maps stuff cached and does the flushing itself and x86 PAT doesn't support mixed mappings (kinda like arm). - It isn't actually enough, there's another hidden buffer between the memory controller interface and the gpu that i915 manually flushes (because even a readback on a wc mapping doesn't flush things in there). So I assume we'll have plenty of funny beating out a good api for cpu access ;-) Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- 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:Wed Dec 21 19:00:21 CET 2011 git hash:875e2e3edf48a206c64195666cf408dd3d119137 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The 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
EasyCAP with identifiers
I just got an EasyCAP usb device with component and S-video inputs, and it doesn't match what I was expecting from reading lists about drivers. It identifies as 1f71:3306 and is not recognized by my Ubuntu system running 3.0.0. 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:34:47 UTC 2011 i686 i686 i386 GNU/Linux Searching for that usb identifier turned up threads about another device called Gadmei USB TVBox. I also found references to the em28xx driver, so I built and installed git://linuxtv.org/media_build.git, but this did not help. The id is not on the list here: http://linuxtv.org/wiki/index.php/Em28xx_devices Anyone have a good suggestion what to do next? I think I covered the basics, but I'm definitely no expert, so apologies if I overlooked something simple. -- 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: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tuesday 20 December 2011, Daniel Vetter wrote: > > I'm thinking for a first version, we can get enough mileage out of it by > > saying: > > 1) only exporter can mmap to userspace > > 2) only importers that do not need CPU access to buffer.. Ok, that sounds possible. The alternative to this would be: 1) The exporter has to use dma_alloc_coherent() or dma_alloc_writecombine() to allocate the buffer 2. Every user space mapping has to go through dma_mmap_coherent() or dma_mmap_writecombine() We can extend the rules later to allow either one after we have gained some experience using it. > > This way we can get dmabuf into the kernel, maybe even for 3.3. I > > know there are a lot of interesting potential uses where this stripped > > down version is good enough. It probably isn't the final version, > > maybe more features are added over time to deal with importers that > > need CPU access to buffer, sync object, etc. But we have to start > > somewhere. > > I agree with Rob here - I think especially for the coherency discussion > some actual users of dma_buf on a bunch of insane platforms (i915 > qualifies here too, because we do some cacheline flushing behind everyones > back) would massively help in clarifying things. Yes, agreed. > It also sounds like that at least for proper userspace mmap support we'd > need some dma api extensions on at least arm, and that might take a while > ... I think it's actually the opposite -- you'd need dma api extensions on everything else other than arm, which already has dma_mmap_coherent() and dma_mmap_writecombine() for this purpose. Arnd -- 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/3] V4L: mt9m111: properly implement .s_crop and .s_fmt(), reset on STREAMON
mt9m111 camera sensors support cropping and scaling. The current
implementation is broken. For example, .s_crop() sets output frame sizes
instead of the input cropping window. This patch adds a proper implementation
of these methods. Besides it adds a sensor-disable and -enable operations
on first open() and last close() respectively, to save power while closed and
to return the camera to the default power-on state.
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/video/mt9m111.c | 226
1 files changed, 113 insertions(+), 113 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index 797660b..ba1ea8c 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -185,19 +185,6 @@ struct mt9m111_datafmt {
enum v4l2_colorspacecolorspace;
};
-/* Find a data format by a pixel code in an array */
-static const struct mt9m111_datafmt *mt9m111_find_datafmt(
- enum v4l2_mbus_pixelcode code, const struct mt9m111_datafmt *fmt,
- int n)
-{
- int i;
- for (i = 0; i < n; i++)
- if (fmt[i].code == code)
- return fmt + i;
-
- return NULL;
-}
-
static const struct mt9m111_datafmt mt9m111_colour_fmts[] = {
{V4L2_MBUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_JPEG},
{V4L2_MBUS_FMT_YVYU8_2X8, V4L2_COLORSPACE_JPEG},
@@ -220,7 +207,9 @@ struct mt9m111 {
int model; /* V4L2_IDENT_MT9M111 or V4L2_IDENT_MT9M112 code
* from v4l2-chip-ident.h */
struct mt9m111_context *ctx;
- struct v4l2_rect rect;
+ struct v4l2_rect rect; /* cropping rectangle */
+ int width; /* output */
+ int height; /* sizes */
struct mutex power_lock; /* lock to protect power_count */
int power_count;
const struct mt9m111_datafmt *fmt;
@@ -228,6 +217,18 @@ struct mt9m111 {
unsigned char datawidth;
};
+/* Find a data format by a pixel code */
+static const struct mt9m111_datafmt *mt9m111_find_datafmt(struct mt9m111
*mt9m111,
+ enum v4l2_mbus_pixelcode code)
+{
+ int i;
+ for (i = 0; i < ARRAY_SIZE(mt9m111_colour_fmts); i++)
+ if (mt9m111_colour_fmts[i].code == code)
+ return mt9m111_colour_fmts + i;
+
+ return mt9m111->fmt;
+}
+
static struct mt9m111 *to_mt9m111(const struct i2c_client *client)
{
return container_of(i2c_get_clientdata(client), struct mt9m111, subdev);
@@ -316,43 +317,49 @@ static int mt9m111_set_context(struct mt9m111 *mt9m111,
}
static int mt9m111_setup_rect_ctx(struct mt9m111 *mt9m111,
- struct v4l2_rect *rect, struct mt9m111_context *ctx)
+ struct mt9m111_context *ctx, struct v4l2_rect *rect,
+ unsigned int width, unsigned int height)
{
struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
- int ret = mt9m111_reg_write(client, ctx->reducer_xzoom,
MT9M111_MAX_WIDTH);
+ int ret = mt9m111_reg_write(client, ctx->reducer_xzoom, rect->width);
if (!ret)
- ret = mt9m111_reg_write(client, ctx->reducer_yzoom,
MT9M111_MAX_HEIGHT);
+ ret = mt9m111_reg_write(client, ctx->reducer_yzoom,
rect->height);
if (!ret)
- ret = mt9m111_reg_write(client, ctx->reducer_xsize,
rect->width);
+ ret = mt9m111_reg_write(client, ctx->reducer_xsize, width);
if (!ret)
- ret = mt9m111_reg_write(client, ctx->reducer_ysize,
rect->height);
+ ret = mt9m111_reg_write(client, ctx->reducer_ysize, height);
return ret;
}
-static int mt9m111_setup_rect(struct mt9m111 *mt9m111,
- struct v4l2_rect *rect)
+static int mt9m111_setup_geometry(struct mt9m111 *mt9m111, struct v4l2_rect
*rect,
+ int width, int height, enum v4l2_mbus_pixelcode code)
{
struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
int ret;
- bool is_raw_format = mt9m111->fmt->code == V4L2_MBUS_FMT_SBGGR8_1X8 ||
- mt9m111->fmt->code == V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE;
ret = reg_write(COLUMN_START, rect->left);
if (!ret)
ret = reg_write(ROW_START, rect->top);
- if (is_raw_format) {
- if (!ret)
- ret = reg_write(WINDOW_WIDTH, rect->width);
- if (!ret)
- ret = reg_write(WINDOW_HEIGHT, rect->height);
- } else {
+ if (!ret)
+ ret = reg_write(WINDOW_WIDTH, rect->width);
+ if (!ret)
+ ret = reg_write(WINDOW_HEIGHT, rect->height);
+
+ if (code != V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE) {
+ /* IFP in use, down-scaling possible */
if (!ret)
- ret = mt9m111_setup_r
[PATCH 1/3] V4L: mt9m111: cleanly separate register contexts
Cleanly separating register contexts A and B will allow us to configure
the contexts independently.
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/video/mt9m111.c | 137 +++--
1 files changed, 76 insertions(+), 61 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index 258adfd..54edb6b4 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -139,6 +139,46 @@
#define MT9M111_MAX_HEIGHT 1024
#define MT9M111_MAX_WIDTH 1280
+struct mt9m111_context {
+ u16 read_mode;
+ u16 blanking_h;
+ u16 blanking_v;
+ u16 reducer_xzoom;
+ u16 reducer_yzoom;
+ u16 reducer_xsize;
+ u16 reducer_ysize;
+ u16 output_fmt_ctrl2;
+ u16 control;
+};
+
+static struct mt9m111_context context_a = {
+ .read_mode = MT9M111_READ_MODE_A,
+ .blanking_h = MT9M111_HORIZONTAL_BLANKING_A,
+ .blanking_v = MT9M111_VERTICAL_BLANKING_A,
+ .reducer_xzoom = MT9M111_REDUCER_XZOOM_A,
+ .reducer_yzoom = MT9M111_REDUCER_YZOOM_A,
+ .reducer_xsize = MT9M111_REDUCER_XSIZE_A,
+ .reducer_ysize = MT9M111_REDUCER_YSIZE_A,
+ .output_fmt_ctrl2 = MT9M111_OUTPUT_FORMAT_CTRL2_A,
+ .control= MT9M111_CTXT_CTRL_RESTART,
+};
+
+static struct mt9m111_context context_b = {
+ .read_mode = MT9M111_READ_MODE_B,
+ .blanking_h = MT9M111_HORIZONTAL_BLANKING_B,
+ .blanking_v = MT9M111_VERTICAL_BLANKING_B,
+ .reducer_xzoom = MT9M111_REDUCER_XZOOM_B,
+ .reducer_yzoom = MT9M111_REDUCER_YZOOM_B,
+ .reducer_xsize = MT9M111_REDUCER_XSIZE_B,
+ .reducer_ysize = MT9M111_REDUCER_YSIZE_B,
+ .output_fmt_ctrl2 = MT9M111_OUTPUT_FORMAT_CTRL2_B,
+ .control= MT9M111_CTXT_CTRL_RESTART |
+ MT9M111_CTXT_CTRL_DEFECTCOR_B | MT9M111_CTXT_CTRL_RESIZE_B |
+ MT9M111_CTXT_CTRL_CTRL2_B | MT9M111_CTXT_CTRL_GAMMA_B |
+ MT9M111_CTXT_CTRL_READ_MODE_B | MT9M111_CTXT_CTRL_VBLANK_SEL_B |
+ MT9M111_CTXT_CTRL_HBLANK_SEL_B,
+};
+
/* MT9M111 has only one fixed colorspace per pixelcode */
struct mt9m111_datafmt {
enum v4l2_mbus_pixelcodecode;
@@ -173,18 +213,13 @@ static const struct mt9m111_datafmt mt9m111_colour_fmts[]
= {
{V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE, V4L2_COLORSPACE_SRGB},
};
-enum mt9m111_context {
- HIGHPOWER = 0,
- LOWPOWER,
-};
-
struct mt9m111 {
struct v4l2_subdev subdev;
struct v4l2_ctrl_handler hdl;
struct v4l2_ctrl *gain;
int model; /* V4L2_IDENT_MT9M111 or V4L2_IDENT_MT9M112 code
* from v4l2-chip-ident.h */
- enum mt9m111_context context;
+ struct mt9m111_context *ctx;
struct v4l2_rect rect;
struct mutex power_lock; /* lock to protect power_count */
int power_count;
@@ -275,35 +310,33 @@ static int mt9m111_reg_mask(struct i2c_client *client,
const u16 reg,
}
static int mt9m111_set_context(struct mt9m111 *mt9m111,
- enum mt9m111_context ctxt)
+ struct mt9m111_context *ctx)
{
struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
- int valB = MT9M111_CTXT_CTRL_RESTART | MT9M111_CTXT_CTRL_DEFECTCOR_B
- | MT9M111_CTXT_CTRL_RESIZE_B | MT9M111_CTXT_CTRL_CTRL2_B
- | MT9M111_CTXT_CTRL_GAMMA_B | MT9M111_CTXT_CTRL_READ_MODE_B
- | MT9M111_CTXT_CTRL_VBLANK_SEL_B
- | MT9M111_CTXT_CTRL_HBLANK_SEL_B;
- int valA = MT9M111_CTXT_CTRL_RESTART;
-
- if (ctxt == HIGHPOWER)
- return reg_write(CONTEXT_CONTROL, valB);
- else
- return reg_write(CONTEXT_CONTROL, valA);
+ return reg_write(CONTEXT_CONTROL, ctx->control);
+}
+
+static int mt9m111_setup_rect_ctx(struct mt9m111 *mt9m111,
+ struct v4l2_rect *rect, struct mt9m111_context *ctx)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
+ int ret = mt9m111_reg_write(client, ctx->reducer_xzoom,
MT9M111_MAX_WIDTH);
+ if (!ret)
+ ret = mt9m111_reg_write(client, ctx->reducer_yzoom,
MT9M111_MAX_HEIGHT);
+ if (!ret)
+ ret = mt9m111_reg_write(client, ctx->reducer_xsize,
rect->width);
+ if (!ret)
+ ret = mt9m111_reg_write(client, ctx->reducer_ysize,
rect->height);
+ return ret;
}
static int mt9m111_setup_rect(struct mt9m111 *mt9m111,
struct v4l2_rect *rect)
{
struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
- int ret, is_raw_format;
- int width = rect->width;
- int height = rect->height;
-
- if (mt9m111->fmt->code == V4L
[PATCH 2/3] V4L: mt9m111: power down most circuits when suspended
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/video/mt9m111.c | 34 ++
1 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index 54edb6b4..797660b 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -226,7 +226,6 @@ struct mt9m111 {
const struct mt9m111_datafmt *fmt;
int lastpage; /* PageMap cache value */
unsigned char datawidth;
- unsigned int powered:1;
};
static struct mt9m111 *to_mt9m111(const struct i2c_client *client)
@@ -360,12 +359,7 @@ static int mt9m111_setup_rect(struct mt9m111 *mt9m111,
static int mt9m111_enable(struct mt9m111 *mt9m111)
{
struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
- int ret;
-
- ret = reg_set(RESET, MT9M111_RESET_CHIP_ENABLE);
- if (!ret)
- mt9m111->powered = 1;
- return ret;
+ return reg_write(RESET, MT9M111_RESET_CHIP_ENABLE);
}
static int mt9m111_reset(struct mt9m111 *mt9m111)
@@ -751,9 +745,20 @@ static int mt9m111_s_ctrl(struct v4l2_ctrl *ctrl)
static int mt9m111_suspend(struct mt9m111 *mt9m111)
{
+ struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
+ int ret;
+
v4l2_ctrl_s_ctrl(mt9m111->gain, mt9m111_get_global_gain(mt9m111));
- return 0;
+ ret = reg_set(RESET, MT9M111_RESET_RESET_MODE);
+ if (!ret)
+ ret = reg_set(RESET, MT9M111_RESET_RESET_SOC |
+ MT9M111_RESET_OUTPUT_DISABLE |
+ MT9M111_RESET_ANALOG_STANDBY);
+ if (!ret)
+ ret = reg_clear(RESET, MT9M111_RESET_CHIP_ENABLE);
+
+ return ret;
}
static void mt9m111_restore_state(struct mt9m111 *mt9m111)
@@ -766,15 +771,12 @@ static void mt9m111_restore_state(struct mt9m111 *mt9m111)
static int mt9m111_resume(struct mt9m111 *mt9m111)
{
- int ret = 0;
+ int ret = mt9m111_enable(mt9m111);
+ if (!ret)
+ ret = mt9m111_reset(mt9m111);
+ if (!ret)
+ mt9m111_restore_state(mt9m111);
- if (mt9m111->powered) {
- ret = mt9m111_enable(mt9m111);
- if (!ret)
- ret = mt9m111_reset(mt9m111);
- if (!ret)
- mt9m111_restore_state(mt9m111);
- }
return ret;
}
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] V4L: mt9m111: clean up and fix .s_crop() / .s_fmt()
Hi all While working on a context-switching test, I've cleaned up the mt9m111 driver a bit and fixed its cropping and scaling functions. These are planned for 3.3. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] V4L: soc-camera: remove redundant parameter from the .set_bus_param() method
The "pixfmt" parameter of the struct soc_camera_host_ops::set_bus_param()
method is redundant, because at the time, when this method is called,
pixfmt is guaranteed to be equal to icd->current_fmt->host_fmt->fourcc.
Remove this parameter and update all drivers accordingly.
Signed-off-by: Guennadi Liakhovetski
---
Will be pushed to 3.3 in a day or two, unless there are objections
drivers/media/video/atmel-isi.c|2 +-
drivers/media/video/mx1_camera.c |2 +-
drivers/media/video/mx2_camera.c |3 +--
drivers/media/video/mx3_camera.c |3 ++-
drivers/media/video/omap1_camera.c |4 ++--
drivers/media/video/pxa_camera.c |3 ++-
drivers/media/video/sh_mobile_ceu_camera.c | 11 ++-
drivers/media/video/soc_camera.c |2 +-
include/media/soc_camera.h |2 +-
9 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index fbc904f..b25bd7b 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -803,7 +803,7 @@ static int isi_camera_querycap(struct soc_camera_host *ici,
return 0;
}
-static int isi_camera_set_bus_param(struct soc_camera_device *icd, u32 pixfmt)
+static int isi_camera_set_bus_param(struct soc_camera_device *icd)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c
index 18e94c7..055d11d 100644
--- a/drivers/media/video/mx1_camera.c
+++ b/drivers/media/video/mx1_camera.c
@@ -487,7 +487,7 @@ static int mx1_camera_set_crop(struct soc_camera_device
*icd,
return v4l2_subdev_call(sd, video, s_crop, a);
}
-static int mx1_camera_set_bus_param(struct soc_camera_device *icd, __u32
pixfmt)
+static int mx1_camera_set_bus_param(struct soc_camera_device *icd)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index a803d9e..ffbfbfe 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -766,8 +766,7 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
pcdev->base_emma + PRP_INTR_CNTL);
}
-static int mx2_camera_set_bus_param(struct soc_camera_device *icd,
- __u32 pixfmt)
+static int mx2_camera_set_bus_param(struct soc_camera_device *icd)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index f96f92f..ba00474 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -982,12 +982,13 @@ static int mx3_camera_querycap(struct soc_camera_host
*ici,
return 0;
}
-static int mx3_camera_set_bus_param(struct soc_camera_device *icd, __u32
pixfmt)
+static int mx3_camera_set_bus_param(struct soc_camera_device *icd)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
struct mx3_camera_dev *mx3_cam = ici->priv;
struct v4l2_mbus_config cfg = {.type = V4L2_MBUS_PARALLEL,};
+ u32 pixfmt = icd->current_fmt->host_fmt->fourcc;
unsigned long bus_flags, common_flags;
u32 dw, sens_conf;
const struct soc_mbus_pixelfmt *fmt;
diff --git a/drivers/media/video/omap1_camera.c
b/drivers/media/video/omap1_camera.c
index 6a6cf38..946ee55 100644
--- a/drivers/media/video/omap1_camera.c
+++ b/drivers/media/video/omap1_camera.c
@@ -1436,13 +1436,13 @@ static int omap1_cam_querycap(struct soc_camera_host
*ici,
return 0;
}
-static int omap1_cam_set_bus_param(struct soc_camera_device *icd,
- __u32 pixfmt)
+static int omap1_cam_set_bus_param(struct soc_camera_device *icd)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct device *dev = icd->parent;
struct soc_camera_host *ici = to_soc_camera_host(dev);
struct omap1_cam_dev *pcdev = ici->priv;
+ u32 pixfmt = icd->current_fmt->host_fmt->fourcc;
const struct soc_camera_format_xlate *xlate;
const struct soc_mbus_pixelfmt *fmt;
struct v4l2_mbus_config cfg = {.type = V4L2_MBUS_PARALLEL,};
diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
index 79fb22c..2f9ae63 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -1133,12 +1133,13 @@ static void pxa_camera_setup_cicr(struct
soc_camera_device *icd,
__raw_writel(cicr0, pcdev->base + CICR0);
}
-static int pxa_camera_set_bus_param(struct soc_camera_device *icd, __u32
pixfmt)
+static int pxa_camera_set
Re: [PATCH] qt1010: Fix tuner frequency selection for 546 to 578 MHz range
On Wednesday 21 Dec 2011 12:36:11 Jyrki Kuoppala wrote: [..] > One possibility to try would be to test if the setting of reg 34 indeed > should be linearly derived from frequency, however not 0xd0, 0xd2, 0xd4 > etc. as in my original patch but instead try 0xd0, 0xd1, 0xd2, 0xd3 etc: > > if (freq < 45000) rd[15].val = 0xd0; /* 450 MHz */ > else if (freq < 46600) rd[15].val = 0xd1; /* 466 MHz */ > else if (freq < 48200) rd[15].val = 0xd2; /* 482 MHz */ > else if (freq < 49800) rd[15].val = 0xd3; /* 498 MHz */ > else if (freq < 51400) rd[15].val = 0xd4; /* 514 MHz */ > else if (freq < 53000) rd[15].val = 0xd5; /* 530 MHz */ > else if (freq < 54600) rd[15].val = 0xd6; /* 546 MHz */ > else if (freq < 56200) rd[15].val = 0xd7; /* 562 MHz */ > else if (freq < 57800) rd[15].val = 0xd8; /* 578 MHz */ > > Carlos, can you try this, if this makes all channels work for you? With the patch and either set of frequency changes (above or from the other thread applied), it kills channel 21 (474MHz) and channel 39 (618.2MHz) for me. Only channel 24 (498MHz), channel 27 (522MHz), channel 66 (834MHz) and channel 31 (554MHz - the original channel I couldn't tune to) work. -Carlos -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Fixed detection of EMP202 audio chip. Some versions have an id of 0x83847650 instead of 0xffffffff.
On Wednesday 21 Dec 2011 11:54:33 you wrote:
> On 20-12-2011 19:45, Gareth Williams wrote:
> > Signed-off-by: Gareth Williams
> >
> > Honestech Vidbox NW03 has a EMP202 audio chip with a different Vendor
> > ID.
> >
> > Apparently, it is the same with the Gadmei ITV380:
> > http://linuxtv.org/wiki/index.php/Gadmei_USB_TVBox_UTV380
> >
> > ---
> >
> > linux/drivers/media/video/em28xx/em28xx-core.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/linux/drivers/media/video/em28xx/em28xx-core.c
> > b/linux/drivers/media/video/em28xx/em28xx-core.c index 804a4ab..2982a06
> > 100644
> > --- a/linux/drivers/media/video/em28xx/em28xx-core.c
> > +++ b/linux/drivers/media/video/em28xx/em28xx-core.c
> > @@ -568,7 +568,7 @@ int em28xx_audio_setup(struct em28xx *dev)
> >
> > em28xx_warn("AC97 features = 0x%04x\n", feat);
> >
> > /* Try to identify what audio processor we have */
> >
> > - if ((vid == 0x) && (feat == 0x6a90))
> > + if (((vid == 0x) || (vid == 0x83847650)) && (feat == 0x6a90))
>
> Are you sure you don't have, instead a STAC9750? 0x83647650 is the code
> for this chip. Did you open your device to be sure it is really an em202?
>
> Vendors are free to put whatever AC97 chip they want. Each of them have
> their own differences (different sample rate, different volume controls,
> etc).
>
> While miss-identifying it may work for your usecase, it will fail for
> other usecases. The good news is that, in general, the datasheets for
> AC97 mixers are generally easy to find on Google. Most vendors release them
> publicly.
>
> Regards,
> Mauro
I opened the box in order to check the chip.
I've opened it again now and can confirm that the chip has the following
markings:-
eMPIA
TECHNOLOGY
EMP202
T10189
1110
I've read the EMP202 datasheet and also noticed that it should have
for the vendor id which is what the driver was originally looking for.
According to the LinuxTV Wiki entry, the Gadmei ITV380 also has the same issue
in that it also has an EMP202 inside and a vendor Id of the STAC9750.
Regards,
Gareth
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] v4l2: add new pixel formats supported on dm365
Laurent,
On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
> Hi Manju,
>
> On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format
> > > > frames compressed by A-LAW alogorithm.
> > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only.
> > > >
> > > > Signed-off-by: Manjunath Hadli
> > > > Cc: Laurent Pinchart
> > > > ---
> > > >
> > > > include/linux/videodev2.h |6 ++
> > > > 1 files changed, 6 insertions(+), 0 deletions(-)
> > >
> > > Could you please also document these formats in
> > > Documentation/DocBook/media/v4l ?
> >
> > I will. Sorry to have missed that out.
> >
> > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > > > index 4b752d5..969112d 100644
> > > > --- a/include/linux/videodev2.h
> > > > +++ b/include/linux/videodev2.h
> > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > >
> > > > #define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2') /* 8
> > > > YUV
> > > >
> > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
> > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line
> > > > uv interleaved */
> > > >
> > > > +/* Chrominance formats */
> > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8
> > > > UV 4:4 */ +
> > > >
> > > > /* two planes -- one Y, one Cr + Cb interleaved */
> > > > #define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12
> > > > Y/CbCr
> > > >
> > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V', '2', '1')
> > > > /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct v4l2_pix_format
> > > > { #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /*
> > > > 12 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits
> > > > */ #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1',
> > > > '0')
> > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > > +
> > >
> > > That's not very future-proof, how would you describe SGBRG10ALAW8
> > > for instance ?
> > >
> > > Maybe it's time to standardize FOURCCs for Bayer new formats. We
> > > have 4 characters, we could start with 'B' to denote Bayer, followed
> > > by one character for the order, one for the compression, and one for
> > > the number of bits.
> >
> > I agree.
> > May be ('B', 'G', 'A', '8') is fine for the above?
>
> We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B', 'g',
> 'G' and 'R' respectively for the second character. The third character would
> be 'A' for A-law and 'D' for DPCM, and the fourth character could describe
> the bus width in bits from 0 to 15 with '0' - '9', 'A' - 'F'. However, I
> suspect that we will need 16-bit wide busses for raw Bayer at some point, and
> a 0 width is definitely not useful. We could thus offset the width by some
> value.
>
> This is just a preliminary idea, I'm open to suggestions.
I think it is a very good suggestion that we can go with.
B : BGGR
g : GBRG
G : GRBG
R : RGGB
and 0-F can signify 1-16.
Thx,
-Manju
>
> > > > /*
> > > >
> > > > * 10bit raw bayer, expanded to 16 bits
> > > > * rrgg ggbb...
>
> --
> 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
Re: [PATCH 1/2] Fixed detection of EMP202 audio chip. Some versions have an id of 0x83847650 instead of 0xffffffff.
On 20-12-2011 19:45, Gareth Williams wrote:
> Signed-off-by: Gareth Williams
>
> Honestech Vidbox NW03 has a EMP202 audio chip with a different Vendor ID.
>
> Apparently, it is the same with the Gadmei ITV380:
> http://linuxtv.org/wiki/index.php/Gadmei_USB_TVBox_UTV380
>
> ---
> linux/drivers/media/video/em28xx/em28xx-core.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/linux/drivers/media/video/em28xx/em28xx-core.c
> b/linux/drivers/media/video/em28xx/em28xx-core.c
> index 804a4ab..2982a06 100644
> --- a/linux/drivers/media/video/em28xx/em28xx-core.c
> +++ b/linux/drivers/media/video/em28xx/em28xx-core.c
> @@ -568,7 +568,7 @@ int em28xx_audio_setup(struct em28xx *dev)
> em28xx_warn("AC97 features = 0x%04x\n", feat);
>
> /* Try to identify what audio processor we have */
> - if ((vid == 0x) && (feat == 0x6a90))
> + if (((vid == 0x) || (vid == 0x83847650)) && (feat == 0x6a90))
Are you sure you don't have, instead a STAC9750? 0x83647650 is the code
for this chip. Did you open your device to be sure it is really an em202?
Vendors are free to put whatever AC97 chip they want. Each of them have
their own differences (different sample rate, different volume controls,
etc).
While miss-identifying it may work for your usecase, it will fail for
other usecases. The good news is that, in general, the datasheets for
AC97 mixers are generally easy to find on Google. Most vendors release them
publicly.
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 1/2] media: add new mediabus format enums for dm365
Laurent,
On Wed, Dec 21, 2011 at 05:28:31, Laurent Pinchart wrote:
> Hi Manju,
>
> On Friday 16 December 2011 15:20:24 Hadli, Manjunath wrote:
> > On Thu, Dec 15, 2011 at 18:32:44, Laurent Pinchart wrote:
> > > On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote:
> > > > add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into
> > > > mbus_pixel_code to represent A-LAW compressed Bayer format. This
> > > > corresponds to pixel format - V4L2_PIX_FMT_SGRBG10ALAW8.
> > > > add UV8 and NV12 ( Y and C separate with UV interleaved) which are
> > > > supported on dm365.
> > > >
> > > > Signed-off-by: Manjunath Hadli
> > > > Cc: Laurent Pinchart
> > > > ---
> > > >
> > > > include/linux/v4l2-mediabus.h | 10 --
> > > > 1 files changed, 8 insertions(+), 2 deletions(-)
> > >
> > > Please also update the documentation in Documentation/DocBook/media/v4l.
> > >
> > > > diff --git a/include/linux/v4l2-mediabus.h
> > > > b/include/linux/v4l2-mediabus.h index 5ea7f75..d408654 100644
> > > > --- a/include/linux/v4l2-mediabus.h
> > > > +++ b/include/linux/v4l2-mediabus.h
> > > > @@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode {
> > > >
> > > > V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
> > > > V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
> > > >
> > > > - /* YUV (including grey) - next is 0x2014 */
> > > > + /* YUV (including grey) - next is 0x2016 */
> > > >
> > > > V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
> > > > V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
> > > > V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
> > > >
> > > > @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode {
> > > >
> > > > V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
> > > > V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
> > > > V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
> > > >
> > > > + V4L2_MBUS_FMT_NV12_1X20 = 0x2014,
> > > > + V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
> > >
> > > NV12, on the bus ? How does that work ? (The documentation should
> > > answer my question :-))
> >
> > Well, this is on the internal bus not exposed outside, but
> > nevertheless bus between two subdevs or two independent hardware
> > blocks. For example Resizer supports NV12 on its pad. Is there any other
> > way to treat this?
>
> How is NV12 transferred on the bus in that case ? Are all luma samples
> transferred first, followed by all chroma samples ?
It uses parallel bus of 16 bits, where Y and C are transmitted simultaneously
on 8 bits each. NV12 uses a dummy C byte for every
valid one.
So I guess we call it V4L2_MBUS_FMT_YDYC_1X16 or V4L2_MBUS_FMT_YCYD_1X16?
That way we will be able to document the format in the documentation also.
Thx,
-Manju
>
> > > > - /* Bayer - next is 0x3015 */
> > > > + /* Bayer - next is 0x3019 */
> > > >
> > > > V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
> > > > V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013,
> > > > V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
> > > >
> > > > @@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode {
> > > >
> > > > V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
> > > > V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
> > > > V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
> > > >
> > > > + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015,
> > > > + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016,
> > > > + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017,
> > > > + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018,
> > >
> > > Please keep the names sorted as described in the comment at the
> > > beginning of the file.
> > >
> > > > /* JPEG compressed formats - next is 0x4002 */
> > > > V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
>
> --
> 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
[PATCH v7 1/8] davinci: vpif: remove machine specific inclusion from driver
remove machine specific inclusion from the driver which
comes in the way of platform code consolidation.
currently was seen that these header inclusions were
not necessary.
Signed-off-by: Manjunath Hadli
Cc: Mauro Carvalho Chehab
Cc: LMML
---
drivers/media/video/davinci/vpif.h |2 --
drivers/media/video/davinci/vpif_display.c |2 --
include/media/davinci/vpif_types.h |2 ++
sound/soc/codecs/cq93vc.c |2 --
4 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index 25036cb..8bcac65 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -18,8 +18,6 @@
#include
#include
-#include
-#include
#include
/* Maximum channel allowed */
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index 286f029..7fa34b4 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -39,8 +39,6 @@
#include
#include
-#include
-
#include "vpif_display.h"
#include "vpif.h"
diff --git a/include/media/davinci/vpif_types.h
b/include/media/davinci/vpif_types.h
index 9929b05..bd8217c 100644
--- a/include/media/davinci/vpif_types.h
+++ b/include/media/davinci/vpif_types.h
@@ -17,6 +17,8 @@
#ifndef _VPIF_TYPES_H
#define _VPIF_TYPES_H
+#include
+
#define VPIF_CAPTURE_MAX_CHANNELS 2
enum vpif_if_type {
diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c
index 46dbfd0..ff4eb7a 100644
--- a/sound/soc/codecs/cq93vc.c
+++ b/sound/soc/codecs/cq93vc.c
@@ -38,8 +38,6 @@
#include
#include
-#include
-
static inline unsigned int cq93vc_read(struct snd_soc_codec *codec,
unsigned int reg)
{
--
1.6.2.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: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?
Hi James, On Wednesday 21 December 2011 04:06:33 James wrote: > On Wed, Dec 21, 2011 at 10:50 AM, James wrote: > > On Thu, Dec 15, 2011 at 6:10 PM, Michael Jones wrote: > >> Hi James, > >> > >> Laurent has a program 'media-ctl' to set up the pipeline (see > >> http://git.ideasonboard.org/?p=media-ctl.git). You will find many > >> examples of its usage in the archives of this mailing list. It will > >> look something like: > >> media-ctl -r > >> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]' > >> media-ctl -l '"your-sensor-name":0 -> "OMAP3 ISP CCDC":0 [1]' > >> > >> you will also need to set the formats through the pipeline with > >> 'media-ctl --set-format'. > >> > >> After you use media-ctl to set up the pipeline, you can use yavta to > >> capture the data from the CCDC output (for me, this is /dev/video2). > >> > >> > >> -Michael > > > > I encountered some obstacles with the driver testing of my monochrome > > sensor on top of Steve's 3.0-pm branch. An NXP SC16IS750 I2C-UART > > bridge is used to 'transform' the sensor into a I2C device. > > > > The PCLK, VSYNC, HSYNC (640x512, 30Hz, fixed output format) are free > > running upon power-on the sensor unlike MT9V032 which uses the XCLKA > > to 'power-on/off' it. > > > > My steps, > > > > 1) media-ctl -r -l '"mono640":0->"OMAP3 ISP CCDC":0:[1], "OMAP3 ISP > > CCDC":1->"OMAP3 ISP CCDC output":0[1]' > > > > Resetting all links to inactive > > Setting up link 16:0 -> 5:0 [1] > > Setting up link 5:1 -> 6:0 [1] > > > > 2) media-ctl -f '"mono640":0[Y12 640x512]", "OMAP3 ISP CCDC":1[Y12 > > 640x512]' > > > > Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/0 > > Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/1 > > > > 3) yavta -p -f Y12 -s 640x512 -n 4 --capture=61 --skip 1 -F `media-ctl > > -e "OMAP3 ISP CCDC output"` --file=./DCIM/Y12 > > > > Unsupported video format 'Y12' > > > > Did I missed something? I've just pushed a patch to the yavta repository to support Y10 and Y12. Please update. > > What parameters did you supplied to yavta to test the Y10/Y12 > > > > Many thanks in adv. > > Sorry if duplicated emails received. > > I changed the parameters for yavta from "-f Y12" to "-f Y16" > > yavta -p -f Y16 -s 640x512 -n 2 --capture=10 --skip 5 -F `media-ctl -e > "OMAP3 ISP CCDC output"` --file=./DCIM/Y16 > > and there are 2 chunks of message at the console now and it ended with > "Unable to request buffers: Invalid argument (22).". > > I've attached the logfile here. (mono640.log) > > Hope you can assist me to grab the raw Y12 data to file. -- 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
Re: [PATCH] qt1010: Fix tuner frequency selection for 546 to 578 MHz range
You should take sniffs from your device and look values from there in
order to get understanding.
Thats seems to be one thing looked from my old tests:
u8 zl10353_unknown[] = { 0x90, 0x00, 0xff, 0xff, 0x00, 0xff, 0x3f, 0x3f };
IIRC those were related to IF/RF AGC limits. If you fix tuner then you
should fix demod too. Otherwise it will not work properly if at all.
I think changing that one register off by one or two does not have much
effort if all the others are correct. Just for the calibration.
regards
Antti
On 12/21/2011 12:36 PM, Jyrki Kuoppala wrote:
Thanks, apparently you mean the valptr setting if clauses in QT1010_RD
and QT1010_M1 cases, if I understand you correctly you are saying code
should be changed as in the diff below (after my signature).
The change has to with setting reg1f_init_val, reg20_init_val and
reg25_init_val. To match with
http://linuxtv.org/wiki/index.php/Quantek_QT1010 , the registers are 31,
32 and 37 in decimal.
The patch sent by Carlos modifies how register 0x22 (register 34 in
decimal) is set from the frequency. Carlos's patch is based on my patch
which was based on the apparently incorrect (based on Carlos's feedback
to my original patch, but see below, perhaps the assumption wasn't
incorrect after all) assumption of linear relation between frequency and
register 34 equals 0x22 value. So, basically Carlos removed the 0xd1 ->
0xd2 part of my patch.
When following frequency setting from the description at
http://linuxtv.org/wiki/index.php/Quantek_QT1010 , register 34 is set
from freq_slot12 in the following manner:
* if reg5_1 is equal to 0x34
o if freq_slot12 is larger equal to 0xF0
+ if freq_slot12 is less equal to 0xFA
# write freq_slot12 minus 0x20 into freq_slot12
+ else
# write 0xDA into freq_slot12
o else
+ write 0xD0 into freq_slot12
o write freq_slot12 into tmp_var1
* else
o write 0xD0 into tmp_var1
* write tmp_var1 to tuner register 34
That does describe a linear correlation between freq_slot12 value and
what is stored to register 34. 0xf0..0xfa are converted to 0xd0 .. 0xda
which are also the values used in qt1010.c. But I can't find where
freq_slot12 comes from (that's apparently in the incomplete part
ofcalculate_parameter). So it's possible freq_slot12 is converted from
the frequency non-linearly somewhere before it's used to set register
34. The current qt1010.c frequency to register 34 value conversion is
non-linear and looks strange, setting 0xd1 where linearly setting the
value would be 0xd2. But IIRC Carlos reported that changing it to 0xd2
(as in my original proposed patch) breaks some frequencies.
One possibility to try would be to test if the setting of reg 34 indeed
should be linearly derived from frequency, however not 0xd0, 0xd2, 0xd4
etc. as in my original patch but instead try 0xd0, 0xd1, 0xd2, 0xd3 etc:
if (freq < 45000) rd[15].val = 0xd0; /* 450 MHz */
else if (freq < 46600) rd[15].val = 0xd1; /* 466 MHz */
else if (freq < 48200) rd[15].val = 0xd2; /* 482 MHz */
else if (freq < 49800) rd[15].val = 0xd3; /* 498 MHz */
else if (freq < 51400) rd[15].val = 0xd4; /* 514 MHz */
else if (freq < 53000) rd[15].val = 0xd5; /* 530 MHz */
else if (freq < 54600) rd[15].val = 0xd6; /* 546 MHz */
else if (freq < 56200) rd[15].val = 0xd7; /* 562 MHz */
else if (freq < 57800) rd[15].val = 0xd8; /* 578 MHz */
Carlos, can you try this, if this makes all channels work for you?
According to my reasoning, this could be the proper patch, as the 0xd1
-> 0xd2 change in my original patch failed for you. This would fit the
picture if your frequency is between 450 Mhz and 466 Mhz, in which case
my patch changes the correct 0xd1 to the incorrect 0xd2.
If the test succeeds and the relation indeed is linear, instead of the
table we'll the conversion with math, it's of course silly to have a
table for a linear relation.
Going through this makes me wonder if we perhaps have two separate
issues here - one problem with frequency setting experienced by me &
Carlos, and another problem with tuner init & AGC which Antti is
describing. Antti, can you comment if you think this may be the case? Or
is the register 31,32&37 setting somehow related to frequency selection?
Just wondering why the frequency table seems to fix the issue that me &
Carlos and others are seeing, if the problem is somewhere else as Antti
is saying. Two separate issues could explain this.
Antti, any pointers / more info on what's the problem with
drivers/media/dvb/frontends/zl10353.c AGC settings and how to fix those
settings?
Jyrki
diff -ur linux-3.0.3.orig/drivers/media/common/tuners/qt1010.c
linux-3.0.3/drivers/media/common/tuners/qt1010.c
--- linux-3.0.3.orig/drivers/media/common/tuners/qt1010.c
2011-08-17 20:57:16.0 +0300
+++ linux-3.0.3/drivers/m
media_build failures on 3.0.6 Gentoo
Hi, I get this build failure: lin-tv src # git clone git://linuxtv.org/media_build.git lin-tv src # cd media_build/ lin-tv media_build # ./build Checking if the needed tools are present Needed package dependencies are met. * This script will download the latest tarball and build it* * Assuming that your kernel is compatible with the latest * * drivers. If not, you'll need to add some extra backports,* * ./backports/ directory. * * It will also update this tree to be sure that all compat * * bits are there, to avoid compilation failures* * All drivers and build system are under GPLv2 License * * Firmware files are under the license terms found at: * * http://www.linuxtv.org/downloads/firmware/ * * Please abort if you don't agree with the license * Updating the building system From git://linuxtv.org/media_build * branchmaster -> FETCH_HEAD Already up-to-date. make: Entering directory `/usr/src/media_build/linux' wget http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5 -O linux-media.tar.bz2.md5.tmp --2011-12-21 11:42:05-- http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5 Resolving linuxtv.org... 130.149.80.248 Connecting to linuxtv.org|130.149.80.248|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 93 [application/x-bzip2] Saving to: `linux-media.tar.bz2.md5.tmp' 100%[=>] 93 --.-K/s in 0s 2011-12-21 11:42:05 (11.1 MB/s) - `linux-media.tar.bz2.md5.tmp' saved [93/93] LD [M] /usr/src/media_build/v4l/m5mols.o CC [M] /usr/src/media_build/v4l/s5k6aa.o CC [M] /usr/src/media_build/v4l/adp1653.o CC [M] /usr/src/media_build/v4l/as3645a.o /usr/src/media_build/v4l/as3645a.c: In function 'as3645a_probe': /usr/src/media_build/v4l/as3645a.c:815:2: error: implicit declaration of function 'kzalloc' /usr/src/media_build/v4l/as3645a.c:815:8: warning: assignment makes pointer from integer without a cast make[3]: *** [/usr/src/media_build/v4l/as3645a.o] Error 1 make[2]: *** [_module_/usr/src/media_build/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-3.0.6-gentoo' make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/media_build/v4l' make: *** [all] Error 2 build failed at ./build line 380. lin-tv media_build # Regards, /Fredrik -- 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
which is correct name DTMB or CTTB?
Morjens, I am adding DTMB/CTTB support for the Linux Kernel DVB API. Do anyone have clear idea which correct name? Background of that discussion can be found from the following patch: http://patchwork.linuxtv.org/patch/8827/ regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.3] HDIC HD29L2 DMB-TH demodulator driv
On Tuesday 20 December 2011 19:09:14 Mauro Carvalho Chehab wrote: > On 20-12-2011 16:01, Antti Palosaari wrote: > > On 12/20/2011 07:16 PM, Antti Palosaari wrote: > >> On 12/20/2011 06:25 PM, Patrick Boettcher wrote: > >>> Hi all, > >>> > >>> On Tuesday 20 December 2011 16:42:53 Antti Palosaari wrote: > Adding those to API is not mission impossible. Interleaver is > only new parameter and all the rest are just extending values. > But my time is limited... and I really would like to finally > got Anysee smart card reader integrated to USB serial first. > >>> > >>> And if it is added we should not forget to discuess whether > >>> DMB-TH is the "right" name. (If this has already been addressed > >>> in another thread please point me to it). > >>> > >>> I know this standard under at least 2 different names: CTTB and > >>> DTMB. > >>> > >>> Which is the one to choose? > >> > >> Yes, there is many names and it is not even clear for me what are > >> differences between names. I called it DMB-TH since existing > >> Kernel drivers have selected that name. > >> > >> http://en.wikipedia.org/wiki/CMMB > >> http://en.wikipedia.org/wiki/DTMB > >> http://en.wikipedia.org/wiki/Digital_Multimedia_Broadcasting > >> http://en.wikipedia.org/wiki/Digital_Terrestrial_Multimedia_Broadc > >> ast > >> > >> CMMB > >> CTTB > >> DTMB (DTMB-T/H, DMB-T/H) > >> DMB (T-DMB) > > > > DMB seems to be much different so drop it out. DTMB seems to be > > official term for DMB-T/H. CMMB seems to be for small devices > > (mobile), maybe subset of DTMB. Finally I have CTTB and DTMB which > > seems to be equivalents. DTMB is more common. > > > > So I end up for the DTMB. I give my vote for that. CMMB has nothing to do with DTMB/CTTB. It modulations parameters and physical/link layers are completely different compared to CMMB. I'll vote for CTTB as this is the (latest) official name. At least this is what DiBcom's Chinese representatives state. Maybe there are some Chinese on this list to enlighten this situation? -- Patrick Boettcher Kernel Labs Inc. http://www.kernellabs.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qt1010: Fix tuner frequency selection for 546 to 578 MHz range
Moikka Jyrki & all. If you look qt1010_init() you can see some registers are stored wrongly. There is compares that stores register values when .val is given. As you can see easily, it should store those when .reg is correct. Store register 0x25 when it is register 0x25 not register value. That leads calibration wrong => tuner sensitivity is bad. But if you fix that it will not likely work since ZL10353 demod AGC settings are not correct. So you should fix it too. I hope you will fix that, since it is surely 10th time I am explaining that same story for someone :-( t. Antti On 12/21/2011 09:42 AM, Jyrki Kuoppala wrote: Hi, To try and shed some more light into the issue, can you describe what the problem really is and how would we fix the driver correctly? By "work or not", do you mean the fix works with some devices but not with some other devices, with some received signal strengths but not some, or something else? Do you think there's a risk the fix will break something? For me, without the fix, some of the major channels from the transmitter in the second largest city of Finland are missing, in other words the fix would remove a major showstopper. Based on Carlos's note, the situation in UK is something similar. It's of course best to aim for the best possible fix, and if we have enough information to do that, that's of course preferable over this one. However, if there isn't enough information, and there's no risk of the proposed fix breaking something, perhaps this patch should be put in as an interim fix and add some notes somewhere that a better fix is preferable. Jyrki 21.12.2011 09:26, Antti Palosaari kirjoitti: Hello, You can try to fix it like that, but it is not proper way. It is kinda of hack which can just work or not. Proper way is to fix that tuner driver correctly and if it was used with zl10353 demoed fix that driver too to support IIRC IF/RF agc settings. regards Antti On 12/20/2011 12:50 PM, Carlos Corbacho wrote: The patch fixes frequency selection for some UHF frequencies e.g. channel 32 (562 MHz) on the qt1010 tuner. For those in the UK, this now means they can tune to the BBC channels (tested on a Compro Vista T750F). One example of problem reports of the bug this fixes can be read at http://www.freak-search.com/de/thread/330303/linux-dvb_tuning_problem_with_some_frequencies_qt1010,_dvb Based on an original patch by Jyrki Kuoppala Signed-off-by: Carlos Corbacho Cc: Jyrki Kuoppala Cc: Mauro Carvalho Chehab --- drivers/media/common/tuners/qt1010.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/media/common/tuners/qt1010.c b/drivers/media/common/tuners/qt1010.c index 9f5dba2..8c57d8c 100644 --- a/drivers/media/common/tuners/qt1010.c +++ b/drivers/media/common/tuners/qt1010.c @@ -200,7 +200,8 @@ static int qt1010_set_params(struct dvb_frontend *fe, if (freq< 45000) rd[15].val = 0xd0; /* 450 MHz */ else if (freq< 48200) rd[15].val = 0xd1; /* 482 MHz */ else if (freq< 51400) rd[15].val = 0xd4; /* 514 MHz */ - else if (freq< 54600) rd[15].val = 0xd7; /* 546 MHz */ + else if (freq< 54600) rd[15].val = 0xd6; /* 546 MHz */ + else if (freq< 57800) rd[15].val = 0xd8; /* 578 MHz */ else if (freq< 61000) rd[15].val = 0xda; /* 610 MHz */ else rd[15].val = 0xd0; -- 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 -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qt1010: Fix tuner frequency selection for 546 to 578 MHz range
Hi, To try and shed some more light into the issue, can you describe what the problem really is and how would we fix the driver correctly? By "work or not", do you mean the fix works with some devices but not with some other devices, with some received signal strengths but not some, or something else? Do you think there's a risk the fix will break something? For me, without the fix, some of the major channels from the transmitter in the second largest city of Finland are missing, in other words the fix would remove a major showstopper. Based on Carlos's note, the situation in UK is something similar. It's of course best to aim for the best possible fix, and if we have enough information to do that, that's of course preferable over this one. However, if there isn't enough information, and there's no risk of the proposed fix breaking something, perhaps this patch should be put in as an interim fix and add some notes somewhere that a better fix is preferable. Jyrki 21.12.2011 09:26, Antti Palosaari kirjoitti: Hello, You can try to fix it like that, but it is not proper way. It is kinda of hack which can just work or not. Proper way is to fix that tuner driver correctly and if it was used with zl10353 demoed fix that driver too to support IIRC IF/RF agc settings. regards Antti On 12/20/2011 12:50 PM, Carlos Corbacho wrote: The patch fixes frequency selection for some UHF frequencies e.g. channel 32 (562 MHz) on the qt1010 tuner. For those in the UK, this now means they can tune to the BBC channels (tested on a Compro Vista T750F). One example of problem reports of the bug this fixes can be read at http://www.freak-search.com/de/thread/330303/linux-dvb_tuning_problem_with_some_frequencies_qt1010,_dvb Based on an original patch by Jyrki Kuoppala Signed-off-by: Carlos Corbacho Cc: Jyrki Kuoppala Cc: Mauro Carvalho Chehab --- drivers/media/common/tuners/qt1010.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/media/common/tuners/qt1010.c b/drivers/media/common/tuners/qt1010.c index 9f5dba2..8c57d8c 100644 --- a/drivers/media/common/tuners/qt1010.c +++ b/drivers/media/common/tuners/qt1010.c @@ -200,7 +200,8 @@ static int qt1010_set_params(struct dvb_frontend *fe, if (freq< 45000) rd[15].val = 0xd0; /* 450 MHz */ else if (freq< 48200) rd[15].val = 0xd1; /* 482 MHz */ else if (freq< 51400) rd[15].val = 0xd4; /* 514 MHz */ -else if (freq< 54600) rd[15].val = 0xd7; /* 546 MHz */ +else if (freq< 54600) rd[15].val = 0xd6; /* 546 MHz */ +else if (freq< 57800) rd[15].val = 0xd8; /* 578 MHz */ else if (freq< 61000) rd[15].val = 0xda; /* 610 MHz */ else rd[15].val = 0xd0; -- 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
