RE: Prof DVB-S2 USB device
Dear Oliver, Sometimes, I am seeing the following errors also. ... ... [ 4150.160583] stv0900_read_reg: i2c error -11, reg[0xf1a8] [ 4150.183959] stv0900_read_reg [ 4150.183990] stv0900_read_reg: i2c error -11, reg[0xf1a8] [ 4150.207427] stv0900_read_reg [ 4150.207458] stv0900_read_reg: i2c error -11, reg[0xf1a8] [ 4150.230834] stv0900_read_reg [ 4150.230865] stv0900_read_reg: i2c error -11, reg[0xf1a8] [ 4150.254302] stv0900_read_reg [ 4150.254333] stv0900_read_reg: i2c error -11, reg[0xf1a8] [ 4150.277740] stv0900_read_reg [ 4150.20] stv0900_read_reg: i2c error -11, reg[0xf1a8] [ 4150.301147] stv0900_read_reg [ 4150.301208] stv0900_read_reg: i2c error -11, reg[0xf1a8] [ 4150.324615] stv0900_read_reg [ 4150.324645] stv0900_read_reg: i2c error -11, reg[0xf1a8] [ 4150.348052] stv0900_read_reg [ 4150.348083] stv0900_read_reg: i2c error -11, reg[0xf1a8] [ 4150.371459] stv0900_read_reg [ 4150.371520] stv0900_read_reg: i2c error -11, reg[0xf1a8] [ 4150.371612] stv0900_search: [ 4150.371643] stv0900_read_status: [ 4150.371673] stv0900_read_reg [ 4156.184020] stv0900_status demod_state = 0 [ 4156.184051] stv0900_status: locked = 0 [ 4156.184082] stv0900_read_reg [ 4160.215240] stv0900_read_reg [ 4164.246490] stv0900_read_reg [ 4168.277740] stv0900_read_reg [ 4172.309020] stv0900_get_mclk_freq: Calculated Mclk = 450 [ 4172.309051] TS bitrate = 0 Mbit/sec [ 4174.324615] DEMOD LOCK FAIL ... ... Regards, Kishore. From: Krishna Kishore Sent: Wednesday, July 24, 2013 12:26 PM To: Oliver Schinagl Cc: linux-media@vger.kernel.org Subject: RE: Prof DVB-S2 USB device Dear Oliver, Thanks for your response. Here are more details. Please help me in making this work. Linux version: -sh-4.1# uname -a Linux (none) 3.4.0 #28 SMP PREEMPT Tue Jul 23 16:24:14 IST 2013 armv7l GNU/Linux [dotconfig is attached to this email] lsusb -t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M |__ Port 1: Dev 2, If 0, Class=, Driver=hub/5p, 480M |__ Port 1: Dev 3, If 0, Class=, Driver=smsc95xx, 480M |__ Port 2: Dev 5, If 0, Class=, Driver=dw2102, 480M dmesg: [ 126.824951] usb 1-1.2: new high-speed USB device number 5 using ehci-omap [ 126.950347] usb 1-1.2: New USB device found, idVendor=3034, idProduct=7500 [ 126.957794] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 126.983184] dvb-usb: found a 'Prof 7500 USB DVB-S2' in cold state, will try to load a firmware [ 127.033477] dvb-usb: downloading firmware from file 'dvb-usb-p7500.fw' [ 127.051177] dw2102: start downloading DW210X firmware [ 127.238739] dvb-usb: found a 'Prof 7500 USB DVB-S2' in warm state. [ 127.255828] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 127.271270] DVB: registering new adapter (Prof 7500 USB DVB-S2) [ 1159.277740] dvb-usb: MAC address: 40:40:40:40:40:40 [ 1159.325531] dw2102: Kishore: prof_7500_frontend_attach [ 1159.325561] [ 1159.340332] Kishore stv0900_attach: [ 1159.340362] stv0900_init_internal [ 1159.340393] stv0900_init_internal: Create New Internal Structure! [ 1159.340423] stv0900_read_reg [ 1179.527770] stv0900_read_reg [ 1550.418365] stv0900_read_reg [ 1637.090240] stv0900_st_dvbs2_single [ 1637.090270] stv0900_stop_all_s2_modcod [ 1669.340270] stv0900_activate_s2_modcod_single [ 1703.605865] stv0900_read_reg [ 1709.652740] stv0900_read_reg [ 1715.699584] stv0900_read_reg [ 1721.746490] stv0900_read_reg [ 1727.793365] stv0900_read_reg [ 1733.840209] stv0900_read_reg [ 1739.887115] stv0900_read_reg [ 1743.918395] stv0900_read_reg [ 1749.965240] stv0900_read_reg [ 1756.012115] stv0900_set_ts_parallel_serial path1 3 path2 0 [ 1758.027740] stv0900_read_reg [ 1764.074615] stv0900_read_reg [ 1770.121490] stv0900_read_reg [ 1776.168334] stv0900_read_reg [ 1782.215209] stv0900_read_reg [ 1788.262115] stv0900_read_reg [ 1810.433990] stv0900_read_reg [ 1816.480865] stv0900_read_reg [ 1824.543365] stv0900_read_reg [ 1830.590240] stv0900_read_reg [ 1838.652740] stv0900_read_reg [ 1844.699615] stv0900_read_reg [ 1850.746490] stv0900_set_mclk: Mclk set to 13500, Quartz = 2700 [ 1850.746520] stv0900_read_reg [ 1854.40] stv0900_read_reg [ 1860.824615] stv0900_read_reg [ 1864.855865] stv0900_read_reg [ 1868.887115] stv0900_get_mclk_freq: Calculated Mclk = 152672117 [ 1876.965209] stv0900_read_reg [ 1883.027709] stv0900_read_reg [ 1887.058990] stv0900_read_reg [ 1891.090240] stv0900_get_mclk_freq: Calculated Mclk = 152672117 [ 1891.090270] Kishore stv0900_attach: Attaching STV0900 demodulator(0) [ 1891.090301] dw2102: Kishore: dvb_attach stb6100_attach [ 1891.090332] [ 1891.097442] Kishore stb6100_attach: [ 1891.101409] Kishore stb6100_attach: Attaching STB6100 [ 1893.105957] dw2102: Attached STV0900+STB6100A! [ 1893.105957] [ 1893.112335] DVB: registering adapter 0 frontend 0 (STV0900 frontend)... [ 1893.137878] input: IR-receiver inside an USB DVB receiver as
Re: Prof DVB-S2 USB device
On 24-07-13 08:56, Krishna Kishore wrote: Dear Oliver, Thanks for your response. Here are more details. Please help me in making this work. Linux version: -sh-4.1# uname -a Linux (none) 3.4.0 #28 SMP PREEMPT Tue Jul 23 16:24:14 IST 2013 armv7l GNU/Linux Your kernel is ancient. The latest kernel with the latest media fluff is 3.10.2; Since you are on arm, chances are your platform isn't that well supported with later kernels, but even in the 3.4 world your kernel is ancient. Latest stable is 3.4.54. So you are asking for help, with something that could have been fixed 3 times over (or not, I don't know). So my first suggestion is to upgrade your kernel. If that's not possible on your arm platform, contact the supplier of your kernel. Meanwhile, since this is an USB device, you could try it on a desktop. Get a recent Ubuntu live CD and see if it works there. At least then you can quickly and easily see if your problem hasn't been fixed in the last year. [dotconfig is attached to this email] lsusb -t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M |__ Port 1: Dev 2, If 0, Class=, Driver=hub/5p, 480M |__ Port 1: Dev 3, If 0, Class=, Driver=smsc95xx, 480M |__ Port 2: Dev 5, If 0, Class=, Driver=dw2102, 480M dmesg: [ 126.824951] usb 1-1.2: new high-speed USB device number 5 using ehci-omap [ 126.950347] usb 1-1.2: New USB device found, idVendor=3034, idProduct=7500 [ 126.957794] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 126.983184] dvb-usb: found a 'Prof 7500 USB DVB-S2' in cold state, will try to load a firmware [ 127.033477] dvb-usb: downloading firmware from file 'dvb-usb-p7500.fw' [ 127.051177] dw2102: start downloading DW210X firmware [ 127.238739] dvb-usb: found a 'Prof 7500 USB DVB-S2' in warm state. [ 127.255828] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 127.271270] DVB: registering new adapter (Prof 7500 USB DVB-S2) [ 1159.277740] dvb-usb: MAC address: 40:40:40:40:40:40 [ 1159.325531] dw2102: Kishore: prof_7500_frontend_attach [ 1159.325561] [ 1159.340332] Kishore stv0900_attach: [ 1159.340362] stv0900_init_internal [ 1159.340393] stv0900_init_internal: Create New Internal Structure! [ 1159.340423] stv0900_read_reg [ 1179.527770] stv0900_read_reg [ 1550.418365] stv0900_read_reg [ 1637.090240] stv0900_st_dvbs2_single [ 1637.090270] stv0900_stop_all_s2_modcod [ 1669.340270] stv0900_activate_s2_modcod_single [ 1703.605865] stv0900_read_reg [ 1709.652740] stv0900_read_reg [ 1715.699584] stv0900_read_reg [ 1721.746490] stv0900_read_reg [ 1727.793365] stv0900_read_reg [ 1733.840209] stv0900_read_reg [ 1739.887115] stv0900_read_reg [ 1743.918395] stv0900_read_reg [ 1749.965240] stv0900_read_reg [ 1756.012115] stv0900_set_ts_parallel_serial path1 3 path2 0 [ 1758.027740] stv0900_read_reg [ 1764.074615] stv0900_read_reg [ 1770.121490] stv0900_read_reg [ 1776.168334] stv0900_read_reg [ 1782.215209] stv0900_read_reg [ 1788.262115] stv0900_read_reg [ 1810.433990] stv0900_read_reg [ 1816.480865] stv0900_read_reg [ 1824.543365] stv0900_read_reg [ 1830.590240] stv0900_read_reg [ 1838.652740] stv0900_read_reg [ 1844.699615] stv0900_read_reg [ 1850.746490] stv0900_set_mclk: Mclk set to 13500, Quartz = 2700 [ 1850.746520] stv0900_read_reg [ 1854.40] stv0900_read_reg [ 1860.824615] stv0900_read_reg [ 1864.855865] stv0900_read_reg [ 1868.887115] stv0900_get_mclk_freq: Calculated Mclk = 152672117 [ 1876.965209] stv0900_read_reg [ 1883.027709] stv0900_read_reg [ 1887.058990] stv0900_read_reg [ 1891.090240] stv0900_get_mclk_freq: Calculated Mclk = 152672117 [ 1891.090270] Kishore stv0900_attach: Attaching STV0900 demodulator(0) [ 1891.090301] dw2102: Kishore: dvb_attach stb6100_attach [ 1891.090332] [ 1891.097442] Kishore stb6100_attach: [ 1891.101409] Kishore stb6100_attach: Attaching STB6100 [ 1893.105957] dw2102: Attached STV0900+STB6100A! [ 1893.105957] [ 1893.112335] DVB: registering adapter 0 frontend 0 (STV0900 frontend)... [ 1893.137878] input: IR-receiver inside an USB DVB receiver as /devices/platform/usbhs_omap/ehci-omap.0/usb1/1-1/1-1.2/input/input2 [ 1893.177368] dvb-usb: schedule remote query interval to 150 msecs. [ 1893.184143] dvb-usb: Prof 7500 USB DVB-S2 successfully initialized and connected. Linux (none) 3.4.0 #28 SMP PREEMPT Tue Jul 23 16:24:14 IST 2013 armv7l GNU/Linux -sh-4.1# /stbref/w_scan-20120112/w_scan -fs -s S93E5 -c IN -G ch.conf w_scan version 20120112 (compiled for DVB API 5.4) using settings for 93.5 east Insat 3A/4B scan type SATELLITE, channellist 42 output format gstreamer WARNING: could not guess your codepage. Falling back to 'UTF-8' output charset 'UTF-8', use -C charset to override Info: using DVB adapter auto detection. /dev/dvb/adapter0/frontend0 - SATELLITE STV0900 frontend: very good :-)) Using SATELLITE frontend (adapter /dev/dvb/adapter0/frontend0) -_-_-_-_ Getting frontend capabilities-_-_-_-_
RE: width and height of JPEG compressed images
Hi Sakiri, On 23 July 2013 23:21 Sakari Ailus wrote: On Sun, Jul 21, 2013 at 10:38:18PM +0200, Sylwester Nawrocki wrote: On 07/19/2013 10:28 PM, Sakari Ailus wrote: On Sat, Jul 06, 2013 at 09:58:23PM +0200, Sylwester Nawrocki wrote: On 07/05/2013 10:22 AM, Thomas Vajzovic wrote: The hardware reads AxB sensor pixels from its array, resamples them to CxD image pixels, and then compresses them to ExF bytes. sensor matrix (AxB pixels) - binning/skipping (CxD pixels) - - JPEG compresion (width = C, height = D, sizeimage ExF bytes) Does the user need to specify ExF, for other purposes than limiting the size of the image? I would leave this up to the sensor driver (with reasonable alignment). The sensor driver would tell about this to the receiver through AFAIU ExF is closely related to the memory buffer size, so the sensor driver itself wouldn't have enough information to fix up ExF, would it ? If the desired sizeimage is known, F can be calculated if E is fixed, say 1024 should probably work for everyone, shoulnd't it? It's a nice clean idea (and I did already consider it) but it reduces the flexibility of the system as a whole. Suppose an embedded device wants to send the compressed image over a network in packets of 1500 bytes, and they want to allow 3 packets per frame. Your proposal limits sizeimage to a multiple of 1K, so they have to set sizeimage to 4K when they want 4.5K, meaning that they waste 500 bytes of bandwidth every frame. You could say tough luck, extra overhead like this is something you should expect if you want to use a general purpose API like V4L2, but why make it worse if we can make it better? Best regards, Tom -- Mr T. Vajzovic Software Engineer Infrared Integrated Systems Ltd Visit us at www.irisys.co.uk Disclaimer: This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the original message and the sent message from your computer. Infrared Integrated Systems Limited Park Circle Tithe Barn Way Swan Valley Northampton NN4 9BG Registration Number: 3186364. -- 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: width and height of JPEG compressed images
Hi, On 07/24/2013 09:47 AM, Thomas Vajzovic wrote: On 23 July 2013 23:21 Sakari Ailus wrote: On Sun, Jul 21, 2013 at 10:38:18PM +0200, Sylwester Nawrocki wrote: On 07/19/2013 10:28 PM, Sakari Ailus wrote: On Sat, Jul 06, 2013 at 09:58:23PM +0200, Sylwester Nawrocki wrote: On 07/05/2013 10:22 AM, Thomas Vajzovic wrote: The hardware reads AxB sensor pixels from its array, resamples them to CxD image pixels, and then compresses them to ExF bytes. sensor matrix (AxB pixels) - binning/skipping (CxD pixels) - - JPEG compresion (width = C, height = D, sizeimage ExF bytes) Does the user need to specify ExF, for other purposes than limiting the size of the image? I would leave this up to the sensor driver (with reasonable alignment). The sensor driver would tell about this to the receiver through AFAIU ExF is closely related to the memory buffer size, so the sensor driver itself wouldn't have enough information to fix up ExF, would it ? If the desired sizeimage is known, F can be calculated if E is fixed, say 1024 should probably work for everyone, shoulnd't it? It's a nice clean idea (and I did already consider it) but it reduces the flexibility of the system as a whole. Suppose an embedded device wants to send the compressed image over a network in packets of 1500 bytes, and they want to allow 3 packets per frame. Your proposal limits sizeimage to a multiple of 1K, so they have to set sizeimage to 4K when they want 4.5K, meaning that they waste 500 bytes of bandwidth every frame. You could say tough luck, extra overhead like this is something you should expect if you want to use a general purpose API like V4L2, but why make it worse if we can make it better? I entirely agree with that. Other issue with fixed number of samples per line is that internal (FIFO) line buffer size of the transmitter devices will vary, and for example some devices might have line buffer smaller than the value we have arbitrarily chosen. I'd expect the optimal number of samples per line to vary among different devices and use cases. 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: Prof DVB-S2 USB device
Dear Oliver, Thanks for your response. I tried with 3.10.1. As you rightly pointed out, it does not seem to work on my board (pandaboard). It gets stuck at Starting kernel Now, I am trying with 3.4.47 version now. Let me see if it works. The delay of creating /dev/dvb/adapter0/frontend0 and /dev/dvb/adapter0/demux0 seems to exists. I am waiting for it to get created. I am downloading 3.4.54 and 3.10.2 now. Regards, Kishore. -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Wednesday, July 24, 2013 1:12 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 24-07-13 08:56, Krishna Kishore wrote: Dear Oliver, Thanks for your response. Here are more details. Please help me in making this work. Linux version: -sh-4.1# uname -a Linux (none) 3.4.0 #28 SMP PREEMPT Tue Jul 23 16:24:14 IST 2013 armv7l GNU/Linux Your kernel is ancient. The latest kernel with the latest media fluff is 3.10.2; Since you are on arm, chances are your platform isn't that well supported with later kernels, but even in the 3.4 world your kernel is ancient. Latest stable is 3.4.54. So you are asking for help, with something that could have been fixed 3 times over (or not, I don't know). So my first suggestion is to upgrade your kernel. If that's not possible on your arm platform, contact the supplier of your kernel. Meanwhile, since this is an USB device, you could try it on a desktop. Get a recent Ubuntu live CD and see if it works there. At least then you can quickly and easily see if your problem hasn't been fixed in the last year. [dotconfig is attached to this email] lsusb -t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M |__ Port 1: Dev 2, If 0, Class=, Driver=hub/5p, 480M |__ Port 1: Dev 3, If 0, Class=, Driver=smsc95xx, 480M |__ Port 2: Dev 5, If 0, Class=, Driver=dw2102, 480M dmesg: [ 126.824951] usb 1-1.2: new high-speed USB device number 5 using ehci-omap [ 126.950347] usb 1-1.2: New USB device found, idVendor=3034, idProduct=7500 [ 126.957794] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 126.983184] dvb-usb: found a 'Prof 7500 USB DVB-S2' in cold state, will try to load a firmware [ 127.033477] dvb-usb: downloading firmware from file 'dvb-usb-p7500.fw' [ 127.051177] dw2102: start downloading DW210X firmware [ 127.238739] dvb-usb: found a 'Prof 7500 USB DVB-S2' in warm state. [ 127.255828] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 127.271270] DVB: registering new adapter (Prof 7500 USB DVB-S2) [ 1159.277740] dvb-usb: MAC address: 40:40:40:40:40:40 [ 1159.325531] dw2102: Kishore: prof_7500_frontend_attach [ 1159.325561] [ 1159.340332] Kishore stv0900_attach: [ 1159.340362] stv0900_init_internal [ 1159.340393] stv0900_init_internal: Create New Internal Structure! [ 1159.340423] stv0900_read_reg [ 1179.527770] stv0900_read_reg [ 1550.418365] stv0900_read_reg [ 1637.090240] stv0900_st_dvbs2_single [ 1637.090270] stv0900_stop_all_s2_modcod [ 1669.340270] stv0900_activate_s2_modcod_single [ 1703.605865] stv0900_read_reg [ 1709.652740] stv0900_read_reg [ 1715.699584] stv0900_read_reg [ 1721.746490] stv0900_read_reg [ 1727.793365] stv0900_read_reg [ 1733.840209] stv0900_read_reg [ 1739.887115] stv0900_read_reg [ 1743.918395] stv0900_read_reg [ 1749.965240] stv0900_read_reg [ 1756.012115] stv0900_set_ts_parallel_serial path1 3 path2 0 [ 1758.027740] stv0900_read_reg [ 1764.074615] stv0900_read_reg [ 1770.121490] stv0900_read_reg [ 1776.168334] stv0900_read_reg [ 1782.215209] stv0900_read_reg [ 1788.262115] stv0900_read_reg [ 1810.433990] stv0900_read_reg [ 1816.480865] stv0900_read_reg [ 1824.543365] stv0900_read_reg [ 1830.590240] stv0900_read_reg [ 1838.652740] stv0900_read_reg [ 1844.699615] stv0900_read_reg [ 1850.746490] stv0900_set_mclk: Mclk set to 13500, Quartz = 2700 [ 1850.746520] stv0900_read_reg [ 1854.40] stv0900_read_reg [ 1860.824615] stv0900_read_reg [ 1864.855865] stv0900_read_reg [ 1868.887115] stv0900_get_mclk_freq: Calculated Mclk = 152672117 [ 1876.965209] stv0900_read_reg [ 1883.027709] stv0900_read_reg [ 1887.058990] stv0900_read_reg [ 1891.090240] stv0900_get_mclk_freq: Calculated Mclk = 152672117 [ 1891.090270] Kishore stv0900_attach: Attaching STV0900 demodulator(0) [ 1891.090301] dw2102: Kishore: dvb_attach stb6100_attach [ 1891.090332] [ 1891.097442] Kishore stb6100_attach: [ 1891.101409] Kishore stb6100_attach: Attaching STB6100 [ 1893.105957] dw2102: Attached STV0900+STB6100A! [ 1893.105957] [ 1893.112335] DVB: registering adapter 0 frontend 0 (STV0900 frontend)... [ 1893.137878] input: IR-receiver inside an USB DVB receiver as /devices/platform/usbhs_omap/ehci-omap.0/usb1/1-1/1-1.2/input/input2 [ 1893.177368] dvb-usb: schedule remote query
Re: width and height of JPEG compressed images
Hi Thomas,
On 07/22/2013 10:40 AM, Thomas Vajzovic wrote:
On 21 July 2013 21:38 Sylwester Nawrocki wrote:
On 07/19/2013 10:28 PM, Sakari Ailus wrote:
On Sat, Jul 06, 2013 at 09:58:23PM +0200, Sylwester Nawrocki wrote:
On 07/05/2013 10:22 AM, Thomas Vajzovic wrote:
The hardware reads AxB sensor pixels from its array, resamples them
to CxD image pixels, and then compresses them to ExF bytes.
I think you should use VIDIOC_S_FMT(width = C, height = D, sizeimage
= ExF) for that. And s_frame_desc sudev op could be used to pass
sizeimage to the sensor subdev driver.
Agreed. Let me take this into account in the next RFC.
I agree that in my use case the user only needs to be able to specify
sizeimage, and then be told in response what the adjusted value of
sizeimage is.
Does the user need to specify ExF, for other purposes than limiting
the size of the image? I would leave this up to the sensor driver
(with reasonable alignment). The sensor driver would tell about this
to the receiver through
AFAIU ExF is closely related to the memory buffer size, so the sensor
driver itself wouldn't have enough information to fix up ExF, would
it ?
If the sensor driver is only told the user's requested sizeimage, it
can be made to factorize (ExF) into (E,F) itself, but then both the
parallel interface and the 2D DMA peripheral need to be told the
particular factorization that it has chosen.
Eg: if the user requests images of 8K, then the bridge needs to know
that they will come out as 10 lines of 800 bytes.
If the user requests sizeimage which cannot be satisfied (eg: a prime
number) then it will need to return (E,F) to the bridge driver which
does not multiply exactly to sizeimage. Because of this the bridge
driver must set the corrected value of sizeimage which it returns
to userspace to the product ExF.
Eg: if the user requests sizeimage = 1601, then the sensor cannot
provide 1601x1 (width exceeds internal FIFO), it will have to tell
the bridge that it will give 800x2 or 801x2. The userspace needs to
be told that sizeimage was adjusted to 1600 or 1602 because there are
data fields aligned to the end of the data.
Ok, let's consider following data structure describing the frame:
struct v4l2_frame_desc_entry {
u32 flags;
u32 pixelcode;
u32 samples_per_line;
u32 num_lines;
u32 size;
};
I think we could treat the frame descriptor to be at lower lever
in the protocol stack than struct v4l2_mbus_framefmt.
Then the bridge would set size and pixelcode and the subdev would
return (E, F) in (samples_per_frame, num_lines) and adjust size
if required. Number of bits per sample can be determined by
pixelcode.
It needs to be considered that for some sensor drivers it might not
be immediately clear what samples_per_line, num_lines values are.
In such case those fields could be left zeroed and bridge driver
could signal such condition as a more or less critical error. In
end of the day specific sensor driver would need to be updated to
interwork with a bridge that requires samples_per_line, num_lines.
Not sure if we need to add image width and height in pixels to the
above structure. It wouldn't make much sensor when single frame
carries multiple images, e.g. interleaved YUV and compressed image
data at different resolutions.
(BTW, would you suggest rounding up or down in this case? If the user
knew how much memory that an embedded system had available and
specified sizeimage to the maximum, then rounding up might result in
failed allocation. But then, if the user knows how much entropy-coded
JPEG data to expect, then rounding down might result in truncated
frames that have to be dropped.)
I think the sensor should always round up, the bridge can then apply
any upper limits. I wouldn't rely too much on what sizeimage user
space provides in VIDIOC_S_FMT.
frame descriptors. (But still I don't think frame descriptors should
be settable; what sensors can support is fully sensor specific and the
parameters that typically need to be changed are quite limited in numbers.
So I'd go with e.g. controls, again.)
I agree it would have been much more clear to have read only frame
descriptors outside of the subdev. But the issue with controls is that
it would have been difficult to define same parameter for multiple
logical stream on the data bus. And data interleaving is a standard
feature, it is well defined in the MIPI CSI-2 specification.
So my feeling is that we would be better off with data structure and a
callback, rather than creating multiple strange controls.
However if we don't use media bus format callbacks, nor frame descriptor
callbacks, then what ?... :) It sounds reasonable to me to have frame
frame descriptor defined by the sensor (data source) based on media bus
format, frame interval, link frequency, etc. Problematic seem to be
parameters that are now handled on the video node side, like, e.g.
Re: [PATCH RFC 4/5] V4L2: Rename subdev field of struct v4l2_async_notifier
Hi Prabhakar,
On 07/23/2013 05:50 PM, Prabhakar Lad wrote:
On Mon, Jul 22, 2013 at 11:34 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
This is a purely cosmetic change. Since the 'subdev' member
points to an array of subdevs it seems more intuitive to name
it in plural form.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/soc_camera/soc_camera.c |2 +-
drivers/media/v4l2-core/v4l2-async.c |2 +-
include/media/v4l2-async.h |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
can you include the following changes in the same patch ?
so that git bisect doesn’t break.
(maybe you need to rebase the patches on
http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/for-v3.12)
Thanks for your testing and Ack. I'll wait couple days to also
let other take a look and review the patches. I'm not going to
try to merge that without at least Guennadi's Ack ;)
I think the best is to wait until the above patches from Hans'
tree get merged to the media master branch. Then I would rebase
my series on top of that before sending any pull request.
Regards,
Sylwester
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index b11d7a7..7fbde6d 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -2168,7 +2168,7 @@ static __init int vpif_probe(struct platform_device
*pdev)
}
vpif_probe_complete();
} else {
- vpif_obj.notifier.subdev = vpif_obj.config-asd;
+ vpif_obj.notifier.subdevs = vpif_obj.config-asd;
vpif_obj.notifier.num_subdevs = vpif_obj.config-asd_sizes[0];
vpif_obj.notifier.bound = vpif_async_bound;
vpif_obj.notifier.complete = vpif_async_complete;
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index c2ff067..6336dfc 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -1832,7 +1832,7 @@ static __init int vpif_probe(struct platform_device
*pdev)
}
vpif_probe_complete();
} else {
- vpif_obj.notifier.subdev = vpif_obj.config-asd;
+ vpif_obj.notifier.subdevs = vpif_obj.config-asd;
vpif_obj.notifier.num_subdevs = vpif_obj.config-asd_sizes[0];
vpif_obj.notifier.bound = vpif_async_bound;
vpif_obj.notifier.complete = vpif_async_complete;
--
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 1/3] [media] coda: Fix error paths
Hi Fabio,
Am Dienstag, den 23.07.2013, 15:04 -0300 schrieb Fabio Estevam:
Some resources were not being released in the error path and some were
released
in the incorrect order.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v3:
- Only disable the clocks after v4l2_m2m_ctx_release()
Changes since v2:
- Newly introduced in this series
drivers/media/platform/coda.c | 38 --
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index df4ada88..9384f02 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -1514,21 +1514,26 @@ static int coda_open(struct file *file)
int ret = 0;
int idx;
- idx = coda_next_free_instance(dev);
- if (idx = CODA_MAX_INSTANCES)
- return -EBUSY;
- set_bit(idx, dev-instance_mask);
-
ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
if (!ctx)
return -ENOMEM;
+ idx = coda_next_free_instance(dev);
+ if (idx = CODA_MAX_INSTANCES) {
+ ret = -EBUSY;
+ goto err_coda_max;
+ }
+ set_bit(idx, dev-instance_mask);
+
v4l2_fh_init(ctx-fh, video_devdata(file));
file-private_data = ctx-fh;
v4l2_fh_add(ctx-fh);
ctx-dev = dev;
ctx-idx = idx;
+ clk_prepare_enable(dev-clk_per);
+ clk_prepare_enable(dev-clk_ahb);
+
set_default_params(ctx);
ctx-m2m_ctx = v4l2_m2m_ctx_init(dev-m2m_dev, ctx,
coda_queue_init);
@@ -1537,12 +1542,12 @@ static int coda_open(struct file *file)
v4l2_err(dev-v4l2_dev, %s return error (%d)\n,
__func__, ret);
- goto err;
+ goto err_ctx_init;
}
ret = coda_ctrls_setup(ctx);
if (ret) {
v4l2_err(dev-v4l2_dev, failed to setup coda controls\n);
- goto err;
+ goto err_ctrls_setup;
}
ctx-fh.ctrl_handler = ctx-ctrls;
@@ -1552,24 +1557,29 @@ static int coda_open(struct file *file)
if (!ctx-parabuf.vaddr) {
v4l2_err(dev-v4l2_dev, failed to allocate parabuf);
ret = -ENOMEM;
- goto err;
+ goto err_dma_alloc;
}
coda_lock(ctx);
list_add(ctx-list, dev-instances);
coda_unlock(ctx);
- clk_prepare_enable(dev-clk_per);
- clk_prepare_enable(dev-clk_ahb);
-
v4l2_dbg(1, coda_debug, dev-v4l2_dev, Created instance %d (%p)\n,
ctx-idx, ctx);
return 0;
-err:
+err_dma_alloc:
+ v4l2_ctrl_handler_free(ctx-ctrls);
+err_ctrls_setup:
+ v4l2_m2m_ctx_release(ctx-m2m_ctx);
+err_ctx_init:
+ clk_disable_unprepare(dev-clk_ahb);
+ clk_disable_unprepare(dev-clk_per);
v4l2_fh_del(ctx-fh);
v4l2_fh_exit(ctx-fh);
+ clear_bit(ctx-idx, dev-instance_mask);
+err_coda_max:
kfree(ctx);
return ret;
}
@@ -1588,10 +1598,10 @@ static int coda_release(struct file *file)
dma_free_coherent(dev-plat_dev-dev, CODA_PARA_BUF_SIZE,
ctx-parabuf.vaddr, ctx-parabuf.paddr);
- v4l2_m2m_ctx_release(ctx-m2m_ctx);
v4l2_ctrl_handler_free(ctx-ctrls);
- clk_disable_unprepare(dev-clk_per);
+ v4l2_m2m_ctx_release(ctx-m2m_ctx);
clk_disable_unprepare(dev-clk_ahb);
+ clk_disable_unprepare(dev-clk_per);
v4l2_fh_del(ctx-fh);
v4l2_fh_exit(ctx-fh);
clear_bit(ctx-idx, dev-instance_mask);
this looks better, thanks. Could you rebase the patches onto Kamil's
http://git.linuxtv.org/kdebski/media.git/shortlog/refs/heads/new-for-3.12
branch?
regards
Philipp
--
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: Prof DVB-S2 USB device
Please see the delay between (1) and (2)... Any idea about the reason for the delay. Though I am not sure, it may not be specific to Linux kernel version. () [3.254455] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [3.267852] DVB: registering new adapter (Prof 7500 USB DVB-S2) [ 14.928314] FAT-fs (mmcblk0p1): Unrecognized mount option smackfsroot=* or missing value [ 1027.269042] dvb-usb: MAC address: 80:80:80:80:80:80 [ 1027.296325] stv0900_init_internal [ 1027.296356] stv0900_init_internal: Create New Internal Structure! [ 1501.339355] stv0900_st_dvbs2_single [ 1501.339355] stv0900_stop_all_s2_modcod [ 1533.339355] stv0900_activate_s2_modcod_single [ 1619.339355] stv0900_set_ts_parallel_serial [ 1713.339324] stv0900_set_mclk: Mclk set to 13500, Quartz = 2700 [ 1731.339385] stv0900_get_mclk_freq: Calculated Mclk = 152672117 [ 1753.370605] stv0900_get_mclk_freq: Calculated Mclk = 152672117 [ 1753.370605] stv0900_attach: Attaching STV0900 demodulator(0) (2) --[ 1755.370635] dw2102: Attached STV0900+STB6100A! [ 1755.370635] [ 1755.376892] DVB: registering adapter 0 frontend 0 (STV0900 frontend)... [ 1755.403869] input: IR-receiver inside an USB DVB receiver as /devices/platform/usbhs_omap/ehci-omap.0/usb1/1-1/1-1.2/input/input0 [ 1755.417938] dvb-usb: schedule remote query interval to 150 msecs. [ 1755.430419] dvb-usb: Prof 7500 USB DVB-S2 successfully initialized and connected. Also, can someone please let me know if following w_scan command is fine. w_scan -fs -s S93E5 -c IN -G ch.conf From: Krishna Kishore Sent: Wednesday, July 24, 2013 2:29 PM To: Oliver Schinagl Cc: linux-media@vger.kernel.org Subject: RE: Prof DVB-S2 USB device Dear Oliver, Thanks for your response. I tried with 3.10.1. As you rightly pointed out, it does not seem to work on my board (pandaboard). It gets stuck at Starting kernel Now, I am trying with 3.4.47 version now. Let me see if it works. The delay of creating /dev/dvb/adapter0/frontend0 and /dev/dvb/adapter0/demux0 seems to exists. I am waiting for it to get created. I am downloading 3.4.54 and 3.10.2 now. Regards, Kishore. -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Wednesday, July 24, 2013 1:12 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 24-07-13 08:56, Krishna Kishore wrote: Dear Oliver, Thanks for your response. Here are more details. Please help me in making this work. Linux version: -sh-4.1# uname -a Linux (none) 3.4.0 #28 SMP PREEMPT Tue Jul 23 16:24:14 IST 2013 armv7l GNU/Linux Your kernel is ancient. The latest kernel with the latest media fluff is 3.10.2; Since you are on arm, chances are your platform isn't that well supported with later kernels, but even in the 3.4 world your kernel is ancient. Latest stable is 3.4.54. So you are asking for help, with something that could have been fixed 3 times over (or not, I don't know). So my first suggestion is to upgrade your kernel. If that's not possible on your arm platform, contact the supplier of your kernel. Meanwhile, since this is an USB device, you could try it on a desktop. Get a recent Ubuntu live CD and see if it works there. At least then you can quickly and easily see if your problem hasn't been fixed in the last year. [dotconfig is attached to this email] lsusb -t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M |__ Port 1: Dev 2, If 0, Class=, Driver=hub/5p, 480M |__ Port 1: Dev 3, If 0, Class=, Driver=smsc95xx, 480M |__ Port 2: Dev 5, If 0, Class=, Driver=dw2102, 480M dmesg: [ 126.824951] usb 1-1.2: new high-speed USB device number 5 using ehci-omap [ 126.950347] usb 1-1.2: New USB device found, idVendor=3034, idProduct=7500 [ 126.957794] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 126.983184] dvb-usb: found a 'Prof 7500 USB DVB-S2' in cold state, will try to load a firmware [ 127.033477] dvb-usb: downloading firmware from file 'dvb-usb-p7500.fw' [ 127.051177] dw2102: start downloading DW210X firmware [ 127.238739] dvb-usb: found a 'Prof 7500 USB DVB-S2' in warm state. [ 127.255828] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 127.271270] DVB: registering new adapter (Prof 7500 USB DVB-S2) [ 1159.277740] dvb-usb: MAC address: 40:40:40:40:40:40 [ 1159.325531] dw2102: Kishore:
RE: Prof DVB-S2 USB device
I am continuously getting following error. I assume that this is expected behavior. At some correct frequency, it will get locked and channel data will be provided. Is it correct? [ 1819.146484] stv0900_init [ 1850.112823] stv0900_sleep [ 1859.615112] stv0900_init [ 1884.433593] stv0900_set_tone: Off [ 1904.433074] stv0900_read_status: [ 1910.433044] stv0900_status: locked = 0 [ 1928.433074] stv0900_get_mclk_freq: Calculated Mclk = 58050 [ 1928.433074] TS bitrate = 1164 Mbit/sec [ 1932.433135] DEMOD LOCK FAIL [ 1938.433105] stv0900_search: [ 1938.433135] stv0900_read_status: [ 1944.433074] stv0900_status: locked = 0 [ 1962.440856] stv0900_get_mclk_freq: Calculated Mclk = 58050 [ 1962.440856] TS bitrate = 1164 Mbit/sec [ 1966.440917] DEMOD LOCK FAIL [ 2068.441009] stv0900_search: [ 2068.441040] stv0900_read_status: [ 2074.440948] stv0900_status: locked = 0 [ 2092.440979] stv0900_get_mclk_freq: Calculated Mclk = 450 [ 2092.440979] TS bitrate = 0 Mbit/sec [ 2446.440948] stv0900_search: [ 2446.440948] stv0900_read_status: [ 2452.440887] stv0900_status: locked = 0 [ 2470.440917] stv0900_get_mclk_freq: Calculated Mclk = 152672117 [ 2470.440917] TS bitrate = 457 Mbit/sec [ 2474.440948] DEMOD LOCK FAIL [ 2564.440948] stv0900_search: [ 2564.440979] stv0900_read_status: [ 2570.440887] stv0900_status: locked = 0 [ 2588.440917] stv0900_get_mclk_freq: Calculated Mclk = 450 [ 2588.440917] TS bitrate = 0 Mbit/sec [ 2592.440979] DEMOD LOCK FAIL [ 2592.440979] stv0900_set_tone: Off [ 2612.440917] stv0900_search: [ 2612.440917] stv0900_read_status: [ 2618.440856] stv0900_status: locked = 0 [ 2636.440887] stv0900_get_mclk_freq: Calculated Mclk = 450 [ 2636.440917] TS bitrate = 0 Mbit/sec [ 2640.440948] DEMOD LOCK FAIL [ 2640.440948] stv0900_set_tone: Off [ 2660.440887] stv0900_search: [ 2660.440887] stv0900_read_status: [ 2666.440948] stv0900_status: locked = 0 [ 2684.440856] stv0900_get_mclk_freq: Calculated Mclk = 450 [ 2684.440856] TS bitrate = 0 Mbit/sec [ 2688.440917] DEMOD LOCK FAIL [ 2694.440887] stv0900_search: [ 2694.440917] stv0900_read_status: [ 2704.440917] stv0900_status: locked = 0 [ 2722.440917] stv0900_get_mclk_freq: Calculated Mclk = 29250 [ 2722.440917] TS bitrate = 293 Mbit/sec [ 2726.440856] DEMOD LOCK FAIL From: Krishna Kishore Sent: Wednesday, July 24, 2013 3:23 PM To: Oliver Schinagl Cc: linux-media@vger.kernel.org Subject: RE: Prof DVB-S2 USB device Please see the delay between (1) and (2)... Any idea about the reason for the delay. Though I am not sure, it may not be specific to Linux kernel version. () [3.254455] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [3.267852] DVB: registering new adapter (Prof 7500 USB DVB-S2) [ 14.928314] FAT-fs (mmcblk0p1): Unrecognized mount option smackfsroot=* or missing value [ 1027.269042] dvb-usb: MAC address: 80:80:80:80:80:80 [ 1027.296325] stv0900_init_internal [ 1027.296356] stv0900_init_internal: Create New Internal Structure! [ 1501.339355] stv0900_st_dvbs2_single [ 1501.339355] stv0900_stop_all_s2_modcod [ 1533.339355] stv0900_activate_s2_modcod_single [ 1619.339355] stv0900_set_ts_parallel_serial [ 1713.339324] stv0900_set_mclk: Mclk set to 13500, Quartz = 2700 [ 1731.339385] stv0900_get_mclk_freq: Calculated Mclk = 152672117 [ 1753.370605] stv0900_get_mclk_freq: Calculated Mclk = 152672117 [ 1753.370605] stv0900_attach: Attaching STV0900 demodulator(0) (2) --[ 1755.370635] dw2102: Attached STV0900+STB6100A! [ 1755.370635] [ 1755.376892] DVB: registering adapter 0 frontend 0 (STV0900 frontend)... [ 1755.403869] input: IR-receiver inside an USB DVB receiver as /devices/platform/usbhs_omap/ehci-omap.0/usb1/1-1/1-1.2/input/input0 [ 1755.417938] dvb-usb: schedule remote query interval to 150 msecs. [ 1755.430419] dvb-usb: Prof 7500 USB DVB-S2 successfully initialized and connected. Also, can someone please let me know if following w_scan command is fine. w_scan -fs -s S93E5 -c IN -G ch.conf From: Krishna Kishore Sent: Wednesday, July 24, 2013 2:29 PM To: Oliver Schinagl Cc: linux-media@vger.kernel.org Subject: RE: Prof DVB-S2 USB device Dear Oliver, Thanks for your response. I tried with 3.10.1. As you rightly pointed out, it does not seem to work on my board (pandaboard). It gets stuck at Starting kernel Now, I am trying with 3.4.47 version now. Let me see if it works. The delay of creating
Re: [PATCH RFC 0/5] v4l2-async DT support improvement and cleanups
Hi Sylwester, Thanks for the patches. On Monday 22 July 2013 20:04:42 Sylwester Nawrocki wrote: Hello, This is a few patches for the v4l2-async API I wrote while adding the asynchronous subdev registration support to the exynos4-is driver. The most significant change is addition of V4L2_ASYNC_MATCH_OF subdev matching method, where host driver can pass a list of of_node pointers identifying its subdevs. I thought it's a reasonable and simple enough way to support device tree based systems. Comments/other ideas are of course welcome. I have similar patches in my tree that I haven't posted yet, so I like the idea :-) For the whole series, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Thanks, Sylwester Sylwester Nawrocki (5): V4L2: Drop bus_type check in v4l2-async match functions V4L2: Rename v4l2_async_bus_* to v4l2_async_match_* V4L2: Add V4L2_ASYNC_MATCH_OF subdev matching type V4L2: Rename subdev field of struct v4l2_async_notifier V4L2: Fold struct v4l2_async_subdev_list with struct v4l2_subdev drivers/media/platform/soc_camera/soc_camera.c |4 +- drivers/media/v4l2-core/v4l2-async.c | 106 ++--- include/media/v4l2-async.h | 36 include/media/v4l2-subdev.h| 13 ++- 4 files changed, 74 insertions(+), 85 deletions(-) -- 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 RFC 0/5] v4l2-async DT support improvement and cleanups
On Mon 22 July 2013 20:04:42 Sylwester Nawrocki wrote: Hello, This is a few patches for the v4l2-async API I wrote while adding the asynchronous subdev registration support to the exynos4-is driver. The most significant change is addition of V4L2_ASYNC_MATCH_OF subdev matching method, where host driver can pass a list of of_node pointers identifying its subdevs. I thought it's a reasonable and simple enough way to support device tree based systems. Comments/other ideas are of course welcome. Looks good! Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks, Sylwester Sylwester Nawrocki (5): V4L2: Drop bus_type check in v4l2-async match functions V4L2: Rename v4l2_async_bus_* to v4l2_async_match_* V4L2: Add V4L2_ASYNC_MATCH_OF subdev matching type V4L2: Rename subdev field of struct v4l2_async_notifier V4L2: Fold struct v4l2_async_subdev_list with struct v4l2_subdev drivers/media/platform/soc_camera/soc_camera.c |4 +- drivers/media/v4l2-core/v4l2-async.c | 106 include/media/v4l2-async.h | 36 include/media/v4l2-subdev.h| 13 ++- 4 files changed, 74 insertions(+), 85 deletions(-) -- 1.7.9.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
Re: [PATCH v2 5/5] v4l: Renesas R-Car VSP1 driver
Hi Laurent,
Thank you for your great work for VSP1.
Some comments below.
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Date: Wed, 17 Jul 2013 16:54:42 +0200
(snip)
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
+/*
+ * vsp1_drv.c -- R-Car VSP1 Driver
+ *
+ * Copyright (C) 2013 Renesas Corporation
+ *
+ * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+
+#include vsp1.h
+#include vsp1_lif.h
+#include vsp1_rwpf.h
+#include vsp1_uds.h
+
+/*
-
+ * Interrupt Handling
+ */
+
+static irqreturn_t vsp1_irq_handler(int irq, void *data)
+{
+ struct vsp1_device *vsp1 = data;
+ irqreturn_t ret = IRQ_NONE;
+ unsigned int i;
+
+ for (i = 0; i VPS1_MAX_WPF; ++i) {
+ struct vsp1_rwpf *wpf = vsp1-wpf[i];
+ struct vsp1_pipeline *pipe;
+ u32 status;
+
+ if (wpf == NULL)
+ continue;
+
+ pipe = to_vsp1_pipeline(wpf-entity.subdev.entity);
+ status = vsp1_read(vsp1, VI6_WPF_IRQ_STA(i));
+ vsp1_write(vsp1, VI6_WPF_IRQ_STA(i), ~status);
The value set into the VI6_WPF_IRQ_STA register should be masked
with VI6_WFP_IRQ_STA_FRE since unused (upper) bits in the register
must be written with 0.
(snip)
+static int vsp1_create_links(struct vsp1_device *vsp1, struct vsp1_entity
*sink)
+{
+ struct media_entity *entity = sink-subdev.entity;
+ struct vsp1_entity *source;
+ unsigned int pad;
+ int ret;
+
+ list_for_each_entry(source, vsp1-entities, list_dev) {
+ u32 flags;
+
+ if (source-type == sink-type)
+ continue;
+
+ if (source-type == VSP1_ENTITY_LIF ||
+ source-type == VSP1_ENTITY_WPF)
+ continue;
+
+ flags = source-type == VSP1_ENTITY_RPF
+ sink-type == VSP1_ENTITY_WPF
+ source-index == sink-index
+ ? MEDIA_LNK_FL_ENABLED : 0;
+
+ for (pad = 0; pad entity-num_pads; ++pad) {
+ if (!(entity-pads[pad].flags MEDIA_PAD_FL_SINK))
+ continue;
+
+ ret = media_entity_create_link(source-subdev.entity,
+source-source_pad,
+entity, pad, flags);
+ if (ret 0)
+ return ret;
This initialization enables some of links as the initial status.
I think link_setup() for each linked entity should be invoked here
to set up the sink value in the vsp_entity structure.
(snip)
+++ b/drivers/media/platform/vsp1/vsp1_regs.h
@@ -0,0 +1,581 @@
+/*
+ * vsp1_regs.h -- R-Car VSP1 Registers Definitions
+ *
+ * Copyright (C) 2013 Renesas Electronics Corporation
+ *
+ * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ */
+
+#ifndef __VSP1_REGS_H__
+#define __VSP1_REGS_H__
+
(snip)
+/*
-
+ * HGO Control Registers
+ */
+
+#define VI6_HGO_OFFSET 0x3000
+#define VI6_HGO_SIZE 0x3004
+#define VI6_HGO_MODE 0x3008
+#define VI6_HGO_LB_TH0x300c
+#define VI6_HGO_LBn_H(0x3010 + (n) * 8)
+#define VI6_HGO_LBn_V(0x3014 + (n) * 8)
It looks like the 'n' argument is missing for VI6_HGO_LBn_H
and VI6_HGO_LBn_V.
+#define VI6_HGO_R_HISTO 0x3030
+#define VI6_HGO_R_MAXMIN 0x3130
+#define VI6_HGO_R_SUM0x3134
+#define VI6_HGO_R_LB_DET 0x3138
+#define VI6_HGO_G_HISTO 0x3140
+#define VI6_HGO_G_MAXMIN 0x3240
+#define VI6_HGO_G_SUM0x3244
+#define VI6_HGO_G_LB_DET 0x3248
+#define VI6_HGO_B_HISTO 0x3250
+#define VI6_HGO_B_MAXMIN 0x3350
+#define VI6_HGO_B_SUM0x3354
+#define VI6_HGO_B_LB_DET 0x3358
+#define VI6_HGO_REGRST 0x33fc
+
+/*
Re: Prof DVB-S2 USB device
On 24-07-13 10:59, Krishna Kishore wrote: Dear Oliver, Thanks for your response. I tried with 3.10.1. As you rightly pointed out, it does not seem to work on my board (pandaboard). It gets stuck at Starting kernel Now, I am trying with 3.4.47 version now. Let me see if it works. The delay of creating /dev/dvb/adapter0/frontend0 and /dev/dvb/adapter0/demux0 seems to exists. I am waiting for it to get created. I am downloading 3.4.54 and 3.10.2 now. What do you get when using on a regular PC? Your beagle board may (or may not) yet be supported by mainline 3.10.1 kernel. Try it in a regular PC and see what happens there with 3.10.2 Regards, Kishore. -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Wednesday, July 24, 2013 1:12 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 24-07-13 08:56, Krishna Kishore wrote: Dear Oliver, Thanks for your response. Here are more details. Please help me in making this work. Linux version: -sh-4.1# uname -a Linux (none) 3.4.0 #28 SMP PREEMPT Tue Jul 23 16:24:14 IST 2013 armv7l GNU/Linux Your kernel is ancient. The latest kernel with the latest media fluff is 3.10.2; Since you are on arm, chances are your platform isn't that well supported with later kernels, but even in the 3.4 world your kernel is ancient. Latest stable is 3.4.54. So you are asking for help, with something that could have been fixed 3 times over (or not, I don't know). So my first suggestion is to upgrade your kernel. If that's not possible on your arm platform, contact the supplier of your kernel. Meanwhile, since this is an USB device, you could try it on a desktop. Get a recent Ubuntu live CD and see if it works there. At least then you can quickly and easily see if your problem hasn't been fixed in the last year. [dotconfig is attached to this email] lsusb -t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M |__ Port 1: Dev 2, If 0, Class=, Driver=hub/5p, 480M |__ Port 1: Dev 3, If 0, Class=, Driver=smsc95xx, 480M |__ Port 2: Dev 5, If 0, Class=, Driver=dw2102, 480M dmesg: [ 126.824951] usb 1-1.2: new high-speed USB device number 5 using ehci-omap [ 126.950347] usb 1-1.2: New USB device found, idVendor=3034, idProduct=7500 [ 126.957794] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 126.983184] dvb-usb: found a 'Prof 7500 USB DVB-S2' in cold state, will try to load a firmware [ 127.033477] dvb-usb: downloading firmware from file 'dvb-usb-p7500.fw' [ 127.051177] dw2102: start downloading DW210X firmware [ 127.238739] dvb-usb: found a 'Prof 7500 USB DVB-S2' in warm state. [ 127.255828] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 127.271270] DVB: registering new adapter (Prof 7500 USB DVB-S2) [ 1159.277740] dvb-usb: MAC address: 40:40:40:40:40:40 [ 1159.325531] dw2102: Kishore: prof_7500_frontend_attach [ 1159.325561] [ 1159.340332] Kishore stv0900_attach: [ 1159.340362] stv0900_init_internal [ 1159.340393] stv0900_init_internal: Create New Internal Structure! [ 1159.340423] stv0900_read_reg [ 1179.527770] stv0900_read_reg [ 1550.418365] stv0900_read_reg [ 1637.090240] stv0900_st_dvbs2_single [ 1637.090270] stv0900_stop_all_s2_modcod [ 1669.340270] stv0900_activate_s2_modcod_single [ 1703.605865] stv0900_read_reg [ 1709.652740] stv0900_read_reg [ 1715.699584] stv0900_read_reg [ 1721.746490] stv0900_read_reg [ 1727.793365] stv0900_read_reg [ 1733.840209] stv0900_read_reg [ 1739.887115] stv0900_read_reg [ 1743.918395] stv0900_read_reg [ 1749.965240] stv0900_read_reg [ 1756.012115] stv0900_set_ts_parallel_serial path1 3 path2 0 [ 1758.027740] stv0900_read_reg [ 1764.074615] stv0900_read_reg [ 1770.121490] stv0900_read_reg [ 1776.168334] stv0900_read_reg [ 1782.215209] stv0900_read_reg [ 1788.262115] stv0900_read_reg [ 1810.433990] stv0900_read_reg [ 1816.480865] stv0900_read_reg [ 1824.543365] stv0900_read_reg [ 1830.590240] stv0900_read_reg [ 1838.652740] stv0900_read_reg [ 1844.699615] stv0900_read_reg [ 1850.746490] stv0900_set_mclk: Mclk set to 13500, Quartz = 2700 [ 1850.746520] stv0900_read_reg [ 1854.40] stv0900_read_reg [ 1860.824615] stv0900_read_reg [ 1864.855865] stv0900_read_reg [ 1868.887115] stv0900_get_mclk_freq: Calculated Mclk = 152672117 [ 1876.965209] stv0900_read_reg [ 1883.027709] stv0900_read_reg [ 1887.058990] stv0900_read_reg [ 1891.090240] stv0900_get_mclk_freq: Calculated Mclk = 152672117 [ 1891.090270] Kishore stv0900_attach: Attaching STV0900 demodulator(0) [ 1891.090301] dw2102: Kishore: dvb_attach stb6100_attach [ 1891.090332] [ 1891.097442] Kishore stb6100_attach: [ 1891.101409] Kishore stb6100_attach: Attaching STB6100 [ 1893.105957] dw2102: Attached STV0900+STB6100A! [ 1893.105957] [ 1893.112335] DVB: registering adapter 0 frontend 0 (STV0900 frontend)... [ 1893.137878] input: IR-receiver inside
RE: Prof DVB-S2 USB device
On Desktop PC (Ubuntu 12.04 which has 3.2.0 Kernel) also, I am not getting the list of channels when I scan. I am using Kaffeine. -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Wednesday, July 24, 2013 4:34 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 24-07-13 10:59, Krishna Kishore wrote: Dear Oliver, Thanks for your response. I tried with 3.10.1. As you rightly pointed out, it does not seem to work on my board (pandaboard). It gets stuck at Starting kernel Now, I am trying with 3.4.47 version now. Let me see if it works. The delay of creating /dev/dvb/adapter0/frontend0 and /dev/dvb/adapter0/demux0 seems to exists. I am waiting for it to get created. I am downloading 3.4.54 and 3.10.2 now. What do you get when using on a regular PC? Your beagle board may (or may not) yet be supported by mainline 3.10.1 kernel. Try it in a regular PC and see what happens there with 3.10.2 Regards, Kishore. -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Wednesday, July 24, 2013 1:12 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 24-07-13 08:56, Krishna Kishore wrote: Dear Oliver, Thanks for your response. Here are more details. Please help me in making this work. Linux version: -sh-4.1# uname -a Linux (none) 3.4.0 #28 SMP PREEMPT Tue Jul 23 16:24:14 IST 2013 armv7l GNU/Linux Your kernel is ancient. The latest kernel with the latest media fluff is 3.10.2; Since you are on arm, chances are your platform isn't that well supported with later kernels, but even in the 3.4 world your kernel is ancient. Latest stable is 3.4.54. So you are asking for help, with something that could have been fixed 3 times over (or not, I don't know). So my first suggestion is to upgrade your kernel. If that's not possible on your arm platform, contact the supplier of your kernel. Meanwhile, since this is an USB device, you could try it on a desktop. Get a recent Ubuntu live CD and see if it works there. At least then you can quickly and easily see if your problem hasn't been fixed in the last year. [dotconfig is attached to this email] lsusb -t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M |__ Port 1: Dev 2, If 0, Class=, Driver=hub/5p, 480M |__ Port 1: Dev 3, If 0, Class=, Driver=smsc95xx, 480M |__ Port 2: Dev 5, If 0, Class=, Driver=dw2102, 480M dmesg: [ 126.824951] usb 1-1.2: new high-speed USB device number 5 using ehci-omap [ 126.950347] usb 1-1.2: New USB device found, idVendor=3034, idProduct=7500 [ 126.957794] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 126.983184] dvb-usb: found a 'Prof 7500 USB DVB-S2' in cold state, will try to load a firmware [ 127.033477] dvb-usb: downloading firmware from file 'dvb-usb-p7500.fw' [ 127.051177] dw2102: start downloading DW210X firmware [ 127.238739] dvb-usb: found a 'Prof 7500 USB DVB-S2' in warm state. [ 127.255828] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 127.271270] DVB: registering new adapter (Prof 7500 USB DVB-S2) [ 1159.277740] dvb-usb: MAC address: 40:40:40:40:40:40 [ 1159.325531] dw2102: Kishore: prof_7500_frontend_attach [ 1159.325561] [ 1159.340332] Kishore stv0900_attach: [ 1159.340362] stv0900_init_internal [ 1159.340393] stv0900_init_internal: Create New Internal Structure! [ 1159.340423] stv0900_read_reg [ 1179.527770] stv0900_read_reg [ 1550.418365] stv0900_read_reg [ 1637.090240] stv0900_st_dvbs2_single [ 1637.090270] stv0900_stop_all_s2_modcod [ 1669.340270] stv0900_activate_s2_modcod_single [ 1703.605865] stv0900_read_reg [ 1709.652740] stv0900_read_reg [ 1715.699584] stv0900_read_reg [ 1721.746490] stv0900_read_reg [ 1727.793365] stv0900_read_reg [ 1733.840209] stv0900_read_reg [ 1739.887115] stv0900_read_reg [ 1743.918395] stv0900_read_reg [ 1749.965240] stv0900_read_reg [ 1756.012115] stv0900_set_ts_parallel_serial path1 3 path2 0 [ 1758.027740] stv0900_read_reg [ 1764.074615] stv0900_read_reg [ 1770.121490] stv0900_read_reg [ 1776.168334] stv0900_read_reg [ 1782.215209] stv0900_read_reg [ 1788.262115] stv0900_read_reg [ 1810.433990] stv0900_read_reg [ 1816.480865] stv0900_read_reg [ 1824.543365] stv0900_read_reg [ 1830.590240] stv0900_read_reg [ 1838.652740] stv0900_read_reg [ 1844.699615] stv0900_read_reg [ 1850.746490] stv0900_set_mclk: Mclk set to 13500, Quartz = 2700 [ 1850.746520] stv0900_read_reg [ 1854.40] stv0900_read_reg [ 1860.824615] stv0900_read_reg [ 1864.855865] stv0900_read_reg [ 1868.887115] stv0900_get_mclk_freq: Calculated Mclk = 152672117 [ 1876.965209] stv0900_read_reg [ 1883.027709] stv0900_read_reg [ 1887.058990] stv0900_read_reg [ 1891.090240] stv0900_get_mclk_freq:
Re: [PATCH RFC 3/5] V4L2: Add V4L2_ASYNC_MATCH_OF subdev matching type
Hi Sylwester
On Mon, 22 Jul 2013, Sylwester Nawrocki wrote:
Add support for matching by device_node pointer. This allows
the notifier user to simply pass a list of device_node pointers
corresponding to sub-devices.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/v4l2-core/v4l2-async.c |9 +
include/media/v4l2-async.h |5 +
2 files changed, 14 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
index 86934ca..9f91013 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -39,6 +39,11 @@ static bool match_devname(struct device *dev, struct
v4l2_async_subdev *asd)
return !strcmp(asd-match.device_name.name, dev_name(dev));
}
+static bool match_of(struct device *dev, struct v4l2_async_subdev *asd)
+{
+ return dev-of_node == asd-match.of.node;
+}
+
static LIST_HEAD(subdev_list);
static LIST_HEAD(notifier_list);
static DEFINE_MUTEX(list_lock);
@@ -66,6 +71,9 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct
v4l2_async_notifier *
case V4L2_ASYNC_MATCH_I2C:
match = match_i2c;
break;
+ case V4L2_ASYNC_MATCH_OF:
+ match = match_of;
+ break;
default:
/* Cannot happen, unless someone breaks us */
WARN_ON(true);
@@ -145,6 +153,7 @@ int v4l2_async_notifier_register(struct v4l2_device
*v4l2_dev,
case V4L2_ASYNC_MATCH_CUSTOM:
case V4L2_ASYNC_MATCH_DEVNAME:
case V4L2_ASYNC_MATCH_I2C:
+ case V4L2_ASYNC_MATCH_OF:
break;
default:
dev_err(notifier-v4l2_dev ? notifier-v4l2_dev-dev :
NULL,
diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h
index 33e3b2a..295782e 100644
--- a/include/media/v4l2-async.h
+++ b/include/media/v4l2-async.h
@@ -13,6 +13,7 @@
#include linux/list.h
#include linux/mutex.h
+#include linux/of.h
struct device;
struct v4l2_device;
A nitpick: it is common to just forward-declare structs as above instead
of including a header if just a pointer to that struct is needed. I think
it would be more consistent to update it here.
Thanks
Guennadi
@@ -26,6 +27,7 @@ enum v4l2_async_match_type {
V4L2_ASYNC_MATCH_CUSTOM,
V4L2_ASYNC_MATCH_DEVNAME,
V4L2_ASYNC_MATCH_I2C,
+ V4L2_ASYNC_MATCH_OF,
};
/**
@@ -39,6 +41,9 @@ struct v4l2_async_subdev {
enum v4l2_async_match_type match_type;
union {
struct {
+ const struct device_node *node;
+ } of;
+ struct {
const char *name;
} device_name;
struct {
--
1.7.9.5
---
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 RFC 4/5] V4L2: Rename subdev field of struct v4l2_async_notifier
Hi Sylwester
On Mon, 22 Jul 2013, Sylwester Nawrocki wrote:
This is a purely cosmetic change. Since the 'subdev' member
points to an array of subdevs it seems more intuitive to name
it in plural form.
Well, I was aware of the fact, that subdev is an array and that the
plural form of subdev would be subdevs :-) It was kind of a conscious
choice. I think, both ways can be found in the kernel: using singulars and
plurals for array names. Whether one of them is better than the other - no
idea. My personal preference is somewhat with the singular form as in, say
subdev array instead of subdevs array, i.e. as an adjective, but I
really don't care all that much :) Feel free to change if that's important
for you or for others on V4L :)
Thanks
Guennadi
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/soc_camera/soc_camera.c |2 +-
drivers/media/v4l2-core/v4l2-async.c |2 +-
include/media/v4l2-async.h |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index 8af572b..4b42572 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1501,7 +1501,7 @@ static int scan_async_group(struct soc_camera_host *ici,
return -ENOMEM;
}
- sasc-notifier.subdev = asd;
+ sasc-notifier.subdevs = asd;
sasc-notifier.num_subdevs = size;
sasc-notifier.bound = soc_camera_async_bound;
sasc-notifier.unbind = soc_camera_async_unbind;
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
index 9f91013..ed31a65 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -147,7 +147,7 @@ int v4l2_async_notifier_register(struct v4l2_device
*v4l2_dev,
INIT_LIST_HEAD(notifier-done);
for (i = 0; i notifier-num_subdevs; i++) {
- asd = notifier-subdev[i];
+ asd = notifier-subdevs[i];
switch (asd-match_type) {
case V4L2_ASYNC_MATCH_CUSTOM:
diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h
index 295782e..4e7834a 100644
--- a/include/media/v4l2-async.h
+++ b/include/media/v4l2-async.h
@@ -77,7 +77,7 @@ struct v4l2_async_subdev_list {
/**
* v4l2_async_notifier - v4l2_device notifier data
* @num_subdevs:number of subdevices
- * @subdev: array of pointers to subdevice descriptors
+ * @subdevs: array of pointers to subdevice descriptors
* @v4l2_dev:pointer to struct v4l2_device
* @waiting: list of struct v4l2_async_subdev, waiting for their drivers
* @done:list of struct v4l2_async_subdev_list, already probed
@@ -88,7 +88,7 @@ struct v4l2_async_subdev_list {
*/
struct v4l2_async_notifier {
unsigned int num_subdevs;
- struct v4l2_async_subdev **subdev;
+ struct v4l2_async_subdev **subdevs;
struct v4l2_device *v4l2_dev;
struct list_head waiting;
struct list_head done;
--
1.7.9.5
---
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: Prof DVB-S2 USB device
Any idea on the following error? scanning /stbref/dvb-apps-f3a70b206f0f/util/scan/dvb-s/Insat4B_C-93.5E using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 3725000 H 2750 3 initial transponder 375 H 425 3 initial transponder 3762000 H 425 3 initial transponder 3768000 H 425 3 initial transponder 3774000 H 425 3 initial transponder 3802000 H 425 3 initial transponder 3808000 H 425 3 initial transponder 3822000 H 425 3 initial transponder 3832000 H 625 3 initial transponder 3841000 H 625 3 initial transponder 3885000 H 2800 3 initial transponder 3925000 H 2750 3 initial transponder 395 H 444 3 initial transponder 4005000 H 25422000 7 initial transponder 4045000 H 2800 3 tune to: 3725:h:0:27500 DVB-S IF freq is 6025000 [ 3095.402008] DVB: adapter 0 frontend 0 frequency 6025000 out of range (95..215) __tune_to_transponder:1910: ERROR: Setting frontend parameters failed: 22 Invalid argument tune to: 3725:h:0:27500 From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] on behalf of Krishna Kishore [krishna.kish...@sasken.com] Sent: Wednesday, July 24, 2013 4:50 PM To: Oliver Schinagl Cc: linux-media@vger.kernel.org Subject: RE: Prof DVB-S2 USB device On Desktop PC (Ubuntu 12.04 which has 3.2.0 Kernel) also, I am not getting the list of channels when I scan. I am using Kaffeine. -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Wednesday, July 24, 2013 4:34 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 24-07-13 10:59, Krishna Kishore wrote: Dear Oliver, Thanks for your response. I tried with 3.10.1. As you rightly pointed out, it does not seem to work on my board (pandaboard). It gets stuck at Starting kernel Now, I am trying with 3.4.47 version now. Let me see if it works. The delay of creating /dev/dvb/adapter0/frontend0 and /dev/dvb/adapter0/demux0 seems to exists. I am waiting for it to get created. I am downloading 3.4.54 and 3.10.2 now. What do you get when using on a regular PC? Your beagle board may (or may not) yet be supported by mainline 3.10.1 kernel. Try it in a regular PC and see what happens there with 3.10.2 Regards, Kishore. -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Wednesday, July 24, 2013 1:12 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 24-07-13 08:56, Krishna Kishore wrote: Dear Oliver, Thanks for your response. Here are more details. Please help me in making this work. Linux version: -sh-4.1# uname -a Linux (none) 3.4.0 #28 SMP PREEMPT Tue Jul 23 16:24:14 IST 2013 armv7l GNU/Linux Your kernel is ancient. The latest kernel with the latest media fluff is 3.10.2; Since you are on arm, chances are your platform isn't that well supported with later kernels, but even in the 3.4 world your kernel is ancient. Latest stable is 3.4.54. So you are asking for help, with something that could have been fixed 3 times over (or not, I don't know). So my first suggestion is to upgrade your kernel. If that's not possible on your arm platform, contact the supplier of your kernel. Meanwhile, since this is an USB device, you could try it on a desktop. Get a recent Ubuntu live CD and see if it works there. At least then you can quickly and easily see if your problem hasn't been fixed in the last year. [dotconfig is attached to this email] lsusb -t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M |__ Port 1: Dev 2, If 0, Class=, Driver=hub/5p, 480M |__ Port 1: Dev 3, If 0, Class=, Driver=smsc95xx, 480M |__ Port 2: Dev 5, If 0, Class=, Driver=dw2102, 480M dmesg: [ 126.824951] usb 1-1.2: new high-speed USB device number 5 using ehci-omap [ 126.950347] usb 1-1.2: New USB device found, idVendor=3034, idProduct=7500 [ 126.957794] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 126.983184] dvb-usb: found a 'Prof 7500 USB DVB-S2' in cold state, will try to load a firmware [ 127.033477] dvb-usb: downloading firmware from file 'dvb-usb-p7500.fw' [ 127.051177] dw2102: start downloading DW210X firmware [ 127.238739] dvb-usb: found a 'Prof 7500 USB DVB-S2' in warm state. [ 127.255828] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 127.271270] DVB: registering new adapter (Prof 7500 USB DVB-S2) [ 1159.277740] dvb-usb: MAC address: 40:40:40:40:40:40 [ 1159.325531] dw2102: Kishore: prof_7500_frontend_attach [ 1159.325561] [ 1159.340332] Kishore stv0900_attach: [ 1159.340362] stv0900_init_internal [ 1159.340393] stv0900_init_internal: Create New Internal Structure! [ 1159.340423] stv0900_read_reg [ 1179.527770] stv0900_read_reg [
Re: [PATCH RFC 0/5] v4l2-async DT support improvement and cleanups
Hi Sylwester On Mon, 22 Jul 2013, Sylwester Nawrocki wrote: Hello, This is a few patches for the v4l2-async API I wrote while adding the asynchronous subdev registration support to the exynos4-is driver. The most significant change is addition of V4L2_ASYNC_MATCH_OF subdev matching method, where host driver can pass a list of of_node pointers identifying its subdevs. I thought it's a reasonable and simple enough way to support device tree based systems. Comments/other ideas are of course welcome. Thanks for the patches. In principle I have nothing against them, OF support looks good, integrating asdl into struct v4l2_subdev, dropping redundant checks, renaming bus to match look ok too. Plural vs. singular seems to be a matter of taste to me :) But in general, provided my single comment concerning struct forward-declaration is addressed Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi Thanks, Sylwester Sylwester Nawrocki (5): V4L2: Drop bus_type check in v4l2-async match functions V4L2: Rename v4l2_async_bus_* to v4l2_async_match_* V4L2: Add V4L2_ASYNC_MATCH_OF subdev matching type V4L2: Rename subdev field of struct v4l2_async_notifier V4L2: Fold struct v4l2_async_subdev_list with struct v4l2_subdev drivers/media/platform/soc_camera/soc_camera.c |4 +- drivers/media/v4l2-core/v4l2-async.c | 106 include/media/v4l2-async.h | 36 include/media/v4l2-subdev.h| 13 ++- 4 files changed, 74 insertions(+), 85 deletions(-) -- 1.7.9.5 --- 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: Prof DVB-S2 USB device
On 24-07-13 13:20, Krishna Kishore wrote: On Desktop PC (Ubuntu 12.04 which has 3.2.0 Kernel) also, I am not getting the list of channels when I scan. I am using Kaffeine. While I understand you prefer to run a LTS distro, 3.2.0 is old! The reason why I keep bringing this up, media drivers are almost updated daily. So if you want to see if your issue is fixed, the most ideal start for this investigation is the media git kernel tree. While I understand building your own kernel might be a little too much, try an Ubuntu 13.04 Live cd, it should come with a 3.9 kernel, not extremly old, but should have most of the recent media changes. Now if it doesn't work right on that, well, then you'd have to build your own media drivers from the git tree. If those don't work, then we can start talking to developers. Otherwise, you are trying to troubleshoot something, that has long been fixed. oliver -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Wednesday, July 24, 2013 4:34 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 24-07-13 10:59, Krishna Kishore wrote: Dear Oliver, Thanks for your response. I tried with 3.10.1. As you rightly pointed out, it does not seem to work on my board (pandaboard). It gets stuck at Starting kernel Now, I am trying with 3.4.47 version now. Let me see if it works. The delay of creating /dev/dvb/adapter0/frontend0 and /dev/dvb/adapter0/demux0 seems to exists. I am waiting for it to get created. I am downloading 3.4.54 and 3.10.2 now. What do you get when using on a regular PC? Your beagle board may (or may not) yet be supported by mainline 3.10.1 kernel. Try it in a regular PC and see what happens there with 3.10.2 Regards, Kishore. -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Wednesday, July 24, 2013 1:12 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 24-07-13 08:56, Krishna Kishore wrote: Dear Oliver, Thanks for your response. Here are more details. Please help me in making this work. Linux version: -sh-4.1# uname -a Linux (none) 3.4.0 #28 SMP PREEMPT Tue Jul 23 16:24:14 IST 2013 armv7l GNU/Linux Your kernel is ancient. The latest kernel with the latest media fluff is 3.10.2; Since you are on arm, chances are your platform isn't that well supported with later kernels, but even in the 3.4 world your kernel is ancient. Latest stable is 3.4.54. So you are asking for help, with something that could have been fixed 3 times over (or not, I don't know). So my first suggestion is to upgrade your kernel. If that's not possible on your arm platform, contact the supplier of your kernel. Meanwhile, since this is an USB device, you could try it on a desktop. Get a recent Ubuntu live CD and see if it works there. At least then you can quickly and easily see if your problem hasn't been fixed in the last year. [dotconfig is attached to this email] lsusb -t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M |__ Port 1: Dev 2, If 0, Class=, Driver=hub/5p, 480M |__ Port 1: Dev 3, If 0, Class=, Driver=smsc95xx, 480M |__ Port 2: Dev 5, If 0, Class=, Driver=dw2102, 480M dmesg: [ 126.824951] usb 1-1.2: new high-speed USB device number 5 using ehci-omap [ 126.950347] usb 1-1.2: New USB device found, idVendor=3034, idProduct=7500 [ 126.957794] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 126.983184] dvb-usb: found a 'Prof 7500 USB DVB-S2' in cold state, will try to load a firmware [ 127.033477] dvb-usb: downloading firmware from file 'dvb-usb-p7500.fw' [ 127.051177] dw2102: start downloading DW210X firmware [ 127.238739] dvb-usb: found a 'Prof 7500 USB DVB-S2' in warm state. [ 127.255828] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 127.271270] DVB: registering new adapter (Prof 7500 USB DVB-S2) [ 1159.277740] dvb-usb: MAC address: 40:40:40:40:40:40 [ 1159.325531] dw2102: Kishore: prof_7500_frontend_attach [ 1159.325561] [ 1159.340332] Kishore stv0900_attach: [ 1159.340362] stv0900_init_internal [ 1159.340393] stv0900_init_internal: Create New Internal Structure! [ 1159.340423] stv0900_read_reg [ 1179.527770] stv0900_read_reg [ 1550.418365] stv0900_read_reg [ 1637.090240] stv0900_st_dvbs2_single [ 1637.090270] stv0900_stop_all_s2_modcod [ 1669.340270] stv0900_activate_s2_modcod_single [ 1703.605865] stv0900_read_reg [ 1709.652740] stv0900_read_reg [ 1715.699584] stv0900_read_reg [ 1721.746490] stv0900_read_reg [ 1727.793365] stv0900_read_reg [ 1733.840209] stv0900_read_reg [ 1739.887115] stv0900_read_reg [ 1743.918395] stv0900_read_reg [ 1749.965240] stv0900_read_reg [ 1756.012115] stv0900_set_ts_parallel_serial path1 3 path2 0 [ 1758.027740] stv0900_read_reg [ 1764.074615] stv0900_read_reg [ 1770.121490] stv0900_read_reg [
Re: Prof DVB-S2 USB device
On 24-07-13 13:31, Krishna Kishore wrote: Any idea on the following error? scanning /stbref/dvb-apps-f3a70b206f0f/util/scan/dvb-s/Insat4B_C-93.5E using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 3725000 H 2750 3 initial transponder 375 H 425 3 initial transponder 3762000 H 425 3 initial transponder 3768000 H 425 3 initial transponder 3774000 H 425 3 initial transponder 3802000 H 425 3 initial transponder 3808000 H 425 3 initial transponder 3822000 H 425 3 initial transponder 3832000 H 625 3 initial transponder 3841000 H 625 3 initial transponder 3885000 H 2800 3 initial transponder 3925000 H 2750 3 initial transponder 395 H 444 3 initial transponder 4005000 H 25422000 7 initial transponder 4045000 H 2800 3 tune to: 3725:h:0:27500 DVB-S IF freq is 6025000 [ 3095.402008] DVB: adapter 0 frontend 0 frequency 6025000 out of range (95..215) __tune_to_transponder:1910: ERROR: Setting frontend parameters failed: 22 Invalid argument No idea, but I wouldn't be supprised if it is a new version of w_scan, and an old driver ;) tune to: 3725:h:0:27500 From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] on behalf of Krishna Kishore [krishna.kish...@sasken.com] Sent: Wednesday, July 24, 2013 4:50 PM To: Oliver Schinagl Cc: linux-media@vger.kernel.org Subject: RE: Prof DVB-S2 USB device On Desktop PC (Ubuntu 12.04 which has 3.2.0 Kernel) also, I am not getting the list of channels when I scan. I am using Kaffeine. -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Wednesday, July 24, 2013 4:34 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 24-07-13 10:59, Krishna Kishore wrote: Dear Oliver, Thanks for your response. I tried with 3.10.1. As you rightly pointed out, it does not seem to work on my board (pandaboard). It gets stuck at Starting kernel Now, I am trying with 3.4.47 version now. Let me see if it works. The delay of creating /dev/dvb/adapter0/frontend0 and /dev/dvb/adapter0/demux0 seems to exists. I am waiting for it to get created. I am downloading 3.4.54 and 3.10.2 now. What do you get when using on a regular PC? Your beagle board may (or may not) yet be supported by mainline 3.10.1 kernel. Try it in a regular PC and see what happens there with 3.10.2 Regards, Kishore. -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Wednesday, July 24, 2013 1:12 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 24-07-13 08:56, Krishna Kishore wrote: Dear Oliver, Thanks for your response. Here are more details. Please help me in making this work. Linux version: -sh-4.1# uname -a Linux (none) 3.4.0 #28 SMP PREEMPT Tue Jul 23 16:24:14 IST 2013 armv7l GNU/Linux Your kernel is ancient. The latest kernel with the latest media fluff is 3.10.2; Since you are on arm, chances are your platform isn't that well supported with later kernels, but even in the 3.4 world your kernel is ancient. Latest stable is 3.4.54. So you are asking for help, with something that could have been fixed 3 times over (or not, I don't know). So my first suggestion is to upgrade your kernel. If that's not possible on your arm platform, contact the supplier of your kernel. Meanwhile, since this is an USB device, you could try it on a desktop. Get a recent Ubuntu live CD and see if it works there. At least then you can quickly and easily see if your problem hasn't been fixed in the last year. [dotconfig is attached to this email] lsusb -t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M |__ Port 1: Dev 2, If 0, Class=, Driver=hub/5p, 480M |__ Port 1: Dev 3, If 0, Class=, Driver=smsc95xx, 480M |__ Port 2: Dev 5, If 0, Class=, Driver=dw2102, 480M dmesg: [ 126.824951] usb 1-1.2: new high-speed USB device number 5 using ehci-omap [ 126.950347] usb 1-1.2: New USB device found, idVendor=3034, idProduct=7500 [ 126.957794] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 126.983184] dvb-usb: found a 'Prof 7500 USB DVB-S2' in cold state, will try to load a firmware [ 127.033477] dvb-usb: downloading firmware from file 'dvb-usb-p7500.fw' [ 127.051177] dw2102: start downloading DW210X firmware [ 127.238739] dvb-usb: found a 'Prof 7500 USB DVB-S2' in warm state. [ 127.255828] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 127.271270] DVB: registering new adapter (Prof 7500 USB DVB-S2) [ 1159.277740] dvb-usb: MAC address: 40:40:40:40:40:40 [ 1159.325531] dw2102: Kishore: prof_7500_frontend_attach [ 1159.325561] [ 1159.340332] Kishore stv0900_attach: [ 1159.340362] stv0900_init_internal [ 1159.340393] stv0900_init_internal: Create New
Re: cron job: media_tree daily build: ERRORS
On Tue 23 July 2013 19:27:47 Hans Verkuil wrote: This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. I've fixed the build issues after the 3.11 merge. So hopefully today's daily build will be back to 'WARNINGS'. Regards, Hans Results of the daily build of media_tree: date: Tue Jul 23 19:00:18 CEST 2013 git branch: test git hash: c859e6ef33ac0c9a5e9e934fe11a2232752b4e96 gcc version: i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware:x86_64 host os: 3.9-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: ERRORS linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.10-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-2.6.31.14-x86_64: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.10-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API 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 -- 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] cx23885[v3]: Fix interrupt storm when enabling IR receiver.
Hi,
New patch for this issue. Changes:
- Added flatiron readreg and writereg functions prototypes (new header file).
- Modified the av work handler to preserve all other register bits when dealing
with the interrupt flag.
Regards,
Luis
Signed-off-by: Luis Alves lja...@gmail.com
---
drivers/media/pci/cx23885/cx23885-av.c| 13 +
drivers/media/pci/cx23885/cx23885-video.c |4 ++--
drivers/media/pci/cx23885/cx23885-video.h | 28
3 files changed, 43 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/pci/cx23885/cx23885-video.h
diff --git a/drivers/media/pci/cx23885/cx23885-av.c
b/drivers/media/pci/cx23885/cx23885-av.c
index e958a01..c443b7a 100644
--- a/drivers/media/pci/cx23885/cx23885-av.c
+++ b/drivers/media/pci/cx23885/cx23885-av.c
@@ -23,6 +23,7 @@
#include cx23885.h
#include cx23885-av.h
+#include cx23885-video.h
void cx23885_av_work_handler(struct work_struct *work)
{
@@ -32,5 +33,17 @@ void cx23885_av_work_handler(struct work_struct *work)
v4l2_subdev_call(dev-sd_cx25840, core, interrupt_service_routine,
PCI_MSK_AV_CORE, handled);
+
+ /* Getting here with the interrupt not handled
+ then probbaly flatiron does have pending interrupts.
+ */
+ if (!handled) {
+ /* clear left and right adc channel interrupt request flag */
+ cx23885_flatiron_write(dev, 0x1f,
+ cx23885_flatiron_read(dev, 0x1f) | 0x80);
+ cx23885_flatiron_write(dev, 0x23,
+ cx23885_flatiron_read(dev, 0x23) | 0x80);
+ }
+
cx23885_irq_enable(dev, PCI_MSK_AV_CORE);
}
diff --git a/drivers/media/pci/cx23885/cx23885-video.c
b/drivers/media/pci/cx23885/cx23885-video.c
index e33d1a7..f4e7cef 100644
--- a/drivers/media/pci/cx23885/cx23885-video.c
+++ b/drivers/media/pci/cx23885/cx23885-video.c
@@ -417,7 +417,7 @@ static void res_free(struct cx23885_dev *dev, struct
cx23885_fh *fh,
mutex_unlock(dev-lock);
}
-static int cx23885_flatiron_write(struct cx23885_dev *dev, u8 reg, u8 data)
+int cx23885_flatiron_write(struct cx23885_dev *dev, u8 reg, u8 data)
{
/* 8 bit registers, 8 bit values */
u8 buf[] = { reg, data };
@@ -428,7 +428,7 @@ static int cx23885_flatiron_write(struct cx23885_dev *dev,
u8 reg, u8 data)
return i2c_transfer(dev-i2c_bus[2].i2c_adap, msg, 1);
}
-static u8 cx23885_flatiron_read(struct cx23885_dev *dev, u8 reg)
+u8 cx23885_flatiron_read(struct cx23885_dev *dev, u8 reg)
{
/* 8 bit registers, 8 bit values */
int ret;
diff --git a/drivers/media/pci/cx23885/cx23885-video.h
b/drivers/media/pci/cx23885/cx23885-video.h
new file mode 100644
index 000..6e88214
--- /dev/null
+++ b/drivers/media/pci/cx23885/cx23885-video.h
@@ -0,0 +1,28 @@
+/*
+ * Driver for the Conexant CX23885/7/8 PCIe bridge
+ *
+ * AV device support routines - non-input, non-vl42_subdev routines
+ *
+ * Copyright (C) 2010 Andy Walls awa...@md.metrocast.net
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#ifndef _CX23885_VIDEO_H_
+#define _CX23885_VIDEO_H_
+int cx23885_flatiron_write(struct cx23885_dev *dev, u8 reg, u8 data);
+u8 cx23885_flatiron_read(struct cx23885_dev *dev, u8 reg);
+#endif
--
1.7.9.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] cx23885[v4]: Fix interrupt storm when enabling IR receiver.
Hi,
Removed wrong description in the header file. Sorry about that...
New patch for this issue. Changes:
- Added flatiron readreg and writereg functions prototypes (new header file).
- Modified the av work handler to preserve all other register bits when dealing
with the interrupt flag.
Regards,
Luis
Signed-off-by: Luis Alves lja...@gmail.com
---
drivers/media/pci/cx23885/cx23885-av.c| 13 +
drivers/media/pci/cx23885/cx23885-video.c |4 ++--
drivers/media/pci/cx23885/cx23885-video.h | 26 ++
3 files changed, 41 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/pci/cx23885/cx23885-video.h
diff --git a/drivers/media/pci/cx23885/cx23885-av.c
b/drivers/media/pci/cx23885/cx23885-av.c
index e958a01..c443b7a 100644
--- a/drivers/media/pci/cx23885/cx23885-av.c
+++ b/drivers/media/pci/cx23885/cx23885-av.c
@@ -23,6 +23,7 @@
#include cx23885.h
#include cx23885-av.h
+#include cx23885-video.h
void cx23885_av_work_handler(struct work_struct *work)
{
@@ -32,5 +33,17 @@ void cx23885_av_work_handler(struct work_struct *work)
v4l2_subdev_call(dev-sd_cx25840, core, interrupt_service_routine,
PCI_MSK_AV_CORE, handled);
+
+ /* Getting here with the interrupt not handled
+ then probbaly flatiron does have pending interrupts.
+ */
+ if (!handled) {
+ /* clear left and right adc channel interrupt request flag */
+ cx23885_flatiron_write(dev, 0x1f,
+ cx23885_flatiron_read(dev, 0x1f) | 0x80);
+ cx23885_flatiron_write(dev, 0x23,
+ cx23885_flatiron_read(dev, 0x23) | 0x80);
+ }
+
cx23885_irq_enable(dev, PCI_MSK_AV_CORE);
}
diff --git a/drivers/media/pci/cx23885/cx23885-video.c
b/drivers/media/pci/cx23885/cx23885-video.c
index e33d1a7..f4e7cef 100644
--- a/drivers/media/pci/cx23885/cx23885-video.c
+++ b/drivers/media/pci/cx23885/cx23885-video.c
@@ -417,7 +417,7 @@ static void res_free(struct cx23885_dev *dev, struct
cx23885_fh *fh,
mutex_unlock(dev-lock);
}
-static int cx23885_flatiron_write(struct cx23885_dev *dev, u8 reg, u8 data)
+int cx23885_flatiron_write(struct cx23885_dev *dev, u8 reg, u8 data)
{
/* 8 bit registers, 8 bit values */
u8 buf[] = { reg, data };
@@ -428,7 +428,7 @@ static int cx23885_flatiron_write(struct cx23885_dev *dev,
u8 reg, u8 data)
return i2c_transfer(dev-i2c_bus[2].i2c_adap, msg, 1);
}
-static u8 cx23885_flatiron_read(struct cx23885_dev *dev, u8 reg)
+u8 cx23885_flatiron_read(struct cx23885_dev *dev, u8 reg)
{
/* 8 bit registers, 8 bit values */
int ret;
diff --git a/drivers/media/pci/cx23885/cx23885-video.h
b/drivers/media/pci/cx23885/cx23885-video.h
new file mode 100644
index 000..c961a2b
--- /dev/null
+++ b/drivers/media/pci/cx23885/cx23885-video.h
@@ -0,0 +1,26 @@
+/*
+ * Driver for the Conexant CX23885/7/8 PCIe bridge
+ *
+ * Copyright (C) 2010 Andy Walls awa...@md.metrocast.net
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#ifndef _CX23885_VIDEO_H_
+#define _CX23885_VIDEO_H_
+int cx23885_flatiron_write(struct cx23885_dev *dev, u8 reg, u8 data);
+u8 cx23885_flatiron_read(struct cx23885_dev *dev, u8 reg);
+#endif
--
1.7.9.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
RE: Prof DVB-S2 USB device
Thanks a lot for your response. On PC (Ubuntu 12.04) also, channel list is not seen. I saw a youtube video (http://www.youtube.com/watch?v=lv-Hel3DUkY) that Prof USB 7500 DVB-S2 device works. Looks like driver is trying to lock at the frequency which is out of range of what driver is expecting (95...215) -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Wednesday, July 24, 2013 5:49 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 24-07-13 13:31, Krishna Kishore wrote: Any idea on the following error? scanning /stbref/dvb-apps-f3a70b206f0f/util/scan/dvb-s/Insat4B_C-93.5E using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 3725000 H 2750 3 initial transponder 375 H 425 3 initial transponder 3762000 H 425 3 initial transponder 3768000 H 425 3 initial transponder 3774000 H 425 3 initial transponder 3802000 H 425 3 initial transponder 3808000 H 425 3 initial transponder 3822000 H 425 3 initial transponder 3832000 H 625 3 initial transponder 3841000 H 625 3 initial transponder 3885000 H 2800 3 initial transponder 3925000 H 2750 3 initial transponder 395 H 444 3 initial transponder 4005000 H 25422000 7 initial transponder 4045000 H 2800 3 tune to: 3725:h:0:27500 DVB-S IF freq is 6025000 [ 3095.402008] DVB: adapter 0 frontend 0 frequency 6025000 out of range (95..215) __tune_to_transponder:1910: ERROR: Setting frontend parameters failed: 22 Invalid argument No idea, but I wouldn't be supprised if it is a new version of w_scan, and an old driver ;) tune to: 3725:h:0:27500 From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] on behalf of Krishna Kishore [krishna.kish...@sasken.com] Sent: Wednesday, July 24, 2013 4:50 PM To: Oliver Schinagl Cc: linux-media@vger.kernel.org Subject: RE: Prof DVB-S2 USB device On Desktop PC (Ubuntu 12.04 which has 3.2.0 Kernel) also, I am not getting the list of channels when I scan. I am using Kaffeine. -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Wednesday, July 24, 2013 4:34 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 24-07-13 10:59, Krishna Kishore wrote: Dear Oliver, Thanks for your response. I tried with 3.10.1. As you rightly pointed out, it does not seem to work on my board (pandaboard). It gets stuck at Starting kernel Now, I am trying with 3.4.47 version now. Let me see if it works. The delay of creating /dev/dvb/adapter0/frontend0 and /dev/dvb/adapter0/demux0 seems to exists. I am waiting for it to get created. I am downloading 3.4.54 and 3.10.2 now. What do you get when using on a regular PC? Your beagle board may (or may not) yet be supported by mainline 3.10.1 kernel. Try it in a regular PC and see what happens there with 3.10.2 Regards, Kishore. -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Wednesday, July 24, 2013 1:12 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 24-07-13 08:56, Krishna Kishore wrote: Dear Oliver, Thanks for your response. Here are more details. Please help me in making this work. Linux version: -sh-4.1# uname -a Linux (none) 3.4.0 #28 SMP PREEMPT Tue Jul 23 16:24:14 IST 2013 armv7l GNU/Linux Your kernel is ancient. The latest kernel with the latest media fluff is 3.10.2; Since you are on arm, chances are your platform isn't that well supported with later kernels, but even in the 3.4 world your kernel is ancient. Latest stable is 3.4.54. So you are asking for help, with something that could have been fixed 3 times over (or not, I don't know). So my first suggestion is to upgrade your kernel. If that's not possible on your arm platform, contact the supplier of your kernel. Meanwhile, since this is an USB device, you could try it on a desktop. Get a recent Ubuntu live CD and see if it works there. At least then you can quickly and easily see if your problem hasn't been fixed in the last year. [dotconfig is attached to this email] lsusb -t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M |__ Port 1: Dev 2, If 0, Class=, Driver=hub/5p, 480M |__ Port 1: Dev 3, If 0, Class=, Driver=smsc95xx, 480M |__ Port 2: Dev 5, If 0, Class=, Driver=dw2102, 480M dmesg: [ 126.824951] usb 1-1.2: new high-speed USB device number 5 using ehci-omap [ 126.950347] usb 1-1.2: New USB device found, idVendor=3034, idProduct=7500 [ 126.957794] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 126.983184] dvb-usb: found a 'Prof 7500 USB DVB-S2' in cold state, will try to load a
Re: [PATCH v2 1/5] media: Fix circular graph traversal
Hi Sakari,
On Thursday 18 July 2013 13:22:09 Sakari Ailus wrote:
On Thu, Jul 18, 2013 at 01:06:40AM +0200, Laurent Pinchart wrote:
On Wednesday 17 July 2013 22:47:03 Sakari Ailus wrote:
On Wed, Jul 17, 2013 at 04:54:38PM +0200, Laurent Pinchart wrote:
The graph traversal API (media_entity_graph_walk_*) will fail to
correctly walk the graph when circular links exist. Fix it by checking
whether an entity is already present in the stack before pushing it.
We never had any multiply connected graphs (ignoring direction, nor
supported them) before. So this is rather a patch that adds support for
those instead of fixing it. :-)
Good point, I'll add support for your comment to the commit message :-D
Signed-off-by: Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com
---
drivers/media/media-entity.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/media/media-entity.c
b/drivers/media/media-entity.c
index cb30ffb..c8aba5e 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -121,9 +121,9 @@ static struct media_entity *stack_pop(struct
media_entity_graph *graph)
return entity;
}
-#define stack_peek(en) ((en)-stack[(en)-top - 1].entity)
-#define link_top(en) ((en)-stack[(en)-top].link)
-#define stack_top(en) ((en)-stack[(en)-top].entity)
+#define stack_peek(en, i) ((en)-stack[i].entity)
+#define link_top(en) ((en)-stack[(en)-top].link)
+#define stack_top(en) ((en)-stack[(en)-top].entity)
/**
* media_entity_graph_walk_start - Start walking the media graph at a
given entity
@@ -159,6 +159,8 @@ EXPORT_SYMBOL_GPL(media_entity_graph_walk_start);
struct media_entity *
media_entity_graph_walk_next(struct media_entity_graph *graph)
{
+ unsigned int i;
+
if (stack_top(graph) == NULL)
return NULL;
@@ -181,8 +183,13 @@ media_entity_graph_walk_next(struct
media_entity_graph *graph)
/* Get the entity in the other end of the link . */
next = media_entity_other(entity, link);
- /* Was it the entity we came here from? */
- if (next == stack_peek(graph)) {
+ /* Is the entity already in the path? */
+ for (i = 1; i graph-top; ++i) {
+ if (next == stack_peek(graph, i))
+ break;
+ }
+
+ if (i graph-top) {
link_top(graph)++;
continue;
}
I think you should also ensure a node in the graph hasn't been
enumerated in the past; otherwise it's possible to do that multiple
times in a multiply connected graph.
I'm not sure to follow you here, could you please elaborate ?
Depth-first search in a multiply connected graph must avoid finding again
the same nodes. As we didn't have multiply connected graphs, the only thing
that was necessary was to avoid going back exactly the same route that the
search came from.
In a multiply connected graph a node can be reached through multiple paths.
This means that instead of avoiding to go back where we came from (either
the previous node or the full stack), we must avoid finding again the same
nodes we've found previously.
Indeed, I somehow managed to overlook the issue. That's not really a problem
in my case, as circular graphs are not supported by my hardware, but a generic
solution is indeed needed.
How about using a bit field that contained as many bits as there were
entities? It's also faster to check for a single bit than loop over the
whole path for each entity, which certainly will start showing in
execution time with these link numbres.
That's possible, yes. We would then need to dynamically allocate the bit
field in the start function, and add a new media_entity_graph_walk_end()
function (I would then rename media_entity_graph_walk_start() to
media_entity_graph_walk_begin()) to free the bit field. If you think
that's worth it I can give it a try.
Do you think we could define a maximum number of entities? It can be
increased if any driver happens to need more. I'd be more comfortable in
doing the allocation in the stack that way: the number will be relatively
small in any case, say, 32 or 64 bits for which kzalloc() would be overkill.
This should work for now, but I'm a bit concerned that it would break in the
future if we introduce dynamic entity (un)registration. In that case the
maximum number of entities could be capped, but the IDs will increase.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send
Re: PROBLEM: dvb-usb-rtl28xxu and Terratec Cinergy TStickRC (rev3) - no signal on some frequencies
Could you test attached patch?
It enhances reception a little bit, you should be able to receive more
weak signals.
I was able to made test setup against modulator. Modulator + attenuator
+ attenuator + TV-stick, where I got picture using Windows driver at
signal level -29dBm whilst on Linux -26.5dBm was needed. With that patch
Linux driver started performing same as Windows.
regards
Antti
On 07/23/2013 12:09 AM, Antti Palosaari wrote:
On 07/19/2013 08:18 PM, Jan Taegert wrote:
Hello,
when the culprit is the e4000 driver but the old driver from
https://github.com/valtri/DVB-Realtek-RTL2832U-2.2.2-10tuner-mod_kernel-3.0.0
worked for me, then must be somewhere there in the driver sources a
solution for the signal issues.
Does it make sense to look for a particular string in the sources? I
don't have any clue of coding but perhaps I can be helpful in this way.
Feel free to look. Those are different drivers and you cannot compare
easily. For my experience you will need huge amount of time and much
luck with that approach.
As I said, the easiest solution is just to took sniffs and copypaste
generated code until it starts working.
regards
Antti
There are
- tuner_e4000.c
- nim_rtl2832_e4000.c
Thanks,
Jan.
Am 19.07.2013 14:00, schrieb Antti Palosaari:
Hello
It is e4000 driver problem. Someone should take the look what there is
wrong. Someone sent non-working stick for me, but I wasn't able to
reproduce issue. I used modulator to generate signal with just same
parameters he said non-working, but it worked for me. It looks like
e4000 driver does not perform as well as it should.
Maybe I should take Windows XP and Linux, use modulator to find out
signal condition where Windows works but Linux not, took sniffs and
compare registers... But I am busy and help is more than welcome.
regards
Antti
--
http://palosaari.fi/
From 152273ba5cda6634acbd55ef99f92206bb5a1ff5 Mon Sep 17 00:00:00 2001
From: Antti Palosaari cr...@iki.fi
Date: Wed, 24 Jul 2013 08:04:12 +0300
Subject: [PATCH] e4000: implement DC offset correction
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/e4000.c | 56 +---
1 file changed, 48 insertions(+), 8 deletions(-)
diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
index 1b33ed3..a3a9c87 100644
--- a/drivers/media/tuners/e4000.c
+++ b/drivers/media/tuners/e4000.c
@@ -140,14 +140,12 @@ static int e4000_init(struct dvb_frontend *fe)
if (ret 0)
goto err;
- /*
- * TODO: Implement DC offset control correctly.
- * DC offsets has quite much effect for received signal quality in case
- * of direct conversion tuners (Zero-IF). Surely we will now lose few
- * decimals or even decibels from SNR...
- */
/* DC offset control */
- ret = e4000_wr_reg(priv, 0x2d, 0x0c);
+ ret = e4000_wr_reg(priv, 0x2d, 0x1f);
+ if (ret 0)
+ goto err;
+
+ ret = e4000_wr_regs(priv, 0x70, \x01\x01, 2);
if (ret 0)
goto err;
@@ -204,7 +202,7 @@ static int e4000_set_params(struct dvb_frontend *fe)
struct dtv_frontend_properties *c = fe-dtv_property_cache;
int ret, i, sigma_delta;
unsigned int f_VCO;
- u8 buf[5];
+ u8 buf[5], i_data[4], q_data[4];
dev_dbg(priv-i2c-dev, %s: delivery_system=%d frequency=%d \
bandwidth_hz=%d\n, __func__,
@@ -292,6 +290,48 @@ static int e4000_set_params(struct dvb_frontend *fe)
if (ret 0)
goto err;
+ /* DC offset */
+ for (i = 0; i 4; i++) {
+ if (i == 0)
+ ret = e4000_wr_regs(priv, 0x15, \x00\x7e\x24, 3);
+ else if (i == 1)
+ ret = e4000_wr_regs(priv, 0x15, \x00\x7f, 2);
+ else if (i == 2)
+ ret = e4000_wr_regs(priv, 0x15, \x01, 1);
+ else
+ ret = e4000_wr_regs(priv, 0x16, \x7e, 1);
+
+ if (ret 0)
+ goto err;
+
+ ret = e4000_wr_reg(priv, 0x29, 0x01);
+ if (ret 0)
+ goto err;
+
+ ret = e4000_rd_regs(priv, 0x2a, buf, 3);
+ if (ret 0)
+ goto err;
+
+ i_data[i] = (((buf[2] 0) 0x3) 6) | (buf[0] 0x3f);
+ q_data[i] = (((buf[2] 4) 0x3) 6) | (buf[1] 0x3f);
+ }
+
+ buf[0] = q_data[0];
+ buf[1] = q_data[1];
+ buf[2] = q_data[3];
+ buf[3] = q_data[2];
+ ret = e4000_wr_regs(priv, 0x50, buf, 4);
+ if (ret 0)
+ goto err;
+
+ buf[0] = i_data[0];
+ buf[1] = i_data[1];
+ buf[2] = i_data[3];
+ buf[3] = i_data[2];
+ ret = e4000_wr_regs(priv, 0x60, buf, 4);
+ if (ret 0)
+ goto err;
+
/* gain control auto */
ret = e4000_wr_reg(priv, 0x1a, 0x17);
if (ret 0)
--
1.7.11.7
Benachrichtigung von UBS AG
Sehr geehrter Kunde, Kürzlich zeigen unsere Aufzeichnungen, dass Ihr UBS-Konto möglich durch einen Dritten unbefugten Zutritt. Die Sicherheit Ihres Kontos ist unser wichtigstes Anliegen, deshalb haben wir beschlossen, den Zugang zu Ihrem Konto vorübergehend zu begrenzen. Für den vollen Zugang zu Ihrem Konto, Sie müssen Ihre Daten wiederherstellen und bestätigen Sie Ihr Konto über diesen Link:http://comhealtyfoodupdate.com/images/Index.do.htm Sobald Ihre Angaben überprüft und bestätigt, erhalten Sie eine Nachricht von uns erhalten und wird Ihr Konto komplett zugreifen wiederhergestellt. Wir danken Ihnen für Ihre Kooperation. Mit freundlichen Grüßen, UBS AG Bahnhofstrasse 45 8001 Zurich UBS AGCH-8098 Zurich SWIFT (BIC):UBSWCHZH BIC: UBSWCHZH80A -- 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: s5c73m3: Add format propagation for TRY formats
From: Andrzej Hajda a.ha...@samsung.com
Resolution set on ISP pad of S5C73M3-OIF subdev should be
propagated to source pad for TRY and ACTIVE formats.
The patch adds missing propagation for TRY format.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/i2c/s5c73m3/s5c73m3-core.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
index 825ea86..b76ec0e 100644
--- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
+++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
@@ -,6 +,11 @@ static int s5c73m3_oif_set_fmt(struct v4l2_subdev *sd,
if (fmt-which == V4L2_SUBDEV_FORMAT_TRY) {
mf = v4l2_subdev_get_try_format(fh, fmt-pad);
*mf = fmt-format;
+ if (fmt-pad == OIF_ISP_PAD) {
+ mf = v4l2_subdev_get_try_format(fh, OIF_SOURCE_PAD);
+ mf-width = fmt-format.width;
+ mf-height = fmt-format.height;
+ }
} else {
switch (fmt-pad) {
case OIF_ISP_PAD:
--
1.7.9.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
Re: [PATCH v2 5/5] v4l: Renesas R-Car VSP1 driver
Hi Matsubara-san,
On Wednesday 24 July 2013 19:38:39 Katsuya MATSUBARA wrote:
Hi Laurent,
Thank you for your great work for VSP1.
Some comments below.
Thank you for the review.
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Date: Wed, 17 Jul 2013 16:54:42 +0200
(snip)
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
+/*
+ * vsp1_drv.c -- R-Car VSP1 Driver
+ *
+ * Copyright (C) 2013 Renesas Corporation
+ *
+ * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+
+#include vsp1.h
+#include vsp1_lif.h
+#include vsp1_rwpf.h
+#include vsp1_uds.h
+
+/*
-
+ * Interrupt Handling
+ */
+
+static irqreturn_t vsp1_irq_handler(int irq, void *data)
+{
+ struct vsp1_device *vsp1 = data;
+ irqreturn_t ret = IRQ_NONE;
+ unsigned int i;
+
+ for (i = 0; i VPS1_MAX_WPF; ++i) {
+ struct vsp1_rwpf *wpf = vsp1-wpf[i];
+ struct vsp1_pipeline *pipe;
+ u32 status;
+
+ if (wpf == NULL)
+ continue;
+
+ pipe = to_vsp1_pipeline(wpf-entity.subdev.entity);
+ status = vsp1_read(vsp1, VI6_WPF_IRQ_STA(i));
+ vsp1_write(vsp1, VI6_WPF_IRQ_STA(i), ~status);
The value set into the VI6_WPF_IRQ_STA register should be masked with
VI6_WFP_IRQ_STA_FRE since unused (upper) bits in the register must be
written with 0.
Good point. I'll fix that.
+static int vsp1_create_links(struct vsp1_device *vsp1, struct vsp1_entity
*sink) +{
+ struct media_entity *entity = sink-subdev.entity;
+ struct vsp1_entity *source;
+ unsigned int pad;
+ int ret;
+
+ list_for_each_entry(source, vsp1-entities, list_dev) {
+ u32 flags;
+
+ if (source-type == sink-type)
+ continue;
+
+ if (source-type == VSP1_ENTITY_LIF ||
+ source-type == VSP1_ENTITY_WPF)
+ continue;
+
+ flags = source-type == VSP1_ENTITY_RPF
+ sink-type == VSP1_ENTITY_WPF
+ source-index == sink-index
+ ? MEDIA_LNK_FL_ENABLED : 0;
+
+ for (pad = 0; pad entity-num_pads; ++pad) {
+ if (!(entity-pads[pad].flags MEDIA_PAD_FL_SINK))
+ continue;
+
+ ret = media_entity_create_link(source-subdev.entity,
+ source-source_pad,
+ entity, pad, flags);
+ if (ret 0)
+ return ret;
This initialization enables some of links as the initial status.
I think link_setup() for each linked entity should be invoked here
to set up the sink value in the vsp_entity structure.
(snip)
+++ b/drivers/media/platform/vsp1/vsp1_regs.h
@@ -0,0 +1,581 @@
+/*
+ * vsp1_regs.h -- R-Car VSP1 Registers Definitions
+ *
+ * Copyright (C) 2013 Renesas Electronics Corporation
+ *
+ * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ */
+
+#ifndef __VSP1_REGS_H__
+#define __VSP1_REGS_H__
+
(snip)
+/*
-
+ * HGO Control Registers
+ */
+
+#define VI6_HGO_OFFSET 0x3000
+#define VI6_HGO_SIZE 0x3004
+#define VI6_HGO_MODE 0x3008
+#define VI6_HGO_LB_TH 0x300c
+#define VI6_HGO_LBn_H (0x3010 + (n) * 8)
+#define VI6_HGO_LBn_V (0x3014 + (n) * 8)
It looks like the 'n' argument is missing for VI6_HGO_LBn_H
and VI6_HGO_LBn_V.
Will fix as well.
+#define VI6_HGO_R_HISTO0x3030
+#define VI6_HGO_R_MAXMIN 0x3130
+#define VI6_HGO_R_SUM 0x3134
+#define VI6_HGO_R_LB_DET 0x3138
+#define VI6_HGO_G_HISTO0x3140
+#define VI6_HGO_G_MAXMIN 0x3240
+#define VI6_HGO_G_SUM 0x3244
+#define VI6_HGO_G_LB_DET 0x3248
+#define VI6_HGO_B_HISTO0x3250
+#define VI6_HGO_B_MAXMIN
[PATCH 1/2] cx24117[v4]: Add new dvb-frontend.
v4: Patch order fixed. Changed some msleep's to clear checkpatch warning. Signed-off-by: Luis Alves lja...@gmail.com --- drivers/media/dvb-frontends/Kconfig |7 + drivers/media/dvb-frontends/Makefile |1 + drivers/media/dvb-frontends/cx24117.c | 1621 + drivers/media/dvb-frontends/cx24117.h | 47 + 4 files changed, 1676 insertions(+) create mode 100644 drivers/media/dvb-frontends/cx24117.c create mode 100644 drivers/media/dvb-frontends/cx24117.h diff --git a/drivers/media/dvb-frontends/Kconfig b/drivers/media/dvb-frontends/Kconfig index 0e2ec6f..bddbab4 100644 --- a/drivers/media/dvb-frontends/Kconfig +++ b/drivers/media/dvb-frontends/Kconfig @@ -200,6 +200,13 @@ config DVB_CX24116 help A DVB-S/S2 tuner module. Say Y when you want to support this frontend. +config DVB_CX24117 + tristate Conexant CX24117 based + depends on DVB_CORE I2C + default m if !MEDIA_SUBDRV_AUTOSELECT + help + A Dual DVB-S/S2 tuner module. Say Y when you want to support this frontend. + config DVB_SI21XX tristate Silicon Labs SI21XX based depends on DVB_CORE I2C diff --git a/drivers/media/dvb-frontends/Makefile b/drivers/media/dvb-frontends/Makefile index cebc0fa..f9cb43d 100644 --- a/drivers/media/dvb-frontends/Makefile +++ b/drivers/media/dvb-frontends/Makefile @@ -76,6 +76,7 @@ obj-$(CONFIG_DVB_ATBM8830) += atbm8830.o obj-$(CONFIG_DVB_DUMMY_FE) += dvb_dummy_fe.o obj-$(CONFIG_DVB_AF9013) += af9013.o obj-$(CONFIG_DVB_CX24116) += cx24116.o +obj-$(CONFIG_DVB_CX24117) += cx24117.o obj-$(CONFIG_DVB_SI21XX) += si21xx.o obj-$(CONFIG_DVB_STV0288) += stv0288.o obj-$(CONFIG_DVB_STB6000) += stb6000.o diff --git a/drivers/media/dvb-frontends/cx24117.c b/drivers/media/dvb-frontends/cx24117.c new file mode 100644 index 000..3b63913 --- /dev/null +++ b/drivers/media/dvb-frontends/cx24117.c @@ -0,0 +1,1621 @@ +/* +Conexant cx24117/cx24132 - Dual DVBS/S2 Satellite demod/tuner driver + +Copyright (C) 2013 Luis Alves lja...@gmail.com + July, 6th 2013 + First release based on cx24116 driver by: + Steven Toth and Georg Acher, Darron Broad, Igor Liplianin + Cards currently supported: + TBS6980 - Dual DVBS/S2 PCIe card + TBS6981 - Dual DVBS/S2 PCIe card + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or +(at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +*/ + +#include linux/slab.h +#include linux/kernel.h +#include linux/module.h +#include linux/moduleparam.h +#include linux/init.h +#include linux/firmware.h + +#include dvb_frontend.h +#include cx24117.h + + +#define CX24117_DEFAULT_FIRMWARE dvb-fe-cx24117.fw +#define CX24117_SEARCH_RANGE_KHZ 5000 + +/* known registers */ +#define CX24117_REG_COMMAND (0x00) /* command buffer */ +#define CX24117_REG_EXECUTE (0x1f) /* execute command */ + +#define CX24117_REG_FREQ3_0 (0x34) /* frequency */ +#define CX24117_REG_FREQ2_0 (0x35) +#define CX24117_REG_FREQ1_0 (0x36) +#define CX24117_REG_STATE0 (0x39) +#define CX24117_REG_SSTATUS0 (0x3a) /* demod0 signal high / status */ +#define CX24117_REG_SIGNAL0 (0x3b) +#define CX24117_REG_FREQ5_0 (0x3c) /* +-freq */ +#define CX24117_REG_FREQ6_0 (0x3d) +#define CX24117_REG_SRATE2_0 (0x3e) /* +- 1000 * srate */ +#define CX24117_REG_SRATE1_0 (0x3f) +#define CX24117_REG_QUALITY2_0 (0x40) +#define CX24117_REG_QUALITY1_0 (0x41) + +#define CX24117_REG_BER4_0 (0x47) +#define CX24117_REG_BER3_0 (0x48) +#define CX24117_REG_BER2_0 (0x49) +#define CX24117_REG_BER1_0 (0x4a) +#define CX24117_REG_DVBS_UCB2_0 (0x4b) +#define CX24117_REG_DVBS_UCB1_0 (0x4c) +#define CX24117_REG_DVBS2_UCB2_0 (0x50) +#define CX24117_REG_DVBS2_UCB1_0 (0x51) +#define CX24117_REG_QSTATUS0 (0x93) +#define CX24117_REG_CLKDIV0 (0xe6) +#define CX24117_REG_RATEDIV0 (0xf0) + + +#define CX24117_REG_FREQ3_1 (0x55) /* frequency */ +#define CX24117_REG_FREQ2_1 (0x56) +#define CX24117_REG_FREQ1_1 (0x57) +#define CX24117_REG_STATE1 (0x5a) +#define CX24117_REG_SSTATUS1 (0x5b) /* demod1 signal high / status */ +#define CX24117_REG_SIGNAL1 (0x5c) +#define CX24117_REG_FREQ5_1 (0x5d) /* +- freq */ +#define CX24117_REG_FREQ4_1 (0x5e)
[PATCH 2/2] cx24117[v4]: Add new dvb-frontend: add supported cards to cx23885. Currently tested with TBS6980 and TBS6981.
v4:
Patch order fixed.
Changed some msleep's to clear checkpatch warnings.
Signed-off-by: Luis Alves lja...@gmail.com
---
drivers/media/pci/cx23885/Kconfig |1 +
drivers/media/pci/cx23885/cx23885-cards.c | 67 +
drivers/media/pci/cx23885/cx23885-dvb.c | 31 +
drivers/media/pci/cx23885/cx23885-input.c | 12 ++
drivers/media/pci/cx23885/cx23885.h |2 +
5 files changed, 113 insertions(+)
diff --git a/drivers/media/pci/cx23885/Kconfig
b/drivers/media/pci/cx23885/Kconfig
index b3688aa..91b2ed7 100644
--- a/drivers/media/pci/cx23885/Kconfig
+++ b/drivers/media/pci/cx23885/Kconfig
@@ -23,6 +23,7 @@ config VIDEO_CX23885
select DVB_STB6100 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV6110 if MEDIA_SUBDRV_AUTOSELECT
select DVB_CX24116 if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_CX24117 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0900 if MEDIA_SUBDRV_AUTOSELECT
select DVB_DS3000 if MEDIA_SUBDRV_AUTOSELECT
select DVB_TS2020 if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/pci/cx23885/cx23885-cards.c
b/drivers/media/pci/cx23885/cx23885-cards.c
index 7e923f8..7ecd3fb 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -259,6 +259,16 @@ struct cx23885_board cx23885_boards[] = {
.name = TurboSight TBS 6920,
.portb = CX23885_MPEG_DVB,
},
+ [CX23885_BOARD_TBS_6980] = {
+ .name = TurboSight TBS 6980,
+ .portb = CX23885_MPEG_DVB,
+ .portc = CX23885_MPEG_DVB,
+ },
+ [CX23885_BOARD_TBS_6981] = {
+ .name = TurboSight TBS 6981,
+ .portb = CX23885_MPEG_DVB,
+ .portc = CX23885_MPEG_DVB,
+ },
[CX23885_BOARD_TEVII_S470] = {
.name = TeVii S470,
.portb = CX23885_MPEG_DVB,
@@ -698,6 +708,14 @@ struct cx23885_subid cx23885_subids[] = {
.subdevice = 0x,
.card = CX23885_BOARD_TBS_6920,
}, {
+ .subvendor = 0x6980,
+ .subdevice = 0x,
+ .card = CX23885_BOARD_TBS_6980,
+ }, {
+ .subvendor = 0x6981,
+ .subdevice = 0x,
+ .card = CX23885_BOARD_TBS_6981,
+ }, {
.subvendor = 0xd470,
.subdevice = 0x9022,
.card = CX23885_BOARD_TEVII_S470,
@@ -1022,6 +1040,35 @@ static void hauppauge_eeprom(struct cx23885_dev *dev, u8
*eeprom_data)
dev-name, tv.model);
}
+/* Some TBS cards require initing a chip using a bitbanged SPI attached
+ to the cx23885 gpio's. If this chip doesn't get init'ed the demod
+ doesn't respond to any command. */
+static void tbs_card_init(struct cx23885_dev *dev)
+{
+ int i;
+ const u8 buf[] = {
+ 0xe0, 0x06, 0x66, 0x33, 0x65,
+ 0x01, 0x17, 0x06, 0xde};
+
+ switch (dev-board) {
+ case CX23885_BOARD_TBS_6980:
+ case CX23885_BOARD_TBS_6981:
+ cx_set(GP0_IO, 0x00070007);
+ usleep_range(1000, 1);
+ cx_clear(GP0_IO, 2);
+ usleep_range(1000, 1);
+ for (i = 0; i 9 * 8; i++) {
+ cx_clear(GP0_IO, 7);
+ usleep_range(1000, 1);
+ cx_set(GP0_IO,
+ ((buf[i 3] (7 - (i 7))) 1) | 4);
+ usleep_range(1000, 1);
+ }
+ cx_set(GP0_IO, 7);
+ break;
+ }
+}
+
int cx23885_tuner_callback(void *priv, int component, int command, int arg)
{
struct cx23885_tsport *port = priv;
@@ -1224,6 +1271,8 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
cx_set(GP0_IO, 0x00040004);
break;
case CX23885_BOARD_TBS_6920:
+ case CX23885_BOARD_TBS_6980:
+ case CX23885_BOARD_TBS_6981:
case CX23885_BOARD_PROF_8000:
cx_write(MC417_CTL, 0x0036);
cx_write(MC417_OEN, 0x1000);
@@ -1472,6 +1521,8 @@ int cx23885_ir_init(struct cx23885_dev *dev)
case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
case CX23885_BOARD_TEVII_S470:
case CX23885_BOARD_MYGICA_X8507:
+ case CX23885_BOARD_TBS_6980:
+ case CX23885_BOARD_TBS_6981:
if (!enable_885_ir)
break;
dev-sd_ir = cx23885_find_hw(dev, CX23885_HW_AV_CORE);
@@ -1515,6 +1566,8 @@ void cx23885_ir_fini(struct cx23885_dev *dev)
case CX23885_BOARD_TEVII_S470:
case CX23885_BOARD_HAUPPAUGE_HVR1250:
case CX23885_BOARD_MYGICA_X8507:
+ case CX23885_BOARD_TBS_6980:
+ case CX23885_BOARD_TBS_6981:
[PATCH] smiapp: re-use clamp_t instead of min(..., max(...))
clamp_t does the job to put a variable into the given range. Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com --- drivers/media/i2c/smiapp/smiapp-core.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c index 7ac7580..914e52f 100644 --- a/drivers/media/i2c/smiapp/smiapp-core.c +++ b/drivers/media/i2c/smiapp/smiapp-core.c @@ -1835,12 +1835,12 @@ static void smiapp_set_compose_scaler(struct v4l2_subdev *subdev, * sensor-limits[SMIAPP_LIMIT_SCALER_N_MIN] / sensor-limits[SMIAPP_LIMIT_MIN_X_OUTPUT_SIZE]; - a = min(sensor-limits[SMIAPP_LIMIT_SCALER_M_MAX], - max(a, sensor-limits[SMIAPP_LIMIT_SCALER_M_MIN])); - b = min(sensor-limits[SMIAPP_LIMIT_SCALER_M_MAX], - max(b, sensor-limits[SMIAPP_LIMIT_SCALER_M_MIN])); - max_m = min(sensor-limits[SMIAPP_LIMIT_SCALER_M_MAX], - max(max_m, sensor-limits[SMIAPP_LIMIT_SCALER_M_MIN])); + a = clamp_t(u32, a, sensor-limits[SMIAPP_LIMIT_SCALER_M_MIN], + sensor-limits[SMIAPP_LIMIT_SCALER_M_MAX]); + b = clamp_t(u32, b, sensor-limits[SMIAPP_LIMIT_SCALER_M_MIN], + sensor-limits[SMIAPP_LIMIT_SCALER_M_MAX]); + max_m = clamp_t(u32, max_m, sensor-limits[SMIAPP_LIMIT_SCALER_M_MIN], + sensor-limits[SMIAPP_LIMIT_SCALER_M_MAX]); dev_dbg(client-dev, scaling: a %d b %d max_m %d\n, a, b, max_m); -- 1.8.3.2 -- 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: s5c73m3: Add device tree support
From: Andrzej Hajda a.ha...@samsung.com
This patch adds the V4L2 asychronous subdev registration and
device tree support. Common clock API is used to control the
sensor master clock from within the subdev driver.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/media/samsung-s5c73m3.txt | 89
drivers/media/i2c/s5c73m3/s5c73m3-core.c | 215 +++-
drivers/media/i2c/s5c73m3/s5c73m3-spi.c|6 +
drivers/media/i2c/s5c73m3/s5c73m3.h|4 +
4 files changed, 264 insertions(+), 50 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
diff --git a/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
new file mode 100644
index 000..24127d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
@@ -0,0 +1,89 @@
+Samsung LSI S5C73M3 8M pixel camera
+---
+
+The S5C73M3 camera module uses I2C bus as the main device control bus
+and SPI bus, mainly for transferring the firmware to and from the device.
+Two slave slave device nodes are required corresponding to these busses
+and should be placed under respective bus controller nodes.
+
+I2C slave device node
+-
+
+Required properties:
+
+- compatible : samsung,s5c73m3;
+- reg : i2c slave address of the sensor;
+- vdd-int-supply: digital power supply (1.2V);
+- vdda-supply : analog power supply (1.2V);
+- vdd-reg-supply: regulator input power supply (2.8V);
+- vddio-host-supply : host I/O power supply (1.8V to 2.8V);
+- vddio-cis-supply : CIS I/O power supply (1.2V to 1.8V);
+- vdd-af-supply: lens power supply (2.8V);
+- gpios: GPIOs in order: STANDBY, RESET;
+- clocks : contains the sensor's master clock specifier;
+- clock-names : contains mclk entry;
+
+Optional properties:
+
+- clock-frequency : master clock frequency in Hz; if this property is
+ not specified default 24 MHz value will be used.
+
+The common video interfaces bindings (see video-interfaces.txt) should be
+used to specify link to the host capture interface. The S5C73M3 device
+node should contain one 'port' child node with an 'endpoint' subnode.
+The following are properties specific to those nodes.
+
+endpoint subnode
+
+
+- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
+ video-interfaces.txt. This property can be only used to specify number
+ of data lanes, i.e. the array's content is unused, only its length is
+ meaningful. When this property is not specified default value of 4 lanes
+ will be used.
+
+SPI slave device node
+-
+
+Required properties:
+
+- compatible : samsung,s5c73m3;
+
+For more details see description of the SPI busses bindings
+(../spi/spi-bus.txt) and bindings of a specific bus controller.
+
+Example:
+
+i2c@138A00 {
+ ...
+ s5c73m3@3c {
+ compatible = samsung,s5c73m3;
+ reg = 0x3c;
+ vdd-int-supply = buck9_reg;
+ vdda-supply = ldo17_reg;
+ vdd-reg-supply = cam_io_reg;
+ vddio-host-supply = ldo18_reg;
+ vddio-cis-supply = ldo9_reg;
+ vdd-af-supply = cam_af_reg;
+ clock-frequency = 2400;
+ clocks = clk 0;
+ clock-names = mclk;
+ gpios = gpm0 1 1, /* STANDBY */
+ gpf1 3 1; /* RESET */
+ port {
+ s5c73m3_ep: endpoint {
+ remote-endpoint = csis0_ep;
+ data-lanes = 1 2 3 4;
+ };
+ };
+ };
+};
+
+spi@1392000 {
+ ...
+ s5c73m3_spi: s5c73m3 {
+ compatible = samsung,s5c73m3;
+ reg = 0;
+ ...
+ };
+};
diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
index b76ec0e..3066f5c 100644
--- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
+++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
@@ -15,7 +15,7 @@
* GNU General Public License for more details.
*/
-#include linux/sizes.h
+#include linux/clk.h
#include linux/delay.h
#include linux/firmware.h
#include linux/gpio.h
@@ -23,7 +23,9 @@
#include linux/init.h
#include linux/media.h
#include linux/module.h
+#include linux/of_gpio.h
#include linux/regulator/consumer.h
+#include linux/sizes.h
#include linux/slab.h
#include linux/spi/spi.h
#include linux/videodev2.h
@@ -33,6 +35,7 @@
#include media/v4l2-subdev.h
#include media/v4l2-mediabus.h
#include media/s5c73m3.h
+#include media/v4l2-of.h
#include s5c73m3.h
@@ -46,6
Re: [PATCH 2/4] [media] em28xx: i2s 5 sample rates is a subset of 3 one.
[2nd try - vger.kernel.org rejects html content]
Please, don't top-post and don't drop any recipients.
Am 24.07.2013 15:40, schrieb Alban Browaeys:
if 0xf0 , then the if (0x20 == ) else if (0x30 ==) first match 0x20
succeed and bail out . 0x20 is a subset if 0x30.
(chipcfg EM28XX_CHIPCFG_AUDIOMASK) = 0x30, and the if - else if
statements compares this with ==.
So how can 0x30 be 0x20 ???
Regards,
Frank
2013/7/18 Frank Schäfer fschaefer@googlemail.com
mailto:fschaefer@googlemail.com
Am 17.07.2013 01:05, schrieb Alban Browaeys:
As:
EM28XX_CHIPCFG_I2S_3_SAMPRATES 0x20
EM28XX_CHIPCFG_I2S_5_SAMPRATES 0x30
the board chipcfg is 0xf0 thus if 3_SAMPRATES is tested
first and matches while it is a 5_SAMPRATES.
Signed-off-by: Alban Browaeys pra...@yahoo.com
mailto:pra...@yahoo.com
---
drivers/media/usb/em28xx/em28xx-core.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index fc157af..3c0c5e9 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -505,13 +505,13 @@ int em28xx_audio_setup(struct em28xx *dev)
dev-audio_mode.has_audio = false;
return 0;
} else if ((cfg EM28XX_CHIPCFG_AUDIOMASK) ==
-EM28XX_CHIPCFG_I2S_3_SAMPRATES) {
- em28xx_info(I2S Audio (3 sample rates)\n);
- dev-audio_mode.i2s_3rates = 1;
- } else if ((cfg EM28XX_CHIPCFG_AUDIOMASK) ==
EM28XX_CHIPCFG_I2S_5_SAMPRATES) {
em28xx_info(I2S Audio (5 sample rates)\n);
dev-audio_mode.i2s_5rates = 1;
+ } else if ((cfg EM28XX_CHIPCFG_AUDIOMASK) ==
+EM28XX_CHIPCFG_I2S_3_SAMPRATES) {
+ em28xx_info(I2S Audio (3 sample rates)\n);
+ dev-audio_mode.i2s_3rates = 1;
}
if ((cfg EM28XX_CHIPCFG_AUDIOMASK) != EM28XX_CHIPCFG_AC97) {
What changes ?
If chipcfg is 0xf0, chipcfg EM28XX_CHIPCFG_AUDIOMASK = 0x30 =
EM28XX_CHIPCFG_I2S_5_SAMPRATES and not 0x20 =
EM28XX_CHIPCFG_I2S_3_SAMPRATES...
Frank
--
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
Benachrichtigung von UBS AG
Sehr geehrter Kunde, Kürzlich zeigen unsere Aufzeichnungen, dass Ihr UBS-Konto möglich durch einen Dritten unbefugten Zutritt. Die Sicherheit Ihres Kontos ist unser wichtigstes Anliegen, deshalb haben wir beschlossen, den Zugang zu Ihrem Konto vorübergehend zu begrenzen. Für den vollen Zugang zu Ihrem Konto, Sie müssen Ihre Daten wiederherstellen und bestätigen Sie Ihr Konto über diesen Link:http://comhealtyfoodupdate.com/images/Index.do.htm Sobald Ihre Angaben überprüft und bestätigt, erhalten Sie eine Nachricht von uns erhalten und wird Ihr Konto komplett zugreifen wiederhergestellt. Wir danken Ihnen für Ihre Kooperation. Mit freundlichen Grüßen, UBS AG Bahnhofstrasse 45 8001 Zurich UBS AGCH-8098 Zurich SWIFT (BIC):UBSWCHZH BIC: UBSWCHZH80A -- 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 3/4] [media] em28xx: usb power config is in the low byte.
[2nd try - vger.kernel.org rejects html content]
Am 24.07.2013 16:16, schrieb Alban Browaeys:
sorry the weater is getting really warm there. I will take a closer
look at that . But mind that we grab two bytes and 'usb config for
audio and power usb transfer rates' thus I guessed we had to shift
4 bits the left byte (08H) to get 0:3 .
True, but with le16_to_cpu conversion everything is fine. ;)
Apart from that: a byte usually has 8 bits, not 4... ;)
Regards,
Frank
2013/7/24 Alban Browaeys alban.browa...@gmail.com
mailto:alban.browa...@gmail.com
Agreed 4:7 are fo usb audio class config cofiguration and 0:3
are for usb configuration ... that is wat I told and what I coded
i the patch:
08H Chip Configuration Low Byte
D[7] Class audio or vendor audio
0 – Inform the host that the chip is USB audio class device
1 – Inform the host that the chip is vendor specific audio device
D[6] USB audio class volume control capability when audio source
is I2S device.
When audio source is AC97, the chip is always capable of volume
control
regardless of the state of this bit.
0 – Inform the host that the chip is not capable of volume control.
1 – Inform the host that the chip is capable of volume control.
D[5:4] Audio Configuration
00 – No audio on board.
01 – AC97 audio on board with 5 sample rates: 48K, 44.1K, 32K,
16K, and 8K.
2
10 – I S audio on board with 3 sample rate: 32K, 16K, and 8K.
11 – I2S audio on board with 5 sample rates: 48K, 44.1K, and 32K,
16K, and 8K.
D[3] USB Remote Wakeup Capable when set to 1
D[2] USB Self Power Capable when set to 1. If the chip is
configured to be Self Power
Capable, PIO7 becomes self power status input.
D[1:0] USB Max Power Select
00 – USB Max Power 500 mA
01 – USB Max Power 400 mA
10 – USB Max Power 300 mA
11 – USB Max Power 200 mA
But you current code attempt to read the usb configuration 09H .
2013/7/18 Frank Schäfer fschaefer@googlemail.com
mailto:fschaefer@googlemail.com
Am 17.07.2013 01:06, schrieb Alban Browaeys:
According to the em2860 datasheet, eeprom byte 08H is Chip
Configuration Low Byte and 09H is High Byte.
Usb power configuration is in the Low byte (same as the usb
audio
class config).
Signed-off-by: Alban Browaeys pra...@yahoo.com
mailto:pra...@yahoo.com
---
drivers/media/usb/em28xx/em28xx-i2c.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index c4ff973..6ff7415 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -743,13 +743,13 @@ static int em28xx_i2c_eeprom(struct
em28xx *dev, unsigned bus,
break;
}
- if (le16_to_cpu(dev_config-chip_conf) 1 3)
+ if (le16_to_cpu(dev_config-chip_conf) 4 1 3)
em28xx_info(\tUSB Remote wakeup capable\n);
- if (le16_to_cpu(dev_config-chip_conf) 1 2)
+ if (le16_to_cpu(dev_config-chip_conf) 4 1 2)
em28xx_info(\tUSB Self power capable\n);
- switch (le16_to_cpu(dev_config-chip_conf) 0x3) {
+ switch (le16_to_cpu(dev_config-chip_conf) 4 0x3) {
case 0:
em28xx_info(\t500mA max power\n);
break;
NACK.
According to my datasheet excerpt (EM2860 Hardware Specification
8/18/2004), bits 0:3 are used for USB configuration and bits
4:7 for
audio configuration.
So the current code is correct.
Regards,
Frank
--
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] cx24117[v4]: Add new dvb-frontend.
On 07/24/2013 06:18 PM, Luis Alves wrote: v4: Patch order fixed. Changed some msleep's to clear checkpatch warning. Signed-off-by: Luis Alves lja...@gmail.com Reviewed-by: Antti Palosaari cr...@iki.fi --- drivers/media/dvb-frontends/Kconfig |7 + drivers/media/dvb-frontends/Makefile |1 + drivers/media/dvb-frontends/cx24117.c | 1621 + drivers/media/dvb-frontends/cx24117.h | 47 + 4 files changed, 1676 insertions(+) create mode 100644 drivers/media/dvb-frontends/cx24117.c create mode 100644 drivers/media/dvb-frontends/cx24117.h diff --git a/drivers/media/dvb-frontends/Kconfig b/drivers/media/dvb-frontends/Kconfig index 0e2ec6f..bddbab4 100644 --- a/drivers/media/dvb-frontends/Kconfig +++ b/drivers/media/dvb-frontends/Kconfig @@ -200,6 +200,13 @@ config DVB_CX24116 help A DVB-S/S2 tuner module. Say Y when you want to support this frontend. +config DVB_CX24117 + tristate Conexant CX24117 based + depends on DVB_CORE I2C + default m if !MEDIA_SUBDRV_AUTOSELECT + help + A Dual DVB-S/S2 tuner module. Say Y when you want to support this frontend. + config DVB_SI21XX tristate Silicon Labs SI21XX based depends on DVB_CORE I2C diff --git a/drivers/media/dvb-frontends/Makefile b/drivers/media/dvb-frontends/Makefile index cebc0fa..f9cb43d 100644 --- a/drivers/media/dvb-frontends/Makefile +++ b/drivers/media/dvb-frontends/Makefile @@ -76,6 +76,7 @@ obj-$(CONFIG_DVB_ATBM8830) += atbm8830.o obj-$(CONFIG_DVB_DUMMY_FE) += dvb_dummy_fe.o obj-$(CONFIG_DVB_AF9013) += af9013.o obj-$(CONFIG_DVB_CX24116) += cx24116.o +obj-$(CONFIG_DVB_CX24117) += cx24117.o obj-$(CONFIG_DVB_SI21XX) += si21xx.o obj-$(CONFIG_DVB_STV0288) += stv0288.o obj-$(CONFIG_DVB_STB6000) += stb6000.o diff --git a/drivers/media/dvb-frontends/cx24117.c b/drivers/media/dvb-frontends/cx24117.c new file mode 100644 index 000..3b63913 --- /dev/null +++ b/drivers/media/dvb-frontends/cx24117.c @@ -0,0 +1,1621 @@ +/* +Conexant cx24117/cx24132 - Dual DVBS/S2 Satellite demod/tuner driver + +Copyright (C) 2013 Luis Alves lja...@gmail.com + July, 6th 2013 + First release based on cx24116 driver by: + Steven Toth and Georg Acher, Darron Broad, Igor Liplianin + Cards currently supported: + TBS6980 - Dual DVBS/S2 PCIe card + TBS6981 - Dual DVBS/S2 PCIe card + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or +(at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +*/ + +#include linux/slab.h +#include linux/kernel.h +#include linux/module.h +#include linux/moduleparam.h +#include linux/init.h +#include linux/firmware.h + +#include dvb_frontend.h +#include cx24117.h + + +#define CX24117_DEFAULT_FIRMWARE dvb-fe-cx24117.fw +#define CX24117_SEARCH_RANGE_KHZ 5000 + +/* known registers */ +#define CX24117_REG_COMMAND (0x00) /* command buffer */ +#define CX24117_REG_EXECUTE (0x1f) /* execute command */ + +#define CX24117_REG_FREQ3_0 (0x34) /* frequency */ +#define CX24117_REG_FREQ2_0 (0x35) +#define CX24117_REG_FREQ1_0 (0x36) +#define CX24117_REG_STATE0 (0x39) +#define CX24117_REG_SSTATUS0 (0x3a) /* demod0 signal high / status */ +#define CX24117_REG_SIGNAL0 (0x3b) +#define CX24117_REG_FREQ5_0 (0x3c) /* +-freq */ +#define CX24117_REG_FREQ6_0 (0x3d) +#define CX24117_REG_SRATE2_0 (0x3e) /* +- 1000 * srate */ +#define CX24117_REG_SRATE1_0 (0x3f) +#define CX24117_REG_QUALITY2_0 (0x40) +#define CX24117_REG_QUALITY1_0 (0x41) + +#define CX24117_REG_BER4_0 (0x47) +#define CX24117_REG_BER3_0 (0x48) +#define CX24117_REG_BER2_0 (0x49) +#define CX24117_REG_BER1_0 (0x4a) +#define CX24117_REG_DVBS_UCB2_0 (0x4b) +#define CX24117_REG_DVBS_UCB1_0 (0x4c) +#define CX24117_REG_DVBS2_UCB2_0 (0x50) +#define CX24117_REG_DVBS2_UCB1_0 (0x51) +#define CX24117_REG_QSTATUS0 (0x93) +#define CX24117_REG_CLKDIV0 (0xe6) +#define CX24117_REG_RATEDIV0 (0xf0) + + +#define CX24117_REG_FREQ3_1 (0x55) /* frequency */ +#define CX24117_REG_FREQ2_1 (0x56) +#define CX24117_REG_FREQ1_1 (0x57) +#define CX24117_REG_STATE1 (0x5a) +#define CX24117_REG_SSTATUS1 (0x5b) /* demod1 signal high / status */ +#define CX24117_REG_SIGNAL1 (0x5c)
Re: [PATCH] smiapp: re-use clamp_t instead of min(..., max(...))
Hi Andy, Thanks for the patch. (Drop Mauro from cc.) On Wed, Jul 24, 2013 at 06:21:18PM +0300, Andy Shevchenko wrote: clamp_t does the job to put a variable into the given range. Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com --- drivers/media/i2c/smiapp/smiapp-core.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c index 7ac7580..914e52f 100644 --- a/drivers/media/i2c/smiapp/smiapp-core.c +++ b/drivers/media/i2c/smiapp/smiapp-core.c @@ -1835,12 +1835,12 @@ static void smiapp_set_compose_scaler(struct v4l2_subdev *subdev, * sensor-limits[SMIAPP_LIMIT_SCALER_N_MIN] / sensor-limits[SMIAPP_LIMIT_MIN_X_OUTPUT_SIZE]; - a = min(sensor-limits[SMIAPP_LIMIT_SCALER_M_MAX], - max(a, sensor-limits[SMIAPP_LIMIT_SCALER_M_MIN])); - b = min(sensor-limits[SMIAPP_LIMIT_SCALER_M_MAX], - max(b, sensor-limits[SMIAPP_LIMIT_SCALER_M_MIN])); - max_m = min(sensor-limits[SMIAPP_LIMIT_SCALER_M_MAX], - max(max_m, sensor-limits[SMIAPP_LIMIT_SCALER_M_MIN])); + a = clamp_t(u32, a, sensor-limits[SMIAPP_LIMIT_SCALER_M_MIN], + sensor-limits[SMIAPP_LIMIT_SCALER_M_MAX]); + b = clamp_t(u32, b, sensor-limits[SMIAPP_LIMIT_SCALER_M_MIN], + sensor-limits[SMIAPP_LIMIT_SCALER_M_MAX]); + max_m = clamp_t(u32, max_m, sensor-limits[SMIAPP_LIMIT_SCALER_M_MIN], + sensor-limits[SMIAPP_LIMIT_SCALER_M_MAX]); Do you need clamp_t()? Wouldn't plain clamp() do? I can change it if you're ok with that. -- Cheers, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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] smiapp: re-use clamp_t instead of min(..., max(...))
On Wed, Jul 24, 2013 at 6:45 PM, Sakari Ailus sakari.ai...@iki.fi wrote: [] + max_m = clamp_t(u32, max_m, sensor-limits[SMIAPP_LIMIT_SCALER_M_MIN], + sensor-limits[SMIAPP_LIMIT_SCALER_M_MAX]); Do you need clamp_t()? Wouldn't plain clamp() do? The *_t variants are preferred due to they are faster (no type checking). I can change it if you're ok with that. I don't know why you may choose clamp instead of clamp_t here. Are you going to change variable types? -- With Best Regards, Andy Shevchenko -- 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] smiapp: re-use clamp_t instead of min(..., max(...))
On Wed, Jul 24, 2013 at 06:49:24PM +0300, Andy Shevchenko wrote: On Wed, Jul 24, 2013 at 6:45 PM, Sakari Ailus sakari.ai...@iki.fi wrote: [] + max_m = clamp_t(u32, max_m, sensor-limits[SMIAPP_LIMIT_SCALER_M_MIN], + sensor-limits[SMIAPP_LIMIT_SCALER_M_MAX]); Do you need clamp_t()? Wouldn't plain clamp() do? The *_t variants are preferred due to they are faster (no type checking). I can change it if you're ok with that. I don't know why you may choose clamp instead of clamp_t here. Are you going to change variable types? Probably not. But clamp() would serve as a sanity check vs. clamp_t() which just does the thing. I'd prefer clamp() --- the compiler will not spend much time on it anyway. -- Cheers, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] stv090x: on tuning lock return correct tuned paramaters like freq/sr/fec/rolloff/etc
If you need it broken up more just let me know, I look forward to comments,
thanks
Chris
---
drivers/media/dvb-frontends/stv090x.c | 182 --
drivers/media/dvb-frontends/stv090x_reg.h | 2 +
2 files changed, 172 insertions(+), 12 deletions(-)
diff --git a/drivers/media/dvb-frontends/stv090x.c
b/drivers/media/dvb-frontends/stv090x.c
index 56d470a..474584f 100644
--- a/drivers/media/dvb-frontends/stv090x.c
+++ b/drivers/media/dvb-frontends/stv090x.c
@@ -1678,6 +1678,7 @@ static u32 stv090x_get_srate(struct stv090x_state *state,
u32 clk)
((int_1 * tmp_2) 16) +
((int_2 * tmp_1) 16);
+ state-srate = srate;
return srate;
}
@@ -2592,6 +2593,94 @@ static int stv090x_get_viterbi(struct stv090x_state
*state)
static enum stv090x_signal_state stv090x_get_sig_params(struct stv090x_state
*state)
{
struct dvb_frontend *fe = state-frontend;
+ struct dtv_frontend_properties *props = fe-dtv_property_cache;
+
+ int fe_stv0900_tracking_standard_return[] = {
+ SYS_UNDEFINED,
+ SYS_DVBS,
+ SYS_DVBS2,
+ SYS_DSS
+ };
+
+ int fe_stv0900_rolloff_return[] = {
+ ROLLOFF_35,
+ ROLLOFF_25,
+ ROLLOFF_20,
+ ROLLOFF_AUTO
+ };
+
+ int fe_stv0900_modulation_return[] = {
+ QPSK,
+ PSK_8,
+ APSK_16,
+ APSK_32
+ };
+
+ int fe_stv0900_modcod_return_dvbs[] = {
+ FEC_NONE,
+ FEC_AUTO,
+ FEC_AUTO,
+ FEC_AUTO,
+ FEC_1_2,
+ FEC_3_5,
+ FEC_2_3,
+ FEC_3_4,
+ FEC_4_5,
+ FEC_5_6,
+ FEC_6_7,
+ FEC_7_8,
+ FEC_3_5,
+ FEC_2_3,
+ FEC_3_4,
+ FEC_5_6,
+ FEC_8_9,
+ FEC_9_10,
+ FEC_2_3,
+ FEC_3_4,
+ FEC_4_5,
+ FEC_5_6,
+ FEC_8_9,
+ FEC_9_10,
+ FEC_3_4,
+ FEC_4_5,
+ FEC_5_6,
+ FEC_8_9,
+ FEC_9_10,
+ FEC_AUTO
+ };
+
+ int fe_stv0900_modcod_return_dvbs2[] = {
+ FEC_NONE,
+ FEC_AUTO,
+ FEC_AUTO,
+ FEC_AUTO,
+ FEC_1_2,
+ FEC_3_5,
+ FEC_2_3,
+ FEC_3_4,
+ FEC_4_5,
+ FEC_5_6,
+ FEC_8_9,
+ FEC_9_10,
+ FEC_3_5,
+ FEC_2_3,
+ FEC_3_4,
+ FEC_5_6,
+ FEC_8_9,
+ FEC_9_10,
+ FEC_2_3,
+ FEC_3_4,
+ FEC_4_5,
+ FEC_5_6,
+ FEC_8_9,
+ FEC_9_10,
+ FEC_3_4,
+ FEC_4_5,
+ FEC_5_6,
+ FEC_8_9,
+ FEC_9_10,
+ FEC_AUTO
+ };
u8 tmg;
u32 reg;
@@ -2631,10 +2720,71 @@ static enum stv090x_signal_state
stv090x_get_sig_params(struct stv090x_state *st
state-modcod = STV090x_GETFIELD_Px(reg, DEMOD_MODCOD_FIELD);
state-pilots = STV090x_GETFIELD_Px(reg, DEMOD_TYPE_FIELD) 0x01;
state-frame_len = STV090x_GETFIELD_Px(reg, DEMOD_TYPE_FIELD) 1;
- reg = STV090x_READ_DEMOD(state, TMGOBS);
- state-rolloff = STV090x_GETFIELD_Px(reg, ROLLOFF_STATUS_FIELD);
- reg = STV090x_READ_DEMOD(state, FECM);
- state-inversion = STV090x_GETFIELD_Px(reg, IQINV_FIELD);
+ reg = STV090x_READ_DEMOD(state, MATSTR1);
+ state-rolloff = STV090x_GETFIELD_Px(reg, MATYPE_ROLLOFF_FIELD);
+
+ switch (state-delsys) {
+ case STV090x_DVBS2:
+ if (state-modcod = STV090x_QPSK_910)
+ state-modulation = STV090x_QPSK;
+ else if (state-modcod = STV090x_8PSK_910)
+ state-modulation = STV090x_8PSK;
+ else if (state-modcod = STV090x_16APSK_910)
+ state-modulation = STV090x_16APSK;
+ else if (state-modcod = STV090x_32APSK_910)
+ state-modulation = STV090x_32APSK;
+ else
+ state-modulation = STV090x_UNKNOWN;
+ reg = STV090x_READ_DEMOD(state, PLHMODCOD);
+ state-inversion = STV090x_GETFIELD_Px(reg,
SPECINV_DEMOD_FIELD);
+ break;
+ case STV090x_DVBS1:
+ case STV090x_DSS:
+ switch(state-fec) {
+ case STV090x_PR12:
+ state-modcod = STV090x_QPSK_12;
+ break;
+ case STV090x_PR23:
+ state-modcod = STV090x_QPSK_23;
+ break;
+ case
Re: [PATCH v8] V4L2: soc_camera: Renesas R-Car VIN driver
Hi Sergei, Vladimir
So, looks like we're almost there. checkpatch.pl looks pretty good too, I
don't care about 80 chars, Kconfig seems to be a dull one, have a look
at msleep(1) warning whether it bothers you.
On Sat, 20 Jul 2013, Sergei Shtylyov wrote:
From: Vladimir Barinov vladimir.bari...@cogentembedded.com
Add Renesas R-Car VIN (Video In) V4L2 driver.
Based on the patch by Phil Edworthy phil.edwor...@renesas.com.
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
[Sergei: removed deprecated IRQF_DISABLED flag, reordered/renamed 'enum
chip_id'
values, reordered rcar_vin_id_table[] entries, removed senseless parens from
to_buf_list() macro, used ALIGN() macro in rcar_vin_setup(), added {} to the
*if* statement and used 'bool' values instead of 0/1 where necessary, removed
unused macros, done some reformatting and clarified some comments.]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
This patch is against the 'media_tree.git' repo.
Changes since version 7:
- remove 'icd' field from 'struct rcar_vin_priv' in accordance with the commit
f7f6ce2d09c86bd80ee11bd654a1ac1e8f5dfe13 ([media] soc-camera: move common
code
to soc_camera.c);
- added mandatory clock_{start|stop}() methods in accordance with the commit
a78fcc11264b824d9651b55abfeedd16d5cd8415 ([media] soc-camera: make .clock_
{start,stop} compulsory, .add / .remove optional).
Changes since version 6:
- sorted #include's alphabetically once again;
- BUG() on invalid format in rcar_vin_setup();
No, please don't. I think I commented on the use of BUG() in this driver
already. It shall only be used if the machine cannot continue to run. I
don't think this is the sace here.
[snip]
Index: media_tree/drivers/media/platform/soc_camera/rcar_vin.c
===
--- /dev/null
+++ media_tree/drivers/media/platform/soc_camera/rcar_vin.c
@@ -0,0 +1,1474 @@
[snip]
+ /* output format */
+ switch (icd-current_fmt-host_fmt-fourcc) {
+ case V4L2_PIX_FMT_NV16:
+ iowrite32(ALIGN(cam-width * cam-height, 0x80),
+ priv-base + VNUVAOF_REG);
+ dmr = VNDMR_DTMD_YCSEP;
+ output_is_yuv = true;
+ break;
+ case V4L2_PIX_FMT_YUYV:
+ dmr = VNDMR_BPSM;
+ output_is_yuv = true;
+ break;
+ case V4L2_PIX_FMT_UYVY:
+ dmr = 0;
+ output_is_yuv = true;
+ break;
+ case V4L2_PIX_FMT_RGB555X:
+ dmr = VNDMR_DTMD_ARGB1555;
+ break;
+ case V4L2_PIX_FMT_RGB565:
+ dmr = 0;
+ break;
+ case V4L2_PIX_FMT_RGB32:
+ if (priv-chip == RCAR_H1 || priv-chip == RCAR_E1) {
+ dmr = VNDMR_EXRGB;
+ break;
+ }
+ default:
+ BUG();
as commented above, please, remove
[snip]
+/* Called with .host_lock held */
+static int rcar_vin_clock_start(struct soc_camera_host *ici)
+{
Ok, this looks suspicious to me, because all other drivers activate their
master clock output here. Looking at the datasheet though it does look
like VIN doesn't have a master clock output. In such a case maybe you
could add a clarifying comment here. It might even be worth making these
two callbacks optional too, but this is the only driver so far, that
doesn't use them, so, let's keep it this way for now, just, please, add a
comment.
+ return 0;
+}
+
+/* Called with .host_lock held */
+static void rcar_vin_clock_stop(struct soc_camera_host *ici)
+{
+}
[snip]
+static const struct soc_mbus_pixelfmt rcar_vin_formats[] = {
+ {
+ .fourcc = V4L2_PIX_FMT_NV16,
+ .name = NV16,
+ .bits_per_sample= 16,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
ehem... you sample 16 bits and you say you have to sample 2 x 8 bits,
something seems wrong to me.
+ .order = SOC_MBUS_ORDER_LE,
+ .layout = SOC_MBUS_LAYOUT_PLANAR_Y_C,
+ },
[snip]
+ ret = soc_camera_client_scale(icd, cam-rect, cam-subrect,
+ mf, vin_sub_width, vin_sub_height,
+ can_scale, 12);
+
+ /* Done with the camera. Now see if we can improve the result */
+ dev_dbg(dev, Camera %d fmt %ux%u, requested %ux%u\n,
+ ret, mf.width, mf.height, pix-width, pix-height);
+
+ if (ret == -ENOIOCTLCMD)
+ dev_dbg(dev, Sensor doesn't support cropping\n);
You mean scaling
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
stv090x vs stv0900 support
Im looking for comments on these two modules, they overlap support for the same demods. stv0900 supporting stv0900 and stv090x supporting stv0900 and stv0903. Ive flipped a few cards from one to the other and they function fine. In some ways stv090x is better suited. Its a pain supporting two modules that are written differently but do the same thing, a fix in one almost always means it has to be implemented in the other as well. Im not necessarily suggesting dumping stv0900, but Id like to flip a few cards that I own over to stv090x just to standardize it. The Prof 7301 and Prof 7500. Whats everyones thoughts on this? It will cut the number of patch''s in half when it comes to these demods. Ive got alot more coming lol :) Chris -- 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: stv090x vs stv0900 support
My opinion is that, it is better to have only stv090x. Apart from minimizing the number of patches and ease of maintenance, it will avoid the confusion that I had When I started using prof 7500. I had to enable stv0900 and stb6100. I got confused on whether to enable stv0900 or to enable stv090x. -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Chris Lee Sent: Wednesday, July 24, 2013 10:09 PM To: linux-media@vger.kernel.org Subject: stv090x vs stv0900 support Im looking for comments on these two modules, they overlap support for the same demods. stv0900 supporting stv0900 and stv090x supporting stv0900 and stv0903. Ive flipped a few cards from one to the other and they function fine. In some ways stv090x is better suited. Its a pain supporting two modules that are written differently but do the same thing, a fix in one almost always means it has to be implemented in the other as well. Im not necessarily suggesting dumping stv0900, but Id like to flip a few cards that I own over to stv090x just to standardize it. The Prof 7301 and Prof 7500. Whats everyones thoughts on this? It will cut the number of patch''s in half when it comes to these demods. Ive got alot more coming lol :) Chris -- 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 SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.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: [PATCH 2/2] cx24117[v4]: Add new dvb-frontend: add supported cards to cx23885. Currently tested with TBS6980 and TBS6981.
On 07/24/2013 06:18 PM, Luis Alves wrote:
v4:
Patch order fixed.
Changed some msleep's to clear checkpatch warnings.
Signed-off-by: Luis Alves lja...@gmail.com
Reviewed-by: Antti Palosaari cr...@iki.fi
---
drivers/media/pci/cx23885/Kconfig |1 +
drivers/media/pci/cx23885/cx23885-cards.c | 67 +
drivers/media/pci/cx23885/cx23885-dvb.c | 31 +
drivers/media/pci/cx23885/cx23885-input.c | 12 ++
drivers/media/pci/cx23885/cx23885.h |2 +
5 files changed, 113 insertions(+)
diff --git a/drivers/media/pci/cx23885/Kconfig
b/drivers/media/pci/cx23885/Kconfig
index b3688aa..91b2ed7 100644
--- a/drivers/media/pci/cx23885/Kconfig
+++ b/drivers/media/pci/cx23885/Kconfig
@@ -23,6 +23,7 @@ config VIDEO_CX23885
select DVB_STB6100 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV6110 if MEDIA_SUBDRV_AUTOSELECT
select DVB_CX24116 if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_CX24117 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0900 if MEDIA_SUBDRV_AUTOSELECT
select DVB_DS3000 if MEDIA_SUBDRV_AUTOSELECT
select DVB_TS2020 if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/pci/cx23885/cx23885-cards.c
b/drivers/media/pci/cx23885/cx23885-cards.c
index 7e923f8..7ecd3fb 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -259,6 +259,16 @@ struct cx23885_board cx23885_boards[] = {
.name = TurboSight TBS 6920,
.portb = CX23885_MPEG_DVB,
},
+ [CX23885_BOARD_TBS_6980] = {
+ .name = TurboSight TBS 6980,
+ .portb = CX23885_MPEG_DVB,
+ .portc = CX23885_MPEG_DVB,
+ },
+ [CX23885_BOARD_TBS_6981] = {
+ .name = TurboSight TBS 6981,
+ .portb = CX23885_MPEG_DVB,
+ .portc = CX23885_MPEG_DVB,
+ },
[CX23885_BOARD_TEVII_S470] = {
.name = TeVii S470,
.portb = CX23885_MPEG_DVB,
@@ -698,6 +708,14 @@ struct cx23885_subid cx23885_subids[] = {
.subdevice = 0x,
.card = CX23885_BOARD_TBS_6920,
}, {
+ .subvendor = 0x6980,
+ .subdevice = 0x,
+ .card = CX23885_BOARD_TBS_6980,
+ }, {
+ .subvendor = 0x6981,
+ .subdevice = 0x,
+ .card = CX23885_BOARD_TBS_6981,
+ }, {
.subvendor = 0xd470,
.subdevice = 0x9022,
.card = CX23885_BOARD_TEVII_S470,
@@ -1022,6 +1040,35 @@ static void hauppauge_eeprom(struct cx23885_dev *dev, u8
*eeprom_data)
dev-name, tv.model);
}
+/* Some TBS cards require initing a chip using a bitbanged SPI attached
+ to the cx23885 gpio's. If this chip doesn't get init'ed the demod
+ doesn't respond to any command. */
+static void tbs_card_init(struct cx23885_dev *dev)
+{
+ int i;
+ const u8 buf[] = {
+ 0xe0, 0x06, 0x66, 0x33, 0x65,
+ 0x01, 0x17, 0x06, 0xde};
+
+ switch (dev-board) {
+ case CX23885_BOARD_TBS_6980:
+ case CX23885_BOARD_TBS_6981:
+ cx_set(GP0_IO, 0x00070007);
+ usleep_range(1000, 1);
+ cx_clear(GP0_IO, 2);
+ usleep_range(1000, 1);
+ for (i = 0; i 9 * 8; i++) {
+ cx_clear(GP0_IO, 7);
+ usleep_range(1000, 1);
+ cx_set(GP0_IO,
+ ((buf[i 3] (7 - (i 7))) 1) | 4);
+ usleep_range(1000, 1);
+ }
+ cx_set(GP0_IO, 7);
+ break;
+ }
+}
+
int cx23885_tuner_callback(void *priv, int component, int command, int arg)
{
struct cx23885_tsport *port = priv;
@@ -1224,6 +1271,8 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
cx_set(GP0_IO, 0x00040004);
break;
case CX23885_BOARD_TBS_6920:
+ case CX23885_BOARD_TBS_6980:
+ case CX23885_BOARD_TBS_6981:
case CX23885_BOARD_PROF_8000:
cx_write(MC417_CTL, 0x0036);
cx_write(MC417_OEN, 0x1000);
@@ -1472,6 +1521,8 @@ int cx23885_ir_init(struct cx23885_dev *dev)
case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
case CX23885_BOARD_TEVII_S470:
case CX23885_BOARD_MYGICA_X8507:
+ case CX23885_BOARD_TBS_6980:
+ case CX23885_BOARD_TBS_6981:
if (!enable_885_ir)
break;
dev-sd_ir = cx23885_find_hw(dev, CX23885_HW_AV_CORE);
@@ -1515,6 +1566,8 @@ void cx23885_ir_fini(struct cx23885_dev *dev)
case CX23885_BOARD_TEVII_S470:
case CX23885_BOARD_HAUPPAUGE_HVR1250:
case CX23885_BOARD_MYGICA_X8507:
Re: stv090x vs stv0900 support
On 07/24/2013 08:21 PM, Krishna Kishore wrote: My opinion is that, it is better to have only stv090x. Apart from minimizing the number of patches and ease of maintenance, it will avoid the confusion that I had When I started using prof 7500. I had to enable stv0900 and stb6100. I got confused on whether to enable stv0900 or to enable stv090x. -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Chris Lee Sent: Wednesday, July 24, 2013 10:09 PM To: linux-media@vger.kernel.org Subject: stv090x vs stv0900 support Im looking for comments on these two modules, they overlap support for the same demods. stv0900 supporting stv0900 and stv090x supporting stv0900 and stv0903. Ive flipped a few cards from one to the other and they function fine. In some ways stv090x is better suited. Its a pain supporting two modules that are written differently but do the same thing, a fix in one almost always means it has to be implemented in the other as well. Im not necessarily suggesting dumping stv0900, but Id like to flip a few cards that I own over to stv090x just to standardize it. The Prof 7301 and Prof 7500. Whats everyones thoughts on this? It will cut the number of patch''s in half when it comes to these demods. Ive got alot more coming lol :) Chris stv0900 is better separated from the tuner whilst stv090x has weird stv6110x_devctl structure. That's why I used stv0900 for anysee driver. I wonder is there something special supported by stv090x because normal tuner/demod callbacks are not enough. 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: linux-next: Tree for Jul 24 (media/usb/stk1160)
Hello Randy, On Wed, Jul 24, 2013 at 10:32:57AM -0700, Randy Dunlap wrote: On 07/23/13 23:32, Stephen Rothwell wrote: Hi all, Changes since 20130723: on x86_64: drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x414e77): undefined reference to `snd_card_create' drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x414f02): undefined reference to `snd_ac97_bus' drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x414f3f): undefined reference to `snd_ac97_mixer' drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x414f64): undefined reference to `snd_card_register' drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x414f8f): undefined reference to `snd_card_free' drivers/built-in.o: In function `stk1160_ac97_unregister': (.text+0x414fd8): undefined reference to `snd_card_free' If I remember correctly this is the same issue you reported on May, and that got solved with a patch by Mauro: https://patchwork.linuxtv.org/patch/18284/ Seems the patch never got merged. @Mauro: Can you apply the patch you proposed in the above link? Thanks, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
cron job: media_tree daily build: WARNINGS
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 Jul 24 19:00:17 CEST 2013 git branch: test git hash: c859e6ef33ac0c9a5e9e934fe11a2232752b4e96 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 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 Media Infrastructure API 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: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a *new* framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. 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
Re: [PATCH v8] V4L2: soc_camera: Renesas R-Car VIN driver
Hi Guennadi,
Thank you for the v8 review.
On 07/24/2013 08:14 PM, Guennadi Liakhovetski wrote:
[snip]
+ /* output format */
+ switch (icd-current_fmt-host_fmt-fourcc) {
+ case V4L2_PIX_FMT_NV16:
+ iowrite32(ALIGN(cam-width * cam-height, 0x80),
+ priv-base + VNUVAOF_REG);
+ dmr = VNDMR_DTMD_YCSEP;
+ output_is_yuv = true;
+ break;
+ case V4L2_PIX_FMT_YUYV:
+ dmr = VNDMR_BPSM;
+ output_is_yuv = true;
+ break;
+ case V4L2_PIX_FMT_UYVY:
+ dmr = 0;
+ output_is_yuv = true;
+ break;
+ case V4L2_PIX_FMT_RGB555X:
+ dmr = VNDMR_DTMD_ARGB1555;
+ break;
+ case V4L2_PIX_FMT_RGB565:
+ dmr = 0;
+ break;
+ case V4L2_PIX_FMT_RGB32:
+ if (priv-chip == RCAR_H1 || priv-chip == RCAR_E1) {
+ dmr = VNDMR_EXRGB;
+ break;
+ }
+ default:
+ BUG();
as commented above, please, remove
Does WARN_ON(1) work instead of removal?
Regards,
Vladimir
--
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 v8] V4L2: soc_camera: Renesas R-Car VIN driver
Hello.
On 07/24/2013 08:14 PM, Guennadi Liakhovetski wrote:
From: Vladimir Barinov vladimir.bari...@cogentembedded.com
Add Renesas R-Car VIN (Video In) V4L2 driver.
Based on the patch by Phil Edworthy phil.edwor...@renesas.com.
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
[Sergei: removed deprecated IRQF_DISABLED flag, reordered/renamed 'enum chip_id'
values, reordered rcar_vin_id_table[] entries, removed senseless parens from
to_buf_list() macro, used ALIGN() macro in rcar_vin_setup(), added {} to the
*if* statement and used 'bool' values instead of 0/1 where necessary, removed
unused macros, done some reformatting and clarified some comments.]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
This patch is against the 'media_tree.git' repo.
Changes since version 7:
- remove 'icd' field from 'struct rcar_vin_priv' in accordance with the commit
f7f6ce2d09c86bd80ee11bd654a1ac1e8f5dfe13 ([media] soc-camera: move common
code
to soc_camera.c);
- added mandatory clock_{start|stop}() methods in accordance with the commit
a78fcc11264b824d9651b55abfeedd16d5cd8415 ([media] soc-camera: make .clock_
{start,stop} compulsory, .add / .remove optional).
Changes since version 6:
- sorted #include's alphabetically once again;
- BUG() on invalid format in rcar_vin_setup();
No, please don't. I think I commented on the use of BUG() in this driver
already. It shall only be used if the machine cannot continue to run. I
don't think this is the sace here.
Note that sh_mobile_ceu_camera.c has BUG() in almost the same case.
WBR, Sergei
--
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 v8] V4L2: soc_camera: Renesas R-Car VIN driver
On Wed, 24 Jul 2013, Sergei Shtylyov wrote:
Hello.
On 07/24/2013 08:14 PM, Guennadi Liakhovetski wrote:
From: Vladimir Barinov vladimir.bari...@cogentembedded.com
Add Renesas R-Car VIN (Video In) V4L2 driver.
Based on the patch by Phil Edworthy phil.edwor...@renesas.com.
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
[Sergei: removed deprecated IRQF_DISABLED flag, reordered/renamed 'enum
chip_id'
values, reordered rcar_vin_id_table[] entries, removed senseless parens
from
to_buf_list() macro, used ALIGN() macro in rcar_vin_setup(), added {} to
the
*if* statement and used 'bool' values instead of 0/1 where necessary,
removed
unused macros, done some reformatting and clarified some comments.]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
This patch is against the 'media_tree.git' repo.
Changes since version 7:
- remove 'icd' field from 'struct rcar_vin_priv' in accordance with the
commit
f7f6ce2d09c86bd80ee11bd654a1ac1e8f5dfe13 ([media] soc-camera: move
common code
to soc_camera.c);
- added mandatory clock_{start|stop}() methods in accordance with the
commit
a78fcc11264b824d9651b55abfeedd16d5cd8415 ([media] soc-camera: make
.clock_
{start,stop} compulsory, .add / .remove optional).
Changes since version 6:
- sorted #include's alphabetically once again;
- BUG() on invalid format in rcar_vin_setup();
No, please don't. I think I commented on the use of BUG() in this driver
already. It shall only be used if the machine cannot continue to run. I
don't think this is the sace here.
Note that sh_mobile_ceu_camera.c has BUG() in almost the same case.
Yes, I know. Unfortunately, back then neither the author nor any of the
reviewers realised, that that wasn't a good idea. That doesn't mean though
we have to repeat old mistakes. Would be good to fix that (and probably
multiple other) such occurrences.
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 v8] V4L2: soc_camera: Renesas R-Car VIN driver
Hi Vladimir
On Wed, 24 Jul 2013, Vladimir Barinov wrote:
Hi Guennadi,
Thank you for the v8 review.
On 07/24/2013 08:14 PM, Guennadi Liakhovetski wrote:
[snip]
+ /* output format */
+ switch (icd-current_fmt-host_fmt-fourcc) {
+ case V4L2_PIX_FMT_NV16:
+ iowrite32(ALIGN(cam-width * cam-height, 0x80),
+ priv-base + VNUVAOF_REG);
+ dmr = VNDMR_DTMD_YCSEP;
+ output_is_yuv = true;
+ break;
+ case V4L2_PIX_FMT_YUYV:
+ dmr = VNDMR_BPSM;
+ output_is_yuv = true;
+ break;
+ case V4L2_PIX_FMT_UYVY:
+ dmr = 0;
+ output_is_yuv = true;
+ break;
+ case V4L2_PIX_FMT_RGB555X:
+ dmr = VNDMR_DTMD_ARGB1555;
+ break;
+ case V4L2_PIX_FMT_RGB565:
+ dmr = 0;
+ break;
+ case V4L2_PIX_FMT_RGB32:
+ if (priv-chip == RCAR_H1 || priv-chip == RCAR_E1) {
+ dmr = VNDMR_EXRGB;
+ break;
+ }
+ default:
+ BUG();
as commented above, please, remove
Does WARN_ON(1) work instead of removal?
Sorry, by remove I certainly meant replace with a proper handling, not
just delete. In principle the above condition should never be entered,
right? Also for fmt == V4L2_PIX_FMT_RGB32 but chip not one of RCAR_H1 or
RCAR_E1? Well, this function is called from your driver's .buf_queue(),
which doesn't return an error. But yes, I would make rcar_vin_setup()
issue a warning and return an error and then, back in
rcar_vin_videobuf_queue() return the buffer with an error code (goto
error).
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 v2 4/5] v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats
Hi Laurent,
On 07/17/2013 04:54 PM, Laurent Pinchart wrote:
NV16M and NV61M are planar YCbCr 4:2:2 and YCrCb 4:2:2 formats with a
luma plane followed by an interleaved chroma plane. The planes are not
required to be contiguous in memory, and the formats can only be used
with the multi-planar formats API.
Signed-off-by: Laurent Pinchartlaurent.pinchart+rene...@ideasonboard.com
Looks good,
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
Thanks,
Sylwester
---
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 170 +++
Documentation/DocBook/media/v4l/pixfmt.xml | 1 +
include/uapi/linux/videodev2.h | 2 +
3 files changed, 173 insertions(+)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
new file mode 100644
index 000..84a8bb3
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
@@ -0,0 +1,170 @@
+refentry
+refmeta
+ refentrytitleV4L2_PIX_FMT_NV16M ('NM16'), V4L2_PIX_FMT_NV61M
('NM61')/refentrytitle
+ manvol;
+/refmeta
+refnamediv
+ refname
id=V4L2-PIX-FMT-NV16MconstantV4L2_PIX_FMT_NV16M/constant/refname
+ refname
id=V4L2-PIX-FMT-NV61MconstantV4L2_PIX_FMT_NV61M/constant/refname
+ refpurposeVariation ofconstantV4L2_PIX_FMT_NV16/constant
andconstantV4L2_PIX_FMT_NV61/constant with planes
+ non contiguous in memory./refpurpose
+/refnamediv
+refsect1
+ titleDescription/title
+
+ paraThis is a multi-planar, two-plane version of the YUV 4:2:0 format.
+The three components are separated into two sub-images or planes.
+constantV4L2_PIX_FMT_NV16M/constant differs
fromconstantV4L2_PIX_FMT_NV16
+/constant in that the two planes are non-contiguous in memory, i.e. the
chroma
+plane do not necessarily immediately follows the luma plane.
+The luminance data occupies the first plane. The Y plane has one byte per
pixel.
+In the second plane there is a chrominance data with alternating chroma
samples.
+The CbCr plane is the same width and height, in bytes, as the Y plane.
+Each CbCr pair belongs to four pixels. For example,
+Cbsubscript0/subscript/Crsubscript0/subscript belongs to
+Y'subscript00/subscript, Y'subscript01/subscript,
+Y'subscript10/subscript, Y'subscript11/subscript.
+constantV4L2_PIX_FMT_NV61M/constant is the same
asconstantV4L2_PIX_FMT_NV16M/constant
+except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr
byte./para
+
+ paraconstantV4L2_PIX_FMT_NV16M/constant is intended to be
+used only in drivers and applications that support the multi-planar API,
+described inxref linkend=planar-apis/./para
+
+ example
+ titleconstantV4L2_PIX_FMT_NV16M/constant 4times; 4 pixel
image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystart0nbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ row
+ entry/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript02/subscript/entry
+ entryCrsubscript02/subscript/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;4:/entry
+ entryCbsubscript10/subscript/entry
+ entryCrsubscript10/subscript/entry
+ entryCbsubscript12/subscript/entry
+ entryCrsubscript12/subscript/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;8:/entry
+
Re: [PATCH v2 3/5] v4l: Add media format codes for ARGB8888 and AYUV8888 on 32-bit busses
Hi Laurent,
On 07/17/2013 04:54 PM, Laurent Pinchart wrote:
Signed-off-by: Laurent Pinchartlaurent.pinchart+rene...@ideasonboard.com
---
Documentation/DocBook/media/v4l/subdev-formats.xml | 609 +
Documentation/DocBook/media_api.tmpl | 6 +
include/uapi/linux/v4l2-mediabus.h | 6 +-
3 files changed, 254 insertions(+), 367 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 0c2b1f2..9100674 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -97,31 +97,39 @@
[...]
+ row id=V4L2-MBUS-FMT-ARGB888-1X24
+ entryV4L2_MBUS_FMT_ARGB888_1X24/entry
This should be V4L2_MBUS_FMT_ARGB888_1X32, right ?
Fix this correction feel free to add:
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
+ entry0x100d/entry
+ entry/entry
[...]
diff --git a/include/uapi/linux/v4l2-mediabus.h
b/include/uapi/linux/v4l2-mediabus.h
index 6ee63d0..a960125 100644
--- a/include/uapi/linux/v4l2-mediabus.h
+++ b/include/uapi/linux/v4l2-mediabus.h
@@ -37,7 +37,7 @@
enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_FIXED = 0x0001,
- /* RGB - next is 0x100d */
+ /* RGB - next is 0x100e */
V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE = 0x1001,
V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE = 0x1002,
V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 0x1003,
@@ -50,8 +50,9 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_RGB888_1X24 = 0x100a,
V4L2_MBUS_FMT_RGB888_2X12_BE = 0x100b,
V4L2_MBUS_FMT_RGB888_2X12_LE = 0x100c,
+ V4L2_MBUS_FMT_ARGB_1X32 = 0x100d,
- /* YUV (including grey) - next is 0x2017 */
+ /* YUV (including grey) - next is 0x2018 */
V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
@@ -74,6 +75,7 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
V4L2_MBUS_FMT_YUV10_1X30 = 0x2016,
+ V4L2_MBUS_FMT_AYUV8_1X32 = 0x2017,
/* Bayer - next is 0x3019 */
V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
Thanks,
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: stv090x vs stv0900 support
On 07/24/13 19:52, Antti Palosaari wrote: On 07/24/2013 08:21 PM, Krishna Kishore wrote: My opinion is that, it is better to have only stv090x. Apart from minimizing the number of patches and ease of maintenance, it will avoid the confusion that I had When I started using prof 7500. I had to enable stv0900 and stb6100. I got confused on whether to enable stv0900 or to enable stv090x. -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Chris Lee Sent: Wednesday, July 24, 2013 10:09 PM To: linux-media@vger.kernel.org Subject: stv090x vs stv0900 support Im looking for comments on these two modules, they overlap support for the same demods. stv0900 supporting stv0900 and stv090x supporting stv0900 and stv0903. Ive flipped a few cards from one to the other and they function fine. In some ways stv090x is better suited. Its a pain supporting two modules that are written differently but do the same thing, a fix in one almost always means it has to be implemented in the other as well. Im not necessarily suggesting dumping stv0900, but Id like to flip a few cards that I own over to stv090x just to standardize it. The Prof 7301 and Prof 7500. Whats everyones thoughts on this? It will cut the number of patch''s in half when it comes to these demods. Ive got alot more coming lol :) Chris stv0900 is better separated from the tuner whilst stv090x has weird stv6110x_devctl structure. That's why I used stv0900 for anysee driver. I wonder is there something special supported by stv090x because normal tuner/demod callbacks are not enough. That's probably for the ddbridge driver, while ours is pretty old (0.5) Ralph/oliver is working on 0.9 atm. 0.8.6 still uses the same structure i think. regards Antti -- 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 v2 5/5] v4l: Renesas R-Car VSP1 driver
Hi Laurent,
What a nice driver! A few minor comments below:
On Wed, Jul 17, 2013 at 04:54:42PM +0200, Laurent Pinchart wrote:
...
+static void vsp1_device_init(struct vsp1_device *vsp1)
+{
+ unsigned int i;
+ u32 status;
+
+ /* Reset any channel that might be running. */
+ status = vsp1_read(vsp1, VI6_STATUS);
+
+ for (i = 0; i VPS1_MAX_WPF; ++i) {
+ unsigned int timeout;
+
+ if (!(status VI6_STATUS_SYS_ACT(i)))
+ continue;
+
+ vsp1_write(vsp1, VI6_SRESET, VI6_SRESET_SRTS(i));
+ for (timeout = 10; timeout 0; --timeout) {
+ status = vsp1_read(vsp1, VI6_STATUS);
+ if (!(status VI6_STATUS_SYS_ACT(i)))
+ break;
+
+ usleep_range(1000, 2000);
+ }
+
+ if (timeout)
+ dev_err(vsp1-dev, failed to reset wpf.%u\n, i);
Have you seen this happening in practice? Do you expect the device to
function if resetting it fails?
+ }
+
+ vsp1_write(vsp1, VI6_CLK_DCSWT, (8 VI6_CLK_DCSWT_CSTPW_SHIFT) |
+(8 VI6_CLK_DCSWT_CSTRW_SHIFT));
+
+ for (i = 0; i VPS1_MAX_RPF; ++i)
+ vsp1_write(vsp1, VI6_DPR_RPF_ROUTE(i), VI6_DPR_NODE_UNUSED);
+
+ for (i = 0; i VPS1_MAX_UDS; ++i)
+ vsp1_write(vsp1, VI6_DPR_UDS_ROUTE(i), VI6_DPR_NODE_UNUSED);
+
+ vsp1_write(vsp1, VI6_DPR_SRU_ROUTE, VI6_DPR_NODE_UNUSED);
+ vsp1_write(vsp1, VI6_DPR_LUT_ROUTE, VI6_DPR_NODE_UNUSED);
+ vsp1_write(vsp1, VI6_DPR_CLU_ROUTE, VI6_DPR_NODE_UNUSED);
+ vsp1_write(vsp1, VI6_DPR_HST_ROUTE, VI6_DPR_NODE_UNUSED);
+ vsp1_write(vsp1, VI6_DPR_HSI_ROUTE, VI6_DPR_NODE_UNUSED);
+ vsp1_write(vsp1, VI6_DPR_BRU_ROUTE, VI6_DPR_NODE_UNUSED);
+
+ vsp1_write(vsp1, VI6_DPR_HGO_SMPPT, (7 VI6_DPR_SMPPT_TGW_SHIFT) |
+(VI6_DPR_NODE_UNUSED VI6_DPR_SMPPT_PT_SHIFT));
+ vsp1_write(vsp1, VI6_DPR_HGT_SMPPT, (7 VI6_DPR_SMPPT_TGW_SHIFT) |
+(VI6_DPR_NODE_UNUSED VI6_DPR_SMPPT_PT_SHIFT));
+}
...
+int vsp1_entity_init(struct vsp1_device *vsp1, struct vsp1_entity *entity,
+ unsigned int num_pads)
+{
+ static const struct {
+ unsigned int id;
+ unsigned int reg;
+ } routes[] = {
+ { VI6_DPR_NODE_LIF, 0 },
+ { VI6_DPR_NODE_RPF(0), VI6_DPR_RPF_ROUTE(0) },
+ { VI6_DPR_NODE_RPF(1), VI6_DPR_RPF_ROUTE(1) },
+ { VI6_DPR_NODE_RPF(2), VI6_DPR_RPF_ROUTE(2) },
+ { VI6_DPR_NODE_RPF(3), VI6_DPR_RPF_ROUTE(3) },
+ { VI6_DPR_NODE_RPF(4), VI6_DPR_RPF_ROUTE(4) },
+ { VI6_DPR_NODE_UDS(0), VI6_DPR_UDS_ROUTE(0) },
+ { VI6_DPR_NODE_UDS(1), VI6_DPR_UDS_ROUTE(1) },
+ { VI6_DPR_NODE_UDS(2), VI6_DPR_UDS_ROUTE(2) },
+ { VI6_DPR_NODE_WPF(0), 0 },
+ { VI6_DPR_NODE_WPF(1), 0 },
+ { VI6_DPR_NODE_WPF(2), 0 },
+ { VI6_DPR_NODE_WPF(3), 0 },
+ };
+
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i ARRAY_SIZE(routes); ++i) {
+ if (routes[i].id == entity-id) {
+ entity-route = routes[i].reg;
+ break;
+ }
+ }
+
+ if (i == ARRAY_SIZE(routes))
+ return -EINVAL;
+
+ entity-vsp1 = vsp1;
+ entity-source_pad = num_pads - 1;
+
+ /* Allocate formats and pads. */
+ entity-formats = devm_kzalloc(vsp1-dev,
+num_pads * sizeof(*entity-formats),
+GFP_KERNEL);
+ if (entity-formats == NULL)
+ return -ENOMEM;
+
+ entity-pads = devm_kzalloc(vsp1-dev, num_pads * sizeof(*entity-pads),
+ GFP_KERNEL);
+ if (entity-pads == NULL)
+ return -ENOMEM;
+
+ /* Initialize pads. */
+ for (i = 0; i num_pads - 1; ++i)
+ entity-pads[i].flags = MEDIA_PAD_FL_SINK;
+
+ entity-pads[num_pads - 1].flags = MEDIA_PAD_FL_SOURCE;
+
+ /* Initialize the media entity. */
+ ret = media_entity_init(entity-subdev.entity, num_pads,
+ entity-pads, 0);
How about return media_entity_init(...) instead?
+ if (ret 0)
+ return ret;
+
+ return 0;
+}
...
+static int lif_enum_mbus_code(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ static const unsigned int codes[] = {
+ V4L2_MBUS_FMT_ARGB_1X32,
+ V4L2_MBUS_FMT_AYUV8_1X32,
+ };
+ struct v4l2_mbus_framefmt *format;
+
+ if (code-pad == LIF_PAD_SINK) {
+ if (code-index = ARRAY_SIZE(codes))
+ return -EINVAL;
+
+ code-code = codes[code-index];
+ }
Re: [PATCH v8] V4L2: soc_camera: Renesas R-Car VIN driver
Hi Vladimir,
Thank you for the revised patch.
From: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Date: Sat, 20 Jul 2013 03:14:34 +0400
From: Vladimir Barinov vladimir.bari...@cogentembedded.com
Add Renesas R-Car VIN (Video In) V4L2 driver.
Based on the patch by Phil Edworthy phil.edwor...@renesas.com.
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
[Sergei: removed deprecated IRQF_DISABLED flag, reordered/renamed 'enum
chip_id'
values, reordered rcar_vin_id_table[] entries, removed senseless parens from
to_buf_list() macro, used ALIGN() macro in rcar_vin_setup(), added {} to the
*if* statement and used 'bool' values instead of 0/1 where necessary, removed
unused macros, done some reformatting and clarified some comments.]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
This patch is against the 'media_tree.git' repo.
Changes since version 7:
- remove 'icd' field from 'struct rcar_vin_priv' in accordance with the commit
f7f6ce2d09c86bd80ee11bd654a1ac1e8f5dfe13 ([media] soc-camera: move common
code
to soc_camera.c);
- added mandatory clock_{start|stop}() methods in accordance with the commit
a78fcc11264b824d9651b55abfeedd16d5cd8415 ([media] soc-camera: make .clock_
{start,stop} compulsory, .add / .remove optional).
From: Vladimir Barinov vladimir.bari...@cogentembedded.com
Subject: Re: [PATCH v6] V4L2: soc_camera: Renesas R-Car VIN driver
Date: Sat, 22 Jun 2013 15:45:10 +0400
But, captured images are still incorrect that means wrong
order of fields desite '_BT' chosen for V4L2_STD_525_60.
I've ordered the NTSC camera.
I will return once I get it.
Did you get an NTSC camera and see the field order issue
occurs on your BOCK-W board?
You may want to consider adding a workaround into
the VIN driver if the issue remains in the latest patch.
Thanks,
---
Katsuya Matsubara / IGEL Co., Ltd
ma...@igel.co.jp
--
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
