cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Jan 17 04:00:22 CET 2015 git branch: test git hash: 99f3cd52aee21091ce62442285a68873e3be833f gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-1.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.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-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: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17.8-i686: OK linux-3.18-i686: OK linux-3.19-rc4-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-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: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16-x86_64: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18-x86_64: ERRORS linux-3.19-rc4-x86_64: ERRORS apps: OK spec-git: OK sparse: ERRORS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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: [possible BUG, cx23885] Dual tuner TV card, works using one tuner only, doesn't work if both tuners are used
Hi, James.
After searching for somebody posting some issues similar to mine, I think this
one you posted to the mailing list can be related:
https://www.mail-archive.com/linux-media%40vger.kernel.org/msg80078.html
I'm having problems using both tuners in a dual tuner card (Terratec Cinergy T
PCIe Dual), also based on cx23885, but it uses different frontends/tuners than
yours.
In summary, my problem is that I started getting signal/locking errors in VDR
if I tuned one frontend, and VDR scanned EIT/EPG using the second tuner in the
background; by disabling the second tuner it works. I managed to reproduce the
problem by simply using dvbzap/dvbv5-zap in command line. And it suddenly
started failing on the 1st of Dec 2014 (after a frequency change in DVB-T in
Spain). I tested different Ubuntu distros wich previously worked, but I can't
manage to make it work now using the default kernel included in the Ubuntu ISO
image that I had installed.
I am testing now with Ubuntu 15.04 nightly, kernel 3.18, in a separate hw
platform. I also tested with MythTV and TVHedaend, but as I managed to
reproduce it with the dvb command line tools, I don't test any GUI anymore.
I've also tested it in Windows 7, and it works tuning both tuners
simultaneously, so I discarded a hardware problem. I've also tested with the
latest git from the v4l repo by following this guide ("basic" approach):
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
with the same result.
My guess is that something in the cx23885 driver does not like the current
DVB-T signal in Spain. Is it possible that something similar happened where you
live?
The problem is that I don't know how to proceed to debug the issue, so any
advice is welcome.
BR
-Mensaje original-
De: linux-media-ow...@vger.kernel.org
[mailto:linux-media-ow...@vger.kernel.org] En nombre de dCrypt
Enviado el: viernes, 09 de enero de 2015 8:16
Para: blind Pete
CC: linux-media@vger.kernel.org
Asunto: RE: [BUG] Dual tuner TV card, works using one tuner only, doesn't work
if both tuners are used
Hi, blind Pete.
Thank you for taking your time to answer.
Yes, I tried different kernels focusing con Ubuntu distro. I don't remember the
exact kernel version, but at least those included by default in the Ubuntu
12.04 lts and 14.04 lts ISO image, which worked for me. The latest Ubuntu
version I tested was the nightly 15.04 from the 7th of January.
BREl 9/1/2015 4:46, blind Pete <0123pe...@gmail.com> escribió:
>
> Hi dCrypt,
>
> I'm not a developer at all. I'm not even sure why I read this list,
> but can you determine if the problem is associated with a particular
> kernel version? i.e. if it works on x.y.z but fails on x.y.(z+1) you
> have a starting point. If you use the word "regression" and a kernel
> version number you might get more attention - but I'm only guessing.
>
> Good luck,
> blind Pete
>
> dCrypt wrote:
>
> > Hi again,
> >
> > I'm sorry if I sound quite rude, but I'm not sure if I am doing it
> > right or not. I subscribed to this mailing list in order to ask for
> > help, or to help with a bug that I've found (as instructed in the
> > wiki http://linuxtv.org/wiki/index.php/Bug_Report), but it seems to
> > me that the mailing list is filled up with developing messages. I
> > don't want to participate in the development, I am a developer but I
> > don't have the skills nor the knowledge.
> >
> > If this is not the right place to direct my questions, I would
> > appreciate some advice.
> >
> > Thank you very much, and best regards.
> >
> > -Mensaje original-
> > De: linux-media-ow...@vger.kernel.org
> > [mailto:linux-media-ow...@vger.kernel.org] En nombre de dCrypt
> > Enviado el: jueves, 01 de enero de 2015 22:04
> > Para: linux-media@vger.kernel.org
> > Asunto: [BUG] Dual tuner TV card, works using one tuner only,
> > doesn't work if both tuners are used
> >
> > Hi,
> >
> > I just subscribed to the mailing list to submit information on the
> > bug which is driving me crazy since one month ago.
> >
> > I have a VDR based PVR at home, installed over an Ubuntu 14.04 LTS.
> > Everything was working perfectly, until beginning of December. It
> > seems to me that something changed that broke my PVR pretty bad.
> >
> > The problem is the following: tuning (zap) both tuners (it's not
> > needed that both are tuned simultaneously, only one after the other,
> > in no particular order) makes the tuners to enter an state where
> > they can't lock the signal anymore.
> >
> > Facts:
> >
> > - My TV card is a Cinergy T PCIe Dual from Terratec
> > (http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_T_PCIe_dual).
> > - The problem arose in the form of "frontend x/0 timed out while
> > tuning to channel ..." in /var/log/syslog. It happened when both
> > tuners are active, during EPG scan. The problem does not happen if
> > VDR is run with -D parameter to limit the number of fr
[PATCH] [media] cx231xx: fix usbdev leak on failure paths in cx231xx_usb_probe()
Commit b7085c086475 ("cx231xx: convert from pr_foo to dev_foo")
moves usb_get_dev(interface_to_usbdev(interface)) to the beginning
of cx231xx_usb_probe() to use udev->dev in dev_err(),
but it does not make sure usbdev is put on all failure paths.
Later dev_err(udev->dev) was replaced by dev_err(d).
So the patch moves usb_get_dev() below (before the first use)
and fixes another failure path.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/media/usb/cx231xx/cx231xx-cards.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index ae05d591f228..33c2fa2e7596 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -1403,7 +1403,6 @@ static int cx231xx_usb_probe(struct usb_interface
*interface,
struct usb_interface_assoc_descriptor *assoc_desc;
ifnum = interface->altsetting[0].desc.bInterfaceNumber;
- udev = usb_get_dev(interface_to_usbdev(interface));
/*
* Interface number 0 - IR interface (handled by mceusb driver)
@@ -1424,11 +1423,13 @@ static int cx231xx_usb_probe(struct usb_interface
*interface,
}
} while (test_and_set_bit(nr, &cx231xx_devused));
+ udev = usb_get_dev(interface_to_usbdev(interface));
+
/* allocate memory for our device state and initialize it */
dev = devm_kzalloc(&udev->dev, sizeof(*dev), GFP_KERNEL);
if (dev == NULL) {
- clear_bit(nr, &cx231xx_devused);
- return -ENOMEM;
+ retval = -ENOMEM;
+ goto err_if;
}
snprintf(dev->name, 29, "cx231xx #%d", nr);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] si2168: add support for 1.7MHz bandwidth
Hi Olli, Thanks for the patch. On Fri, Jan 16, 2015 at 12:35 PM, Olli Salonen wrote: > This patch is based on Antti's silabs branch. > > Add support for 1.7 MHz bandwidth. Supported in all versions of Si2168 > according to short data sheets. > > Signed-off-by: Olli Salonen > --- > drivers/media/dvb-frontends/si2168.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/media/dvb-frontends/si2168.c > b/drivers/media/dvb-frontends/si2168.c > index 7fef5ab..ec893ee 100644 > --- a/drivers/media/dvb-frontends/si2168.c > +++ b/drivers/media/dvb-frontends/si2168.c > @@ -185,6 +185,8 @@ static int si2168_set_frontend(struct dvb_frontend *fe) > dev_err(&client->dev, "automatic bandwidth not supported"); > goto err; > } > + else if (c->bandwidth_hz <= 200) > + bandwidth = 0x02; Please fix checkpatch errors for this patch aswel. Thanks, --Prabhakar Lad -- 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
[PATCHv2] si2168: return error if set_frontend is called with invalid parameters
This patch is based on Antti's silabs branch.
According to dvb-frontend.h set_frontend may be called with bandwidth_hz set to
0 if automatic bandwidth is required. Si2168 does not support automatic
bandwidth and does not declare FE_CAN_BANDWIDTH_AUTO in caps.
This patch will change the behaviour in a way that EINVAL is returned if
bandwidth_hz is 0.
v2: remove error message, remove line break to comply with coding style.
Signed-off-by: Olli Salonen
---
drivers/media/dvb-frontends/si2168.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 7f966f3..85acc54 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -180,7 +180,10 @@ static int si2168_set_frontend(struct dvb_frontend *fe)
goto err;
}
- if (c->bandwidth_hz <= 500)
+ if (c->bandwidth_hz == 0) {
+ ret = -EINVAL;
+ goto err;
+ } else if (c->bandwidth_hz <= 500)
bandwidth = 0x05;
else if (c->bandwidth_hz <= 600)
bandwidth = 0x06;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cx23885/vb2 regression: please test this patch
On 01/16/2015 05:20 PM, Raimonds Cicans wrote: > On 16.01.2015 16:54, Hans Verkuil wrote: >> On 01/13/2015 06:55 PM, Raimonds Cicans wrote: >>> On 13.01.2015 16:01, Hans Verkuil wrote: Can you both test this patch? It should (I hope) solve the problems you both had with the cx23885 driver. >> Can you check that the function cx23885_risc_field in >> drivers/media/pci/cx23885/cx23885-core.c uses "sg = sg_next(sg);" >> instead of "sg++;"? > There is no sg++ in whole drivers/media/pci/cx23885/ directory. >> To avoid confusion I would prefer that you test with a 3.18 or higher kernel >> and please state which kernel version you use and whether you used the >> media_build system or a specific git repo to build the drivers. > kernel: Gentoo Hardened kernel 3.18.1 (hardened part turned off) > media_build: pure original media_build > media tree: https://github.com/ljalves/linux_media (original linux-media > plus some > new out of kernel TBS drivers (from this tree I need TBS6285 driver)) >> I'm also interested if you can reproduce it using just command-line >> tools (and let me know what it is you do). > For tests I use only command line tools: w_scan & dvb-fe-tool > > Tests: > 1) w_scan on first front end then after 5-10 seconds w_scan on other > 2) w_scan on second front end then after 5-10 seconds w_scan on first > 3) "dvb-fe-tool -d DVBS" on first front end then after 5-10 seconds > w_scan on second front end then after 5-10 seconds w_scan on first > 4) "dvb-fe-tool -d DVBS" on second front end then after 5-10 seconds > w_scan on first front end then after 5-10 seconds w_scan on second > > w_scan run on both front ends simultaneously. > > > > Use only one DVB adapter, not both. > > Do you mean one card or one front end? One frontend. Regards, Hans -- 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] cx23885/vb2 regression: please test this patch
On 01/16/2015 05:48 PM, Luis Alves wrote: > Hans, > > There is another guy having issues with TBS8820 card (uses cx88 and cx24116) > > His syslog: > http://paste.ubuntu.com/9284564/ > > The stackdump makes me believe that the issue also appeared since > "[media] cx88: convert to vb2" > (still to confirm) He needs to upgrade to a newer media_build version. This is a cx88 bug that's fixed here: http://www.spinics.net/lists/linux-media/msg84255.html Regards, Hans > > Regards, > Luis > > > On Fri, Jan 16, 2015 at 4:20 PM, Raimonds Cicans wrote: >> On 16.01.2015 16:54, Hans Verkuil wrote: >>> >>> On 01/13/2015 06:55 PM, Raimonds Cicans wrote: On 13.01.2015 16:01, Hans Verkuil wrote: > > Can you both test this patch? It should (I hope) solve the problems you > both had with the cx23885 driver. > >>> Can you check that the function cx23885_risc_field in >>> drivers/media/pci/cx23885/cx23885-core.c uses "sg = sg_next(sg);" >>> instead of "sg++;"? >> >> There is no sg++ in whole drivers/media/pci/cx23885/ directory. >>> >>> To avoid confusion I would prefer that you test with a 3.18 or higher >>> kernel >>> and please state which kernel version you use and whether you used the >>> media_build system or a specific git repo to build the drivers. >> >> kernel: Gentoo Hardened kernel 3.18.1 (hardened part turned off) >> media_build: pure original media_build >> media tree: https://github.com/ljalves/linux_media (original linux-media >> plus some >> new out of kernel TBS drivers (from this tree I need TBS6285 driver)) >>> >>> I'm also interested if you can reproduce it using just command-line tools >>> (and let me know what it is you do). >> >> For tests I use only command line tools: w_scan & dvb-fe-tool >> >> Tests: >> 1) w_scan on first front end then after 5-10 seconds w_scan on other >> 2) w_scan on second front end then after 5-10 seconds w_scan on first >> 3) "dvb-fe-tool -d DVBS" on first front end then after 5-10 seconds w_scan >> on second front end then after 5-10 seconds w_scan on first >> 4) "dvb-fe-tool -d DVBS" on second front end then after 5-10 seconds w_scan >> on first front end then after 5-10 seconds w_scan on second >> >> w_scan run on both front ends simultaneously. >> >> >>> Use only one DVB adapter, not both. >> >> Do you mean one card or one front end? >> >> >> >> Raimonds Cicans >> >> -- >> 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 > -- 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] cx23885/vb2 regression: please test this patch
Hans, There is another guy having issues with TBS8820 card (uses cx88 and cx24116) His syslog: http://paste.ubuntu.com/9284564/ The stackdump makes me believe that the issue also appeared since "[media] cx88: convert to vb2" (still to confirm) Regards, Luis On Fri, Jan 16, 2015 at 4:20 PM, Raimonds Cicans wrote: > On 16.01.2015 16:54, Hans Verkuil wrote: >> >> On 01/13/2015 06:55 PM, Raimonds Cicans wrote: >>> >>> On 13.01.2015 16:01, Hans Verkuil wrote: Can you both test this patch? It should (I hope) solve the problems you both had with the cx23885 driver. >> Can you check that the function cx23885_risc_field in >> drivers/media/pci/cx23885/cx23885-core.c uses "sg = sg_next(sg);" >> instead of "sg++;"? > > There is no sg++ in whole drivers/media/pci/cx23885/ directory. >> >> To avoid confusion I would prefer that you test with a 3.18 or higher >> kernel >> and please state which kernel version you use and whether you used the >> media_build system or a specific git repo to build the drivers. > > kernel: Gentoo Hardened kernel 3.18.1 (hardened part turned off) > media_build: pure original media_build > media tree: https://github.com/ljalves/linux_media (original linux-media > plus some > new out of kernel TBS drivers (from this tree I need TBS6285 driver)) >> >> I'm also interested if you can reproduce it using just command-line tools >> (and let me know what it is you do). > > For tests I use only command line tools: w_scan & dvb-fe-tool > > Tests: > 1) w_scan on first front end then after 5-10 seconds w_scan on other > 2) w_scan on second front end then after 5-10 seconds w_scan on first > 3) "dvb-fe-tool -d DVBS" on first front end then after 5-10 seconds w_scan > on second front end then after 5-10 seconds w_scan on first > 4) "dvb-fe-tool -d DVBS" on second front end then after 5-10 seconds w_scan > on first front end then after 5-10 seconds w_scan on second > > w_scan run on both front ends simultaneously. > > >> Use only one DVB adapter, not both. > > Do you mean one card or one front end? > > > > Raimonds Cicans > > -- > 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
Re: [PATCH] cx23885/vb2 regression: please test this patch
On Fri, 2015-01-16 at 15:58 +0100, Hans Verkuil wrote: > On 01/15/2015 05:32 PM, Jurgen Kramer wrote: > > Hi Hans, > > > > On Tue, 2015-01-13 at 17:59 +0100, Jurgen Kramer wrote: > >> Hi Hans, > >> On Tue, 2015-01-13 at 15:01 +0100, Hans Verkuil wrote: > >>> Hi Raimonds, Jurgen, > >>> > >>> Can you both test this patch? It should (I hope) solve the problems you > >>> both had with the cx23885 driver. > >>> > >>> This patch fixes a race condition in the vb2_thread that occurs when > >>> the thread is stopped. The crucial fix is calling kthread_stop much > >>> earlier in vb2_thread_stop(). But I also made the vb2_thread more > >>> robust. > >> > >> Thanks. Will test your patch and report back. > > I have tested the patch, unfortunately results are not positive. > > With the patch MythTV has issues with the tuners. Live TV no longer > > works and eventually mythbackend hangs. Reverting the patch brings > > everything back to a working state. > > Which kernel version are you using? Do you use media_build to install > the drivers or do you use a git repository? Do you see any kernel messages? I am on 3.17.7 (F20 x86-64) with current media_build (git://linuxtv.org/media_build.git) There were no kernel messages indicating failure, same goes for mythbackend. > Do you get problems with e.g. mplayer or vlc or another GUI tool as well? I have only tested it with MythTV. I'll give a w_scan and mplayer a try to see if that combo gives working TV output. Regards, Jurgen -- 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
randconfig build error with next-20150116, in drivers/media/v4l2-core/tuner-core.c
Building with the attached random configuration file, drivers/built-in.o: In function `set_type': tuner-core.c:(.text+0x245dd0): undefined reference to `tea5767_attach' tuner-core.c:(.text+0x245f5f): undefined reference to `xc2028_attach' tuner-core.c:(.text+0x2460e3): undefined reference to `tda18271_attach' tuner-core.c:(.text+0x246146): undefined reference to `xc4000_attach' drivers/built-in.o: In function `tuner_probe': tuner-core.c:(.text+0x246908): undefined reference to `tea5767_autodetection' make: *** [vmlinux] Error 1 # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.19.0-rc4 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_SRCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y # CONFIG_RCU_USER_QS is not set CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_KTHREAD_PRIO=1 # CONFIG_RCU_NOCB_CPU is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_SUPPORTS_INT128=y # CONFIG_NUMA_BALANCING is not set # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y # CONFIG_USER_NS is not set CONFIG_PID_NS=y # CONFIG_NET_NS is not set # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # CONFIG_LTO_MENU is not set CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y CONFIG_EXPERT=y # CONFIG_UID16 is not set CONFIG_SGETMASK_SYSCALL=y # CONFIG_SYSFS_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_PRINTK is not set CONFIG_BUG=y
[RFC PATCH 0/5] media: rcar_vin: Fixes for buffer management
The following is a subset of our work in progress branch for video support on the Renesas "Lager" board, comprising hotfixes for video buffer management. We are successfully capturing single frames and video with the complete branch, and intend to follow up with stable patches from the branch in due course. Included here: [PATCH 1/2] media: rcar_vin: helper function for streaming stop [PATCH 2/2] media: rcar_vin: move buffer management to .stop_streaming handler Cheers, Wills. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] media: rcar_vin: helper function for streaming stop
From: Ian Molton
The code that tests that capture from a stream has stopped is
presently insufficient and the potential for a race condition
exists where frame capture may generate an interrupt between
requesting the capture process halt and freeing buffers.
This patch refactors code out of rcar_vin_videobuf_release() and
into rcar_vin_wait_stop_streaming(), and ensures there are calls
in places where we need to know that capturing has finished.
Signed-off-by: Ian Molton
Signed-off-by: William Towle
---
drivers/media/platform/soc_camera/rcar_vin.c | 41 +-
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 8d8438b..89c409b 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -458,6 +458,28 @@ error:
vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
}
+/*
+ * Wait for capture to stop and all in-flight buffers to be finished with by
+ * the video hardware. This must be called under &priv->lock
+ *
+ */
+static void rcar_vin_wait_stop_streaming(struct rcar_vin_priv *priv)
+{
+ while (priv->state != STOPPED) {
+ /* issue stop if running */
+ if (priv->state == RUNNING)
+ rcar_vin_request_capture_stop(priv);
+
+ /* wait until capturing has been stopped */
+ if (priv->state == STOPPING) {
+ priv->request_to_stop = true;
+ spin_unlock_irq(&priv->lock);
+ wait_for_completion(&priv->capture_stop);
+ spin_lock_irq(&priv->lock);
+ }
+ }
+}
+
static void rcar_vin_videobuf_release(struct vb2_buffer *vb)
{
struct soc_camera_device *icd = soc_camera_from_vb2q(vb->vb2_queue);
@@ -477,20 +499,8 @@ static void rcar_vin_videobuf_release(struct vb2_buffer
*vb)
}
if (buf_in_use) {
- while (priv->state != STOPPED) {
-
- /* issue stop if running */
- if (priv->state == RUNNING)
- rcar_vin_request_capture_stop(priv);
-
- /* wait until capturing has been stopped */
- if (priv->state == STOPPING) {
- priv->request_to_stop = true;
- spin_unlock_irq(&priv->lock);
- wait_for_completion(&priv->capture_stop);
- spin_lock_irq(&priv->lock);
- }
- }
+ rcar_vin_wait_stop_streaming(priv);
+
/*
* Capturing has now stopped. The buffer we have been asked
* to release could be any of the current buffers in use, so
@@ -524,8 +534,11 @@ static void rcar_vin_stop_streaming(struct vb2_queue *vq)
struct list_head *buf_head, *tmp;
spin_lock_irq(&priv->lock);
+
+ rcar_vin_wait_stop_streaming(priv);
list_for_each_safe(buf_head, tmp, &priv->capture)
list_del_init(buf_head);
+
spin_unlock_irq(&priv->lock);
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] media: rcar_vin: move buffer management to .stop_streaming handler
This commit moves the "buffer in use" logic from the .buf_cleanup
handler into .stop_streaming, based on advice that this is its
proper logical home.
By ensuring the list of pointers in priv->queue_buf[] is managed
as soon as possible, we avoid warnings concerning buffers in ACTIVE
state when the system cleans up after streaming stops. This fixes a
problem with modification of buffers after their content has been
cleared for passing to userspace.
Signed-off-by: William Towle
---
drivers/media/platform/soc_camera/rcar_vin.c | 47 +-
1 file changed, 16 insertions(+), 31 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 89c409b..022fa9d 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -485,37 +485,10 @@ static void rcar_vin_videobuf_release(struct vb2_buffer
*vb)
struct soc_camera_device *icd = soc_camera_from_vb2q(vb->vb2_queue);
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
struct rcar_vin_priv *priv = ici->priv;
- unsigned int i;
- int buf_in_use = 0;
spin_lock_irq(&priv->lock);
- /* Is the buffer in use by the VIN hardware? */
- for (i = 0; i < MAX_BUFFER_NUM; i++) {
- if (priv->queue_buf[i] == vb) {
- buf_in_use = 1;
- break;
- }
- }
-
- if (buf_in_use) {
- rcar_vin_wait_stop_streaming(priv);
-
- /*
-* Capturing has now stopped. The buffer we have been asked
-* to release could be any of the current buffers in use, so
-* release all buffers that are in use by HW
-*/
- for (i = 0; i < MAX_BUFFER_NUM; i++) {
- if (priv->queue_buf[i]) {
- vb2_buffer_done(priv->queue_buf[i],
- VB2_BUF_STATE_ERROR);
- priv->queue_buf[i] = NULL;
- }
- }
- } else {
- list_del_init(to_buf_list(vb));
- }
+ list_del_init(to_buf_list(vb));
spin_unlock_irq(&priv->lock);
}
@@ -532,13 +505,25 @@ static void rcar_vin_stop_streaming(struct vb2_queue *vq)
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
struct rcar_vin_priv *priv = ici->priv;
struct list_head *buf_head, *tmp;
+ int i;
spin_lock_irq(&priv->lock);
-
rcar_vin_wait_stop_streaming(priv);
- list_for_each_safe(buf_head, tmp, &priv->capture)
- list_del_init(buf_head);
+ for (i = 0; i < MAX_BUFFER_NUM; i++) {
+ if (priv->queue_buf[i]) {
+ vb2_buffer_done(priv->queue_buf[i],
+ VB2_BUF_STATE_ERROR);
+ priv->queue_buf[i] = NULL;
+ }
+ }
+
+ list_for_each_safe(buf_head, tmp, &priv->capture) {
+ vb2_buffer_done(&list_entry(buf_head,
+ struct rcar_vin_buffer, list)->vb,
+ VB2_BUF_STATE_ERROR);
+ list_del_init(buf_head);
+ }
spin_unlock_irq(&priv->lock);
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cx23885/vb2 regression: please test this patch
On 16.01.2015 16:54, Hans Verkuil wrote: On 01/13/2015 06:55 PM, Raimonds Cicans wrote: On 13.01.2015 16:01, Hans Verkuil wrote: Can you both test this patch? It should (I hope) solve the problems you both had with the cx23885 driver. Can you check that the function cx23885_risc_field in drivers/media/pci/cx23885/cx23885-core.c uses "sg = sg_next(sg);" instead of "sg++;"? There is no sg++ in whole drivers/media/pci/cx23885/ directory. To avoid confusion I would prefer that you test with a 3.18 or higher kernel and please state which kernel version you use and whether you used the media_build system or a specific git repo to build the drivers. kernel: Gentoo Hardened kernel 3.18.1 (hardened part turned off) media_build: pure original media_build media tree: https://github.com/ljalves/linux_media (original linux-media plus some new out of kernel TBS drivers (from this tree I need TBS6285 driver)) I'm also interested if you can reproduce it using just command-line tools (and let me know what it is you do). For tests I use only command line tools: w_scan & dvb-fe-tool Tests: 1) w_scan on first front end then after 5-10 seconds w_scan on other 2) w_scan on second front end then after 5-10 seconds w_scan on first 3) "dvb-fe-tool -d DVBS" on first front end then after 5-10 seconds w_scan on second front end then after 5-10 seconds w_scan on first 4) "dvb-fe-tool -d DVBS" on second front end then after 5-10 seconds w_scan on first front end then after 5-10 seconds w_scan on second w_scan run on both front ends simultaneously. > Use only one DVB adapter, not both. Do you mean one card or one front end? Raimonds Cicans -- 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 v10 03/19] DT: leds: Add led-sources property
On 01/16/2015 02:48 PM, Rob Herring wrote: On Fri, Jan 16, 2015 at 3:07 AM, Jacek Anaszewski wrote: On 01/15/2015 03:24 PM, Rob Herring wrote: On Tue, Jan 13, 2015 at 2:42 AM, Jacek Anaszewski wrote: On 01/12/2015 05:55 PM, Rob Herring wrote: Adding Mark B and Liam... On Mon, Jan 12, 2015 at 10:10 AM, Jacek Anaszewski wrote: On 01/12/2015 02:52 PM, Rob Herring wrote: On Mon, Jan 12, 2015 at 2:32 AM, Jacek Anaszewski wrote: On 01/09/2015 07:33 PM, Rob Herring wrote: On Fri, Jan 9, 2015 at 9:22 AM, Jacek Anaszewski wrote: Add a property for defining the device outputs the LED represented by the DT child node is connected to. [...] b/Documentation/devicetree/bindings/leds/common.txt index a2c3f7a..29295bf 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -1,6 +1,10 @@ Common leds properties. Optional properties for child nodes: +- led-sources : Array of bits signifying the LED current regulator outputs the + LED represented by the child node is connected to (1 - the LED + is connected to the output, 0 - the LED isn't connected to the + output). Sorry, I just don't understand this. In some Flash LED devices one LED can be connected to one or more electric current outputs, which allows for multiplying the maximum current allowed for the LED. Each sub-LED is represented by a child node in the DT binding of the Flash LED device and it needs to declare which outputs it is connected to. In the example below the led-sources property is a two element array, which means that the flash LED device has two current outputs, and the bits signify if the LED is connected to the output. Sounds like a regulator for which we already have bindings for and we have a driver for regulator based LEDs (but no binding for it). Do you think of drivers/leds/leds-regulator.c driver? This driver just allows for registering an arbitrary regulator device as a LED subsystem device. There are however devices that don't fall into this category, i.e. they have many outputs, that can be connected to a single LED or to many LEDs and the driver has to know what is the actual arrangement. We may need to extend the regulator binding slightly and allow for multiple phandles on a supply property, but wouldn't something like this work: led-supply = <&led-reg0>, <&led-reg1>, <&led-reg2>, <&led-reg3>; The shared source is already supported by the regulator binding. I think that we shouldn't split the LED devices into power supply providers and consumers as in case of generic regulators. From this point of view a LED device current output is a provider and a discrete LED element is a consumer. In this approach each discrete LED element should have a related driver which is not how LED devices are being handled in the LED subsystem, where there is a single binding for a LED device and there is a single driver for it which creates separate LED class devices for each LED connected to the LED device output. Each discrete LED is represented by a child node in the LED device binding. I am aware that it may be tempting to treat LED devices as common regulators, but they have their specific features which gave a reason for introducing LED class for them. Besides, there is already drivers/leds/leds-regulator.c driver for LED devices which support only turning on/off and setting brightness level. In your proposition a separate regulator provider binding would have to be created for each current output and a separate binding for each discrete LED connected to the LED device. It would create unnecessary noise in a dts file. Moreover, using regulator binding implies that we want to treat it as a sheer power supply for our device (which would be a discrete LED element in this case), whereas LED devices provide more features like blinking pattern and for flash LED devices - flash timeout, external strobe and flash faults. Okay, fair enough. Please include some of this explanation in the binding description. I do still have some concerns about led-sources and whether it can support other scenarios. It is very much tied to the parent node. Are there any cases where we don't want the LEDs to be sub nodes? Perhaps the LEDs are on a separate daughterboard from the driver/supply and we can have different drivers. It's a stretch maybe. I think it is. Such arrangements would introduce problems also to the other existing bindings. Probably not only LED subsystem related ones. Or are there cases where you need more information than just the connection? Currently I can't think of any. Modified rough proposal of the description: -Optional properties for child nodes: +LED and flash LED devices provide the same basic functionality as +current regulators, but extended with LED and flash LED specific +features like blinking patterns, flash timeout, flash faults and +externa
[PATCH 1/2] media: rcar_vin: Fix race condition terminating stream
From: Ian Molton
The potential for a race condition exists where frame capture may
generate an interrupt between requesting the capture process halt
and freeing buffers.
Introduce rcar_vin_wait_stop_streaming() and call it in appropriate
places so we ensure capturing has finished where this is critical.
Signed-off-by: Ian Molton
Signed-off-by: William Towle
---
drivers/media/platform/soc_camera/rcar_vin.c | 41 +-
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 8d8438b..89c409b 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -458,6 +458,28 @@ error:
vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
}
+/*
+ * Wait for capture to stop and all in-flight buffers to be finished with by
+ * the video hardware. This must be called under &priv->lock
+ *
+ */
+static void rcar_vin_wait_stop_streaming(struct rcar_vin_priv *priv)
+{
+ while (priv->state != STOPPED) {
+ /* issue stop if running */
+ if (priv->state == RUNNING)
+ rcar_vin_request_capture_stop(priv);
+
+ /* wait until capturing has been stopped */
+ if (priv->state == STOPPING) {
+ priv->request_to_stop = true;
+ spin_unlock_irq(&priv->lock);
+ wait_for_completion(&priv->capture_stop);
+ spin_lock_irq(&priv->lock);
+ }
+ }
+}
+
static void rcar_vin_videobuf_release(struct vb2_buffer *vb)
{
struct soc_camera_device *icd = soc_camera_from_vb2q(vb->vb2_queue);
@@ -477,20 +499,8 @@ static void rcar_vin_videobuf_release(struct vb2_buffer
*vb)
}
if (buf_in_use) {
- while (priv->state != STOPPED) {
-
- /* issue stop if running */
- if (priv->state == RUNNING)
- rcar_vin_request_capture_stop(priv);
-
- /* wait until capturing has been stopped */
- if (priv->state == STOPPING) {
- priv->request_to_stop = true;
- spin_unlock_irq(&priv->lock);
- wait_for_completion(&priv->capture_stop);
- spin_lock_irq(&priv->lock);
- }
- }
+ rcar_vin_wait_stop_streaming(priv);
+
/*
* Capturing has now stopped. The buffer we have been asked
* to release could be any of the current buffers in use, so
@@ -524,8 +534,11 @@ static void rcar_vin_stop_streaming(struct vb2_queue *vq)
struct list_head *buf_head, *tmp;
spin_lock_irq(&priv->lock);
+
+ rcar_vin_wait_stop_streaming(priv);
list_for_each_safe(buf_head, tmp, &priv->capture)
list_del_init(buf_head);
+
spin_unlock_irq(&priv->lock);
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] media: rcar_vin: move buffer management to .stop_streaming handler
This commit moves the "buffer in use" logic from the .buf_cleanup
handler into .stop_streaming, based on advice that this is its
proper logical home.
By ensuring the list of pointers in priv->queue_buf[] is managed
as soon as possible, we avoid warnings concerning buffers in ACTIVE
state when the system cleans up after streaming stops. This fixes a
problem with modification of buffers after their content has been
cleared for passing to userspace.
Signed-off-by: William Towle
---
drivers/media/platform/soc_camera/rcar_vin.c | 47 +-
1 file changed, 16 insertions(+), 31 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 89c409b..022fa9d 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -485,37 +485,10 @@ static void rcar_vin_videobuf_release(struct vb2_buffer
*vb)
struct soc_camera_device *icd = soc_camera_from_vb2q(vb->vb2_queue);
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
struct rcar_vin_priv *priv = ici->priv;
- unsigned int i;
- int buf_in_use = 0;
spin_lock_irq(&priv->lock);
- /* Is the buffer in use by the VIN hardware? */
- for (i = 0; i < MAX_BUFFER_NUM; i++) {
- if (priv->queue_buf[i] == vb) {
- buf_in_use = 1;
- break;
- }
- }
-
- if (buf_in_use) {
- rcar_vin_wait_stop_streaming(priv);
-
- /*
-* Capturing has now stopped. The buffer we have been asked
-* to release could be any of the current buffers in use, so
-* release all buffers that are in use by HW
-*/
- for (i = 0; i < MAX_BUFFER_NUM; i++) {
- if (priv->queue_buf[i]) {
- vb2_buffer_done(priv->queue_buf[i],
- VB2_BUF_STATE_ERROR);
- priv->queue_buf[i] = NULL;
- }
- }
- } else {
- list_del_init(to_buf_list(vb));
- }
+ list_del_init(to_buf_list(vb));
spin_unlock_irq(&priv->lock);
}
@@ -532,13 +505,25 @@ static void rcar_vin_stop_streaming(struct vb2_queue *vq)
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
struct rcar_vin_priv *priv = ici->priv;
struct list_head *buf_head, *tmp;
+ int i;
spin_lock_irq(&priv->lock);
-
rcar_vin_wait_stop_streaming(priv);
- list_for_each_safe(buf_head, tmp, &priv->capture)
- list_del_init(buf_head);
+ for (i = 0; i < MAX_BUFFER_NUM; i++) {
+ if (priv->queue_buf[i]) {
+ vb2_buffer_done(priv->queue_buf[i],
+ VB2_BUF_STATE_ERROR);
+ priv->queue_buf[i] = NULL;
+ }
+ }
+
+ list_for_each_safe(buf_head, tmp, &priv->capture) {
+ vb2_buffer_done(&list_entry(buf_head,
+ struct rcar_vin_buffer, list)->vb,
+ VB2_BUF_STATE_ERROR);
+ list_del_init(buf_head);
+ }
spin_unlock_irq(&priv->lock);
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/15] media: blackfin: bfin_capture enhancements
Hi Scott, Any idea when you will have time to test this? Regards, Hans On 12/26/2014 08:13 AM, Scott Jiang wrote: > Hi Lad, > > I'm on holiday these days. I will test these patches later. > > Thanks, > Scott > > 2014-12-20 18:47 GMT+08:00 Lad, Prabhakar : >> Hi Scott, >> >> Although I was on holiday but couldn't resist myself from working, >> since I was away from my hardware I had to choose a different one, >> blackfin driver was lucky one. Since I don't have the blackfin >> board I haven't tested them on the actual board, but just compile >> tested, Can you please test it & ACK. >> >> Lad, Prabhakar (15): >> media: blackfin: bfin_capture: drop buf_init() callback >> media: blackfin: bfin_capture: release buffers in case >> start_streaming() call back fails >> media: blackfin: bfin_capture: set min_buffers_needed >> media: blackfin: bfin_capture: improve buf_prepare() callback >> media: blackfin: bfin_capture: improve queue_setup() callback >> media: blackfin: bfin_capture: use vb2_fop_mmap/poll >> media: blackfin: bfin_capture: use v4l2_fh_open and vb2_fop_release >> media: blackfin: bfin_capture: use vb2_ioctl_* helpers >> media: blackfin: bfin_capture: make sure all buffers are returned on >> stop_streaming() callback >> media: blackfin: bfin_capture: return -ENODATA for *std calls >> media: blackfin: bfin_capture: return -ENODATA for *dv_timings calls >> media: blackfin: bfin_capture: add support for vidioc_create_bufs >> media: blackfin: bfin_capture: add support for VB2_DMABUF >> media: blackfin: bfin_capture: add support for VIDIOC_EXPBUF >> media: blackfin: bfin_capture: set v4l2 buffer sequence >> >> drivers/media/platform/blackfin/bfin_capture.c | 310 >> - >> 1 file changed, 98 insertions(+), 212 deletions(-) >> >> -- >> 1.9.1 >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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] cx23885/vb2 regression: please test this patch
On 01/15/2015 05:32 PM, Jurgen Kramer wrote: > Hi Hans, > > On Tue, 2015-01-13 at 17:59 +0100, Jurgen Kramer wrote: >> Hi Hans, >> On Tue, 2015-01-13 at 15:01 +0100, Hans Verkuil wrote: >>> Hi Raimonds, Jurgen, >>> >>> Can you both test this patch? It should (I hope) solve the problems you >>> both had with the cx23885 driver. >>> >>> This patch fixes a race condition in the vb2_thread that occurs when >>> the thread is stopped. The crucial fix is calling kthread_stop much >>> earlier in vb2_thread_stop(). But I also made the vb2_thread more >>> robust. >> >> Thanks. Will test your patch and report back. > I have tested the patch, unfortunately results are not positive. > With the patch MythTV has issues with the tuners. Live TV no longer > works and eventually mythbackend hangs. Reverting the patch brings > everything back to a working state. Which kernel version are you using? Do you use media_build to install the drivers or do you use a git repository? Do you see any kernel messages? Do you get problems with e.g. mplayer or vlc or another GUI tool as well? This doesn't really make sense to me why this would fail. Regards, Hans > > Regards, > Jurgen > >> >> >> -- >> 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 > -- 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] cx23885/vb2 regression: please test this patch
On 01/13/2015 06:55 PM, Raimonds Cicans wrote: > On 13.01.2015 16:01, Hans Verkuil wrote: >> Hi Raimonds, Jurgen, >> >> Can you both test this patch? It should (I hope) solve the problems you >> both had with the cx23885 driver. >> >> This patch fixes a race condition in the vb2_thread that occurs when >> the thread is stopped. The crucial fix is calling kthread_stop much >> earlier in vb2_thread_stop(). But I also made the vb2_thread more >> robust. > > With this patch I am unable to get any error except first > (AMD-Vi: Event logged [IO_PAGE_FAULT...). > But I am not convinced, because before patch I get > first error much often and earlier than almost any other error, > so it may be just "bad luck" and other errors do not > appear because first error appear earlier. No, the first error and the others errors are unrelated. Can you check that the function cx23885_risc_field in drivers/media/pci/cx23885/cx23885-core.c uses "sg = sg_next(sg);" instead of "sg++;"? See also the original patch: https://patchwork.linuxtv.org/patch/27071/ To avoid confusion I would prefer that you test with a 3.18 or higher kernel and please state which kernel version you use and whether you used the media_build system or a specific git repo to build the drivers. > > BTW question about RISC engine: > what kind of memory use RISC engine to store > DMA programs (code)? Internal SRAM or host's? Internal SRAM. > I ask because "cx23885[0]: mpeg risc op code error" > error message storm after first message looks like > RISC engine used host's memory when this memory > was unmapped. That's why I need to know whether sg_next is used or not. Because if that's not the case, then that explains the error. If you get the error again with a 3.18 or higher kernel and with my patch, then please copy-and-paste that message again. I'm also interested if you can reproduce it using just command-line tools (and let me know what it is you do). Use only one DVB adapter, not both. Regards, Hans -- 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] si2168: return error if set_frontend is called with invalid parameters
Hi Olli,
Thanks for the patch.
On Fri, Jan 16, 2015 at 12:35 PM, Olli Salonen wrote:
> This patch should is based on Antti's silabs branch.
>
> According to dvb-frontend.h set_frontend may be called with bandwidth_hz set
> to 0 if automatic bandwidth is required. Si2168 does not support automatic
> bandwidth and does not declare FE_CAN_BANDWIDTH_AUTO in caps.
>
> This patch will change the behaviour in a way that EINVAL is returned if
> bandwidth_hz is 0.
>
> Cc-to: Antti Palosaari
> Signed-off-by: Olli Salonen
> ---
> drivers/media/dvb-frontends/si2168.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-frontends/si2168.c
> b/drivers/media/dvb-frontends/si2168.c
> index 7f966f3..7fef5ab 100644
> --- a/drivers/media/dvb-frontends/si2168.c
> +++ b/drivers/media/dvb-frontends/si2168.c
> @@ -180,7 +180,12 @@ static int si2168_set_frontend(struct dvb_frontend *fe)
> goto err;
> }
>
> - if (c->bandwidth_hz <= 500)
> + if (c->bandwidth_hz == 0) {
> + ret = -EINVAL;
> + dev_err(&client->dev, "automatic bandwidth not supported");
> + goto err;
> + }
> + else if (c->bandwidth_hz <= 500)
> bandwidth = 0x05;
Checkpatch should catch it. did you run checkpatch ?
Thanks,
--Prabhakar Lad
--
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] si2168: add support for 1.7MHz bandwidth
Hi Olli, did you commit this anywhere? Regards, Tycho. Op 16-01-15 om 13:35 schreef Olli Salonen: This patch is based on Antti's silabs branch. Add support for 1.7 MHz bandwidth. Supported in all versions of Si2168 according to short data sheets. Signed-off-by: Olli Salonen --- drivers/media/dvb-frontends/si2168.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/dvb-frontends/si2168.c b/drivers/media/dvb-frontends/si2168.c index 7fef5ab..ec893ee 100644 --- a/drivers/media/dvb-frontends/si2168.c +++ b/drivers/media/dvb-frontends/si2168.c @@ -185,6 +185,8 @@ static int si2168_set_frontend(struct dvb_frontend *fe) dev_err(&client->dev, "automatic bandwidth not supported"); goto err; } + else if (c->bandwidth_hz <= 200) + bandwidth = 0x02; else if (c->bandwidth_hz <= 500) bandwidth = 0x05; else if (c->bandwidth_hz <= 600) -- 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] si2168: add support for 1.7MHz bandwidth
On 01/16/2015 02:35 PM, Olli Salonen wrote: This patch is based on Antti's silabs branch. Add support for 1.7 MHz bandwidth. Supported in all versions of Si2168 according to short data sheets. Signed-off-by: Olli Salonen Reviewed-by: Antti Palosaari How about tuner driver filters? Having too wide channel filters reduces some performance, but it still works. It could be even possible 5MHz is smallest filter tuner supports... regards Antti --- drivers/media/dvb-frontends/si2168.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/dvb-frontends/si2168.c b/drivers/media/dvb-frontends/si2168.c index 7fef5ab..ec893ee 100644 --- a/drivers/media/dvb-frontends/si2168.c +++ b/drivers/media/dvb-frontends/si2168.c @@ -185,6 +185,8 @@ static int si2168_set_frontend(struct dvb_frontend *fe) dev_err(&client->dev, "automatic bandwidth not supported"); goto err; } + else if (c->bandwidth_hz <= 200) + bandwidth = 0x02; else if (c->bandwidth_hz <= 500) bandwidth = 0x05; else if (c->bandwidth_hz <= 600) -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] si2168: return error if set_frontend is called with invalid parameters
On 01/16/2015 02:35 PM, Olli Salonen wrote:
This patch should is based on Antti's silabs branch.
According to dvb-frontend.h set_frontend may be called with bandwidth_hz set to
0 if automatic bandwidth is required. Si2168 does not support automatic
bandwidth and does not declare FE_CAN_BANDWIDTH_AUTO in caps.
This patch will change the behaviour in a way that EINVAL is returned if
bandwidth_hz is 0.
Cc-to: Antti Palosaari
Signed-off-by: Olli Salonen
Reviewed-by: Antti Palosaari
Antti
---
drivers/media/dvb-frontends/si2168.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 7f966f3..7fef5ab 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -180,7 +180,12 @@ static int si2168_set_frontend(struct dvb_frontend *fe)
goto err;
}
- if (c->bandwidth_hz <= 500)
+ if (c->bandwidth_hz == 0) {
+ ret = -EINVAL;
+ dev_err(&client->dev, "automatic bandwidth not supported");
+ goto err;
+ }
+ else if (c->bandwidth_hz <= 500)
bandwidth = 0x05;
else if (c->bandwidth_hz <= 600)
bandwidth = 0x06;
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property
On Fri, Jan 16, 2015 at 3:07 AM, Jacek Anaszewski wrote: > On 01/15/2015 03:24 PM, Rob Herring wrote: >> >> On Tue, Jan 13, 2015 at 2:42 AM, Jacek Anaszewski >> wrote: >>> >>> On 01/12/2015 05:55 PM, Rob Herring wrote: Adding Mark B and Liam... On Mon, Jan 12, 2015 at 10:10 AM, Jacek Anaszewski wrote: > > > On 01/12/2015 02:52 PM, Rob Herring wrote: >> >> >> >> On Mon, Jan 12, 2015 at 2:32 AM, Jacek Anaszewski >> wrote: >>> >>> >>> On 01/09/2015 07:33 PM, Rob Herring wrote: On Fri, Jan 9, 2015 at 9:22 AM, Jacek Anaszewski wrote: > > > Add a property for defining the device outputs the LED > represented by the DT child node is connected to. [...] > b/Documentation/devicetree/bindings/leds/common.txt > index a2c3f7a..29295bf 100644 > --- a/Documentation/devicetree/bindings/leds/common.txt > +++ b/Documentation/devicetree/bindings/leds/common.txt > @@ -1,6 +1,10 @@ > Common leds properties. > > Optional properties for child nodes: > +- led-sources : Array of bits signifying the LED current regulator > outputs the > + LED represented by the child node is connected to > (1 > - > the LED > + is connected to the output, 0 - the LED isn't > connected > to the > + output). Sorry, I just don't understand this. >>> >>> >>> >>> >>> >>> In some Flash LED devices one LED can be connected to one or more >>> electric current outputs, which allows for multiplying the maximum >>> current allowed for the LED. Each sub-LED is represented by a child >>> node in the DT binding of the Flash LED device and it needs to >>> declare >>> which outputs it is connected to. In the example below the >>> led-sources >>> property is a two element array, which means that the flash LED >>> device >>> has two current outputs, and the bits signify if the LED is connected >>> to the output. >> >> >> >> >> Sounds like a regulator for which we already have bindings for and we >> have a driver for regulator based LEDs (but no binding for it). > > > > > Do you think of drivers/leds/leds-regulator.c driver? This driver just > allows for registering an arbitrary regulator device as a LED subsystem > device. > > There are however devices that don't fall into this category, i.e. they > have many outputs, that can be connected to a single LED or to many > LEDs > and the driver has to know what is the actual arrangement. We may need to extend the regulator binding slightly and allow for multiple phandles on a supply property, but wouldn't something like this work: led-supply = <&led-reg0>, <&led-reg1>, <&led-reg2>, <&led-reg3>; The shared source is already supported by the regulator binding. >>> >>> >>> >>> I think that we shouldn't split the LED devices into power supply >>> providers and consumers as in case of generic regulators. From this >>> point of view a LED device current output is a provider and a discrete >>> LED element is a consumer. In this approach each discrete LED element >>> should have a related driver which is not how LED devices are being >>> handled in the LED subsystem, where there is a single binding for a LED >>> device and there is a single driver for it which creates separate LED >>> class devices for each LED connected to the LED device output. Each >>> discrete LED is represented by a child node in the LED device binding. >>> >>> I am aware that it may be tempting to treat LED devices as common >>> regulators, but they have their specific features which gave a >>> reason for introducing LED class for them. Besides, there is already >>> drivers/leds/leds-regulator.c driver for LED devices which support only >>> turning on/off and setting brightness level. >>> >>> In your proposition a separate regulator provider binding would have >>> to be created for each current output and a separate binding for >>> each discrete LED connected to the LED device. It would create >>> unnecessary noise in a dts file. >>> >>> Moreover, using regulator binding implies that we want to treat it >>> as a sheer power supply for our device (which would be a discrete LED >>> element in this case), whereas LED devices provide more features like >>> blinking pattern and for flash LED devices - flash timeout, external >>> strobe and flash faults. >> >> >> Okay, fair enough. Please include some of this explanation in the >> binding description. >> >> I do still have some concerns about led-sources and whether it can >> support other scenarios. It is very much
[PATCH 2/2] si2168: add support for 1.7MHz bandwidth
This patch is based on Antti's silabs branch. Add support for 1.7 MHz bandwidth. Supported in all versions of Si2168 according to short data sheets. Signed-off-by: Olli Salonen --- drivers/media/dvb-frontends/si2168.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/dvb-frontends/si2168.c b/drivers/media/dvb-frontends/si2168.c index 7fef5ab..ec893ee 100644 --- a/drivers/media/dvb-frontends/si2168.c +++ b/drivers/media/dvb-frontends/si2168.c @@ -185,6 +185,8 @@ static int si2168_set_frontend(struct dvb_frontend *fe) dev_err(&client->dev, "automatic bandwidth not supported"); goto err; } + else if (c->bandwidth_hz <= 200) + bandwidth = 0x02; else if (c->bandwidth_hz <= 500) bandwidth = 0x05; else if (c->bandwidth_hz <= 600) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] si2168: return error if set_frontend is called with invalid parameters
This patch should is based on Antti's silabs branch.
According to dvb-frontend.h set_frontend may be called with bandwidth_hz set to
0 if automatic bandwidth is required. Si2168 does not support automatic
bandwidth and does not declare FE_CAN_BANDWIDTH_AUTO in caps.
This patch will change the behaviour in a way that EINVAL is returned if
bandwidth_hz is 0.
Cc-to: Antti Palosaari
Signed-off-by: Olli Salonen
---
drivers/media/dvb-frontends/si2168.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 7f966f3..7fef5ab 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -180,7 +180,12 @@ static int si2168_set_frontend(struct dvb_frontend *fe)
goto err;
}
- if (c->bandwidth_hz <= 500)
+ if (c->bandwidth_hz == 0) {
+ ret = -EINVAL;
+ dev_err(&client->dev, "automatic bandwidth not supported");
+ goto err;
+ }
+ else if (c->bandwidth_hz <= 500)
bandwidth = 0x05;
else if (c->bandwidth_hz <= 600)
bandwidth = 0x06;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT FIXES FOR v3.19] Fixes for 3.19
The following changes since commit 99f3cd52aee21091ce62442285a68873e3be833f: [media] vb2-vmalloc: Protect DMA-specific code by #ifdef CONFIG_HAS_DMA (2014-12-23 16:28:09 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.19a for you to fetch changes up to f490fe1a4b4cd0a6454db02e8459d30a2ff02c49: Fix Mygica T230 support (2015-01-16 13:07:28 +0100) Jim Davis (1): media: tlg2300: disable building the driver Jonathan McDowell (1): Fix Mygica T230 support Matthias Schwarzott (1): cx23885: Split Hauppauge WinTV Starburst from HVR4400 card entry drivers/media/pci/cx23885/cx23885-cards.c | 23 +-- drivers/media/pci/cx23885/cx23885-dvb.c | 11 +++ drivers/media/pci/cx23885/cx23885.h | 1 + drivers/media/usb/dvb-usb/cxusb.c | 2 +- drivers/staging/media/tlg2300/Kconfig | 1 + 5 files changed, 31 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.20] Fixes, cleanups, improvements
Hi Mauro, This pull request contains various fixes, cleanups and improvements. The only notable change is the addition of unpacking and logging functions for InfoFrames to drivers/video/hdmi.c. Thierry was OK with taking this via the media tree (http://www.spinics.net/lists/linux-media/msg84655.html) and Acked all patches touching hdmi.c/h. Regards, Hans The following changes since commit 99f3cd52aee21091ce62442285a68873e3be833f: [media] vb2-vmalloc: Protect DMA-specific code by #ifdef CONFIG_HAS_DMA (2014-12-23 16:28:09 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.20a for you to fetch changes up to 2f45da9e0a1b198a99b6e92486a85311920e799d: adv7842: simplify InfoFrame logging (2015-01-16 12:54:55 +0100) Asaf Vertz (1): media: stb0899_drv: use time_after() Dan Carpenter (1): coda: improve safety in coda_register_device() Fabian Frederick (2): tw68: remove unnecessary version.h inclusion vivid: remove unnecessary version.h inclusion Fabio Estevam (2): coda: coda-common: Remove mx53 entry from coda_platform_ids adv7180: Remove the unneeded 'err' label Hans Verkuil (3): videobuf: make unused exported functions static hdmi: add new HDMI 2.0 defines hdmi: rename HDMI_AUDIO_CODING_TYPE_EXT_STREAM to _EXT_CT Ismael Luceno (4): solo6x10: s/unsigned char/u8/ solo6x10: Fix eeprom_* functions buffer's type solo6x10: Fix solo_eeprom_read retval type solo6x10: s/uint8_t/u8/ Julia Lawall (4): au0828: Use setup_timer s2255drv: Use setup_timer usbvision: Use setup_timer pvrusb2: Use setup_timer Martin Bugge (2): hdmi: added unpack and logging functions for InfoFrames adv7842: simplify InfoFrame logging Ondrej Zary (3): bttv: Convert to generic TEA575x interface tea575x: split and export functions bttv: Improve TEA575x support Prabhakar Lad (1): media: Kconfig: drop duplicate dependency of HAS_DMA Rickard Strandqvist (7): media: radio: wl128x: fmdrv_rx.c: Remove unused function media: i2c: adv7604.c: Remove some unused functions media: pci: mantis: mantis_core.c: Remove unused function media: pci: saa7134: saa7134-video.c: Remove unused function media: platform: vsp1: vsp1_hsit: Remove unused function media: i2c: adv7604: Remove some unused functions usb: pvrusb2: pvrusb2-hdw: Remove unused function Wolfram Sang (1): staging: media: bcm2048: Remove obsolete cleanup for clientdata drivers/media/dvb-frontends/stb0899_drv.c | 7 +- drivers/media/i2c/Kconfig | 1 + drivers/media/i2c/adv7180.c| 7 +- drivers/media/i2c/adv7604.c| 76 drivers/media/i2c/adv7842.c| 184 +- drivers/media/i2c/ths8200.c| 10 - drivers/media/pci/bt8xx/Kconfig| 3 + drivers/media/pci/bt8xx/bttv-cards.c | 317 +++--- drivers/media/pci/bt8xx/bttv-driver.c | 37 +++- drivers/media/pci/bt8xx/bttvp.h| 14 +- drivers/media/pci/mantis/mantis_core.c | 23 --- drivers/media/pci/saa7134/saa7134-video.c | 5 - drivers/media/pci/solo6x10/solo6x10-core.c | 4 +- drivers/media/pci/solo6x10/solo6x10-eeprom.c | 2 +- drivers/media/pci/solo6x10/solo6x10-enc.c | 6 +- drivers/media/pci/solo6x10/solo6x10-g723.c | 4 +- drivers/media/pci/solo6x10/solo6x10-jpeg.h | 4 +- drivers/media/pci/solo6x10/solo6x10-tw28.c | 4 +- drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 18 +- drivers/media/pci/solo6x10/solo6x10.h | 4 +- drivers/media/pci/tw68/tw68.h | 1 - drivers/media/platform/Kconfig | 1 - drivers/media/platform/coda/coda-common.c | 6 +- drivers/media/platform/vivid/vivid-tpg.h | 1 - drivers/media/platform/vsp1/vsp1_hsit.c| 5 - drivers/media/radio/tea575x.c | 41 +++- drivers/media/radio/wl128x/fmdrv_rx.c | 16 -- drivers/media/radio/wl128x/fmdrv_rx.h | 1 - drivers/media/usb/au0828/au0828-video.c| 11 +- drivers/media/usb/pvrusb2/pvrusb2-hdw.c| 31 +-- drivers/media/usb/pvrusb2/pvrusb2-hdw.h| 3 - drivers/media/usb/s2255/s2255drv.c | 4 +- drivers/media/usb/usbvision/usbvision-core.c | 5 +- drivers/media/v4l2-core/videobuf-dma-sg.c | 15 +- drivers/staging/media/bcm2048/radio-bcm2048.c | 2 - drivers/video/hdmi.c | 822 - include/linux/hdmi.h | 37 +++- include/media/tea575x.h| 5 + include/media/videobuf-dma-sg.h| 8 - 39 files c
Re: [PATCH] [media] [pvrusb2]: remove dead retry cmd code
Removing 8 years old dead code seemed right to silly me.
On Fri, 2015-01-16 at 12:37 +0100, Hans Verkuil wrote:
> On 01/16/2015 12:29 PM, Haim Daniel wrote:
> > It looks that "if (try_count < 20) continue" jumps to end of the do ...
> > while(0) loop and goes out.
>
> Ah, you are right. But that is obviously not what was intended, so just
> removing
> it is not a proper 'fix'.
>
> Mike, can you take a look at this?
>
> Regards,
>
> Hans
>
> >
> > --hd.
> > On Fri, 2015-01-16 at 11:57 +0100, Hans Verkuil wrote:
> >> On 01/05/2015 11:38 PM, Haim Daniel wrote:
> >>> In case a command is timed out, current flow sets the retry_flag
> >>> and does nothing.
> >>
> >> Really? That's not how I read the code: it retries up to 20 times before
> >> bailing out.
> >>
> >> Perhaps you missed the "if (try_count < 20) continue;" line?
> >>
> >> Regards,
> >>
> >>Hans
> >>
> >>>
> >>> Signed-off-by: Haim Daniel
> >>> ---
> >>> drivers/media/usb/pvrusb2/pvrusb2-encoder.c | 15 +--
> >>> 1 file changed, 1 insertion(+), 14 deletions(-)
> >>>
> >>> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> >>> b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> >>> index f7702ae..02028aa 100644
> >>> --- a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> >>> +++ b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> >>> @@ -145,8 +145,6 @@ static int pvr2_encoder_cmd(void *ctxt,
> >>> u32 *argp)
> >>> {
> >>> unsigned int poll_count;
> >>> - unsigned int try_count = 0;
> >>> - int retry_flag;
> >>> int ret = 0;
> >>> unsigned int idx;
> >>> /* These sizes look to be limited by the FX2 firmware implementation */
> >>> @@ -213,8 +211,6 @@ static int pvr2_encoder_cmd(void *ctxt,
> >>> break;
> >>> }
> >>>
> >>> - retry_flag = 0;
> >>> - try_count++;
> >>> ret = 0;
> >>> wrData[0] = 0;
> >>> wrData[1] = cmd;
> >>> @@ -245,11 +241,9 @@ static int pvr2_encoder_cmd(void *ctxt,
> >>> }
> >>> if (rdData[0] && (poll_count < 1000)) continue;
> >>> if (!rdData[0]) {
> >>> - retry_flag = !0;
> >>> pvr2_trace(
> >>> PVR2_TRACE_ERROR_LEGS,
> >>> - "Encoder timed out waiting for us"
> >>> - "; arranging to retry");
> >>> + "Encoder timed out waiting for us");
> >>> } else {
> >>> pvr2_trace(
> >>> PVR2_TRACE_ERROR_LEGS,
> >>> @@ -269,13 +263,6 @@ static int pvr2_encoder_cmd(void *ctxt,
> >>> ret = -EBUSY;
> >>> break;
> >>> }
> >>> - if (retry_flag) {
> >>> - if (try_count < 20) continue;
> >>> - pvr2_trace(
> >>> - PVR2_TRACE_ERROR_LEGS,
> >>> - "Too many retries...");
> >>> - ret = -EBUSY;
> >>> - }
> >>> if (ret) {
> >>> del_timer_sync(&hdw->encoder_run_timer);
> >>> hdw->state_encoder_ok = 0;
> >>>
> >>
> >
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] [pvrusb2]: remove dead retry cmd code
On 01/16/2015 12:29 PM, Haim Daniel wrote:
> It looks that "if (try_count < 20) continue" jumps to end of the do ...
> while(0) loop and goes out.
Ah, you are right. But that is obviously not what was intended, so just removing
it is not a proper 'fix'.
Mike, can you take a look at this?
Regards,
Hans
>
> --hd.
> On Fri, 2015-01-16 at 11:57 +0100, Hans Verkuil wrote:
>> On 01/05/2015 11:38 PM, Haim Daniel wrote:
>>> In case a command is timed out, current flow sets the retry_flag
>>> and does nothing.
>>
>> Really? That's not how I read the code: it retries up to 20 times before
>> bailing out.
>>
>> Perhaps you missed the "if (try_count < 20) continue;" line?
>>
>> Regards,
>>
>> Hans
>>
>>>
>>> Signed-off-by: Haim Daniel
>>> ---
>>> drivers/media/usb/pvrusb2/pvrusb2-encoder.c | 15 +--
>>> 1 file changed, 1 insertion(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
>>> b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
>>> index f7702ae..02028aa 100644
>>> --- a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
>>> +++ b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
>>> @@ -145,8 +145,6 @@ static int pvr2_encoder_cmd(void *ctxt,
>>> u32 *argp)
>>> {
>>> unsigned int poll_count;
>>> - unsigned int try_count = 0;
>>> - int retry_flag;
>>> int ret = 0;
>>> unsigned int idx;
>>> /* These sizes look to be limited by the FX2 firmware implementation */
>>> @@ -213,8 +211,6 @@ static int pvr2_encoder_cmd(void *ctxt,
>>> break;
>>> }
>>>
>>> - retry_flag = 0;
>>> - try_count++;
>>> ret = 0;
>>> wrData[0] = 0;
>>> wrData[1] = cmd;
>>> @@ -245,11 +241,9 @@ static int pvr2_encoder_cmd(void *ctxt,
>>> }
>>> if (rdData[0] && (poll_count < 1000)) continue;
>>> if (!rdData[0]) {
>>> - retry_flag = !0;
>>> pvr2_trace(
>>> PVR2_TRACE_ERROR_LEGS,
>>> - "Encoder timed out waiting for us"
>>> - "; arranging to retry");
>>> + "Encoder timed out waiting for us");
>>> } else {
>>> pvr2_trace(
>>> PVR2_TRACE_ERROR_LEGS,
>>> @@ -269,13 +263,6 @@ static int pvr2_encoder_cmd(void *ctxt,
>>> ret = -EBUSY;
>>> break;
>>> }
>>> - if (retry_flag) {
>>> - if (try_count < 20) continue;
>>> - pvr2_trace(
>>> - PVR2_TRACE_ERROR_LEGS,
>>> - "Too many retries...");
>>> - ret = -EBUSY;
>>> - }
>>> if (ret) {
>>> del_timer_sync(&hdw->encoder_run_timer);
>>> hdw->state_encoder_ok = 0;
>>>
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] [pvrusb2]: remove dead retry cmd code
It looks that "if (try_count < 20) continue" jumps to end of the do ...
while(0) loop and goes out.
--hd.
On Fri, 2015-01-16 at 11:57 +0100, Hans Verkuil wrote:
> On 01/05/2015 11:38 PM, Haim Daniel wrote:
> > In case a command is timed out, current flow sets the retry_flag
> > and does nothing.
>
> Really? That's not how I read the code: it retries up to 20 times before
> bailing out.
>
> Perhaps you missed the "if (try_count < 20) continue;" line?
>
> Regards,
>
> Hans
>
> >
> > Signed-off-by: Haim Daniel
> > ---
> > drivers/media/usb/pvrusb2/pvrusb2-encoder.c | 15 +--
> > 1 file changed, 1 insertion(+), 14 deletions(-)
> >
> > diff --git a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> > b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> > index f7702ae..02028aa 100644
> > --- a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> > +++ b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> > @@ -145,8 +145,6 @@ static int pvr2_encoder_cmd(void *ctxt,
> > u32 *argp)
> > {
> > unsigned int poll_count;
> > - unsigned int try_count = 0;
> > - int retry_flag;
> > int ret = 0;
> > unsigned int idx;
> > /* These sizes look to be limited by the FX2 firmware implementation */
> > @@ -213,8 +211,6 @@ static int pvr2_encoder_cmd(void *ctxt,
> > break;
> > }
> >
> > - retry_flag = 0;
> > - try_count++;
> > ret = 0;
> > wrData[0] = 0;
> > wrData[1] = cmd;
> > @@ -245,11 +241,9 @@ static int pvr2_encoder_cmd(void *ctxt,
> > }
> > if (rdData[0] && (poll_count < 1000)) continue;
> > if (!rdData[0]) {
> > - retry_flag = !0;
> > pvr2_trace(
> > PVR2_TRACE_ERROR_LEGS,
> > - "Encoder timed out waiting for us"
> > - "; arranging to retry");
> > + "Encoder timed out waiting for us");
> > } else {
> > pvr2_trace(
> > PVR2_TRACE_ERROR_LEGS,
> > @@ -269,13 +263,6 @@ static int pvr2_encoder_cmd(void *ctxt,
> > ret = -EBUSY;
> > break;
> > }
> > - if (retry_flag) {
> > - if (try_count < 20) continue;
> > - pvr2_trace(
> > - PVR2_TRACE_ERROR_LEGS,
> > - "Too many retries...");
> > - ret = -EBUSY;
> > - }
> > if (ret) {
> > del_timer_sync(&hdw->encoder_run_timer);
> > hdw->state_encoder_ok = 0;
> >
>
--
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] BLACKFIN MEDIA DRIVER: rewrite the blackfin style of read/write into common style
Hi Hao,
Why would you do this? read/writew() is AFAICT not the same as bfin_read/write16
(defined in arch/blackfin/include/asm/def_LPBlackfin.h). And all other blackfin
sources I've seen all use bfin_read/write.
So unless there is a good reason for this change I am not going to accept this.
Regards,
Hans
On 01/14/2015 07:57 AM, Hao Liang wrote:
> Signed-off-by: Hao Liang
> ---
> drivers/media/platform/blackfin/ppi.c | 72
> -
> 1 file changed, 35 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/media/platform/blackfin/ppi.c
> b/drivers/media/platform/blackfin/ppi.c
> index cff63e5..de4b5c7 100644
> --- a/drivers/media/platform/blackfin/ppi.c
> +++ b/drivers/media/platform/blackfin/ppi.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -59,10 +60,10 @@ static irqreturn_t ppi_irq_err(int irq, void *dev_id)
> /* register on bf561 is cleared when read
>* others are W1C
>*/
> - status = bfin_read16(®->status);
> + status = readw(®->status);
> if (status & 0x3000)
> ppi->err = true;
> - bfin_write16(®->status, 0xff00);
> + writew(0xff00, ®->status);
> break;
> }
> case PPI_TYPE_EPPI:
> @@ -70,10 +71,10 @@ static irqreturn_t ppi_irq_err(int irq, void *dev_id)
> struct bfin_eppi_regs *reg = info->base;
> unsigned short status;
>
> - status = bfin_read16(®->status);
> + status = readw(®->status);
> if (status & 0x2)
> ppi->err = true;
> - bfin_write16(®->status, 0x);
> + writew(0x, ®->status);
> break;
> }
> case PPI_TYPE_EPPI3:
> @@ -81,10 +82,10 @@ static irqreturn_t ppi_irq_err(int irq, void *dev_id)
> struct bfin_eppi3_regs *reg = info->base;
> unsigned long stat;
>
> - stat = bfin_read32(®->stat);
> + stat = readl(®->stat);
> if (stat & 0x2)
> ppi->err = true;
> - bfin_write32(®->stat, 0xc0ff);
> + writel(0xc0ff, ®->stat);
> break;
> }
> default:
> @@ -139,26 +140,25 @@ static int ppi_start(struct ppi_if *ppi)
> case PPI_TYPE_PPI:
> {
> struct bfin_ppi_regs *reg = info->base;
> - bfin_write16(®->control, ppi->ppi_control);
> + writew(ppi->ppi_control, ®->control);
> break;
> }
> case PPI_TYPE_EPPI:
> {
> struct bfin_eppi_regs *reg = info->base;
> - bfin_write32(®->control, ppi->ppi_control);
> + writel(ppi->ppi_control, ®->control);
> break;
> }
> case PPI_TYPE_EPPI3:
> {
> struct bfin_eppi3_regs *reg = info->base;
> - bfin_write32(®->ctl, ppi->ppi_control);
> + writel(ppi->ppi_control, ®->ctl);
> break;
> }
> default:
> return -EINVAL;
> }
>
> - SSYNC();
> return 0;
> }
>
> @@ -172,19 +172,19 @@ static int ppi_stop(struct ppi_if *ppi)
> case PPI_TYPE_PPI:
> {
> struct bfin_ppi_regs *reg = info->base;
> - bfin_write16(®->control, ppi->ppi_control);
> + writew(ppi->ppi_control, ®->control);
> break;
> }
> case PPI_TYPE_EPPI:
> {
> struct bfin_eppi_regs *reg = info->base;
> - bfin_write32(®->control, ppi->ppi_control);
> + writel(ppi->ppi_control, ®->control);
> break;
> }
> case PPI_TYPE_EPPI3:
> {
> struct bfin_eppi3_regs *reg = info->base;
> - bfin_write32(®->ctl, ppi->ppi_control);
> + writel(ppi->ppi_control, ®->ctl);
> break;
> }
> default:
> @@ -195,7 +195,6 @@ static int ppi_stop(struct ppi_if *ppi)
> clear_dma_irqstat(info->dma_ch);
> disable_dma(info->dma_ch);
>
> - SSYNC();
> return 0;
> }
>
> @@ -242,9 +241,9 @@ static int ppi_set_params(struct ppi_if *ppi, struct
> ppi_params *params)
> if (params->ppi_control & DMA32)
> dma32 = 1;
>
> - bfin_write16(®->control, ppi->ppi_control);
> - bfin_write16(®->count, samples_per_line - 1);
> - bfin_write16(®->frame, params->frame);
> + writew(ppi->ppi_control, ®->control);
> + writew(samples_per_line - 1, ®->count);
> + writew(params->frame, ®->frame);
> break;
> }
> case PPI_TYPE_EPPI:
> @@ -255,13 +254,13 @@ static int ppi_set_params(struct ppi_if *ppi, struct
> ppi_params *params)
> || (params->ppi_control & 0x38000) > DLEN_16)
> dma32 = 1;
>
[PATCH v2 1/2] dvb: tua6034: add a new driver for Infineon tua6034 tuner
From: Akihiro Tsukada
this 3-band tuner is used in Friio (dvb-usb-friio),
and it was buried in friio-fe.c.
Signed-off-by: Akihiro Tsukada
---
drivers/media/tuners/Kconfig | 7 +
drivers/media/tuners/Makefile | 1 +
drivers/media/tuners/tua6034.c | 464 +
drivers/media/tuners/tua6034.h | 113 ++
4 files changed, 585 insertions(+)
create mode 100644 drivers/media/tuners/tua6034.c
create mode 100644 drivers/media/tuners/tua6034.h
diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
index 42e5a01..6c15d28 100644
--- a/drivers/media/tuners/Kconfig
+++ b/drivers/media/tuners/Kconfig
@@ -282,4 +282,11 @@ config MEDIA_TUNER_QM1D1C0042
default m if !MEDIA_SUBDRV_AUTOSELECT
help
Sharp QM1D1C0042 trellis coded 8PSK tuner driver.
+
+config MEDIA_TUNER_TUA6034
+ tristate "Infineon TUA6034 tuner"
+ depends on MEDIA_SUPPORT && I2C
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+ help
+ Infineon TUA6034 3-band ditigal TV tuner driver.
endmenu
diff --git a/drivers/media/tuners/Makefile b/drivers/media/tuners/Makefile
index da4fe6e..8c95c08 100644
--- a/drivers/media/tuners/Makefile
+++ b/drivers/media/tuners/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_MEDIA_TUNER_R820T) += r820t.o
obj-$(CONFIG_MEDIA_TUNER_MXL301RF) += mxl301rf.o
obj-$(CONFIG_MEDIA_TUNER_QM1D1C0042) += qm1d1c0042.o
obj-$(CONFIG_MEDIA_TUNER_M88RS6000T) += m88rs6000t.o
+obj-$(CONFIG_MEDIA_TUNER_TUA6034) += tua6034.o
ccflags-y += -I$(srctree)/drivers/media/dvb-core
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
diff --git a/drivers/media/tuners/tua6034.c b/drivers/media/tuners/tua6034.c
new file mode 100644
index 000..7cbc185
--- /dev/null
+++ b/drivers/media/tuners/tua6034.c
@@ -0,0 +1,464 @@
+/*
+ * Infineon TUA6034 terrestial tuner driver
+ *
+ * Copyright (C) 2014 Akihiro Tsukada
+ *
+ * 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 version 2.
+ *
+ *
+ * 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.
+ */
+
+#include
+#include "dvb_i2c.h"
+#include "tua6034.h"
+
+#define TUA6034_XTL_FREQ 400
+
+struct tua6034_state {
+ struct tua6034_config cfg;
+ struct i2c_client *i2c;
+
+ /* current parameters (except frequency divider) */
+ u8 ctrl_byte;
+ u8 band_sw_byte;
+ u8 aux_byte;
+};
+
+struct def_param {
+ /* for auto "band" selection */
+ u32 band_sw_freq[4]; /* fmin, flow_mid, fmid_high, fmax */
+
+ /* for auto "CP current" selection */
+ /* band:[low, mid, high] x cp:[50uA/125uA,125uA/250uA,250uA/650uA] */
+ u32 cp_sw_freq[3][3];
+ u32 if_freq;
+ u32 if_bw;
+ enum tua6034_ref_div ref_div;
+};
+
+/* per-DELSYS default configuration */
+static const struct def_param def_cfgs[] = {
+ /* ISDB-T */
+ {
+ .band_sw_freq = {9000, 17000, 47000, 9},
+ .cp_sw_freq = {
+ {0, 0, 17000},
+ {0, 27000, 37000},
+ {0, 0, 67000}
+ },
+
+ .if_freq = 5700,
+ .if_bw = 600,
+ .ref_div = TUA6034_REF_DIV_1_28,
+ },
+
+ /* DVB-T */
+ {
+ .band_sw_freq = {4425, 15750, 44300, 9},
+ .cp_sw_freq = {
+ {0, 14050, 15750},
+ {0, 44300, 0},
+ {0, 80200, 9}
+ },
+
+ .if_freq = 36125000,
+ .if_bw = 800,
+ .ref_div = TUA6034_REF_DIV_1_24,
+ },
+
+ /* ATSC */
+ {
+ .band_sw_freq = {5000, 16000, 45400, 9},
+ .cp_sw_freq = {
+ {0, 16000, 0},
+ {0, 45400, 0},
+ {0, 9, 0}
+ },
+
+ .if_freq = 4400,
+ .if_bw = 600,
+ .ref_div = TUA6034_REF_DIV_1_64,
+ },
+};
+
+
+static int raw_write(struct tua6034_state *state, const u8 *buf, int len)
+{
+ int ret;
+
+ ret = i2c_master_send(state->i2c, buf, len);
+ if (ret >= 0 && ret < len)
+ ret = -EIO;
+ return (ret == len) ? 0 : ret;
+}
+
+static int raw_read(struct tua6034_state *state, u8 *val)
+{
+ int ret;
+
+ ret = i2c_master_recv(state->i2c, val, 1);
+ if (ret >= 0 && ret < 1)
+ ret = -EIO;
+ return (ret == 1) ? 0 : ret;
+}
+
+static int calc_ctrl_bytes(struct tua6034_state *state, u32 freq)
+{
+
[PATCH v2 2/2] dvb-usb-friio: split and merge into dvb-usbv2-gl861
From: Akihiro Tsukada
A Friio device consists of a GL861 adapter/bridge chip,
a TC90522 demod chip and a TUA6034 tuner chip, but
the friio driver was implemented as one combined driver.
This patch separates off the each chip drivers and
re-uses the existing modules: dvb-usbv2-gl861,tc90522.
It also adds some modifications to gl861,
to support the black-boxed init/config of friio devices and
implement an usb vendor request that is used for
relay'ed i2c communications to a tuner via a demod.
Signed-off-by: Akihiro Tsukada
---
drivers/media/usb/dvb-usb-v2/Kconfig | 5 +-
drivers/media/usb/dvb-usb-v2/Makefile | 2 +-
drivers/media/usb/dvb-usb-v2/gl861-friio.c | 320 ++
drivers/media/usb/dvb-usb-v2/gl861.c | 125 ++-
drivers/media/usb/dvb-usb-v2/gl861.h | 11 +
drivers/media/usb/dvb-usb/Kconfig | 6 -
drivers/media/usb/dvb-usb/Makefile | 3 -
drivers/media/usb/dvb-usb/friio-fe.c | 472 --
drivers/media/usb/dvb-usb/friio.c | 522 -
drivers/media/usb/dvb-usb/friio.h | 99 --
10 files changed, 447 insertions(+), 1118 deletions(-)
create mode 100644 drivers/media/usb/dvb-usb-v2/gl861-friio.c
delete mode 100644 drivers/media/usb/dvb-usb/friio-fe.c
delete mode 100644 drivers/media/usb/dvb-usb/friio.c
delete mode 100644 drivers/media/usb/dvb-usb/friio.h
diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
b/drivers/media/usb/dvb-usb-v2/Kconfig
index 7423033..79694d3 100644
--- a/drivers/media/usb/dvb-usb-v2/Kconfig
+++ b/drivers/media/usb/dvb-usb-v2/Kconfig
@@ -95,10 +95,13 @@ config DVB_USB_GL861
tristate "Genesys Logic GL861 USB2.0 support"
depends on DVB_USB_V2
select DVB_ZL10353 if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_TC90522 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT
+ select MEDIA_TUNER_TUA6034 if MEDIA_SUBDRV_AUTOSELECT
help
Say Y here to support the MSI Megasky 580 (55801) DVB-T USB2.0
- receiver with USB ID 0db0:5581.
+ receiver with USB ID 0db0:5581, or 774 Friio White ISDB-T
+ USB2.0 receiver with USB ID 7a69:0001.
config DVB_USB_LME2510
tristate "LME DM04/QQBOX DVB-S USB2.0 support"
diff --git a/drivers/media/usb/dvb-usb-v2/Makefile
b/drivers/media/usb/dvb-usb-v2/Makefile
index f10d4df..70c0c9f 100644
--- a/drivers/media/usb/dvb-usb-v2/Makefile
+++ b/drivers/media/usb/dvb-usb-v2/Makefile
@@ -25,7 +25,7 @@ obj-$(CONFIG_DVB_USB_EC168) += dvb-usb-ec168.o
dvb-usb-lmedm04-objs := lmedm04.o
obj-$(CONFIG_DVB_USB_LME2510) += dvb-usb-lmedm04.o
-dvb-usb-gl861-objs := gl861.o
+dvb-usb-gl861-objs := gl861.o gl861-friio.o
obj-$(CONFIG_DVB_USB_GL861) += dvb-usb-gl861.o
dvb-usb-mxl111sf-objs += mxl111sf.o mxl111sf-phy.o mxl111sf-i2c.o
diff --git a/drivers/media/usb/dvb-usb-v2/gl861-friio.c
b/drivers/media/usb/dvb-usb-v2/gl861-friio.c
new file mode 100644
index 000..bf66aff
--- /dev/null
+++ b/drivers/media/usb/dvb-usb-v2/gl861-friio.c
@@ -0,0 +1,320 @@
+/*
+ * GL861 DTV USB bridge driver
+ * "Friio White" specific part
+ * Copyright (C) 2014 Akihiro Tsukada
+ *
+ * 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 version 2.
+ *
+ *
+ * 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.
+ */
+
+#include "dvb_i2c.h"
+#include "dvb_frontend.h"
+
+#include "gl861.h"
+#include "tc90522.h"
+#include "tua6034.h"
+
+struct friio_priv {
+ struct i2c_client *i2c_client_demod;
+ struct i2c_adapter *demod_sub_i2c;
+};
+
+struct friio_config {
+ struct i2c_board_info demod_info;
+ struct tc90522_config demod_cfg;
+
+ struct i2c_board_info tuner_info;
+ struct tua6034_config tuner_cfg;
+};
+
+static const struct friio_config friio_config = {
+ .demod_info = { I2C_BOARD_INFO(TC90522_I2C_DEV_TER, 0x18), },
+ .tuner_info = { I2C_BOARD_INFO("tua6034", 0x60), },
+ .tuner_cfg = {
+ .agc_tkov = TUA6034_AGC_103dBuV,
+ .ports = TUA6034_PORT4_ON,
+ .cp_cur = TUA6034_CP_50uA,
+ },
+};
+
+
+#define FRIIO_CTL_LNB (1 << 0)
+#define FRIIO_CTL_STROBE (1 << 1)
+#define FRIIO_CTL_CLK (1 << 2)
+#define FRIIO_CTL_LED (1 << 3)
+
+#define FRIIO_LED_RUNNING 0x6400ff64
+#define FRIIO_LED_STOPPED 0x96ff00ff
+
+/* control PIC16F676 attached to this chip */
+static int friio_ext_ctl(struct dvb_usb_device *d,
+ u32 sat_color, int power_on)
+{
+ int i, ret;
+ struct i2c_msg msg;
+ u8 *buf;
+ u32 mask;
+ u8 power = (power_on) ? FRIIO_CTL_LNB : 0;
+
+ buf = kmalloc(2, GFP_KERNEL);
+
[PATCH v2 0/2] split dvb-usb-friio into parts
From: Akihiro Tsukada This patch series decomposes the friio driver which was monolithic into adapter,demod,tuner modules. Changes in v2: - dvb-usbv2-gl861: adapt to i2c template patch v3, fe_i2c_client was moved from dvb_frontend* to priv Akihiro Tsukada (2): dvb: tua6034: add a new driver for Infineon tua6034 tuner dvb-usb-friio: split and merge into dvb-usbv2-gl861 drivers/media/tuners/Kconfig | 7 + drivers/media/tuners/Makefile | 1 + drivers/media/tuners/tua6034.c | 464 + drivers/media/tuners/tua6034.h | 113 +++ drivers/media/usb/dvb-usb-v2/Kconfig | 5 +- drivers/media/usb/dvb-usb-v2/Makefile | 2 +- drivers/media/usb/dvb-usb-v2/gl861-friio.c | 320 ++ drivers/media/usb/dvb-usb-v2/gl861.c | 125 ++- drivers/media/usb/dvb-usb-v2/gl861.h | 11 + drivers/media/usb/dvb-usb/Kconfig | 6 - drivers/media/usb/dvb-usb/Makefile | 3 - drivers/media/usb/dvb-usb/friio-fe.c | 472 -- drivers/media/usb/dvb-usb/friio.c | 522 - drivers/media/usb/dvb-usb/friio.h | 99 -- 14 files changed, 1032 insertions(+), 1118 deletions(-) create mode 100644 drivers/media/tuners/tua6034.c create mode 100644 drivers/media/tuners/tua6034.h create mode 100644 drivers/media/usb/dvb-usb-v2/gl861-friio.c delete mode 100644 drivers/media/usb/dvb-usb/friio-fe.c delete mode 100644 drivers/media/usb/dvb-usb/friio.c delete mode 100644 drivers/media/usb/dvb-usb/friio.h -- 2.2.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
Re: [PATCH 2/2] [media] adv7180: Remove the unneeded 'err' label
On 12/16/2014 05:49 PM, Fabio Estevam wrote: There is no need to jump to the 'err' label as we can simply return the error code directly and make the code shorter. Signed-off-by: Fabio Estevam Acked-by: Lars-Peter Clausen -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] dvb: tc90522: use dvb-core i2c binding model template
From: Akihiro Tsukada
Signed-off-by: Akihiro Tsukada
---
drivers/media/dvb-frontends/tc90522.c | 64 ---
drivers/media/dvb-frontends/tc90522.h | 8 ++---
2 files changed, 34 insertions(+), 38 deletions(-)
diff --git a/drivers/media/dvb-frontends/tc90522.c
b/drivers/media/dvb-frontends/tc90522.c
index b35d65c..123f42d 100644
--- a/drivers/media/dvb-frontends/tc90522.c
+++ b/drivers/media/dvb-frontends/tc90522.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include "dvb_i2c.h"
#include "dvb_math.h"
#include "tc90522.h"
@@ -39,7 +40,6 @@
struct tc90522_state {
struct tc90522_config cfg;
- struct dvb_frontend fe;
struct i2c_client *i2c_client;
struct i2c_adapter tuner_i2c;
@@ -98,11 +98,6 @@ static int reg_read(struct tc90522_state *state, u8 reg, u8
*val, u8 len)
return ret;
}
-static struct tc90522_state *cfg_to_state(struct tc90522_config *c)
-{
- return container_of(c, struct tc90522_state, cfg);
-}
-
static int tc90522s_set_tsid(struct dvb_frontend *fe)
{
@@ -512,7 +507,7 @@ static int tc90522_set_frontend(struct dvb_frontend *fe)
return 0;
failed:
- dev_warn(&state->tuner_i2c.dev, "(%s) failed. [adap%d-fe%d]\n",
+ dev_warn(&state->i2c_client->dev, "(%s) failed. [adap%d-fe%d]\n",
__func__, fe->dvb->num, fe->id);
return ret;
}
@@ -587,7 +582,7 @@ static int tc90522_sleep(struct dvb_frontend *fe)
}
}
if (ret < 0)
- dev_warn(&state->tuner_i2c.dev,
+ dev_warn(&state->i2c_client->dev,
"(%s) failed. [adap%d-fe%d]\n",
__func__, fe->dvb->num, fe->id);
return ret;
@@ -620,7 +615,7 @@ static int tc90522_init(struct dvb_frontend *fe)
}
}
if (ret < 0) {
- dev_warn(&state->tuner_i2c.dev,
+ dev_warn(&state->i2c_client->dev,
"(%s) failed. [adap%d-fe%d]\n",
__func__, fe->dvb->num, fe->id);
return ret;
@@ -640,6 +635,7 @@ static int tc90522_init(struct dvb_frontend *fe)
static int
tc90522_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
{
+ struct dvb_frontend *fe;
struct tc90522_state *state;
struct i2c_msg *new_msgs;
int i, j;
@@ -658,7 +654,8 @@ tc90522_master_xfer(struct i2c_adapter *adap, struct
i2c_msg *msgs, int num)
if (!new_msgs)
return -ENOMEM;
- state = i2c_get_adapdata(adap);
+ fe = i2c_get_adapdata(adap);
+ state = fe->demodulator_priv;
p = wbuf;
bufend = wbuf + sizeof(wbuf);
for (i = 0, j = 0; i < num; i++, j++) {
@@ -766,51 +763,51 @@ static const struct dvb_frontend_ops tc90522_ops_ter = {
static int tc90522_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
+ struct dvb_frontend *fe;
struct tc90522_state *state;
- struct tc90522_config *cfg;
+ struct dvb_i2c_dev_config *cfg;
const struct dvb_frontend_ops *ops;
struct i2c_adapter *adap;
int ret;
- state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (!state)
- return -ENOMEM;
+ fe = i2c_get_clientdata(client);
+ state = fe->demodulator_priv;
state->i2c_client = client;
cfg = client->dev.platform_data;
- memcpy(&state->cfg, cfg, sizeof(state->cfg));
- cfg->fe = state->cfg.fe = &state->fe;
+ if (cfg && cfg->priv_cfg)
+ memcpy(&state->cfg, cfg->priv_cfg, sizeof(state->cfg));
ops = id->driver_data == 0 ? &tc90522_ops_sat : &tc90522_ops_ter;
- memcpy(&state->fe.ops, ops, sizeof(*ops));
- state->fe.demodulator_priv = state;
+ memcpy(&fe->ops, ops, sizeof(*ops));
adap = &state->tuner_i2c;
adap->owner = THIS_MODULE;
adap->algo = &tc90522_tuner_i2c_algo;
adap->dev.parent = &client->dev;
strlcpy(adap->name, "tc90522_sub", sizeof(adap->name));
- i2c_set_adapdata(adap, state);
ret = i2c_add_adapter(adap);
if (ret < 0)
- goto err;
- cfg->tuner_i2c = state->cfg.tuner_i2c = adap;
+ goto err_mem;
+ if (cfg && cfg->out)
+ *cfg->out = (struct tc90522_out *)adap;
+ i2c_set_adapdata(adap, fe); /* used in tc90522_master_xfer() */
- i2c_set_clientdata(client, &state->cfg);
dev_info(&client->dev, "Toshiba TC90522 attached.\n");
return 0;
-err:
+err_mem:
kfree(state);
return ret;
}
static int tc90522_remove(struct i2c_client *client)
{
+ struct dvb_frontend *fe;
struct tc90522_state *state;
- state = cfg_to_state(i2c_get_clientdata(client));
+ fe = i2c_get_clientdata(client);
+ state = fe->demodulator_priv;
i2c_del_adapter(&state->tuner_i2c);
- kf
[PATCH v3 4/4] dvb: earth-pt3: use dvb-core i2c binding model template
From: Akihiro Tsukada
Signed-off-by: Akihiro Tsukada
---
drivers/media/pci/pt3/pt3.c | 85 ++---
drivers/media/pci/pt3/pt3.h | 11 +++---
2 files changed, 32 insertions(+), 64 deletions(-)
diff --git a/drivers/media/pci/pt3/pt3.c b/drivers/media/pci/pt3/pt3.c
index 7a37e8f..f21009d 100644
--- a/drivers/media/pci/pt3/pt3.c
+++ b/drivers/media/pci/pt3/pt3.c
@@ -26,6 +26,7 @@
#include "dvbdev.h"
#include "dvb_demux.h"
#include "dvb_frontend.h"
+#include "dvb_i2c.h"
#include "pt3.h"
@@ -375,67 +376,40 @@ static int pt3_fe_init(struct pt3_board *pt3)
static int pt3_attach_fe(struct pt3_board *pt3, int i)
{
- struct i2c_board_info info;
- struct tc90522_config cfg;
- struct i2c_client *cl;
+ struct dvb_frontend *fe;
+ struct tc90522_out *out;
+ struct i2c_client *demod_cl, *tuner_cl;
struct dvb_adapter *dvb_adap;
int ret;
- info = adap_conf[i].demod_info;
- cfg = adap_conf[i].demod_cfg;
- cfg.tuner_i2c = NULL;
- info.platform_data = &cfg;
+ out = NULL;
+ demod_cl = dvb_i2c_attach_fe(&pt3->i2c_adap, &adap_conf[i].demod_info,
+&adap_conf[i].demod_cfg, (void **)&out);
+ if (!demod_cl)
+ return -ENODEV;
ret = -ENODEV;
- request_module("tc90522");
- cl = i2c_new_device(&pt3->i2c_adap, &info);
- if (!cl || !cl->dev.driver)
- return -ENODEV;
- pt3->adaps[i]->i2c_demod = cl;
- if (!try_module_get(cl->dev.driver->owner))
- goto err_demod_i2c_unregister_device;
-
- if (!strncmp(cl->name, TC90522_I2C_DEV_SAT, sizeof(cl->name))) {
- struct qm1d1c0042_config tcfg;
-
- tcfg = adap_conf[i].tuner_cfg.qm1d1c0042;
- tcfg.fe = cfg.fe;
- info = adap_conf[i].tuner_info;
- info.platform_data = &tcfg;
- request_module("qm1d1c0042");
- cl = i2c_new_device(cfg.tuner_i2c, &info);
- } else {
- struct mxl301rf_config tcfg;
-
- tcfg = adap_conf[i].tuner_cfg.mxl301rf;
- tcfg.fe = cfg.fe;
- info = adap_conf[i].tuner_info;
- info.platform_data = &tcfg;
- request_module("mxl301rf");
- cl = i2c_new_device(cfg.tuner_i2c, &info);
- }
- if (!cl || !cl->dev.driver)
- goto err_demod_module_put;
- pt3->adaps[i]->i2c_tuner = cl;
- if (!try_module_get(cl->dev.driver->owner))
- goto err_tuner_i2c_unregister_device;
+ if (!out)
+ goto err;
+ fe = dvb_i2c_to_fe(demod_cl);
+ tuner_cl = dvb_i2c_attach_tuner(&(out->demod_bus),
+ &adap_conf[i].tuner_info, fe,
+ &adap_conf[i].tuner_cfg, NULL);
+ if (!tuner_cl)
+ goto err;
dvb_adap = &pt3->adaps[one_adapter ? 0 : i]->dvb_adap;
- ret = dvb_register_frontend(dvb_adap, cfg.fe);
+ ret = dvb_register_frontend(dvb_adap, fe);
if (ret < 0)
- goto err_tuner_module_put;
- pt3->adaps[i]->fe = cfg.fe;
+ goto err;
+ pt3->adaps[i]->fe = fe;
+ pt3->adaps[i]->i2c_demod = demod_cl;
return 0;
-err_tuner_module_put:
- module_put(pt3->adaps[i]->i2c_tuner->dev.driver->owner);
-err_tuner_i2c_unregister_device:
- i2c_unregister_device(pt3->adaps[i]->i2c_tuner);
-err_demod_module_put:
- module_put(pt3->adaps[i]->i2c_demod->dev.driver->owner);
-err_demod_i2c_unregister_device:
- i2c_unregister_device(pt3->adaps[i]->i2c_demod);
-
+err:
+ /* tuner i2c_client is unregister'ed as well, */
+ /* because it is a (grand) child of the demod i2c_client device */
+ i2c_unregister_device(demod_cl);
return ret;
}
@@ -630,17 +604,10 @@ static void pt3_cleanup_adapter(struct pt3_board *pt3,
int index)
dmx = &adap->demux.dmx;
dmx->close(dmx);
if (adap->fe) {
- adap->fe->callback = NULL;
if (adap->fe->frontend_priv)
dvb_unregister_frontend(adap->fe);
- if (adap->i2c_tuner) {
- module_put(adap->i2c_tuner->dev.driver->owner);
- i2c_unregister_device(adap->i2c_tuner);
- }
- if (adap->i2c_demod) {
- module_put(adap->i2c_demod->dev.driver->owner);
+ if (adap->i2c_demod)
i2c_unregister_device(adap->i2c_demod);
- }
}
pt3_free_dmabuf(adap);
dvb_dmxdev_release(&adap->dmxdev);
diff --git a/drivers/media/pci/pt3/pt3.h b/drivers/media/pci/pt3/pt3.h
index 1b3f2ad..86eafd7 100644
--- a/drivers/media/pci/pt3/pt3.h
+++ b/drivers/media/pci/pt3/pt3.h
@@ -104,15 +104,17 @@ struct dma_data_buffer {
/*
* device things
*/
+union
[PATCH v3 1/4] dvb: qm1d1c0042: use dvb-core i2c binding model template
From: Akihiro Tsukada
Signed-off-by: Akihiro Tsukada
---
drivers/media/tuners/qm1d1c0042.c | 60 +--
drivers/media/tuners/qm1d1c0042.h | 2 --
2 files changed, 19 insertions(+), 43 deletions(-)
diff --git a/drivers/media/tuners/qm1d1c0042.c
b/drivers/media/tuners/qm1d1c0042.c
index 18bc745..b6d637d 100644
--- a/drivers/media/tuners/qm1d1c0042.c
+++ b/drivers/media/tuners/qm1d1c0042.c
@@ -29,6 +29,7 @@
#include
#include
+#include "dvb_i2c.h"
#include "qm1d1c0042.h"
#define QM1D1C0042_NUM_REGS 0x20
@@ -55,11 +56,6 @@ struct qm1d1c0042_state {
u8 regs[QM1D1C0042_NUM_REGS];
};
-static struct qm1d1c0042_state *cfg_to_state(struct qm1d1c0042_config *c)
-{
- return container_of(c, struct qm1d1c0042_state, cfg);
-}
-
static int reg_write(struct qm1d1c0042_state *state, u8 reg, u8 val)
{
u8 wbuf[2] = { reg, val };
@@ -106,10 +102,12 @@ static int qm1d1c0042_set_srch_mode(struct
qm1d1c0042_state *state, bool fast)
return reg_write(state, 0x03, state->regs[0x03]);
}
-static int qm1d1c0042_wakeup(struct qm1d1c0042_state *state)
+static int qm1d1c0042_wakeup(struct dvb_frontend *fe)
{
+ struct qm1d1c0042_state *state;
int ret;
+ state = fe->tuner_priv;
state->regs[0x01] |= 1 << 3; /* BB_Reg_enable */
state->regs[0x01] &= (~(1 << 0)) & 0xff; /* NORMAL (wake-up) */
state->regs[0x05] &= (~(1 << 3)) & 0xff; /* pfd_rst NORMAL */
@@ -119,7 +117,7 @@ static int qm1d1c0042_wakeup(struct qm1d1c0042_state *state)
if (ret < 0)
dev_warn(&state->i2c->dev, "(%s) failed. [adap%d-fe%d]\n",
- __func__, state->cfg.fe->dvb->num, state->cfg.fe->id);
+ __func__, fe->dvb->num, fe->id);
return ret;
}
@@ -133,9 +131,6 @@ static int qm1d1c0042_set_config(struct dvb_frontend *fe,
void *priv_cfg)
state = fe->tuner_priv;
cfg = priv_cfg;
- if (cfg->fe)
- state->cfg.fe = cfg->fe;
-
if (cfg->xtal_freq != QM1D1C0042_CFG_XTAL_DFLT)
dev_warn(&state->i2c->dev,
"(%s) changing xtal_freq not supported. ", __func__);
@@ -359,7 +354,7 @@ static int qm1d1c0042_init(struct dvb_frontend *fe)
goto failed;
}
- ret = qm1d1c0042_wakeup(state);
+ ret = qm1d1c0042_wakeup(fe);
if (ret < 0)
goto failed;
@@ -395,33 +390,18 @@ static const struct dvb_tuner_ops qm1d1c0042_ops = {
static int qm1d1c0042_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct qm1d1c0042_state *state;
- struct qm1d1c0042_config *cfg;
+ struct dvb_i2c_tuner_config *cfg;
struct dvb_frontend *fe;
-
- state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (!state)
- return -ENOMEM;
- state->i2c = client;
+ struct qm1d1c0042_state *state;
cfg = client->dev.platform_data;
fe = cfg->fe;
- fe->tuner_priv = state;
- qm1d1c0042_set_config(fe, cfg);
- memcpy(&fe->ops.tuner_ops, &qm1d1c0042_ops, sizeof(qm1d1c0042_ops));
+ state = fe->tuner_priv;
+ state->i2c = client;
- i2c_set_clientdata(client, &state->cfg);
- dev_info(&client->dev, "Sharp QM1D1C0042 attached.\n");
- return 0;
-}
+ qm1d1c0042_set_config(fe, (void *)cfg->devcfg.priv_cfg);
-static int qm1d1c0042_remove(struct i2c_client *client)
-{
- struct qm1d1c0042_state *state;
-
- state = cfg_to_state(i2c_get_clientdata(client));
- state->cfg.fe->tuner_priv = NULL;
- kfree(state);
+ dev_info(&client->dev, "Sharp QM1D1C0042 attached.\n");
return 0;
}
@@ -430,18 +410,16 @@ static const struct i2c_device_id qm1d1c0042_id[] = {
{"qm1d1c0042", 0},
{}
};
-MODULE_DEVICE_TABLE(i2c, qm1d1c0042_id);
-static struct i2c_driver qm1d1c0042_driver = {
- .driver = {
- .name = "qm1d1c0042",
- },
- .probe = qm1d1c0042_probe,
- .remove = qm1d1c0042_remove,
- .id_table = qm1d1c0042_id,
+static const struct dvb_i2c_module_param qm1d1c0042_param = {
+ .ops.tuner_ops = &qm1d1c0042_ops,
+ .priv_probe = qm1d1c0042_probe,
+
+ .priv_size = sizeof(struct qm1d1c0042_state),
+ .is_tuner = true,
};
-module_i2c_driver(qm1d1c0042_driver);
+DEFINE_DVB_I2C_MODULE(qm1d1c0042, qm1d1c0042_id, qm1d1c0042_param);
MODULE_DESCRIPTION("Sharp QM1D1C0042 tuner");
MODULE_AUTHOR("Akihiro TSUKADA");
diff --git a/drivers/media/tuners/qm1d1c0042.h
b/drivers/media/tuners/qm1d1c0042.h
index 4f5c188..043787e 100644
--- a/drivers/media/tuners/qm1d1c0042.h
+++ b/drivers/media/tuners/qm1d1c0042.h
@@ -21,8 +21,6 @@
struct qm1d1c0042_config {
- struct dvb_frontend *fe;
-
u32 xtal_freq;/* [kHz] */ /* currently ignored */
bool lpf; /* enable LPF
[PATCH v3 2/4] dvb: mxl301rf: use dvb-core i2c binding model template
From: Akihiro Tsukada
Signed-off-by: Akihiro Tsukada
---
drivers/media/tuners/mxl301rf.c | 50 +++--
drivers/media/tuners/mxl301rf.h | 2 +-
2 files changed, 14 insertions(+), 38 deletions(-)
diff --git a/drivers/media/tuners/mxl301rf.c b/drivers/media/tuners/mxl301rf.c
index 1575a5d..d94a692 100644
--- a/drivers/media/tuners/mxl301rf.c
+++ b/drivers/media/tuners/mxl301rf.c
@@ -29,6 +29,8 @@
*/
#include
+#include "dvb_i2c.h"
+
#include "mxl301rf.h"
struct mxl301rf_state {
@@ -36,11 +38,6 @@ struct mxl301rf_state {
struct i2c_client *i2c;
};
-static struct mxl301rf_state *cfg_to_state(struct mxl301rf_config *c)
-{
- return container_of(c, struct mxl301rf_state, cfg);
-}
-
static int raw_write(struct mxl301rf_state *state, const u8 *buf, int len)
{
int ret;
@@ -295,54 +292,33 @@ static const struct dvb_tuner_ops mxl301rf_ops = {
static int mxl301rf_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
+ struct dvb_i2c_tuner_config *cfg;
struct mxl301rf_state *state;
- struct mxl301rf_config *cfg;
- struct dvb_frontend *fe;
- state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (!state)
- return -ENOMEM;
-
- state->i2c = client;
cfg = client->dev.platform_data;
+ state = cfg->fe->tuner_priv;
+ state->i2c = client;
- memcpy(&state->cfg, cfg, sizeof(state->cfg));
- fe = cfg->fe;
- fe->tuner_priv = state;
- memcpy(&fe->ops.tuner_ops, &mxl301rf_ops, sizeof(mxl301rf_ops));
+ memcpy(&state->cfg, cfg->devcfg.priv_cfg, sizeof(state->cfg));
- i2c_set_clientdata(client, &state->cfg);
dev_info(&client->dev, "MaxLinear MxL301RF attached.\n");
return 0;
}
-static int mxl301rf_remove(struct i2c_client *client)
-{
- struct mxl301rf_state *state;
-
- state = cfg_to_state(i2c_get_clientdata(client));
- state->cfg.fe->tuner_priv = NULL;
- kfree(state);
- return 0;
-}
-
-
static const struct i2c_device_id mxl301rf_id[] = {
{"mxl301rf", 0},
{}
};
-MODULE_DEVICE_TABLE(i2c, mxl301rf_id);
-static struct i2c_driver mxl301rf_driver = {
- .driver = {
- .name = "mxl301rf",
- },
- .probe = mxl301rf_probe,
- .remove = mxl301rf_remove,
- .id_table = mxl301rf_id,
+static const struct dvb_i2c_module_param mxl301rf_param = {
+ .ops.tuner_ops = &mxl301rf_ops,
+ .priv_probe = mxl301rf_probe,
+
+ .priv_size = sizeof(struct mxl301rf_state),
+ .is_tuner = true,
};
-module_i2c_driver(mxl301rf_driver);
+DEFINE_DVB_I2C_MODULE(mxl301rf, mxl301rf_id, mxl301rf_param);
MODULE_DESCRIPTION("MaxLinear MXL301RF tuner");
MODULE_AUTHOR("Akihiro TSUKADA");
diff --git a/drivers/media/tuners/mxl301rf.h b/drivers/media/tuners/mxl301rf.h
index 19e6840..069a6a0 100644
--- a/drivers/media/tuners/mxl301rf.h
+++ b/drivers/media/tuners/mxl301rf.h
@@ -20,7 +20,7 @@
#include "dvb_frontend.h"
struct mxl301rf_config {
- struct dvb_frontend *fe;
+ /* none now */
};
#endif /* MXL301RF_H */
--
2.2.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 v3 0/4] modify earth-pt3 and its dependees to use i2c template
From: Akihiro Tsukada This patch series depends on the previous patch: "[PATCH v3]dvb-core: add template code for i2c binding model" The adapter(earth-pt3), its demod (tc90522) and tuners (mxl301rf, qm1d1c0042) are ported to dvb-core i2c template. Changes in v3: - tc90522,earth-pt3: adapt to i2c template patch v3, moved fe_i2c_client from dvb_frontend* to state Akihiro Tsukada (4): dvb: qm1d1c0042: use dvb-core i2c binding model template dvb: mxl301rf: use dvb-core i2c binding model template dvb: tc90522: use dvb-core i2c binding model template dvb: earth-pt3: use dvb-core i2c binding model template drivers/media/dvb-frontends/tc90522.c | 64 +- drivers/media/dvb-frontends/tc90522.h | 8 ++-- drivers/media/pci/pt3/pt3.c | 85 +++ drivers/media/pci/pt3/pt3.h | 11 ++--- drivers/media/tuners/mxl301rf.c | 50 ++--- drivers/media/tuners/mxl301rf.h | 2 +- drivers/media/tuners/qm1d1c0042.c | 60 - drivers/media/tuners/qm1d1c0042.h | 2 - 8 files changed, 99 insertions(+), 183 deletions(-) -- 2.2.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 v3] dvb-core: add template code for i2c binding model
From: Akihiro Tsukada
Define a standard interface for demod/tuner i2c driver modules.
A module client calls dvb_i2c_attach_{fe,tuner}(),
and a module driver defines struct dvb_i2c_module_param and
calls DEFINE_DVB_I2C_MODULE() macro.
This template provides implicit module requests and ref-counting,
alloc/free's private data structures,
fixes the usage of clientdata of i2c devices,
and defines the platformdata structures for passing around
device specific config/output parameters between drivers and clients.
These kinds of code are common to (almost) all dvb i2c drivers/client,
but they were scattered over adapter modules and demod/tuner modules.
Signed-off-by: Akihiro Tsukada
---
Changes in v3:
- removed demod i2c client out of struct dvb_frontend*
drivers/media/dvb-core/Makefile | 4 +
drivers/media/dvb-core/dvb_i2c.c | 221 +++
drivers/media/dvb-core/dvb_i2c.h | 112
3 files changed, 337 insertions(+)
create mode 100644 drivers/media/dvb-core/dvb_i2c.c
create mode 100644 drivers/media/dvb-core/dvb_i2c.h
diff --git a/drivers/media/dvb-core/Makefile b/drivers/media/dvb-core/Makefile
index 8f22bcd..271648d 100644
--- a/drivers/media/dvb-core/Makefile
+++ b/drivers/media/dvb-core/Makefile
@@ -8,4 +8,8 @@ dvb-core-objs := dvbdev.o dmxdev.o dvb_demux.o dvb_filter.o
\
dvb_ca_en50221.o dvb_frontend.o\
$(dvb-net-y) dvb_ringbuffer.o dvb_math.o
+ifneq ($(CONFIG_I2C)$(CONFIG_I2C_MODULE),)
+dvb-core-objs += dvb_i2c.o
+endif
+
obj-$(CONFIG_DVB_CORE) += dvb-core.o
diff --git a/drivers/media/dvb-core/dvb_i2c.c b/drivers/media/dvb-core/dvb_i2c.c
new file mode 100644
index 000..6c4d6ae
--- /dev/null
+++ b/drivers/media/dvb-core/dvb_i2c.c
@@ -0,0 +1,221 @@
+/*
+ * dvb_i2c.c
+ *
+ * Copyright 2014 Akihiro Tsukada
+ *
+ * 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, see
Re: [PATCHv3 0/3] hdmi: add unpack and logging functions
On Fri, Dec 19, 2014 at 01:14:19PM +0100, Hans Verkuil wrote: > This patch series adds new HDMI 2.0/CEA-861-F defines to hdmi.h and > adds unpacking and logging functions to hdmi.c. It also uses those > in the V4L2 adv7842 driver (and they will be used in other HDMI drivers > once this functionality is merged). > > Changes since v2: > - Applied most comments from Thierry's review > - Renamed HDMI_AUDIO_CODING_TYPE_EXT_STREAM as per Thierry's suggestion. > > Thierry, if this OK, then please give your Ack and I'll post a pull > request for 3.20 for the media git tree. Patches 1, 2 and 3: Acked-by: Thierry Reding pgpULFGjIc2lj.pgp Description: PGP signature
Re: [PATCH] [media] [pvrusb2]: remove dead retry cmd code
On 01/05/2015 11:38 PM, Haim Daniel wrote:
> In case a command is timed out, current flow sets the retry_flag
> and does nothing.
Really? That's not how I read the code: it retries up to 20 times before
bailing out.
Perhaps you missed the "if (try_count < 20) continue;" line?
Regards,
Hans
>
> Signed-off-by: Haim Daniel
> ---
> drivers/media/usb/pvrusb2/pvrusb2-encoder.c | 15 +--
> 1 file changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> index f7702ae..02028aa 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> @@ -145,8 +145,6 @@ static int pvr2_encoder_cmd(void *ctxt,
> u32 *argp)
> {
> unsigned int poll_count;
> - unsigned int try_count = 0;
> - int retry_flag;
> int ret = 0;
> unsigned int idx;
> /* These sizes look to be limited by the FX2 firmware implementation */
> @@ -213,8 +211,6 @@ static int pvr2_encoder_cmd(void *ctxt,
> break;
> }
>
> - retry_flag = 0;
> - try_count++;
> ret = 0;
> wrData[0] = 0;
> wrData[1] = cmd;
> @@ -245,11 +241,9 @@ static int pvr2_encoder_cmd(void *ctxt,
> }
> if (rdData[0] && (poll_count < 1000)) continue;
> if (!rdData[0]) {
> - retry_flag = !0;
> pvr2_trace(
> PVR2_TRACE_ERROR_LEGS,
> - "Encoder timed out waiting for us"
> - "; arranging to retry");
> + "Encoder timed out waiting for us");
> } else {
> pvr2_trace(
> PVR2_TRACE_ERROR_LEGS,
> @@ -269,13 +263,6 @@ static int pvr2_encoder_cmd(void *ctxt,
> ret = -EBUSY;
> break;
> }
> - if (retry_flag) {
> - if (try_count < 20) continue;
> - pvr2_trace(
> - PVR2_TRACE_ERROR_LEGS,
> - "Too many retries...");
> - ret = -EBUSY;
> - }
> if (ret) {
> del_timer_sync(&hdw->encoder_run_timer);
> hdw->state_encoder_ok = 0;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: pci: solo6x10: solo6x10-enc.c: Remove unused function
(resent with correct email address for Ismael)
Ismael, Andrey,
Can you take a look at this? Shouldn't solo_s_jpeg_qp() be hooked up to
something?
Regards,
Hans
On 12/21/2014 06:58 PM, Rickard Strandqvist wrote:
> Remove the function solo_s_jpeg_qp() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/media/pci/solo6x10/solo6x10-enc.c | 35
> -
> drivers/media/pci/solo6x10/solo6x10.h |2 --
> 2 files changed, 37 deletions(-)
>
> diff --git a/drivers/media/pci/solo6x10/solo6x10-enc.c
> b/drivers/media/pci/solo6x10/solo6x10-enc.c
> index d19c0ae..6b589b8 100644
> --- a/drivers/media/pci/solo6x10/solo6x10-enc.c
> +++ b/drivers/media/pci/solo6x10/solo6x10-enc.c
> @@ -175,41 +175,6 @@ out:
> return 0;
> }
>
> -/**
> - * Set channel Quality Profile (0-3).
> - */
> -void solo_s_jpeg_qp(struct solo_dev *solo_dev, unsigned int ch,
> - unsigned int qp)
> -{
> - unsigned long flags;
> - unsigned int idx, reg;
> -
> - if ((ch > 31) || (qp > 3))
> - return;
> -
> - if (solo_dev->type == SOLO_DEV_6010)
> - return;
> -
> - if (ch < 16) {
> - idx = 0;
> - reg = SOLO_VE_JPEG_QP_CH_L;
> - } else {
> - ch -= 16;
> - idx = 1;
> - reg = SOLO_VE_JPEG_QP_CH_H;
> - }
> - ch *= 2;
> -
> - spin_lock_irqsave(&solo_dev->jpeg_qp_lock, flags);
> -
> - solo_dev->jpeg_qp[idx] &= ~(3 << ch);
> - solo_dev->jpeg_qp[idx] |= (qp & 3) << ch;
> -
> - solo_reg_write(solo_dev, reg, solo_dev->jpeg_qp[idx]);
> -
> - spin_unlock_irqrestore(&solo_dev->jpeg_qp_lock, flags);
> -}
> -
> int solo_g_jpeg_qp(struct solo_dev *solo_dev, unsigned int ch)
> {
> int idx;
> diff --git a/drivers/media/pci/solo6x10/solo6x10.h
> b/drivers/media/pci/solo6x10/solo6x10.h
> index 72017b7..ad5afc6 100644
> --- a/drivers/media/pci/solo6x10/solo6x10.h
> +++ b/drivers/media/pci/solo6x10/solo6x10.h
> @@ -399,8 +399,6 @@ int solo_eeprom_write(struct solo_dev *solo_dev, int loc,
> __be16 data);
>
> /* JPEG Qp functions */
> -void solo_s_jpeg_qp(struct solo_dev *solo_dev, unsigned int ch,
> - unsigned int qp);
> int solo_g_jpeg_qp(struct solo_dev *solo_dev, unsigned int ch);
>
> #define CHK_FLAGS(v, flags) (((v) & (flags)) == (flags))
>
--
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
Re: [PATCH] media: pci: solo6x10: solo6x10-enc.c: Remove unused function
Ismael, Andrey,
Can you take a look at this? Shouldn't solo_s_jpeg_qp() be hooked up to
something?
Regards,
Hans
On 12/21/2014 06:58 PM, Rickard Strandqvist wrote:
> Remove the function solo_s_jpeg_qp() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/media/pci/solo6x10/solo6x10-enc.c | 35
> -
> drivers/media/pci/solo6x10/solo6x10.h |2 --
> 2 files changed, 37 deletions(-)
>
> diff --git a/drivers/media/pci/solo6x10/solo6x10-enc.c
> b/drivers/media/pci/solo6x10/solo6x10-enc.c
> index d19c0ae..6b589b8 100644
> --- a/drivers/media/pci/solo6x10/solo6x10-enc.c
> +++ b/drivers/media/pci/solo6x10/solo6x10-enc.c
> @@ -175,41 +175,6 @@ out:
> return 0;
> }
>
> -/**
> - * Set channel Quality Profile (0-3).
> - */
> -void solo_s_jpeg_qp(struct solo_dev *solo_dev, unsigned int ch,
> - unsigned int qp)
> -{
> - unsigned long flags;
> - unsigned int idx, reg;
> -
> - if ((ch > 31) || (qp > 3))
> - return;
> -
> - if (solo_dev->type == SOLO_DEV_6010)
> - return;
> -
> - if (ch < 16) {
> - idx = 0;
> - reg = SOLO_VE_JPEG_QP_CH_L;
> - } else {
> - ch -= 16;
> - idx = 1;
> - reg = SOLO_VE_JPEG_QP_CH_H;
> - }
> - ch *= 2;
> -
> - spin_lock_irqsave(&solo_dev->jpeg_qp_lock, flags);
> -
> - solo_dev->jpeg_qp[idx] &= ~(3 << ch);
> - solo_dev->jpeg_qp[idx] |= (qp & 3) << ch;
> -
> - solo_reg_write(solo_dev, reg, solo_dev->jpeg_qp[idx]);
> -
> - spin_unlock_irqrestore(&solo_dev->jpeg_qp_lock, flags);
> -}
> -
> int solo_g_jpeg_qp(struct solo_dev *solo_dev, unsigned int ch)
> {
> int idx;
> diff --git a/drivers/media/pci/solo6x10/solo6x10.h
> b/drivers/media/pci/solo6x10/solo6x10.h
> index 72017b7..ad5afc6 100644
> --- a/drivers/media/pci/solo6x10/solo6x10.h
> +++ b/drivers/media/pci/solo6x10/solo6x10.h
> @@ -399,8 +399,6 @@ int solo_eeprom_write(struct solo_dev *solo_dev, int loc,
> __be16 data);
>
> /* JPEG Qp functions */
> -void solo_s_jpeg_qp(struct solo_dev *solo_dev, unsigned int ch,
> - unsigned int qp);
> int solo_g_jpeg_qp(struct solo_dev *solo_dev, unsigned int ch);
>
> #define CHK_FLAGS(v, flags) (((v) & (flags)) == (flags))
>
--
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 15/16] [media] adv7180: Add free run mode controls
Hi Lars,
On 01/13/2015 01:01 PM, Lars-Peter Clausen wrote:
> The adv7180 (and similar) has support for a so called free run mode in which
> it will output a predefined test signal. This patch adds support for
> configuring the various aspects of the so called free run mode.
>
> The patch adds three new v4l controls:
> * Free Running Mode: Allows to either disable or enable free running
> mode or set it to automatic. In automatic mode the adv7180 will go to
> free run mode if no external signal source could be detected
> * Free Running Pattern: Allows to select which pattern will be displayed
> in free run mode
> * Free Running Color: Allows to select the color of the pattern
>
> Signed-off-by: Lars-Peter Clausen
> ---
> drivers/media/i2c/adv7180.c | 125
> ++--
> 1 file changed, 122 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> index 82c8296..678d6c9 100644
> --- a/drivers/media/i2c/adv7180.c
> +++ b/drivers/media/i2c/adv7180.c
> @@ -75,6 +75,9 @@
> #define ADV7180_HUE_DEF 0
> #define ADV7180_HUE_MAX 128
>
> +#define ADV7180_REG_DEF_VAL_Y0x000c
> +#define ADV7180_REG_DEF_VAL_C0x000d
> +
> #define ADV7180_REG_CTRL 0x000e
> #define ADV7180_CTRL_IRQ_SPACE 0x20
>
> @@ -168,6 +171,11 @@
> #define ADV7180_DEFAULT_VPP_I2C_ADDR 0x42
>
> #define V4L2_CID_ADV_FAST_SWITCH (V4L2_CID_DV_CLASS_BASE + 0x1010)
> +#define V4L2_CID_ADV_FREE_RUN_COLOR (V4L2_CID_DV_CLASS_BASE + 0x1002)
> +#define V4L2_CID_ADV_FREE_RUN_MODE (V4L2_CID_DV_CLASS_BASE + 0x1003)
> +#define V4L2_CID_ADV_FREE_RUN_PATTERN(V4L2_CID_DV_CLASS_BASE +
> 0x1004)
See same comment as I made in patch 8 regarding private controls.
> +
> +#define ADV7180_INPUT_DISABLED (~0x00)
>
> struct adv7180_state;
>
> @@ -193,6 +201,7 @@ struct adv7180_state {
> v4l2_std_id curr_norm;
> boolautodetect;
> boolpowered;
> + boolforce_free_run;
> u8 input;
>
> struct i2c_client *client;
> @@ -363,10 +372,13 @@ static int adv7180_s_routing(struct v4l2_subdev *sd,
> u32 input,
> goto out;
> }
>
> - ret = state->chip_info->select_input(state, input);
> -
> - if (ret == 0)
> + if (state->force_free_run) {
> state->input = input;
> + } else {
> + ret = state->chip_info->select_input(state, input);
> + if (ret == 0)
> + state->input = input;
> + }
> out:
> mutex_unlock(&state->mutex);
> return ret;
> @@ -488,6 +500,7 @@ static int adv7180_s_ctrl(struct v4l2_ctrl *ctrl)
> {
> struct adv7180_state *state = ctrl_to_adv7180(ctrl);
> int ret = mutex_lock_interruptible(&state->mutex);
> + int reg_val;
> int val;
>
> if (ret)
> @@ -526,6 +539,53 @@ static int adv7180_s_ctrl(struct v4l2_ctrl *ctrl)
> adv7180_write(state, ADV7180_REG_FLCONTROL, 0x00);
> }
> break;
> + case V4L2_CID_ADV_FREE_RUN_MODE:
> + switch (ctrl->val) {
> + case 1: /* Enabled */
> + ret = state->chip_info->select_input(state,
> + ADV7180_INPUT_DISABLED);
> + state->force_free_run = true;
> + break;
> + case 0: /* Disabled */
> + case 2: /* Automatic */
> + ret = state->chip_info->select_input(state,
> + state->input);
> + state->force_free_run = false;
> + break;
> + default:
> + break;
> + }
> + reg_val = adv7180_read(state, ADV7180_REG_DEF_VAL_Y);
> + reg_val &= 0xfc;
> + reg_val |= ctrl->val;
> + adv7180_write(state, ADV7180_REG_DEF_VAL_Y, reg_val);
> + break;
> + case V4L2_CID_ADV_FREE_RUN_PATTERN:
> + reg_val = adv7180_read(state, 0x14);
> + reg_val &= 0xf8;
> + reg_val |= ctrl->val;
> + adv7180_write(state, 0x14, reg_val);
> + break;
> + case V4L2_CID_ADV_FREE_RUN_COLOR: {
> + int r = (ctrl->val & 0xff) >> 16;
> + int g = (ctrl->val & 0x00ff00) >> 8;
> + int b = (ctrl->val & 0xff);
> + /* RGB -> YCbCr, numerical approximation */
> + int y = ((66 * r + 129 * g + 25 * b + 128) >> 8) + 16;
> + int cb = ((-38 * r - 74 * g + 112 * b + 128) >> 8) + 128;
> + int cr = ((112 * r - 94 * g - 18 * b + 128) >> 8) + 128;
> +
> + /* Y is 6-bit, Cb and Cr 4-bit */
> + y >>= 2;
> + cb >>= 4;
> + cr >>= 4;
> +
> +
Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property
Hi,
On 15/01/15 22:03, Pavel Machek wrote:
>> Perhaps we could use the 'reg' property to describe actual connections,
>> > I'm not sure if it's better than a LED specific property, e.g.
>> >
>> > max77387@52 {
>> > compatible = "nxp,max77387";
>> > #address-cells = <2>;
>> > #size-cells = <0>;
>> > reg = <0x52>;
>> >
>> >flash_led {
>> >reg = <1 1>;
>> >...
>> >};
>> > };
>
> Normally, reg property is , if I understand things
> correctly? Would that be enough here, or would we be doing list of
> outputs?
In general the exact meaning depends on value of the #address-cells and
#size-cells properties in the parent node. In case as above #size-cells
is 0. You can find exact explanation in [1], at page 25.
Anyway, the above example might an abuse of the simple bus. I thought more
about a list of outputs, but the indexes wouldn't be contiguous, e.g.
curr. reg. outputs | "addres" value
FLED2FLED1 | reg
+---
01| 0x0001
10| 0x0001
11| 0x00010001
But it might be not a good idea as Rob pointed out.
OTOH we could simply assign indices 1,2,3 to the above FLED1/2 output
combinations.
[1]
https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf
--
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: [PATCH 08/16] [media] adv7180: Consolidate video mode setting
Hi Lars,
On 01/13/2015 01:01 PM, Lars-Peter Clausen wrote:
> We have basically the same code to set the video standard in init_device()
> and adv7180_s_std(). Factor this out into a common helper function.
>
> Signed-off-by: Lars-Peter Clausen
> ---
> drivers/media/i2c/adv7180.c | 67
> ++---
> 1 file changed, 32 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> index 349cae3..4d9bcc8 100644
> --- a/drivers/media/i2c/adv7180.c
> +++ b/drivers/media/i2c/adv7180.c
> @@ -304,37 +304,54 @@ static int adv7180_g_input_status(struct v4l2_subdev
> *sd, u32 *status)
> return ret;
> }
>
> -static int adv7180_s_std(struct v4l2_subdev *sd, v4l2_std_id std)
> +static int adv7180_program_std(struct adv7180_state *state)
> {
> - struct adv7180_state *state = to_state(sd);
> - int ret = mutex_lock_interruptible(&state->mutex);
> - if (ret)
> - return ret;
> + int ret;
>
> - /* all standards -> autodetect */
> - if (std == V4L2_STD_ALL) {
> + if (state->autodetect) {
Acked-by: Hans Verkuil
That said, I am unhappy about this autodetect handling. That isn't something
that this patch changes, which is why I've Acked it, but I hope you can look
at this yourself.
The reason I don't like it is because 1) it is non-standard behavior of a video
receiver to turn on autodetect if STD_ALL is passed in. And 2) there are
multiple autodetect modes and the one chosen seems to imply that NTSC M is not
autodetected, only NTSC-J. I have no adv7180 hardware, so I can't test if that
is indeed what is happening. In any case, every autodetect mode seems to
autodetect only a subset of all possible standards according to the adv7180
datasheet, which doesn't really make it a real autodetect IMHO.
The third and last reason is that if the autodetect system switches from NTSC to
PAL you suddenly get larger frames. Depending on the exact DMA configuration
of the board this could lead to buffer overflows (e.g. if the DMA configuration
just DMAs until the end of frame, and yes, such terrible DMA implementations
exist).
An initial autodetect when the driver is loaded might make sense in order to get
a reasonable initial standard, but I am skeptical about using it anywhere else.
BTW, if you can easily detect standard changes via an interrupt, then you can
use that interrupt to send a V4L2_EVENT_SOURCE_CHANGE event. That would allow
applications to dynamically react to changes in the standard.
As I said, I have no adv718x hardware so I am unable to test this, but if you
could test this autodetect functionality and think about whether it should be
kept at all, then that would be useful.
Regards,
Hans
> ret = adv7180_write(state, ADV7180_REG_INPUT_CONTROL,
> ADV7180_INPUT_CONTROL_AD_PAL_BG_NTSC_J_SECAM
> | state->input);
> if (ret < 0)
> - goto out;
> + return ret;
>
> __adv7180_status(state, NULL, &state->curr_norm);
> - state->autodetect = true;
> } else {
> - ret = v4l2_std_to_adv7180(std);
> + ret = v4l2_std_to_adv7180(state->curr_norm);
> if (ret < 0)
> - goto out;
> + return ret;
>
> ret = adv7180_write(state, ADV7180_REG_INPUT_CONTROL,
> ret | state->input);
> if (ret < 0)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int adv7180_s_std(struct v4l2_subdev *sd, v4l2_std_id std)
> +{
> + struct adv7180_state *state = to_state(sd);
> + int ret = mutex_lock_interruptible(&state->mutex);
> +
> + if (ret)
> + return ret;
> +
> + /* all standards -> autodetect */
> + if (std == V4L2_STD_ALL) {
> + state->autodetect = true;
> + } else {
> + /* Make sure we can support this std */
> + ret = v4l2_std_to_adv7180(std);
> + if (ret < 0)
> goto out;
>
> state->curr_norm = std;
> state->autodetect = false;
> }
> - ret = 0;
> +
> + ret = adv7180_program_std(state);
> out:
> mutex_unlock(&state->mutex);
> return ret;
> @@ -547,30 +564,10 @@ static int init_device(struct adv7180_state *state)
> adv7180_write(state, ADV7180_REG_PWR_MAN, ADV7180_PWR_MAN_RES);
> usleep_range(2000, 1);
>
> - /* Initialize adv7180 */
> - /* Enable autodetection */
> - if (state->autodetect) {
> - ret = adv7180_write(state, ADV7180_REG_INPUT_CONTROL,
> - ADV7180_INPUT_CONTROL_AD_PAL_BG_NTSC_J_SECAM
> - | state->input);
> - if (ret < 0)
> - goto out_unlock;
> -
> -
[PATCH 3/3 v2] bttv: Improve TEA575x support
Improve g_tuner and add s_hw_freq_seek and enum_freq_bands support for cards
with TEA575x radio.
This allows signal/stereo detection and HW seek to work on these cards.
Signed-off-by: Ondrej Zary
---
drivers/media/pci/bt8xx/bttv-driver.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index e7f8ade..4ec2a3c 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -2515,6 +2515,8 @@ static int bttv_querycap(struct file *file, void *priv,
if (btv->has_saa6588)
cap->device_caps |= V4L2_CAP_READWRITE |
V4L2_CAP_RDS_CAPTURE;
+ if (btv->has_tea575x)
+ cap->device_caps |= V4L2_CAP_HW_FREQ_SEEK;
}
return 0;
}
@@ -3244,6 +3246,9 @@ static int radio_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *t)
if (btv->audio_mode_gpio)
btv->audio_mode_gpio(btv, t, 0);
+ if (btv->has_tea575x)
+ return snd_tea575x_g_tuner(&btv->tea, t);
+
return 0;
}
@@ -3261,6 +3266,30 @@ static int radio_s_tuner(struct file *file, void *priv,
return 0;
}
+static int radio_s_hw_freq_seek(struct file *file, void *priv,
+ const struct v4l2_hw_freq_seek *a)
+{
+ struct bttv_fh *fh = priv;
+ struct bttv *btv = fh->btv;
+
+ if (btv->has_tea575x)
+ return snd_tea575x_s_hw_freq_seek(file, &btv->tea, a);
+
+ return -ENOTTY;
+}
+
+static int radio_enum_freq_bands(struct file *file, void *priv,
+struct v4l2_frequency_band *band)
+{
+ struct bttv_fh *fh = priv;
+ struct bttv *btv = fh->btv;
+
+ if (btv->has_tea575x)
+ return snd_tea575x_enum_freq_bands(&btv->tea, band);
+
+ return -ENOTTY;
+}
+
static ssize_t radio_read(struct file *file, char __user *data,
size_t count, loff_t *ppos)
{
@@ -3318,6 +3347,8 @@ static const struct v4l2_ioctl_ops radio_ioctl_ops = {
.vidioc_s_tuner = radio_s_tuner,
.vidioc_g_frequency = bttv_g_frequency,
.vidioc_s_frequency = bttv_s_frequency,
+ .vidioc_s_hw_freq_seek = radio_s_hw_freq_seek,
+ .vidioc_enum_freq_bands = radio_enum_freq_bands,
.vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
--
Ondrej Zary
--
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/3] bttv: Improve TEA575x support
Hi Ondrej,
Just two small comments:
On 01/15/2015 09:10 PM, Ondrej Zary wrote:
> Improve g_tuner and add s_hw_freq_seek and enum_freq_bands support for cards
> with TEA575x radio.
>
> This allows signal/stereo detection and HW seek to work on these cards.
>
> Signed-off-by: Ondrej Zary
> ---
> drivers/media/pci/bt8xx/bttv-driver.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
> b/drivers/media/pci/bt8xx/bttv-driver.c
> index e7f8ade..5476a7d 100644
> --- a/drivers/media/pci/bt8xx/bttv-driver.c
> +++ b/drivers/media/pci/bt8xx/bttv-driver.c
> @@ -2515,6 +2515,8 @@ static int bttv_querycap(struct file *file, void *priv,
> if (btv->has_saa6588)
> cap->device_caps |= V4L2_CAP_READWRITE |
> V4L2_CAP_RDS_CAPTURE;
> + if (btv->has_tea575x)
> + cap->device_caps |= V4L2_CAP_HW_FREQ_SEEK;
> }
> return 0;
> }
> @@ -3244,6 +3246,9 @@ static int radio_g_tuner(struct file *file, void *priv,
> struct v4l2_tuner *t)
> if (btv->audio_mode_gpio)
> btv->audio_mode_gpio(btv, t, 0);
>
> + if (btv->has_tea575x)
> + return snd_tea575x_g_tuner(&btv->tea, t);
> +
> return 0;
> }
>
> @@ -3261,6 +3266,30 @@ static int radio_s_tuner(struct file *file, void *priv,
> return 0;
> }
>
> +static int radio_s_hw_freq_seek(struct file *file, void *priv,
> + const struct v4l2_hw_freq_seek *a)
> +{
> + struct bttv_fh *fh = priv;
> + struct bttv *btv = fh->btv;
> +
> + if (btv->has_tea575x)
> + return snd_tea575x_s_hw_freq_seek(file, &btv->tea, a);
> + else
> + return -ENOTTY;
Please drop the superfluous 'else'. I thought checkpatch warned about this
these days.
> +}
> +
> +static int radio_enum_freq_bands(struct file *file, void *priv,
> + struct v4l2_frequency_band *band)
> +{
> + struct bttv_fh *fh = priv;
> + struct bttv *btv = fh->btv;
> +
> + if (btv->has_tea575x)
> + return snd_tea575x_enum_freq_bands(&btv->tea, band);
> + else
> + return -ENOTTY;
Ditto.
> +}
> +
> static ssize_t radio_read(struct file *file, char __user *data,
>size_t count, loff_t *ppos)
> {
> @@ -3318,6 +3347,8 @@ static const struct v4l2_ioctl_ops radio_ioctl_ops = {
> .vidioc_s_tuner = radio_s_tuner,
> .vidioc_g_frequency = bttv_g_frequency,
> .vidioc_s_frequency = bttv_s_frequency,
> + .vidioc_s_hw_freq_seek = radio_s_hw_freq_seek,
> + .vidioc_enum_freq_bands = radio_enum_freq_bands,
> .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
> .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
> };
>
Regards,
Hans
--
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
[GIT PULL FOR v3.20] Remove deprecated drivers
As promised, remove the deprecated tlg2300, vino, saa7191, bw-qcam, c-qcam and pms drivers. Regards, Hans The following changes since commit 99f3cd52aee21091ce62442285a68873e3be833f: [media] vb2-vmalloc: Protect DMA-specific code by #ifdef CONFIG_HAS_DMA (2014-12-23 16:28:09 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git removedrvs for you to fetch changes up to c93947c835df35500b952b2bdfea603ef54529fe: Documentation/video4linux: remove obsolete text files (2015-01-16 10:26:54 +0100) Hans Verkuil (4): tlg2300: remove deprecated staging driver vino/saa7191: remove deprecated drivers bw/c-qcam, w9966, pms: remove deprecated staging drivers Documentation/video4linux: remove obsolete text files Documentation/video4linux/CQcam.txt| 205 Documentation/video4linux/README.tlg2300 | 47 - Documentation/video4linux/w9966.txt| 33 - MAINTAINERS| 22 - drivers/staging/media/Kconfig |6 - drivers/staging/media/Makefile |4 - drivers/staging/media/parport/Kconfig | 69 -- drivers/staging/media/parport/Makefile |4 - drivers/staging/media/parport/bw-qcam.c| 1177 -- drivers/staging/media/parport/c-qcam.c | 882 - drivers/staging/media/parport/pms.c| 1156 -- drivers/staging/media/parport/w9966.c | 980 -- drivers/staging/media/tlg2300/Kconfig | 20 - drivers/staging/media/tlg2300/Makefile |9 - drivers/staging/media/tlg2300/pd-alsa.c| 337 --- drivers/staging/media/tlg2300/pd-common.h | 270 - drivers/staging/media/tlg2300/pd-dvb.c | 597 --- drivers/staging/media/tlg2300/pd-main.c| 553 --- drivers/staging/media/tlg2300/pd-radio.c | 336 --- drivers/staging/media/tlg2300/pd-video.c | 1560 - drivers/staging/media/tlg2300/vendorcmds.h | 243 - drivers/staging/media/vino/Kconfig | 24 - drivers/staging/media/vino/Makefile|3 - drivers/staging/media/vino/indycam.c | 378 --- drivers/staging/media/vino/indycam.h | 93 -- drivers/staging/media/vino/saa7191.c | 649 drivers/staging/media/vino/saa7191.h | 245 - drivers/staging/media/vino/vino.c | 4345 drivers/staging/media/vino/vino.h | 138 --- 29 files changed, 14385 deletions(-) delete mode 100644 Documentation/video4linux/CQcam.txt delete mode 100644 Documentation/video4linux/README.tlg2300 delete mode 100644 Documentation/video4linux/w9966.txt delete mode 100644 drivers/staging/media/parport/Kconfig delete mode 100644 drivers/staging/media/parport/Makefile delete mode 100644 drivers/staging/media/parport/bw-qcam.c delete mode 100644 drivers/staging/media/parport/c-qcam.c delete mode 100644 drivers/staging/media/parport/pms.c delete mode 100644 drivers/staging/media/parport/w9966.c delete mode 100644 drivers/staging/media/tlg2300/Kconfig delete mode 100644 drivers/staging/media/tlg2300/Makefile delete mode 100644 drivers/staging/media/tlg2300/pd-alsa.c delete mode 100644 drivers/staging/media/tlg2300/pd-common.h delete mode 100644 drivers/staging/media/tlg2300/pd-dvb.c delete mode 100644 drivers/staging/media/tlg2300/pd-main.c delete mode 100644 drivers/staging/media/tlg2300/pd-radio.c delete mode 100644 drivers/staging/media/tlg2300/pd-video.c delete mode 100644 drivers/staging/media/tlg2300/vendorcmds.h delete mode 100644 drivers/staging/media/vino/Kconfig delete mode 100644 drivers/staging/media/vino/Makefile delete mode 100644 drivers/staging/media/vino/indycam.c delete mode 100644 drivers/staging/media/vino/indycam.h delete mode 100644 drivers/staging/media/vino/saa7191.c delete mode 100644 drivers/staging/media/vino/saa7191.h delete mode 100644 drivers/staging/media/vino/vino.c delete mode 100644 drivers/staging/media/vino/vino.h -- 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 v10 03/19] DT: leds: Add led-sources property
On 01/15/2015 03:24 PM, Rob Herring wrote: On Tue, Jan 13, 2015 at 2:42 AM, Jacek Anaszewski wrote: On 01/12/2015 05:55 PM, Rob Herring wrote: Adding Mark B and Liam... On Mon, Jan 12, 2015 at 10:10 AM, Jacek Anaszewski wrote: On 01/12/2015 02:52 PM, Rob Herring wrote: On Mon, Jan 12, 2015 at 2:32 AM, Jacek Anaszewski wrote: On 01/09/2015 07:33 PM, Rob Herring wrote: On Fri, Jan 9, 2015 at 9:22 AM, Jacek Anaszewski wrote: Add a property for defining the device outputs the LED represented by the DT child node is connected to. [...] b/Documentation/devicetree/bindings/leds/common.txt index a2c3f7a..29295bf 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -1,6 +1,10 @@ Common leds properties. Optional properties for child nodes: +- led-sources : Array of bits signifying the LED current regulator outputs the + LED represented by the child node is connected to (1 - the LED + is connected to the output, 0 - the LED isn't connected to the + output). Sorry, I just don't understand this. In some Flash LED devices one LED can be connected to one or more electric current outputs, which allows for multiplying the maximum current allowed for the LED. Each sub-LED is represented by a child node in the DT binding of the Flash LED device and it needs to declare which outputs it is connected to. In the example below the led-sources property is a two element array, which means that the flash LED device has two current outputs, and the bits signify if the LED is connected to the output. Sounds like a regulator for which we already have bindings for and we have a driver for regulator based LEDs (but no binding for it). Do you think of drivers/leds/leds-regulator.c driver? This driver just allows for registering an arbitrary regulator device as a LED subsystem device. There are however devices that don't fall into this category, i.e. they have many outputs, that can be connected to a single LED or to many LEDs and the driver has to know what is the actual arrangement. We may need to extend the regulator binding slightly and allow for multiple phandles on a supply property, but wouldn't something like this work: led-supply = <&led-reg0>, <&led-reg1>, <&led-reg2>, <&led-reg3>; The shared source is already supported by the regulator binding. I think that we shouldn't split the LED devices into power supply providers and consumers as in case of generic regulators. From this point of view a LED device current output is a provider and a discrete LED element is a consumer. In this approach each discrete LED element should have a related driver which is not how LED devices are being handled in the LED subsystem, where there is a single binding for a LED device and there is a single driver for it which creates separate LED class devices for each LED connected to the LED device output. Each discrete LED is represented by a child node in the LED device binding. I am aware that it may be tempting to treat LED devices as common regulators, but they have their specific features which gave a reason for introducing LED class for them. Besides, there is already drivers/leds/leds-regulator.c driver for LED devices which support only turning on/off and setting brightness level. In your proposition a separate regulator provider binding would have to be created for each current output and a separate binding for each discrete LED connected to the LED device. It would create unnecessary noise in a dts file. Moreover, using regulator binding implies that we want to treat it as a sheer power supply for our device (which would be a discrete LED element in this case), whereas LED devices provide more features like blinking pattern and for flash LED devices - flash timeout, external strobe and flash faults. Okay, fair enough. Please include some of this explanation in the binding description. I do still have some concerns about led-sources and whether it can support other scenarios. It is very much tied to the parent node. Are there any cases where we don't want the LEDs to be sub nodes? Perhaps the LEDs are on a separate daughterboard from the driver/supply and we can have different drivers. It's a stretch maybe. I think it is. Such arrangements would introduce problems also to the other existing bindings. Probably not only LED subsystem related ones. Or are there cases where you need more information than just the connection? Currently I can't think of any. Modified rough proposal of the description: -Optional properties for child nodes: +LED and flash LED devices provide the same basic functionality as +current regulators, but extended with LED and flash LED specific +features like blinking patterns, flash timeout, flash faults and +external flash strobe mode. + +Many LED devices expose more than one current output that can be +connected to one or more discre
