OMAP 3530 camera ISP forks and new media framework
Hello media team, I want to write a sensor driver for the mt9p031 (not mt9t031) camera chip and start getting confused about the different kernel forks and architectural changes that happen in V4L2. A similar problem was discussed in this mailing list at http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html. Currently I don't know which branch to follow. Either http://gitorious.org/omap3camera from Sakari Ailus or the branch media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from Laurent Pinchart. Both have an folder drivers/media/video/isp and are written for the new media controller architecture if I am right. I see in http://gitorious.org/omap3camera/camera-firmware that there is already an empty placeholder for the mt9t031. The README of the camera-firmware repository states: makemodes.pl is a perl script which converts sensor register lists from FIXME into C code. dcc-pulautin is a Makefile (mostly) that converts sensor register lists as C code into binaries understandable to sensor drivers. The end result is a binary with sensor driver name, sensor version and bin suffix, for example et8ek8-0002.bin. So I think the goal is to provide a script framework for camera systems. You just script some register tables and it creates a binary that can be read by a sensor driver made for that framework. If the a camera bridge driver for your chip exists, you are done. Am I right? Are drivers/media/video/et8ek8.c and drivers/staging/dream/camera/mt9p012_* such drivers? So do you think it is the right way to go to use your ISP driver, adapt drivers/staging/dream/camera/mt9p012_* to suit my mt9p031 and write a register list and create a camera firmware for that sensor driver with makemodes? I am still quite confused... if I get something wrong, please give me some hints. Thanks a lot! Bastian Hecht -- 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: OMAP 3530 camera ISP forks and new media framework
Bastian Hecht wrote: Hello media team, Hi Bastian, I want to write a sensor driver for the mt9p031 (not mt9t031) camera chip and start getting confused about the different kernel forks and architectural changes that happen in V4L2. A similar problem was discussed in this mailing list at http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html. Currently I don't know which branch to follow. Either http://gitorious.org/omap3camera from Sakari Ailus or the branch media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from Laurent Pinchart. Both have an folder drivers/media/video/isp and are written for the new media controller architecture if I am right. Take Laurent's branch it has all the current patches in it. My gitorious tree isn't updated anymore. (I just had forgotten to add a note, it's there now.) I see in http://gitorious.org/omap3camera/camera-firmware that there is already an empty placeholder for the mt9t031. The README of the camera-firmware repository states: makemodes.pl is a perl script which converts sensor register lists from FIXME into C code. dcc-pulautin is a Makefile (mostly) that converts sensor register lists as C code into binaries understandable to sensor drivers. The end result is a binary with sensor driver name, sensor version and bin suffix, for example et8ek8-0002.bin. So I think the goal is to provide a script framework for camera systems. You just script some register tables and it creates a binary that can be read by a sensor driver made for that framework. If the a camera bridge driver for your chip exists, you are done. Am I right? Are drivers/media/video/et8ek8.c and drivers/staging/dream/camera/mt9p012_* such drivers? et8ek8 and smia-sensor currently use the camera-firmware binaries. The long term goal is to move more things to the sensor driver itself. Register lists related to a set of sensor settings are not an ideal way to handle sensor related settings since they could be controlled the driver instead. So do you think it is the right way to go to use your ISP driver, adapt drivers/staging/dream/camera/mt9p012_* to suit my mt9p031 and write a register list and create a camera firmware for that sensor driver with makemodes? I would go with drivers/media/video/et8ek8.c in Laurent's tree instead if you want to write a sensor driver to be used with the OMAP 3 ISP driver. Register lists are not that nice but the v4l2_subdev interface in that one is one of the good parts you get with that. I'd also advice against using camera-firmware if you don't necessarily need that kind of functionality. I am still quite confused... if I get something wrong, please give me some hints. I hope this helped. :-) If you have any further questions feel free to ask. Cheers, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
[PATCH 2/3] V4L/DVB: lirc_igorplugusb: Fix a compilation waring
drivers/staging/lirc/lirc_igorplugusb.c: In function ‘usb_remote_probe’: drivers/staging/lirc/lirc_igorplugusb.c:393: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 3 has type ‘unsigned int’ Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/staging/lirc/lirc_igorplugusb.c b/drivers/staging/lirc/lirc_igorplugusb.c index bce600e..e680d88 100644 --- a/drivers/staging/lirc/lirc_igorplugusb.c +++ b/drivers/staging/lirc/lirc_igorplugusb.c @@ -390,7 +390,7 @@ static int usb_remote_probe(struct usb_interface *intf, devnum = dev-devnum; maxp = usb_maxpacket(dev, pipe, usb_pipeout(pipe)); - dprintk(DRIVER_NAME [%d]: bytes_in_key=%lu maxp=%d\n, + dprintk(DRIVER_NAME [%d]: bytes_in_key=%zu maxp=%d\n, devnum, CODE_LENGTH, maxp); -- 1.7.1 -- 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/DVB: staging/tm6000: Fix a warning message
I added a code to the driver to force it to produce a warning. This
were intended to remind me about a very bad hack. I never found a way
to workaround. So, instead of those warnings:
drivers/staging/tm6000/tm6000-core.c: In function ‘tm6000_init_analog_mode’:
drivers/staging/tm6000/tm6000-core.c:328: warning: ISO C90 forbids mixed
declarations and code
Let's document the issue and hope if someone with the support of the vendor
might fix it.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index 57cb69e..3d82510 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -188,6 +188,8 @@ void tm6000_set_fourcc_format(struct tm6000_core *dev)
int tm6000_init_analog_mode(struct tm6000_core *dev)
{
+ struct v4l2_frequency f;
+
if (dev-dev_type == TM6010) {
int val;
@@ -324,8 +326,16 @@ int tm6000_init_analog_mode(struct tm6000_core *dev)
/* Tuner firmware can now be loaded */
- /*FIXME: Hack!!! */
- struct v4l2_frequency f;
+ /*
+* FIXME: This is a hack! xc3028 sleeps when no channel is detected
+* for more than a few seconds. Not sure why, as this behavior does
+* not happen on other devices with xc3028. So, I suspect that it
+* is yet another bug at tm6000. After start sleeping, decoding
+* doesn't start automatically. Instead, it requires some
+* I2C commands to wake it up. As we want to have image at the
+* beginning, we needed to add this hack. The better would be to
+* discover some way to make tm6000 to wake up without this hack.
+*/
mutex_lock(dev-lock);
f.frequency = dev-freq;
v4l2_device_call_all(dev-v4l2_dev, 0, tuner, s_frequency, f);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] V4L/DVB: videobuf-dma-sg: Use min_t(size_t, PAGE_SIZE ..)
As pointed by Laurent: I think min_t(size_t, PAGE_SIZE, size) is the preferred way. Thanks-to: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/video/videobuf-dma-sg.c b/drivers/media/video/videobuf-dma-sg.c index 7153e44..20f227e 100644 --- a/drivers/media/video/videobuf-dma-sg.c +++ b/drivers/media/video/videobuf-dma-sg.c @@ -116,8 +116,8 @@ static struct scatterlist *videobuf_pages_to_sg(struct page **pages, goto nopage; if (PageHighMem(pages[i])) goto highmem; - sg_set_page(sglist[i], pages[i], min((unsigned)PAGE_SIZE, size), 0); - size -= min((unsigned)PAGE_SIZE, size); + sg_set_page(sglist[i], pages[i], min_t(size_t, PAGE_SIZE, size), 0); + size -= min_t(size_t, PAGE_SIZE, size); } return sglist; -- 1.7.1 -- 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 v12 1/3] V4L2: Add seek spacing and RDS CAP bits.
Add spacing field to v4l2_hw_freq_seek.
Add V4L2_TUNER_CAP_RDS_BLOCK_IO, which indicates that the tuner/
transmitter if capable of transmitting/receiving RDS blocks.
Add V4L2_TUNER_CAP_RDS_CONTROLS capability, which indicates that the
RDS data is handled as values of predefined controls like radio text,
program ID and so on.
Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
---
include/linux/videodev2.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 61490c6..eadcda3 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1363,6 +1363,8 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_SAP 0x0020
#define V4L2_TUNER_CAP_LANG1 0x0040
#define V4L2_TUNER_CAP_RDS 0x0080
+#define V4L2_TUNER_CAP_RDS_BLOCK_IO0x0100
+#define V4L2_TUNER_CAP_RDS_CONTROLS0x0200
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO0x0001
@@ -1392,7 +1394,8 @@ struct v4l2_hw_freq_seek {
enum v4l2_tuner_type type;
__u32 seek_upward;
__u32 wrap_around;
- __u32 reserved[8];
+ __u32 spacing;
+ __u32 reserved[7];
};
/*
--
1.6.1.3
--
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 v12 3/3] Documentation: v4l: Add hw_seek spacing and two TUNER_RDS_CAP flags.
Add a couple of words about the spacing field in the HW seek struct, also a few words about the new RDS tuner capability flags V4L2_TUNER_CAP_RDS_BLOCK-IO and V4L2_TUNER_CAP_RDS_CONTROLS. Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com --- Documentation/DocBook/v4l/dev-rds.xml | 10 +- .../DocBook/v4l/vidioc-s-hw-freq-seek.xml | 10 -- 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/v4l/dev-rds.xml b/Documentation/DocBook/v4l/dev-rds.xml index 0869d70..e7be392 100644 --- a/Documentation/DocBook/v4l/dev-rds.xml +++ b/Documentation/DocBook/v4l/dev-rds.xml @@ -28,6 +28,10 @@ returned by the VIDIOC-QUERYCAP; ioctl. Any tuner that supports RDS will set the constantV4L2_TUNER_CAP_RDS/constant flag in the structfieldcapability/structfield field of v4l2-tuner;. +If the driver only passes RDS blocks without interpreting the data +the constantV4L2_TUNER_SUB_RDS_BLOCK_IO/constant flag has to be set. If the +tuner is capable of handling RDS entities like program identication codes and radio +text the flag constantV4L2_TUNER_SUB_RDS_CONTROLS/constant should be set. Whether an RDS signal is present can be detected by looking at the structfieldrxsubchans/structfield field of v4l2-tuner;: the constantV4L2_TUNER_SUB_RDS/constant will be set if RDS data was detected./para @@ -40,7 +44,11 @@ Any modulator that supports RDS will set the constantV4L2_TUNER_CAP_RDS/constant flag in the structfieldcapability/structfield field of v4l2-modulator;. In order to enable the RDS transmission one must set the constantV4L2_TUNER_SUB_RDS/constant -bit in the structfieldtxsubchans/structfield field of v4l2-modulator;./para +bit in the structfieldtxsubchans/structfield field of v4l2-modulator;. +If the driver only passes RDS blocks without interpreting the data +the constantV4L2_TUNER_SUB_RDS_BLOCK_IO/constant flag has to be set. If the +tuner is capable of handling RDS entities like program identication codes and radio +text the flag constantV4L2_TUNER_SUB_RDS_CONTROLS/constant should be set./para /section diff --git a/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml index 14b3ec7..c30dcc4 100644 --- a/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml +++ b/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml @@ -51,7 +51,8 @@ paraStart a hardware frequency seek from the current frequency. To do this applications initialize the structfieldtuner/structfield, -structfieldtype/structfield, structfieldseek_upward/structfield and +structfieldtype/structfield, structfieldseek_upward/structfield, +structfieldspacing/structfield and structfieldwrap_around/structfield fields, and zero out the structfieldreserved/structfield array of a v4l2-hw-freq-seek; and call the constantVIDIOC_S_HW_FREQ_SEEK/constant ioctl with a pointer @@ -89,7 +90,12 @@ field and the v4l2-tuner; structfieldindex/structfield field./entry /row row entry__u32/entry - entrystructfieldreserved/structfield[8]/entry + entrystructfieldspacing/structfield/entry + entryIf non-zero, defines the hardware seek resolution in Hz. The driver selects the nearest value that is supported by the device. If spacing is zero a reasonable default value is used./entry + /row + row + entry__u32/entry + entrystructfieldreserved/structfield[7]/entry entryReserved for future extensions. Drivers and applications must set the array to zero./entry /row -- 1.6.1.3 -- 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 v12 0/3] TI WL1273 FM Radio driver...
Hello Mauro, Hans and others. I haven't gotten any comments to the latest patch set. The audio part of the driver has already been accepted so I'm now trying to apply a similar approach as with the codec. I've abstracted out the physical control layer from the driver, it could use I2c or UART but the driver now has only read and write calls (and a couple of other calls). Also the driver doesn't export anything and it doesn't expose the FM radio bands it uses internally to the outsize world. Cheers, Matti Matti J. Aaltonen (3): V4L2: Add seek spacing and RDS CAP bits. V4L2: WL1273 FM Radio: Controls for the FM radio. Documentation: v4l: Add hw_seek spacing and two TUNER_RDS_CAP flags. Documentation/DocBook/v4l/dev-rds.xml | 10 +- .../DocBook/v4l/vidioc-s-hw-freq-seek.xml | 10 +- drivers/media/radio/Kconfig| 16 + drivers/media/radio/Makefile |1 + drivers/media/radio/radio-wl1273.c | 1848 include/linux/videodev2.h |5 +- 6 files changed, 1886 insertions(+), 4 deletions(-) create mode 100644 drivers/media/radio/radio-wl1273.c -- 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: OMAP 3530 camera ISP forks and new media framework
Hi Bastian, On Thursday 07 October 2010 12:58:53 Sakari Ailus wrote: Bastian Hecht wrote: I want to write a sensor driver for the mt9p031 (not mt9t031) camera chip and start getting confused about the different kernel forks and architectural changes that happen in V4L2. A similar problem was discussed in this mailing list at http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html. Currently I don't know which branch to follow. Either http://gitorious.org/omap3camera from Sakari Ailus or the branch media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from Laurent Pinchart. Both have an folder drivers/media/video/isp and are written for the new media controller architecture if I am right. Take Laurent's branch it has all the current patches in it. My gitorious tree isn't updated anymore. (I just had forgotten to add a note, it's there now.) I see in http://gitorious.org/omap3camera/camera-firmware that there is already an empty placeholder for the mt9t031. The README of the camera-firmware repository states: makemodes.pl is a perl script which converts sensor register lists from FIXME into C code. dcc-pulautin is a Makefile (mostly) that converts sensor register lists as C code into binaries understandable to sensor drivers. The end result is a binary with sensor driver name, sensor version and bin suffix, for example et8ek8-0002.bin. So I think the goal is to provide a script framework for camera systems. You just script some register tables and it creates a binary that can be read by a sensor driver made for that framework. If the a camera bridge driver for your chip exists, you are done. Am I right? Are drivers/media/video/et8ek8.c and drivers/staging/dream/camera/mt9p012_* such drivers? et8ek8 and smia-sensor currently use the camera-firmware binaries. The long term goal is to move more things to the sensor driver itself. Register lists related to a set of sensor settings are not an ideal way to handle sensor related settings since they could be controlled the driver instead. To be compatible with the OMAP3 ISP driver, sensor drivers need to provide a v4l2_subdev interface and implement the pad-level operations (see the media-0003-subdev-pad branch in the repository). I've written such a driver for the MT9T001. I've pushed it to the media- mt9t001 branch on http://git.linuxtv.org/pinchartl/media.git. Please note that the driver is based on a previous version of the subdev pad-level operations API, so it won't compile out of the box. As Sakari stated, the camera-firmware system shouldn't be used by new drivers. The driver should instead compute the register values directly from the information supplied by userspace (through the v4l2_subdev API) such as the frame size and the crop rectangle. Binary lists of register address/value pairs are definitely not the way to go. So do you think it is the right way to go to use your ISP driver, adapt drivers/staging/dream/camera/mt9p012_* to suit my mt9p031 and write a register list and create a camera firmware for that sensor driver with makemodes? I would go with drivers/media/video/et8ek8.c in Laurent's tree instead if you want to write a sensor driver to be used with the OMAP 3 ISP driver. Register lists are not that nice but the v4l2_subdev interface in that one is one of the good parts you get with that. Start with the MT9T001 driver, that will be easier. I'd also advice against using camera-firmware if you don't necessarily need that kind of functionality. I'd very strongly advice against it as well. Try to forget it even exists, it was a development mistake :-) I am still quite confused... if I get something wrong, please give me some hints. I hope this helped. :-) If you have any further questions feel free to ask. Ditto :-) -- 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/3] V4L/DVB: videobuf-dma-sg: Use min_t(size_t, PAGE_SIZE ..)
Hi Mauro, On Thursday 07 October 2010 14:45:43 Mauro Carvalho Chehab wrote: As pointed by Laurent: I think min_t(size_t, PAGE_SIZE, size) is the preferred way. Thanks-to: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/video/videobuf-dma-sg.c b/drivers/media/video/videobuf-dma-sg.c index 7153e44..20f227e 100644 --- a/drivers/media/video/videobuf-dma-sg.c +++ b/drivers/media/video/videobuf-dma-sg.c @@ -116,8 +116,8 @@ static struct scatterlist *videobuf_pages_to_sg(struct page **pages, goto nopage; if (PageHighMem(pages[i])) goto highmem; - sg_set_page(sglist[i], pages[i], min((unsigned)PAGE_SIZE, size), 0); - size -= min((unsigned)PAGE_SIZE, size); + sg_set_page(sglist[i], pages[i], min_t(size_t, PAGE_SIZE, size), 0); This won't pass checkpatch.pl (line 80 characters long). Beside, this patch applies on top of the previous one whereas I suppose you'd want to replace the previous one. + size -= min_t(size_t, PAGE_SIZE, size); } return sglist; -- 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: OMAP 3530 camera ISP forks and new media framework
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Thursday, October 07, 2010 6:58 PM To: Sakari Ailus Cc: Bastian Hecht; Linux Media Mailing List Subject: Re: OMAP 3530 camera ISP forks and new media framework Hi Bastian, On Thursday 07 October 2010 12:58:53 Sakari Ailus wrote: Bastian Hecht wrote: I want to write a sensor driver for the mt9p031 (not mt9t031) camera chip and start getting confused about the different kernel forks and architectural changes that happen in V4L2. A similar problem was discussed in this mailing list at http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html. Currently I don't know which branch to follow. Either http://gitorious.org/omap3camera from Sakari Ailus or the branch media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from Laurent Pinchart. Both have an folder drivers/media/video/isp and are written for the new media controller architecture if I am right. Take Laurent's branch it has all the current patches in it. My gitorious tree isn't updated anymore. (I just had forgotten to add a note, it's there now.) I see in http://gitorious.org/omap3camera/camera-firmware that there is already an empty placeholder for the mt9t031. The README of the camera-firmware repository states: makemodes.pl is a perl script which converts sensor register lists from FIXME into C code. dcc-pulautin is a Makefile (mostly) that converts sensor register lists as C code into binaries understandable to sensor drivers. The end result is a binary with sensor driver name, sensor version and bin suffix, for example et8ek8-0002.bin. So I think the goal is to provide a script framework for camera systems. You just script some register tables and it creates a binary that can be read by a sensor driver made for that framework. If the a camera bridge driver for your chip exists, you are done. Am I right? Are drivers/media/video/et8ek8.c and drivers/staging/dream/camera/mt9p012_* such drivers? et8ek8 and smia-sensor currently use the camera-firmware binaries. The long term goal is to move more things to the sensor driver itself. Register lists related to a set of sensor settings are not an ideal way to handle sensor related settings since they could be controlled the driver instead. To be compatible with the OMAP3 ISP driver, sensor drivers need to provide a v4l2_subdev interface and implement the pad-level operations (see the media-0003-subdev-pad branch in the repository). I've written such a driver for the MT9T001. I've pushed it to the media- mt9t001 branch on http://git.linuxtv.org/pinchartl/media.git. Please note that the driver is based on a previous version of the subdev pad-level operations API, so it won't compile out of the box. Just to add ontop of this, you can find couple of more sensor (MT9V113 MT9T111) sub-dev driver at http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git?p=people/vaibhav/ti-psp-omap-video.git;a=shortlog;h=refs/heads/omap3cam-mc-devel Also I have already ported these sensor drivers to latest sub-dev pad level operations but have not tested and pushed to the Repository which I will do by this weekend. Thanks, Vaibhav As Sakari stated, the camera-firmware system shouldn't be used by new drivers. The driver should instead compute the register values directly from the information supplied by userspace (through the v4l2_subdev API) such as the frame size and the crop rectangle. Binary lists of register address/value pairs are definitely not the way to go. So do you think it is the right way to go to use your ISP driver, adapt drivers/staging/dream/camera/mt9p012_* to suit my mt9p031 and write a register list and create a camera firmware for that sensor driver with makemodes? I would go with drivers/media/video/et8ek8.c in Laurent's tree instead if you want to write a sensor driver to be used with the OMAP 3 ISP driver. Register lists are not that nice but the v4l2_subdev interface in that one is one of the good parts you get with that. Start with the MT9T001 driver, that will be easier. I'd also advice against using camera-firmware if you don't necessarily need that kind of functionality. I'd very strongly advice against it as well. Try to forget it even exists, it was a development mistake :-) I am still quite confused... if I get something wrong, please give me some hints. I hope this helped. :-) If you have any further questions feel free to ask. Ditto :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line
Re: [linux-dvb] Samsung S2 Tuner(DNBU10711IST) Driver
В сообщении от 21 сентября 2010 07:53:13 автор Bala Subramaniam написал: Hello all, I am making the driver for Samsung S2 Tuner(DNBU10711IST),which has stv0903b link chip with front end stv6110 Rf chip. Yet another stv0903 driver? There is a couple already existed. I have implemented the initialize routine and search algorithm with help of ST's reference code. In case of DVB-S, it works well but DVB-S2 has some problem on checking the lock. I would like to to get some help what is wrong. Or any experience on this is welcome. Regards, Bala -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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 v3 0/4] Add support for camera capture in s5p-fimc driver
Hi all, Here is a third version of patches adding camera capture capability to the s5p-fimc driver. I didn't receive any comments on v2 but I tracked a few issues myself and made little additions. I hope to get these patches merged in current form unless any objections appear. The driver has been tested on Samsung Aquila and GONI boards (S5PC110) with SR030PC30 (VGA) and NOON010PC30 (CIF) image sensors. Changes since v1: - entirely removed plat-samsung/include/plat/fimc.h header so there is no platform code dependency - improved s/try_fmt ioctl and introduced common ioctl handlers for mem2mem and capture node where it's reasonable - register definition changes merged with previous commit [3/8] v4l: s5p-fimc: Register definition cleanup Changes since v2: - improved s/g/crop(cap) handling in capture node - added passing of v4l control to the sensor subdevice The patch series contains: [PATCH 1/4] V4L/DVB: s5p-fimc: Register definition cleanup [PATCH 2/4] V4L/DVB: s5p-fimc: M2M driver cleanup and minor improvements [PATCH 3/4] V4L/DVB: s5p-fimc: Do not lock both capture and output buffer queue in s_fmt [PATCH 4/4] V4L/DVB: s5p-fimc: Add camera capture support It has been rebased onto linuxtv/staging-2.6.37 branch at git://linuxtv.org/media_tree.git with 2 bugfix patches: v4l: s5p-fimc: Fix 3-planar formats handling and pixel offset error on S5PV210 SoCs v4l: s5p-fimc: Fix return value on probe() failure also applied. Cheers, Sylwester -- Sylwester Nawrocki Linux Platform Group Samsung Poland RD Center -- 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/4 v3] V4L/DVB: s5p-fimc: Register definition cleanup
Add MIPI CSI format definitions, prepare DMA address definitions for interlaced input frame mode. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/s5p-fimc/fimc-reg.c |6 +- drivers/media/video/s5p-fimc/regs-fimc.h | 61 - 2 files changed, 28 insertions(+), 39 deletions(-) diff --git a/drivers/media/video/s5p-fimc/fimc-reg.c b/drivers/media/video/s5p-fimc/fimc-reg.c index 5570f1c..70f29c5 100644 --- a/drivers/media/video/s5p-fimc/fimc-reg.c +++ b/drivers/media/video/s5p-fimc/fimc-reg.c @@ -507,9 +507,9 @@ void fimc_hw_set_input_addr(struct fimc_dev *dev, struct fimc_addr *paddr) cfg |= S5P_CIREAL_ISIZE_ADDR_CH_DIS; writel(cfg, dev-regs + S5P_CIREAL_ISIZE); - writel(paddr-y, dev-regs + S5P_CIIYSA0); - writel(paddr-cb, dev-regs + S5P_CIICBSA0); - writel(paddr-cr, dev-regs + S5P_CIICRSA0); + writel(paddr-y, dev-regs + S5P_CIIYSA(0)); + writel(paddr-cb, dev-regs + S5P_CIICBSA(0)); + writel(paddr-cr, dev-regs + S5P_CIICRSA(0)); cfg = ~S5P_CIREAL_ISIZE_ADDR_CH_DIS; writel(cfg, dev-regs + S5P_CIREAL_ISIZE); diff --git a/drivers/media/video/s5p-fimc/regs-fimc.h b/drivers/media/video/s5p-fimc/regs-fimc.h index a3cfe82..9e83315 100644 --- a/drivers/media/video/s5p-fimc/regs-fimc.h +++ b/drivers/media/video/s5p-fimc/regs-fimc.h @@ -11,10 +11,6 @@ #ifndef REGS_FIMC_H_ #define REGS_FIMC_H_ -#define S5P_CIOYSA(__x)(0x18 + (__x) * 4) -#define S5P_CIOCBSA(__x) (0x28 + (__x) * 4) -#define S5P_CIOCRSA(__x) (0x38 + (__x) * 4) - /* Input source format */ #define S5P_CISRCFMT 0x00 #define S5P_CISRCFMT_ITU601_8BIT (1 31) @@ -28,22 +24,21 @@ /* Window offset */ #define S5P_CIWDOFST 0x04 -#define S5P_CIWDOFST_WINOFSEN (1 31) +#define S5P_CIWDOFST_OFF_EN(1 31) #define S5P_CIWDOFST_CLROVFIY (1 30) #define S5P_CIWDOFST_CLROVRLB (1 29) -#define S5P_CIWDOFST_WINHOROFST_MASK (0x7ff 16) +#define S5P_CIWDOFST_HOROFF_MASK (0x7ff 16) #define S5P_CIWDOFST_CLROVFICB (1 15) #define S5P_CIWDOFST_CLROVFICR (1 14) -#define S5P_CIWDOFST_WINHOROFST(x) ((x) 16) -#define S5P_CIWDOFST_WINVEROFST(x) ((x) 0) -#define S5P_CIWDOFST_WINVEROFST_MASK (0xfff 0) +#define S5P_CIWDOFST_HOROFF(x) ((x) 16) +#define S5P_CIWDOFST_VEROFF(x) ((x) 0) +#define S5P_CIWDOFST_VEROFF_MASK (0xfff 0) /* Global control */ #define S5P_CIGCTRL0x08 #define S5P_CIGCTRL_SWRST (1 31) #define S5P_CIGCTRL_CAMRST_A (1 30) #define S5P_CIGCTRL_SELCAM_ITU_A (1 29) -#define S5P_CIGCTRL_SELCAM_ITU_MASK(1 29) #define S5P_CIGCTRL_TESTPAT_NORMAL (0 27) #define S5P_CIGCTRL_TESTPAT_COLOR_BAR (1 27) #define S5P_CIGCTRL_TESTPAT_HOR_INC(2 27) @@ -61,6 +56,8 @@ #define S5P_CIGCTRL_SHDW_DISABLE (1 12) #define S5P_CIGCTRL_SELCAM_MIPI_A (1 7) #define S5P_CIGCTRL_CAMIF_SELWB(1 6) +/* 0 - ITU601; 1 - ITU709 */ +#define S5P_CIGCTRL_CSC_ITU601_709 (1 5) #define S5P_CIGCTRL_INVPOLHSYNC(1 4) #define S5P_CIGCTRL_SELCAM_MIPI(1 3) #define S5P_CIGCTRL_INTERLACE (1 0) @@ -72,23 +69,10 @@ #define S5P_CIWDOFST2_HOROFF(x)((x) 16) #define S5P_CIWDOFST2_VEROFF(x)((x) 0) -/* Output DMA Y plane start address */ -#define S5P_CIOYSA10x18 -#define S5P_CIOYSA20x1c -#define S5P_CIOYSA30x20 -#define S5P_CIOYSA40x24 - -/* Output DMA Cb plane start address */ -#define S5P_CIOCBSA1 0x28 -#define S5P_CIOCBSA2 0x2c -#define S5P_CIOCBSA3 0x30 -#define S5P_CIOCBSA4 0x34 - -/* Output DMA Cr plane start address */ -#define S5P_CIOCRSA1 0x38 -#define S5P_CIOCRSA2 0x3c -#define S5P_CIOCRSA3 0x40 -#define S5P_CIOCRSA4 0x44 +/* Output DMA Y/Cb/Cr plane start addresses */ +#define S5P_CIOYSA(n) (0x18 + (n) * 4) +#define S5P_CIOCBSA(n) (0x28 + (n) * 4) +#define S5P_CIOCRSA(n) (0x38 + (n) * 4) /* Target image format */ #define S5P_CITRGFMT 0x48 @@ -168,6 +152,8 @@ #define S5P_CISTATUS_OVFICB(1 30) #define S5P_CISTATUS_OVFICR(1 29) #define S5P_CISTATUS_VSYNC (1 28) +#define S5P_CISTATUS_FRAMECNT_MASK (3 26) +#define S5P_CISTATUS_FRAMECNT_SHIFT26 #define S5P_CISTATUS_WINOFF_EN (1 25) #define S5P_CISTATUS_IMGCPT_EN (1 22) #define S5P_CISTATUS_IMGCPT_SCEN (1 21) @@ -206,10 +192,10 @@ #define S5P_CIIMGEFF_PAT_CB(x) ((x) 13) #define S5P_CIIMGEFF_PAT_CR(x)
[PATCH 2/4 v3] V4L/DVB: s5p-fimc: M2M driver cleanup and minor improvements
Fixed errors on module unload, comments and whitespace cleanup.
Removed workqueue since it was only useful for FIFO output mode
which is not supported at this time.
Fixed 90/270 deg rotation errors (driver performing 270 deg rotation
instead of 90 in some conditions).
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-core.c | 151 +++---
drivers/media/video/s5p-fimc/fimc-core.h | 132 ++
drivers/media/video/s5p-fimc/fimc-reg.c | 125 -
3 files changed, 188 insertions(+), 220 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 6961c55..fe46aea 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -117,7 +117,7 @@ static struct fimc_fmt fimc_formats[] = {
.buff_cnt = 1,
.planes_cnt = 2
}
- };
+};
static struct v4l2_queryctrl fimc_ctrls[] = {
{
@@ -127,16 +127,14 @@ static struct v4l2_queryctrl fimc_ctrls[] = {
.minimum= 0,
.maximum= 1,
.default_value = 0,
- },
- {
+ }, {
.id = V4L2_CID_VFLIP,
.type = V4L2_CTRL_TYPE_BOOLEAN,
.name = Vertical flip,
.minimum= 0,
.maximum= 1,
.default_value = 0,
- },
- {
+ }, {
.id = V4L2_CID_ROTATE,
.type = V4L2_CTRL_TYPE_INTEGER,
.name = Rotation (CCW),
@@ -181,28 +179,23 @@ static int fimc_check_scaler_ratio(struct v4l2_rect *r,
struct fimc_frame *f)
static int fimc_get_scaler_factor(u32 src, u32 tar, u32 *ratio, u32 *shift)
{
- if (src = tar * 64) {
+ u32 sh = 6;
+
+ if (src = 64 * tar)
return -EINVAL;
- } else if (src = tar * 32) {
- *ratio = 32;
- *shift = 5;
- } else if (src = tar * 16) {
- *ratio = 16;
- *shift = 4;
- } else if (src = tar * 8) {
- *ratio = 8;
- *shift = 3;
- } else if (src = tar * 4) {
- *ratio = 4;
- *shift = 2;
- } else if (src = tar * 2) {
- *ratio = 2;
- *shift = 1;
- } else {
- *ratio = 1;
- *shift = 0;
+
+ while (sh--) {
+ u32 tmp = 1 sh;
+ if (src = tar * tmp) {
+ *shift = sh, *ratio = tmp;
+ return 0;
+ }
}
+ *shift = 0, *ratio = 1;
+
+ dbg(s: %d, t: %d, shift: %d, ratio: %d,
+ src, tar, *shift, *ratio);
return 0;
}
@@ -265,8 +258,8 @@ static int fimc_set_scaler_info(struct fimc_ctx *ctx)
static irqreturn_t fimc_isr(int irq, void *priv)
{
struct fimc_vid_buffer *src_buf, *dst_buf;
- struct fimc_dev *fimc = (struct fimc_dev *)priv;
struct fimc_ctx *ctx;
+ struct fimc_dev *fimc = priv;
BUG_ON(!fimc);
fimc_hw_clear_irq(fimc);
@@ -281,7 +274,7 @@ static irqreturn_t fimc_isr(int irq, void *priv)
dst_buf = v4l2_m2m_dst_buf_remove(ctx-m2m_ctx);
if (src_buf dst_buf) {
spin_lock(fimc-irqlock);
- src_buf-vb.state = dst_buf-vb.state = VIDEOBUF_DONE;
+ src_buf-vb.state = dst_buf-vb.state = VIDEOBUF_DONE;
wake_up(src_buf-vb.done);
wake_up(dst_buf-vb.done);
spin_unlock(fimc-irqlock);
@@ -295,20 +288,13 @@ isr_unlock:
}
/* The color format (planes_cnt, buff_cnt) must be already configured. */
-static int fimc_prepare_addr(struct fimc_ctx *ctx,
- struct fimc_vid_buffer *buf, enum v4l2_buf_type type)
+int fimc_prepare_addr(struct fimc_ctx *ctx, struct fimc_vid_buffer *buf,
+ struct fimc_frame *frame, struct fimc_addr *paddr)
{
- struct fimc_frame *frame;
- struct fimc_addr *paddr;
- u32 pix_size;
int ret = 0;
+ u32 pix_size;
- frame = ctx_m2m_get_frame(ctx, type);
- if (IS_ERR(frame))
- return PTR_ERR(frame);
- paddr = frame-paddr;
-
- if (!buf)
+ if (buf == NULL || frame == NULL)
return -EINVAL;
pix_size = frame-width * frame-height;
@@ -344,8 +330,8 @@ static int fimc_prepare_addr(struct fimc_ctx *ctx,
}
}
- dbg(PHYS_ADDR: type= %d, y= 0x%X cb= 0x%X cr= 0x%X ret= %d,
- type, paddr-y, paddr-cb, paddr-cr, ret);
+ dbg(PHYS_ADDR: y= 0x%X cb= 0x%X cr= 0x%X ret= %d,
+ paddr-y, paddr-cb, paddr-cr, ret);
return ret;
[PATCH 3/4 v3] V4L/DVB: s5p-fimc: Do not lock both capture and output buffer queue in s_fmt
It is not necessary to lock both capture and output buffer queue while
setting format for single queue.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-core.c | 69 +
1 files changed, 31 insertions(+), 38 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index fe46aea..a83977f 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -743,8 +743,9 @@ static int fimc_m2m_try_fmt(struct file *file, void *priv,
static int fimc_m2m_s_fmt(struct file *file, void *priv, struct v4l2_format *f)
{
struct fimc_ctx *ctx = priv;
- struct v4l2_device *v4l2_dev = ctx-fimc_dev-m2m.v4l2_dev;
- struct videobuf_queue *src_vq, *dst_vq;
+ struct fimc_dev *fimc = ctx-fimc_dev;
+ struct v4l2_device *v4l2_dev = fimc-m2m.v4l2_dev;
+ struct videobuf_queue *vq;
struct fimc_frame *frame;
struct v4l2_pix_format *pix;
unsigned long flags;
@@ -756,69 +757,61 @@ static int fimc_m2m_s_fmt(struct file *file, void *priv,
struct v4l2_format *f)
if (ret)
return ret;
- mutex_lock(ctx-fimc_dev-lock);
+ if (mutex_lock_interruptible(fimc-lock))
+ return -ERESTARTSYS;
- src_vq = v4l2_m2m_get_src_vq(ctx-m2m_ctx);
- dst_vq = v4l2_m2m_get_dst_vq(ctx-m2m_ctx);
+ vq = v4l2_m2m_get_vq(ctx-m2m_ctx, f-type);
+ mutex_lock(vq-vb_lock);
- mutex_lock(src_vq-vb_lock);
- mutex_lock(dst_vq-vb_lock);
+ if (videobuf_queue_is_busy(vq)) {
+ v4l2_err(v4l2_dev, %s: queue (%d) busy\n, __func__, f-type);
+ ret = -EBUSY;
+ goto sf_out;
+ }
+ spin_lock_irqsave(ctx-slock, flags);
if (f-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
- if (videobuf_queue_is_busy(src_vq)) {
- v4l2_err(v4l2_dev, %s queue busy\n, __func__);
- ret = -EBUSY;
- goto s_fmt_out;
- }
frame = ctx-s_frame;
- spin_lock_irqsave(ctx-slock, flags);
ctx-state |= FIMC_SRC_FMT;
- spin_unlock_irqrestore(ctx-slock, flags);
-
} else if (f-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
- if (videobuf_queue_is_busy(dst_vq)) {
- v4l2_err(v4l2_dev, %s queue busy\n, __func__);
- ret = -EBUSY;
- goto s_fmt_out;
- }
frame = ctx-d_frame;
- spin_lock_irqsave(ctx-slock, flags);
ctx-state |= FIMC_DST_FMT;
- spin_unlock_irqrestore(ctx-slock, flags);
} else {
+ spin_unlock_irqrestore(ctx-slock, flags);
v4l2_err(ctx-fimc_dev-m2m.v4l2_dev,
Wrong buffer/video queue type (%d)\n, f-type);
ret = -EINVAL;
- goto s_fmt_out;
+ goto sf_out;
}
+ spin_unlock_irqrestore(ctx-slock, flags);
pix = f-fmt.pix;
frame-fmt = find_format(f);
if (!frame-fmt) {
ret = -EINVAL;
- goto s_fmt_out;
+ goto sf_out;
}
- frame-f_width = pix-bytesperline * 8 / frame-fmt-depth;
- frame-f_height = pix-sizeimage/pix-bytesperline;
- frame-width = pix-width;
- frame-height = pix-height;
- frame-o_width = pix-width;
+ frame-f_width = pix-bytesperline * 8 / frame-fmt-depth;
+ frame-f_height = pix-height;
+ frame-width= pix-width;
+ frame-height = pix-height;
+ frame-o_width = pix-width;
frame-o_height = pix-height;
- frame-offs_h = 0;
- frame-offs_v = 0;
- frame-size = (pix-width * pix-height * frame-fmt-depth) 3;
- src_vq-field = dst_vq-field = pix-field;
+ frame-offs_h = 0;
+ frame-offs_v = 0;
+ frame-size = (pix-width * pix-height * frame-fmt-depth) 3;
+ vq-field = pix-field;
+
spin_lock_irqsave(ctx-slock, flags);
ctx-state |= FIMC_PARAMS;
spin_unlock_irqrestore(ctx-slock, flags);
- dbg(f_width= %d, f_height= %d, frame-f_width, frame-f_height);
+ dbg(f_w: %d, f_h: %d, frame-f_width, frame-f_height);
-s_fmt_out:
- mutex_unlock(dst_vq-vb_lock);
- mutex_unlock(src_vq-vb_lock);
- mutex_unlock(ctx-fimc_dev-lock);
+sf_out:
+ mutex_unlock(vq-vb_lock);
+ mutex_unlock(fimc-lock);
return ret;
}
--
1.7.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] V4L/DVB: videobuf-dma-sg: Use min_t(size_t, PAGE_SIZE ..)
Em 07-10-2010 10:46, Laurent Pinchart escreveu: Hi Mauro, On Thursday 07 October 2010 14:45:43 Mauro Carvalho Chehab wrote: As pointed by Laurent: I think min_t(size_t, PAGE_SIZE, size) is the preferred way. Thanks-to: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/video/videobuf-dma-sg.c b/drivers/media/video/videobuf-dma-sg.c index 7153e44..20f227e 100644 --- a/drivers/media/video/videobuf-dma-sg.c +++ b/drivers/media/video/videobuf-dma-sg.c @@ -116,8 +116,8 @@ static struct scatterlist *videobuf_pages_to_sg(struct page **pages, goto nopage; if (PageHighMem(pages[i])) goto highmem; -sg_set_page(sglist[i], pages[i], min((unsigned)PAGE_SIZE, size), 0); -size -= min((unsigned)PAGE_SIZE, size); +sg_set_page(sglist[i], pages[i], min_t(size_t, PAGE_SIZE, size), 0); This won't pass checkpatch.pl (line 80 characters long). Yes, but the 80 char-long is not a hard limit. In this case, it seemed better to just have a longer line. Beside, this patch applies on top of the previous one whereas I suppose you'd want to replace the previous one. I'll eventually merge the two patches when sending upstream. +size -= min_t(size_t, PAGE_SIZE, size); } return sglist; Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/16] go7007: Add MODULE_DEVICE_TABLE to the go7007 I2C modules
Acked-by: Pete Eberlein p...@sensoray.com
On Fri, 2010-09-24 at 16:14 +0200, Laurent Pinchart wrote:
The device table is required to load modules based on modaliases.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/staging/go7007/wis-ov7640.c |1 +
drivers/staging/go7007/wis-saa7113.c|1 +
drivers/staging/go7007/wis-saa7115.c|1 +
drivers/staging/go7007/wis-sony-tuner.c |1 +
drivers/staging/go7007/wis-tw2804.c |1 +
drivers/staging/go7007/wis-tw9903.c |1 +
drivers/staging/go7007/wis-uda1342.c|1 +
7 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/go7007/wis-ov7640.c
b/drivers/staging/go7007/wis-ov7640.c
index 4f0cbdd..6bc9470 100644
--- a/drivers/staging/go7007/wis-ov7640.c
+++ b/drivers/staging/go7007/wis-ov7640.c
@@ -81,6 +81,7 @@ static const struct i2c_device_id wis_ov7640_id[] = {
{ wis_ov7640, 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c, wis_ov7640_id);
static struct i2c_driver wis_ov7640_driver = {
.driver = {
diff --git a/drivers/staging/go7007/wis-saa7113.c
b/drivers/staging/go7007/wis-saa7113.c
index 72f5c1f..05e0e10 100644
--- a/drivers/staging/go7007/wis-saa7113.c
+++ b/drivers/staging/go7007/wis-saa7113.c
@@ -308,6 +308,7 @@ static const struct i2c_device_id wis_saa7113_id[] = {
{ wis_saa7113, 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c, wis_saa7113_id);
static struct i2c_driver wis_saa7113_driver = {
.driver = {
diff --git a/drivers/staging/go7007/wis-saa7115.c
b/drivers/staging/go7007/wis-saa7115.c
index cd950b6..46cff59 100644
--- a/drivers/staging/go7007/wis-saa7115.c
+++ b/drivers/staging/go7007/wis-saa7115.c
@@ -441,6 +441,7 @@ static const struct i2c_device_id wis_saa7115_id[] = {
{ wis_saa7115, 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c, wis_saa7115_id);
static struct i2c_driver wis_saa7115_driver = {
.driver = {
diff --git a/drivers/staging/go7007/wis-sony-tuner.c
b/drivers/staging/go7007/wis-sony-tuner.c
index 981c9b3..8f1b7d4 100644
--- a/drivers/staging/go7007/wis-sony-tuner.c
+++ b/drivers/staging/go7007/wis-sony-tuner.c
@@ -692,6 +692,7 @@ static const struct i2c_device_id wis_sony_tuner_id[] = {
{ wis_sony_tuner, 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c, wis_sony_tuner_id);
static struct i2c_driver wis_sony_tuner_driver = {
.driver = {
diff --git a/drivers/staging/go7007/wis-tw2804.c
b/drivers/staging/go7007/wis-tw2804.c
index ee28a99..5b218c5 100644
--- a/drivers/staging/go7007/wis-tw2804.c
+++ b/drivers/staging/go7007/wis-tw2804.c
@@ -331,6 +331,7 @@ static const struct i2c_device_id wis_tw2804_id[] = {
{ wis_tw2804, 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c, wis_tw2804_id);
static struct i2c_driver wis_tw2804_driver = {
.driver = {
diff --git a/drivers/staging/go7007/wis-tw9903.c
b/drivers/staging/go7007/wis-tw9903.c
index 80d4726..9230f4a 100644
--- a/drivers/staging/go7007/wis-tw9903.c
+++ b/drivers/staging/go7007/wis-tw9903.c
@@ -313,6 +313,7 @@ static const struct i2c_device_id wis_tw9903_id[] = {
{ wis_tw9903, 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c, wis_tw9903_id);
static struct i2c_driver wis_tw9903_driver = {
.driver = {
diff --git a/drivers/staging/go7007/wis-uda1342.c
b/drivers/staging/go7007/wis-uda1342.c
index 5c4eb49..0127be2 100644
--- a/drivers/staging/go7007/wis-uda1342.c
+++ b/drivers/staging/go7007/wis-uda1342.c
@@ -86,6 +86,7 @@ static const struct i2c_device_id wis_uda1342_id[] = {
{ wis_uda1342, 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c, wis_uda1342_id);
static struct i2c_driver wis_uda1342_driver = {
.driver = {
--
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 05/16] go7007: Don't use module names to load I2C modules
Acked-by: Pete Eberlein p...@sensoray.com
On Fri, 2010-09-24 at 16:14 +0200, Laurent Pinchart wrote:
With the v4l2_i2c_new_subdev* functions now supporting loading modules
based on modaliases, replace the hardcoded module name passed to those
functions by NULL.
All corresponding I2C modules have been checked, and all of them include
a module aliases table with names corresponding to what the go7007
driver uses.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/staging/go7007/go7007-driver.c | 43 ++-
1 files changed, 3 insertions(+), 40 deletions(-)
diff --git a/drivers/staging/go7007/go7007-driver.c
b/drivers/staging/go7007/go7007-driver.c
index 372a7c6..0a1d925 100644
--- a/drivers/staging/go7007/go7007-driver.c
+++ b/drivers/staging/go7007/go7007-driver.c
@@ -194,51 +194,15 @@ int go7007_reset_encoder(struct go7007 *go)
* Attempt to instantiate an I2C client by ID, probably loading a module.
*/
static int init_i2c_module(struct i2c_adapter *adapter, const char *type,
-int id, int addr)
+int addr)
{
struct go7007 *go = i2c_get_adapdata(adapter);
struct v4l2_device *v4l2_dev = go-v4l2_dev;
- char *modname;
- switch (id) {
- case I2C_DRIVERID_WIS_SAA7115:
- modname = wis-saa7115;
- break;
- case I2C_DRIVERID_WIS_SAA7113:
- modname = wis-saa7113;
- break;
- case I2C_DRIVERID_WIS_UDA1342:
- modname = wis-uda1342;
- break;
- case I2C_DRIVERID_WIS_SONY_TUNER:
- modname = wis-sony-tuner;
- break;
- case I2C_DRIVERID_WIS_TW9903:
- modname = wis-tw9903;
- break;
- case I2C_DRIVERID_WIS_TW2804:
- modname = wis-tw2804;
- break;
- case I2C_DRIVERID_WIS_OV7640:
- modname = wis-ov7640;
- break;
- case I2C_DRIVERID_S2250:
- modname = s2250;
- break;
- default:
- modname = NULL;
- break;
- }
-
- if (v4l2_i2c_new_subdev(v4l2_dev, adapter, modname, type, addr, NULL))
+ if (v4l2_i2c_new_subdev(v4l2_dev, adapter, NULL, type, addr, NULL))
return 0;
- if (modname != NULL)
- printk(KERN_INFO
- go7007: probing for module %s failed\n, modname);
- else
- printk(KERN_INFO
- go7007: sensor %u seems to be unsupported!\n, id);
+ printk(KERN_INFO go7007: probing for module i2c:%s failed\n, type);
return -1;
}
@@ -277,7 +241,6 @@ int go7007_register_encoder(struct go7007 *go)
for (i = 0; i go-board_info-num_i2c_devs; ++i)
init_i2c_module(go-i2c_adapter,
go-board_info-i2c_devs[i].type,
- go-board_info-i2c_devs[i].id,
go-board_info-i2c_devs[i].addr);
if (go-board_id == GO7007_BOARDID_ADLINK_MPG24)
i2c_clients_command(go-i2c_adapter,
--
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 04/16] go7007: Fix the TW2804 I2C type name
Acked-by: Pete Eberlein p...@sensoray.com
On Fri, 2010-09-24 at 16:14 +0200, Laurent Pinchart wrote:
The TW2804 I2C sub-device type name was incorrectly set to wis_twTW2804
for the adlink mpg24 board. Rename it to wis_tw2804.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/staging/go7007/go7007-usb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/go7007/go7007-usb.c
b/drivers/staging/go7007/go7007-usb.c
index 20ed930..bea9f4d 100644
--- a/drivers/staging/go7007/go7007-usb.c
+++ b/drivers/staging/go7007/go7007-usb.c
@@ -394,7 +394,7 @@ static struct go7007_usb_board board_adlink_mpg24 = {
.num_i2c_devs= 1,
.i2c_devs= {
{
- .type = wis_twTW2804,
+ .type = wis_tw2804,
.id = I2C_DRIVERID_WIS_TW2804,
.addr = 0x00, /* yes, really */
},
--
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: gspca, audio and ov534: regression.
On Wed, 6 Oct 2010 16:53:37 +0200 Antonio Ospite osp...@studenti.unina.it wrote: PS3 Eye audio is working with linux-2.6.33.7 it is broken in linux-2.6.35.7 already, I'll try to further narrow down the interval. Ah, alsamixer doesn't work even when the device is OK in pulseaudio... I was wrong, the audio part works even in 2.6.36-rc6 but _only_ when the webcam is plugged in from boot, could this have to do with the order gspca and snd-usb-audio are loaded? Hi Antonio, If you still have a kernel 2.6.33, may you try my test version (tarball in my web page)? As it contain only the gspca stuff, this may tell if the problem is in gspca or elsewhere in the kernel. Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: OMAP 3530 camera ISP forks and new media framework
On Thu, 7 Oct 2010, Hiremath, Vaibhav wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Thursday, October 07, 2010 6:58 PM To: Sakari Ailus Cc: Bastian Hecht; Linux Media Mailing List Subject: Re: OMAP 3530 camera ISP forks and new media framework Hi Bastian, On Thursday 07 October 2010 12:58:53 Sakari Ailus wrote: Bastian Hecht wrote: I want to write a sensor driver for the mt9p031 (not mt9t031) camera chip and start getting confused about the different kernel forks and There is already an mt9t031 v4l2-subdev / soc-camera driver, so, if mt9t031 and mt9p031 are indeed similar enough, I think, the right way is to join efforts to port soc-camera over to the new pad-level API and re-use the driver. Thanks Guennadi architectural changes that happen in V4L2. A similar problem was discussed in this mailing list at http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html. Currently I don't know which branch to follow. Either http://gitorious.org/omap3camera from Sakari Ailus or the branch media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from Laurent Pinchart. Both have an folder drivers/media/video/isp and are written for the new media controller architecture if I am right. Take Laurent's branch it has all the current patches in it. My gitorious tree isn't updated anymore. (I just had forgotten to add a note, it's there now.) I see in http://gitorious.org/omap3camera/camera-firmware that there is already an empty placeholder for the mt9t031. The README of the camera-firmware repository states: makemodes.pl is a perl script which converts sensor register lists from FIXME into C code. dcc-pulautin is a Makefile (mostly) that converts sensor register lists as C code into binaries understandable to sensor drivers. The end result is a binary with sensor driver name, sensor version and bin suffix, for example et8ek8-0002.bin. So I think the goal is to provide a script framework for camera systems. You just script some register tables and it creates a binary that can be read by a sensor driver made for that framework. If the a camera bridge driver for your chip exists, you are done. Am I right? Are drivers/media/video/et8ek8.c and drivers/staging/dream/camera/mt9p012_* such drivers? et8ek8 and smia-sensor currently use the camera-firmware binaries. The long term goal is to move more things to the sensor driver itself. Register lists related to a set of sensor settings are not an ideal way to handle sensor related settings since they could be controlled the driver instead. To be compatible with the OMAP3 ISP driver, sensor drivers need to provide a v4l2_subdev interface and implement the pad-level operations (see the media-0003-subdev-pad branch in the repository). I've written such a driver for the MT9T001. I've pushed it to the media- mt9t001 branch on http://git.linuxtv.org/pinchartl/media.git. Please note that the driver is based on a previous version of the subdev pad-level operations API, so it won't compile out of the box. Just to add ontop of this, you can find couple of more sensor (MT9V113 MT9T111) sub-dev driver at http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git?p=people/vaibhav/ti-psp-omap-video.git;a=shortlog;h=refs/heads/omap3cam-mc-devel Also I have already ported these sensor drivers to latest sub-dev pad level operations but have not tested and pushed to the Repository which I will do by this weekend. Thanks, Vaibhav As Sakari stated, the camera-firmware system shouldn't be used by new drivers. The driver should instead compute the register values directly from the information supplied by userspace (through the v4l2_subdev API) such as the frame size and the crop rectangle. Binary lists of register address/value pairs are definitely not the way to go. So do you think it is the right way to go to use your ISP driver, adapt drivers/staging/dream/camera/mt9p012_* to suit my mt9p031 and write a register list and create a camera firmware for that sensor driver with makemodes? I would go with drivers/media/video/et8ek8.c in Laurent's tree instead if you want to write a sensor driver to be used with the OMAP 3 ISP driver. Register lists are not that nice but the v4l2_subdev interface in that one is one of the good parts you get with that. Start with the MT9T001 driver, that will be easier. I'd also advice against using camera-firmware if you don't necessarily need that kind of functionality. I'd very strongly advice against it as well. Try to forget it even exists, it was a development mistake :-) I am still quite confused... if I get something wrong,
[cron job] v4l-dvb daily build 2.6.26 and up: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Oct 7 19:00:17 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15164:1da5fed5c8b2 git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: c8dd732fd119ce6d562d5fa82a10bbe75a376575 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.32.6-armv5: WARNINGS linux-2.6.33-armv5: WARNINGS linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: ERRORS linux-2.6.34-armv5-davinci: ERRORS linux-2.6.35.3-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: ERRORS linux-2.6.34-armv5-ixp: ERRORS linux-2.6.35.3-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: ERRORS linux-2.6.34-armv5-omap2: ERRORS linux-2.6.35.3-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS 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.32.6-m32r: WARNINGS linux-2.6.33-m32r: WARNINGS linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS 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 spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [git:v4l-dvb/v2.6.37] V4L/DVB: Staging: cx25821: fix braces and space coding style issues
Thanks.
Looks ok.
Signed off by Palash Bandyopadhyay
-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
Sent: Thursday, October 07, 2010 11:37 AM
To: linuxtv-comm...@linuxtv.org
Cc: Ruslan Pisarev; Palash Bandyopadhyay
Subject: [git:v4l-dvb/v2.6.37] V4L/DVB: Staging: cx25821: fix braces and space
coding style issues
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media-tree.git tree:
Subject: V4L/DVB: Staging: cx25821: fix braces and space coding style issues
Author: Ruslan Pisarev ruslanpisa...@gmail.com
Date:Mon Sep 27 10:01:36 2010 -0300
Errors found by the checkpatch.pl tool.
[mche...@redhat.com: merged a series of CodingStyle cleanup patches for
cx25851. They're all from the same author, and patches the same driver]
Signed-off-by: Ruslan Pisarev rus...@rpisarev.org.ua
Cc: Palash Bandyopadhyay palash.bandyopadh...@conexant.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
drivers/staging/cx25821/cx25821-audio-upstream.c | 13 +-
drivers/staging/cx25821/cx25821-audio.h| 10 +-
drivers/staging/cx25821/cx25821-core.c | 62 +-
drivers/staging/cx25821/cx25821-i2c.c |2 +-
drivers/staging/cx25821/cx25821-medusa-reg.h | 10 +-
drivers/staging/cx25821/cx25821-medusa-video.c |8 +-
drivers/staging/cx25821/cx25821-reg.h |4 +-
.../staging/cx25821/cx25821-video-upstream-ch2.c | 135 +---
.../staging/cx25821/cx25821-video-upstream-ch2.h | 14 +-
drivers/staging/cx25821/cx25821-video-upstream.c | 28 ++--
drivers/staging/cx25821/cx25821-video-upstream.h | 10 +-
drivers/staging/cx25821/cx25821.h | 51
12 files changed, 168 insertions(+), 179 deletions(-)
---
http://git.linuxtv.org/media-tree.git?a=commitdiff;h=b9a1211dff08aa73fc26db66980ec0710a6c7134
diff --git a/drivers/staging/cx25821/cx25821-audio-upstream.c
b/drivers/staging/cx25821/cx25821-audio-upstream.c
index cdff49f..6f32006 100644
--- a/drivers/staging/cx25821/cx25821-audio-upstream.c
+++ b/drivers/staging/cx25821/cx25821-audio-upstream.c
@@ -40,8 +40,8 @@ MODULE_AUTHOR(Hiep Huynh hiep.hu...@conexant.com);
MODULE_LICENSE(GPL);
static int _intr_msk =
-FLD_AUD_SRC_RISCI1 | FLD_AUD_SRC_OF | FLD_AUD_SRC_SYNC |
-FLD_AUD_SRC_OPC_ERR;
+ FLD_AUD_SRC_RISCI1 | FLD_AUD_SRC_OF | FLD_AUD_SRC_SYNC |
+ FLD_AUD_SRC_OPC_ERR;
int cx25821_sram_channel_setup_upstream_audio(struct cx25821_dev *dev,
struct sram_channel *ch,
@@ -506,7 +506,7 @@ int cx25821_audio_upstream_irq(struct cx25821_dev *dev, int
chan_num,
{
int i = 0;
u32 int_msk_tmp;
- struct sram_channel *channel = dev-channels[chan_num].sram_channels;
+ struct sram_channel *channel = dev-channels[chan_num].sram_channels;
dma_addr_t risc_phys_jump_addr;
__le32 *rp;
@@ -608,7 +608,7 @@ static irqreturn_t cx25821_upstream_irq_audio(int irq, void
*dev_id)
if (!dev)
return -1;
- sram_ch = dev-channels[dev-_audio_upstream_channel_select].
+ sram_ch = dev-channels[dev-_audio_upstream_channel_select].
sram_channels;
msk_stat = cx_read(sram_ch-int_mstat);
@@ -733,7 +733,7 @@ int cx25821_audio_upstream_init(struct cx25821_dev *dev,
int channel_select)
}
dev-_audio_upstream_channel_select = channel_select;
- sram_ch = dev-channels[channel_select].sram_channels;
+ sram_ch = dev-channels[channel_select].sram_channels;
/* Work queue */
INIT_WORK(dev-_audio_work_entry, cx25821_audioups_handler);
@@ -764,9 +764,8 @@ int cx25821_audio_upstream_init(struct cx25821_dev *dev,
int channel_select)
str_length + 1);
/* Default if filename is empty string */
- if (strcmp(dev-input_audiofilename, ) == 0) {
+ if (strcmp(dev-input_audiofilename, ) == 0)
dev-_audiofilename = /root/audioGOOD.wav;
- }
} else {
str_length = strlen(_defaultAudioName);
dev-_audiofilename = kmalloc(str_length + 1, GFP_KERNEL);
diff --git a/drivers/staging/cx25821/cx25821-audio.h
b/drivers/staging/cx25821/cx25821-audio.h
index 434b2a3..a702a0d 100644
--- a/drivers/staging/cx25821/cx25821-audio.h
+++ b/drivers/staging/cx25821/cx25821-audio.h
@@ -31,18 +31,18 @@
#define NUMBER_OF_PROGRAMS 8
/*
- Max size of the RISC program for a buffer. - worst case is 2 writes per line
- Space is also added for the 4 no-op instructions added on the end.
-*/
+ * Max size of the RISC program for a buffer. - worst case is 2 writes per line
+ * Space is also added for the 4 no-op instructions added on the end.
+ */
#ifndef USE_RISC_NOOP
#define MAX_BUFFER_PROGRAM_SIZE \
-
Re: bttv: No analogue sound output by TV card
Hello, my problem is still present in 2.6.36-rc7, the log output is unchanged from rc5. All the best, Richard On Fri, Oct 01, 2010 at 12:19:53AM +0200, Richard Atterer wrote: [Please CC me, I'm not on the list.] Hi, after switching from 2.6.34 to 2.6.36-rc5, the sound on my old Hauppauge analogue TV card has stopped working. Audio out from the TV card is connected to line-in of my motherboard (Gigabyte EG45M-DS2H) using the short cable that came with the TV card. Other audio sources (e.g. MP3 player) are audible when connected to line-in. The TV picture is fine. The log messages look really similar for the two kernels. 2.6.34 works: kernel: bttv: driver version 0.9.18 loaded kernel: bttv: using 8 buffers with 2080k (520 pages) each for capture kernel: bttv: Bt8xx card found (0). kernel: bttv0: Bt878 (rev 17) at :03:01.0, irq: 19, latency: 32, mmio: 0xe360 kernel: bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb kernel: bttv0: using: Hauppauge (bt878) [card=10,autodetected] kernel: IRQ 19/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs kernel: bttv0: gpio: en=, out= in=00db [init] kernel: bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] kernel: tveeprom 1-0050: Hauppauge model 44354, rev D147, serial# 1234567 kernel: tveeprom 1-0050: tuner model is LG TP18PSB01D (idx 47, type 28) kernel: tveeprom 1-0050: TV standards PAL(B/G) (eeprom 0x04) kernel: tveeprom 1-0050: audio processor is MSP3415 (idx 6) kernel: tveeprom 1-0050: has radio kernel: bttv0: Hauppauge eeprom indicates model#44354 kernel: bttv0: tuner type=28 kernel: msp3400 1-0040: MSP3415D-B3 found @ 0x80 (bt878 #0 [sw]) kernel: msp3400 1-0040: msp3400 supports nicam, mode is autodetect kernel: tuner 1-0061: chip found @ 0xc2 (bt878 #0 [sw]) kernel: tuner-simple 1-0061: creating new instance kernel: tuner-simple 1-0061: type set to 28 (LG PAL_BG+FM (TPI8PSB01D)) kernel: bttv0: registered device video0 kernel: bttv0: registered device vbi0 kernel: bttv0: registered device radio0 kernel: bttv0: PLL: 28636363 = 35468950 . kernel: bttv0: PLL: 28636363 = 35468950 . ok kernel: ok 2.6.36-rc5 does not work: kernel: bttv: driver version 0.9.18 loaded kernel: bttv: using 8 buffers with 2080k (520 pages) each for capture kernel: bttv: Bt8xx card found (0). kernel: bttv0: Bt878 (rev 17) at :03:01.0, irq: 19, latency: 32, mmio: 0xe360 kernel: bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb kernel: bttv0: using: Hauppauge (bt878) [card=10,autodetected] kernel: bttv0: gpio: en=, out= in=00db [init] kernel: bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] kernel: tveeprom 1-0050: Hauppauge model 44354, rev D147, serial# 1234567 kernel: tveeprom 1-0050: tuner model is LG TP18PSB01D (idx 47, type 28) kernel: tveeprom 1-0050: TV standards PAL(B/G) (eeprom 0x04) kernel: tveeprom 1-0050: audio processor is MSP3415 (idx 6) kernel: tveeprom 1-0050: has radio kernel: bttv0: Hauppauge eeprom indicates model#44354 kernel: bttv0: tuner type=28 kernel: msp3400 1-0040: MSP3415D-B3 found @ 0x80 (bt878 #0 [sw]) kernel: msp3400 1-0040: msp3400 supports nicam, mode is autodetect kernel: tuner 1-0061: chip found @ 0xc2 (bt878 #0 [sw]) kernel: tuner-simple 1-0061: creating new instance kernel: tuner-simple 1-0061: type set to 28 (LG PAL_BG+FM (TPI8PSB01D)) kernel: bttv0: registered device video0 kernel: bttv0: registered device vbi0 kernel: bttv0: registered device radio0 kernel: bttv0: PLL: 28636363 = 35468950 . ok The only real change is that the IRQF_DISABLED warning is gone. -- __ , | ) /| Richard Atterer | \/ | http://atterer.org -- 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: bttv: No analogue sound output by TV card
Em 07-10-2010 17:55, Richard Atterer escreveu: Hello, my problem is still present in 2.6.36-rc7, the log output is unchanged from rc5. All the best, Richard On Fri, Oct 01, 2010 at 12:19:53AM +0200, Richard Atterer wrote: [Please CC me, I'm not on the list.] Hi, after switching from 2.6.34 to 2.6.36-rc5, the sound on my old Hauppauge analogue TV card has stopped working. Audio out from the TV card is connected to line-in of my motherboard (Gigabyte EG45M-DS2H) using the short cable that came with the TV card. Other audio sources (e.g. MP3 player) are audible when connected to line-in. The TV picture is fine. The log messages look really similar for the two kernels. 2.6.34 works: kernel: bttv: driver version 0.9.18 loaded kernel: bttv: using 8 buffers with 2080k (520 pages) each for capture kernel: bttv: Bt8xx card found (0). kernel: bttv0: Bt878 (rev 17) at :03:01.0, irq: 19, latency: 32, mmio: 0xe360 kernel: bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb kernel: bttv0: using: Hauppauge (bt878) [card=10,autodetected] kernel: IRQ 19/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs kernel: bttv0: gpio: en=, out= in=00db [init] kernel: bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] kernel: tveeprom 1-0050: Hauppauge model 44354, rev D147, serial# 1234567 kernel: tveeprom 1-0050: tuner model is LG TP18PSB01D (idx 47, type 28) kernel: tveeprom 1-0050: TV standards PAL(B/G) (eeprom 0x04) kernel: tveeprom 1-0050: audio processor is MSP3415 (idx 6) kernel: tveeprom 1-0050: has radio kernel: bttv0: Hauppauge eeprom indicates model#44354 kernel: bttv0: tuner type=28 kernel: msp3400 1-0040: MSP3415D-B3 found @ 0x80 (bt878 #0 [sw]) kernel: msp3400 1-0040: msp3400 supports nicam, mode is autodetect kernel: tuner 1-0061: chip found @ 0xc2 (bt878 #0 [sw]) kernel: tuner-simple 1-0061: creating new instance kernel: tuner-simple 1-0061: type set to 28 (LG PAL_BG+FM (TPI8PSB01D)) kernel: bttv0: registered device video0 kernel: bttv0: registered device vbi0 kernel: bttv0: registered device radio0 kernel: bttv0: PLL: 28636363 = 35468950 . kernel: bttv0: PLL: 28636363 = 35468950 . ok kernel: ok 2.6.36-rc5 does not work: kernel: bttv: driver version 0.9.18 loaded kernel: bttv: using 8 buffers with 2080k (520 pages) each for capture kernel: bttv: Bt8xx card found (0). kernel: bttv0: Bt878 (rev 17) at :03:01.0, irq: 19, latency: 32, mmio: 0xe360 kernel: bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb kernel: bttv0: using: Hauppauge (bt878) [card=10,autodetected] kernel: bttv0: gpio: en=, out= in=00db [init] kernel: bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] kernel: tveeprom 1-0050: Hauppauge model 44354, rev D147, serial# 1234567 kernel: tveeprom 1-0050: tuner model is LG TP18PSB01D (idx 47, type 28) kernel: tveeprom 1-0050: TV standards PAL(B/G) (eeprom 0x04) kernel: tveeprom 1-0050: audio processor is MSP3415 (idx 6) kernel: tveeprom 1-0050: has radio kernel: bttv0: Hauppauge eeprom indicates model#44354 kernel: bttv0: tuner type=28 kernel: msp3400 1-0040: MSP3415D-B3 found @ 0x80 (bt878 #0 [sw]) kernel: msp3400 1-0040: msp3400 supports nicam, mode is autodetect kernel: tuner 1-0061: chip found @ 0xc2 (bt878 #0 [sw]) kernel: tuner-simple 1-0061: creating new instance kernel: tuner-simple 1-0061: type set to 28 (LG PAL_BG+FM (TPI8PSB01D)) kernel: bttv0: registered device video0 kernel: bttv0: registered device vbi0 kernel: bttv0: registered device radio0 kernel: bttv0: PLL: 28636363 = 35468950 . ok The only real change is that the IRQF_DISABLED warning is gone. I can't remember of any functional changes at sound stuff that might cause such trouble. The better would be if you could bisect what patch broke it and point it to us. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] V4L/DVB: cx231xx: remove a printk warning at -avcore and at -417
Em 28-09-2010 15:46, Mauro Carvalho Chehab escreveu: drivers/media/video/cx231xx/cx231xx-avcore.c:1608: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long unsigned int’ drivers/media/video/cx231xx/cx231xx-417.c:1047: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’ Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com OK, I just updated my tree with the patches that Mkrufky acked. It basically contains the same patches from my previous post, plus the patches that Palash sent, and Devin/Mkrufky patches from polaris4 tree, rebased over the top of kernel v2.6.36-rc7 (this makes easier for me to test and to merge). The patches are at: http://git.linuxtv.org/mchehab/cx231xx.git Sri already sent his ack for the first series of the patches. The tree contains two extra patches: 1) a cx231xx large CodingStyle fix patch: http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=eacd1a7749ae45d1f2f5782c013b863ff480746d It basically solves the issues that checkpatch.pl complained on this series of patches; 2) a cx231xx-417 gcc warning fix: http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=ca3a6a8c2a4819702e93b9612c4a6d90474ea9b5 Devin, Would it be ok for you if I merge them on my main tree? They're needed for one board I'm working with (a Pixelview SBTVD Hybrid - that supports both analog and full-seg ISDB-T). Thanks, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] V4L/DVB: cx231xx: remove a printk warning at -avcore and at -417
On Thu, Oct 7, 2010 at 5:48 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 28-09-2010 15:46, Mauro Carvalho Chehab escreveu: drivers/media/video/cx231xx/cx231xx-avcore.c:1608: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long unsigned int’ drivers/media/video/cx231xx/cx231xx-417.c:1047: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’ Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com OK, I just updated my tree with the patches that Mkrufky acked. It basically contains the same patches from my previous post, plus the patches that Palash sent, and Devin/Mkrufky patches from polaris4 tree, rebased over the top of kernel v2.6.36-rc7 (this makes easier for me to test and to merge). The patches are at: http://git.linuxtv.org/mchehab/cx231xx.git Sri already sent his ack for the first series of the patches. The tree contains two extra patches: 1) a cx231xx large CodingStyle fix patch: http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=eacd1a7749ae45d1f2f5782c013b863ff480746d It basically solves the issues that checkpatch.pl complained on this series of patches; 2) a cx231xx-417 gcc warning fix: http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=ca3a6a8c2a4819702e93b9612c4a6d90474ea9b5 Devin, Would it be ok for you if I merge them on my main tree? They're needed for one board I'm working with (a Pixelview SBTVD Hybrid - that supports both analog and full-seg ISDB-T). Yeah, I've got additional fixes which aren't on that tree yet, but I don't see any reason why what's there cannot be merged. It would be helpful if you could get Douglas to merge both sets of patches (mine and yours) to the hg backport tree as well, so I can continue development without requiring the bleeding edge kernel (all the work going on is for an embedded target which is running a relatively old kernel). I've got another couple dozen patches and I'm willing to continue pushing this stuff upstream, but you need to meet me halfway here by not making the bleeding edge kernel a requirement for this work. 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 01/10] V4L/DVB: cx231xx: remove a printk warning at -avcore and at -417
Em 07-10-2010 19:04, Devin Heitmueller escreveu: On Thu, Oct 7, 2010 at 5:48 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 28-09-2010 15:46, Mauro Carvalho Chehab escreveu: drivers/media/video/cx231xx/cx231xx-avcore.c:1608: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long unsigned int’ drivers/media/video/cx231xx/cx231xx-417.c:1047: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’ Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com OK, I just updated my tree with the patches that Mkrufky acked. It basically contains the same patches from my previous post, plus the patches that Palash sent, and Devin/Mkrufky patches from polaris4 tree, rebased over the top of kernel v2.6.36-rc7 (this makes easier for me to test and to merge). The patches are at: http://git.linuxtv.org/mchehab/cx231xx.git Sri already sent his ack for the first series of the patches. The tree contains two extra patches: 1) a cx231xx large CodingStyle fix patch: http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=eacd1a7749ae45d1f2f5782c013b863ff480746d It basically solves the issues that checkpatch.pl complained on this series of patches; 2) a cx231xx-417 gcc warning fix: http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=ca3a6a8c2a4819702e93b9612c4a6d90474ea9b5 Devin, Would it be ok for you if I merge them on my main tree? They're needed for one board I'm working with (a Pixelview SBTVD Hybrid - that supports both analog and full-seg ISDB-T). Yeah, I've got additional fixes which aren't on that tree yet, but I don't see any reason why what's there cannot be merged. Ok, thanks! It would be helpful if you could get Douglas to merge both sets of patches (mine and yours) to the hg backport tree as well, so I can continue development without requiring the bleeding edge kernel (all the work going on is for an embedded target which is running a relatively old kernel). I'm c/c Douglas on this email. Douglas had an ugent issue that required him to travel abroad. He just returned yesterday night. Let's hope he'll find some time to sync -hg with -git and backport those patches. I've got another couple dozen patches and I'm willing to continue pushing this stuff upstream, but you need to meet me halfway here by not making the bleeding edge kernel a requirement for this work. Ok. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Asus MyCinema P7131 Dual support
Hi Giorgio, Am Mittwoch, den 06.10.2010, 13:50 +0200 schrieb Giorgio: [big snip] Likely, I only have to read the LKML daily ... Despite of that, we need a good analysis of course, and a way how to avoid such. Maybe we can have some kind of test team? It would help to find regressions before it's too late. Cheers, Hermann Giorgio Vazzana Yes, we always need test teams. And Mauro explicitly did call for testing. I did, Dmitry did and Mauro. But we did not find the potential bug, caused by moving some identical code between saa7134-ts and saa7134-core forth and back. This was still on hg and I only have _some_ of such cards. Having this on latest Linus git stuff, likely only compile fixes on previous -next, can find such ... ;) I'm sorry for repeating my dumbness on that. Cheers, Hermann -- 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] V4L/DVB: cx231xx: declare static functions as such
drivers/media/video/cx23885/built-in.o: In function `mc417_memory_write':
/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cx23885-417.c:482: multiple
definition of `mc417_memory_write'
drivers/media/video/cx231xx/built-in.o:/home/v4l/v4l/patchwork/drivers/media/video/cx231xx/cx231xx-417.c:477:
first defined here
drivers/media/video/cx23885/built-in.o: In function `mc417_gpio_set':
/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cx23885-417.c:636: multiple
definition of `mc417_gpio_set'
drivers/media/video/cx231xx/built-in.o:/home/v4l/v4l/patchwork/drivers/media/video/cx231xx/cx231xx-417.c:615:
first defined here
drivers/media/video/cx23885/built-in.o: In function `mc417_gpio_enable':
/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cx23885-417.c:656: multiple
definition of `mc417_gpio_enable'
drivers/media/video/cx231xx/built-in.o:/home/v4l/v4l/patchwork/drivers/media/video/cx231xx/cx231xx-417.c:635:
first defined here
drivers/media/video/cx23885/built-in.o: In function `mc417_memory_read':
/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cx23885-417.c:546: multiple
definition of `mc417_memory_read'
drivers/media/video/cx231xx/built-in.o:/home/v4l/v4l/patchwork/drivers/media/video/cx231xx/cx231xx-417.c:541:
first defined here
drivers/media/video/cx23885/built-in.o: In function `mc417_gpio_clear':
/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cx23885-417.c:646: multiple
definition of `mc417_gpio_clear'
drivers/media/video/cx231xx/built-in.o:/home/v4l/v4l/patchwork/drivers/media/video/cx231xx/cx231xx-417.c:625:
first defined here
drivers/media/video/cx23885/built-in.o: In function `mc417_register_read':
/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cx23885-417.c:388: multiple
definition of `mc417_register_read'
drivers/media/video/cx231xx/built-in.o:/home/v4l/v4l/patchwork/drivers/media/video/cx231xx/cx231xx-417.c:401:
first defined here
drivers/media/video/cx23885/built-in.o: In function `mc417_register_write':
/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cx23885-417.c:324: multiple
definition of `mc417_register_write'
drivers/media/video/cx231xx/built-in.o:/home/v4l/v4l/patchwork/drivers/media/video/cx231xx/cx231xx-417.c:343:
first defined here
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/cx231xx/cx231xx-417.c
b/drivers/media/video/cx231xx/cx231xx-417.c
index b5b6998..2dbad82 100644
--- a/drivers/media/video/cx231xx/cx231xx-417.c
+++ b/drivers/media/video/cx231xx/cx231xx-417.c
@@ -296,7 +296,7 @@ enum cx231xx_mute_video_shift {
#define CX23417_GPIO_MASK 0xFC0003FF
-int setITVCReg(struct cx231xx *dev, u32 gpio_direction, u32 value)
+static int setITVCReg(struct cx231xx *dev, u32 gpio_direction, u32 value)
{
int status = 0;
u32 _gpio_direction = 0;
@@ -307,7 +307,7 @@ int setITVCReg(struct cx231xx *dev, u32 gpio_direction, u32
value)
(u8 *)value, 4, 0, 0);
return status;
}
-int getITVCReg(struct cx231xx *dev, u32 gpio_direction, u32 *pValue)
+static int getITVCReg(struct cx231xx *dev, u32 gpio_direction, u32 *pValue)
{
int status = 0;
u32 _gpio_direction = 0;
@@ -319,7 +319,8 @@ int getITVCReg(struct cx231xx *dev, u32 gpio_direction, u32
*pValue)
(u8 *)pValue, 4, 0, 1);
return status;
}
-int waitForMciComplete(struct cx231xx *dev)
+
+static int waitForMciComplete(struct cx231xx *dev)
{
u32 gpio;
u32 gpio_driection = 0;
@@ -339,7 +340,7 @@ int waitForMciComplete(struct cx231xx *dev)
return 0;
}
-int mc417_register_write(struct cx231xx *dev, u16 address, u32 value)
+static int mc417_register_write(struct cx231xx *dev, u16 address, u32 value)
{
u32 temp;
int status = 0;
@@ -397,7 +398,7 @@ int mc417_register_write(struct cx231xx *dev, u16 address,
u32 value)
return waitForMciComplete(dev);
}
-int mc417_register_read(struct cx231xx *dev, u16 address, u32 *value)
+static int mc417_register_read(struct cx231xx *dev, u16 address, u32 *value)
{
/*write address byte 0;*/
u32 temp;
@@ -473,7 +474,7 @@ int mc417_register_read(struct cx231xx *dev, u16 address,
u32 *value)
return ret;
}
-int mc417_memory_write(struct cx231xx *dev, u32 address, u32 value)
+static int mc417_memory_write(struct cx231xx *dev, u32 address, u32 value)
{
/*write data byte 0;*/
@@ -537,7 +538,7 @@ int mc417_memory_write(struct cx231xx *dev, u32 address,
u32 value)
return 0;
}
-int mc417_memory_read(struct cx231xx *dev, u32 address, u32 *value)
+static int mc417_memory_read(struct cx231xx *dev, u32 address, u32 *value)
{
u32 temp = 0;
u32 return_value = 0;
@@ -611,7 +612,7 @@ int mc417_memory_read(struct cx231xx *dev, u32 address, u32
*value)
return ret;
}
-void mc417_gpio_set(struct cx231xx *dev, u32 mask)
+static void mc417_gpio_set(struct cx231xx *dev, u32 mask)
{
u32 val;
@@ -621,7 +622,7 @@ void
[PATCH 2/2] V4L/DVB: cx231xx: remove some unused functions
This file came originally from cx23885 driver. Some functions aren't
used. Now that they are declared as static, we have those errors:
drivers/media/video/cx231xx/cx231xx-417.c:615: warning: ‘mc417_gpio_set’
defined but not used
drivers/media/video/cx231xx/cx231xx-417.c:625: warning: ‘mc417_gpio_clear’
defined but not used
drivers/media/video/cx231xx/cx231xx-417.c:635: warning: ‘mc417_gpio_enable’
defined but not used
As they're not used, just remove them. If needed, they can be restored from
the git logs or from the cx23885 driver.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/cx231xx/cx231xx-417.c
b/drivers/media/video/cx231xx/cx231xx-417.c
index 2dbad82..e456b97 100644
--- a/drivers/media/video/cx231xx/cx231xx-417.c
+++ b/drivers/media/video/cx231xx/cx231xx-417.c
@@ -612,39 +612,6 @@ static int mc417_memory_read(struct cx231xx *dev, u32
address, u32 *value)
return ret;
}
-static void mc417_gpio_set(struct cx231xx *dev, u32 mask)
-{
- u32 val;
-
- /* Set the gpio value */
- mc417_register_read(dev, 0x900C, val);
- val |= (mask 0x000);
- mc417_register_write(dev, 0x900C, val);
-}
-
-static void mc417_gpio_clear(struct cx231xx *dev, u32 mask)
-{
- u32 val;
-
- /* Clear the gpio value */
- mc417_register_read(dev, 0x900C, val);
- val = ~(mask 0x);
- mc417_register_write(dev, 0x900C, val);
-}
-
-static void mc417_gpio_enable(struct cx231xx *dev, u32 mask, int asoutput)
-{
- u32 val;
-
- /* Enable GPIO direction bits */
- mc417_register_read(dev, 0x9020, val);
- if (asoutput)
- val |= (mask 0x);
- else
- val = ~(mask 0x);
-
- mc417_register_write(dev, 0x9020, val);
-}
/* -- */
/* MPEG encoder API */
--
1.7.1
--
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/2] cx231xx: fix some compilation issues
cx231xx compilation were broken with allmodconfig, due to some duplicated symbols with cx23885 driver. This small patch series fix it. Mauro Carvalho Chehab (2): V4L/DVB: cx231xx: declare static functions as such V4L/DVB: cx231xx: remove some unused functions drivers/media/video/cx231xx/cx231xx-417.c | 57 +++-- 1 files changed, 13 insertions(+), 44 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] V4L/DVB: cx231xx: remove a printk warning at -avcore and at -417
Em 07-10-2010 19:04, Devin Heitmueller escreveu: On Thu, Oct 7, 2010 at 5:48 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 28-09-2010 15:46, Mauro Carvalho Chehab escreveu: drivers/media/video/cx231xx/cx231xx-avcore.c:1608: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long unsigned int’ drivers/media/video/cx231xx/cx231xx-417.c:1047: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’ Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com OK, I just updated my tree with the patches that Mkrufky acked. It basically contains the same patches from my previous post, plus the patches that Palash sent, and Devin/Mkrufky patches from polaris4 tree, rebased over the top of kernel v2.6.36-rc7 (this makes easier for me to test and to merge). The patches are at: http://git.linuxtv.org/mchehab/cx231xx.git Sri already sent his ack for the first series of the patches. The tree contains two extra patches: 1) a cx231xx large CodingStyle fix patch: http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=eacd1a7749ae45d1f2f5782c013b863ff480746d It basically solves the issues that checkpatch.pl complained on this series of patches; 2) a cx231xx-417 gcc warning fix: http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=ca3a6a8c2a4819702e93b9612c4a6d90474ea9b5 Devin, Would it be ok for you if I merge them on my main tree? They're needed for one board I'm working with (a Pixelview SBTVD Hybrid - that supports both analog and full-seg ISDB-T). Yeah, I've got additional fixes which aren't on that tree yet, but I don't see any reason why what's there cannot be merged. Applied, thanks! Thanks to the compilation tests I do here, I discovered some duplicated symbols between cx23885 and cx231xx-417. I just fixed the errors. Patches were post to the ML and were also applied to the tree, to avoid compilation breakages. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] Audio standards on tm6000
Hi Mauro
Not so good. Audio with this patch has bad white noise sometimes and
bad quality. I try found better configuration for SECAM-DK.
With my best regards, Dmitry.
Hi Dmitri,
IMO, the better is to remove the audio init from tm6000-core and add
a separate per-standard set of tables.
I'm enclosing the patch for it. Please check if this won't break for
your device.
On all tests I did here with a tm6010 device (HVR 900H), I was only
able to listen to white noise.
I'm suspecting that this device uses XC3028 MTS mode (e. g. uses
xc3028 to decode audio, and just inputs the audio stream from some
line IN. As the driver is not able yet to handle an audio mux, this
may explain why I'm not able to receive any audio at all.
Maybe tm5600 devices may also require (or use) line input entries,
instead of I2S.
Could you please check those issues?
PS.: the PAL/M hunk will probably fail, as I likely applied some
patches before this one, in order to try to fix it. It should be
trivial to solve the conflicts.
---
tm6000: Implement audio standard tables
Implement separate tables for audio standards, associating them with
the video standards.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c index 57cb69e..9cb2901 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -200,6 +200,10 @@ int tm6000_init_analog_mode(struct tm6000_core
*dev) val = ~0x40;
tm6000_set_reg(dev,
TM6010_REQ07_RC0_ACTIVE_VIDEO_SOURCE, val);
+ tm6000_set_reg(dev,
TM6010_REQ08_RF1_AADC_POWER_DOWN, 0xfc); +
+#if 0/* FIXME: VBI is standard-dependent */
+
/* Init teletext */
tm6000_set_reg(dev, TM6010_REQ07_R3F_RESET, 0x01);
tm6000_set_reg(dev,
TM6010_REQ07_R41_TELETEXT_VBI_CODE1, 0x27); @@ -249,44 +253,7 @@ int
tm6000_init_analog_mode(struct tm6000_core *dev) tm6000_set_reg(dev,
TM6010_REQ07_R5B_VBI_TELETEXT_DTO0, 0x4c); tm6000_set_reg(dev,
TM6010_REQ07_R40_TELETEXT_VBI_CODE0, 0x01); tm6000_set_reg(dev,
TM6010_REQ07_R3F_RESET, 0x00); -
-
- /* Init audio */
- tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x00);
- tm6000_set_reg(dev,
TM6010_REQ08_R02_A_FIX_GAIN_CTRL, 0x04);
- tm6000_set_reg(dev,
TM6010_REQ08_R03_A_AUTO_GAIN_CTRL, 0x00);
- tm6000_set_reg(dev, TM6010_REQ08_R04_A_SIF_AMP_CTRL,
0xa0);
- tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD,
0x06);
- tm6000_set_reg(dev, TM6010_REQ08_R07_A_LEFT_VOL,
0x00);
- tm6000_set_reg(dev, TM6010_REQ08_R08_A_RIGHT_VOL,
0x00);
- tm6000_set_reg(dev, TM6010_REQ08_R09_A_MAIN_VOL,
0x08);
- tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD,
0x91);
- tm6000_set_reg(dev, TM6010_REQ08_R0B_A_ASD_THRES1,
0x20);
- tm6000_set_reg(dev, TM6010_REQ08_R0C_A_ASD_THRES2,
0x12);
- tm6000_set_reg(dev, TM6010_REQ08_R0D_A_AMD_THRES,
0x20);
- tm6000_set_reg(dev, TM6010_REQ08_R0E_A_MONO_THRES1,
0xf0);
- tm6000_set_reg(dev, TM6010_REQ08_R0F_A_MONO_THRES2,
0x80);
- tm6000_set_reg(dev, TM6010_REQ08_R10_A_MUTE_THRES1,
0xc0);
- tm6000_set_reg(dev, TM6010_REQ08_R11_A_MUTE_THRES2,
0x80);
- tm6000_set_reg(dev, TM6010_REQ08_R12_A_AGC_U, 0x12);
- tm6000_set_reg(dev, TM6010_REQ08_R13_A_AGC_ERR_T,
0xfe);
- tm6000_set_reg(dev,
TM6010_REQ08_R14_A_AGC_GAIN_INIT, 0x20);
- tm6000_set_reg(dev, TM6010_REQ08_R15_A_AGC_STEP_THR,
0x14);
- tm6000_set_reg(dev, TM6010_REQ08_R16_A_AGC_GAIN_MAX,
0xfe);
- tm6000_set_reg(dev, TM6010_REQ08_R17_A_AGC_GAIN_MIN,
0x01);
- tm6000_set_reg(dev, TM6010_REQ08_R18_A_TR_CTRL,
0xa0);
- tm6000_set_reg(dev, TM6010_REQ08_R19_A_FH_2FH_GAIN,
0x32);
- tm6000_set_reg(dev,
TM6010_REQ08_R1A_A_NICAM_SER_MAX, 0x64);
- tm6000_set_reg(dev,
TM6010_REQ08_R1B_A_NICAM_SER_MIN, 0x20);
- tm6000_set_reg(dev, REQ_08_SET_GET_AVREG_BIT, 0x1c,
0x00);
- tm6000_set_reg(dev, REQ_08_SET_GET_AVREG_BIT, 0x1d,
0x00);
- tm6000_set_reg(dev,
TM6010_REQ08_R1E_A_GAIN_DEEMPH_OUT, 0x13);
- tm6000_set_reg(dev,
TM6010_REQ08_R1F_A_TEST_INTF_SEL, 0x00);
- tm6000_set_reg(dev, TM6010_REQ08_R20_A_TEST_PIN_SEL,
0x00);
- tm6000_set_reg(dev, TM6010_REQ08_RE4_ADC_IN2_SEL,
0xf3);
- tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD,
0x00);
- tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x80);
-
+#endif
} else {
/* Enables soft reset */
tm6000_set_reg(dev, TM6010_REQ07_R3F_RESET, 0x01);
@@ -360,7 +327,6 @@ int tm6000_init_digital_mode(struct tm6000_core
*dev) tm6000_set_reg(dev,
