[GIT PULL v2] SAA716x DVB driver
lated routines saa716x: Do not initialize the CGU twice saa716x: Add more debug info, initialize handler count saa716x: Add/remove I2C MSI vectors saa716x: Add interrupt debugging saa716x: Return error on MSI enable failure saa716x: Initialize FPGI pagetables saa716x: Setup FGPI parameters saa716x: Use a separate module to handle Full fledged cards saa716x: NULL terminate PCI ID list saa716x: Read the mask bits instead saa716x: Reduce a bit of noise in the handler debug mode saa716x: Sleep a little while before enabling interrupts again saa716x: Use individual handlers saa716x: Transmit D is programmed, not S data saa716x: Print return values saa716x: Use adapter ordering saa716x: Disable debugging osd.h: Kickstart the TT S2 6400 Dual HD Premium - OSD update saa716x: Kickstart the TT S2 6400 Dual HD Premium saa716x: Code simplification, Overhaul, ROM dump saa716x: Set the default rate for the NEMO reference design saa716x: Code simplification, Overhauling, I2C related fixes Initial test with the NEMO reference device saa716x: Try to attach the frontends saa716x: Don't cast pointers to 32 bit int saa716x: Partial rework of SPI I/O saa716x: Add video device support saa716x: S2-6400: Try to attach the frontend saa716x: Handle multiple I2C messages saa716x: Fix ROM parser saa716x: Setup default I2C rates saa716x: Fix BUS ordering saa716x: Fix swapped I2C buses saa716x: Print wait time, reduce number of loops saa716x: Fix missing address in single write operation saa716x: make register definitions specific to each of the modules saa716x: Fix register definition typo saa716x: Add function declaration saa716x: Fix FGPI internal clock divider state saa716x: Fix dmabuf allocation saa716x: Cleanup debug prints saa716x: Handle failure correctly saa716x: Handle proper buffer flush saa716x: FGPI DMA handling fixes saa716x: Finally! we have stream capture saa716x: Make the framework buildable saa716x: Fix build issues saa716x: Deinitialize I2C interrupts on exit saa716x: Factorize register/detach routines to common code saa716x: Start DMA engine as and when requested saa716x: Enable timeout for modules having no clock saa716x: Reset the frontend after powerup saa716x: GPIO fix saa716x: Fix powerup/reset saa716x: Use the correct I2C Bus saa716x: Code simplification saa716x: Try to attach frontend on the Nemo reference board saa716x: Do not report non-fatal errors to avoid issues with buggy BIOS's Oliver Endriss (3): saa716x_ff: Rename saa716x_ff.c to saa716x_ff_main.c saa716x_ff: Support remote control receiver saa716x: Use tasklet to transfer data to the demuxer (TT S2-6400) Soeren Moch (94): saa716x: i2c_del_adapter() fix saa716x_ff: init frontends to low-power mode saa716x_ff: Add linux-4.5 support saa716x_ff: Avoid sleeping in fifo_worker saa716x: remove unused saa716x_msi_handler saa716x: pci: Remove asm includes for compatibility with linux-4.6 saa716x: add linux-4.10 support saa716x: Remove broken MSI-X support saa716x: Use %zu printk format for sizeof return values saa716x_budget: Fix build in linux-4.13 saa716x_hybrid: Fix build in linux-4.13 saa716x_ff: Remove autorepeat handling saa716x_ff: Convert to new timer API saa716x: adapt for moved header files media: dvb/audio.h: re-add AUDIO_GET_PTS saa716x: remove kernel version conditionals saa716x: fix include directories saa716x: fix module dependencies saa716x: simplify irq registration saa716x: remove unused multi-vector MSI support saa716x: remove unused i2c irq code saa716x: simplify MSI init saa716x: perform soft reset on device probe saa716x: remove separate msi reset saa716x_ff: move phi reset to probe function saa716x: also soft-reset greg and gpio blocks on device probe saa716x: move demux_worker to saa716x_adap saa716x: remove rom debug code saa716x: remove unused audio input port code saa716x: remove unused spi code saa716x: remove unused audio function prototypes saa716x: remove boot function prototypes from saa716x_priv.h saa716x: remove unused greg code saa716x: remove unused gpio code saa716x: remove unused private config and adapter entries saa716x: remove decoder resets from common code saa716x: move function headers from priv.h to own header files saa716x_hybrid: remove incomplete Avermedia H-788 support saa716x_hybrid: remove incomplete Avermedia HC-82 support saa716x_hybrid: remove incomplete Twinhan VP-6090 DVB-S support saa716x_budget: remove
Re: SAA716x DVB driver
Hi all, I know anything about this driver. I'm still ready to maintain this, in fact I'm doing this for years. Why do you look for another maintainer instead of supporting my pull request? In the long lasting discussion about this there was not a single technical reason why this driver cannot be merged as is, especially in staging as first step to do the required cleanup. Regards, Soeren On 25.01.2018 18:08, Jemma Denson wrote: > Hi Tycho, > > On 20/01/18 15:49, Tycho Lürsen wrote: >> Right, but we still need a maintainer. Are you capable/willing to >> volunteer for the job? > If no-one else will then yes I can, but I can't claim to know these devices > inside out. It would really depend on what's required of a maintainer, I'm > struggling to find this documented anywhere. > > Cards I can't test with would really need someone to be able to add a > tested-by to verify they work. > I think that your proposal to use a stripped version of Luis Alves repo is a no go, since it contains a couple of demod/tuner drivers that are not upstreamed yet. That complicates the upstreaming process too much, I think. >>> Oh, I would have stripped it *right* down and removed every card except >>> my TBS6280. The end result would probably be pretty close to Soeren's at >>> that point anyway, so I was starting to think like what you've done and >>> base it on that instead. >> If you want, I can strip the driver down a lot more and ad back the >> drivers you need. Just tell me what it is you need. > As above, it's really just a case of making it maintainable. If someone > can step forward and ack for them working then they could be included > but if not then I think it's best dropping them until that happens. > > > Jemma.
Re: [GIT PULL] SAA716x DVB driver
On 03.12.2017 11:57, Jemma Denson wrote: > On 02/12/17 23:59, Soeren Moch wrote: >> On 02.12.2017 20:49, Mauro Carvalho Chehab wrote: >>> Em Sat, 2 Dec 2017 18:51:16 + >>> Jemma Denson escreveu: >>>> Would I be correct in thinking the main blocker to this is the *_ff >>>> features >>>> used by the S2-6400 card? There's plenty of other cards using this >>>> chipset >>>> that don't need that part. >>>> >>>> Would a solution for now to be a driver with the ff components >>>> stripped out, >>>> and then the ff API work can be done later when / if there's any >>>> interest? >>> Works for me. In such case (and provided that the driver without >>> *_ff are >>> in good shape), we could merge it under drivers/media (instead of >>> merging >>> it on staging). >> All the entries in the TODO file are not specific for saa716x_ff. > > Ah, it's been a few months since I looked at that. I think some of the > things listed I had already identified as problems - checkpatch > especially, Finding checkpatch problems is easy... > and the irq code probably needs a bit more auto-detection. > I'm not sure I've seen how the other issues manifest themselves so I > might need some explanation of that (off list if you prefer) > >>>> I guess a problem would be finding a maintainer, I'm happy to put >>>> together >>>> a stripped down driver just supporting the TBS card I use (I >>>> already have >>>> one I use with dkms), but I'm not sure I have the time or knowledge >>>> of this >>>> chipset to be a maintainer. >> There is chipset specific stuff to fix, especially irq handling. > > Is this the module parameter kludges or something else? > >>> As we're talking more about touching at uAPI, probably it doesn't >>> require >>> chipsed knowledge. Only time and interest on doing it. >>> >>> Please sync with Soeren. Perhaps if you both could help on it, it would >>> make the task easier. >> As I already wrote to different people off-list: I'm happy to support >> more cards with the saa7160 bridge and maintain these in this driver. As >> hobbyist programmer this of course makes no sense to me, if the hardware >> I own (S2-6400) is not supported. >> > > Hence my comment about finding a maintainer - I had assumed if the > immediate result didn't support your card you probably wouldn't be > willing > to do that. > > What I'm trying to do here is get *something* merged, and then once > that work is done any interested parties can add to it. Or at the very > least if some patches are left OOT the constant workload required to > keep that up to date should be reduced significantly because they'll be > far less to look after. > Why not merge the driver as-is? The community would get support for several cards, easy access to the code without the need for separate git repositories or dkms packages, and a maintainer that understands the hardware and driver code. The whole purpose of driver development is bringing support for existing hardware to available user applications, preferably with existing APIs. And exactly that is in this pull request. In the whole discussion I cannot find a single reason, how merging this driver would violate the linux development principles. > One of the problems though is choosing which fork to use. I *think* there > are 2 - the one you've got which is the original powARman branch and the > one I would be using is the CrazyCat / Luis / TBS line. There are > going to be > some differences but hopefully that's all frontend support based and > one cut > down to a single frontend would end up a good base to add the rest back > in. > I think my repository represents the main development branch, just maintained by different people (adding Manu, Andreas, Oliver, in case they want to object). The CrazyCat repo is not a fork (including history), it is just a snapshot of the driver plus several patches. I already promised to help with adding TBS support. Regards, Soeren > I'm looking at maybe finding time over christmas break. > > > Jemma
Re: [GIT PULL] SAA716x DVB driver
On 02.12.2017 20:49, Mauro Carvalho Chehab wrote: > Em Sat, 2 Dec 2017 18:51:16 + > Jemma Denson escreveu: > >> Hi Mauro, >> >> On 27/11/17 11:24, Mauro Carvalho Chehab wrote: >>> Em Fri, 24 Nov 2017 17:28:37 +0100 >>> Tycho Lürsen escreveu: >>> Hi Mauro, afaik the last communication about submission of this driver was about two months ago. This driver is important to me, because I own several TurboSight cards that are saa716x based. I want to submit a patch that supports my cards. Of course I can only do so when you accept this driver in the first place. Any chance you and Sören agree about how to proceed about this driver anytime soon? >>> If we can reach an agreement about what should be done for the driver >>> to be promoted from staging some day, I'll merge it. Otherwise, >>> it can be kept maintained out of tree. This driver has been maintained >>> OOT for a very long time, and it seems that people were happy with >>> that, as only at the second half of this year someone is requesting >>> to merge it. >>> >>> So, while I agree that the best is to merge it upstream and >>> address the issues that made it OOT for a long time, we shouldn't >>> rush it with the risk of doing more harm than good. >>> >>> Thanks, >>> Mauro >> Would I be correct in thinking the main blocker to this is the *_ff features >> used by the S2-6400 card? There's plenty of other cards using this chipset >> that don't need that part. >> >> Would a solution for now to be a driver with the ff components stripped out, >> and then the ff API work can be done later when / if there's any interest? > Works for me. In such case (and provided that the driver without *_ff are > in good shape), we could merge it under drivers/media (instead of merging > it on staging). All the entries in the TODO file are not specific for saa716x_ff. >> I guess a problem would be finding a maintainer, I'm happy to put together >> a stripped down driver just supporting the TBS card I use (I already have >> one I use with dkms), but I'm not sure I have the time or knowledge of this >> chipset to be a maintainer. There is chipset specific stuff to fix, especially irq handling. > As we're talking more about touching at uAPI, probably it doesn't require > chipsed knowledge. Only time and interest on doing it. > > Please sync with Soeren. Perhaps if you both could help on it, it would > make the task easier. As I already wrote to different people off-list: I'm happy to support more cards with the saa7160 bridge and maintain these in this driver. As hobbyist programmer this of course makes no sense to me, if the hardware I own (S2-6400) is not supported. Regards, Soeren >> Unfortunately my workplace is phasing out >> these cards otherwise I'd try and get them to sponsor me rather than do it >> on my own time! > Yeah, getting sponsored to do it would make things easier. > > Thanks, > Mauro
Re: [GIT PULL] SAA716x DVB driver
Mauro, On 28.11.2017 19:35, Mauro Carvalho Chehab wrote: > Em Mon, 25 Sep 2017 00:17:00 +0200 > Soeren Moch escreveu: > >>> What I'm saying is that, >>> if we're adding it on staging, we need to have a plan to reimplement >>> it to whatever API replaces the DVB video API, as this API likely >>> won't stay upstream much longer. >> AFAIK it is not usual linux policy to remove existing drivers >> with happy users and even someone who volunteered to >> maintain this. > The usual Linux policy doesn't apply to staging. The goal of staging is > to add drivers that have problems, but are fixable, and whose someone > is working to solve those issues. It is totally clear to me what staging is for. Therefore I submitted this driver for staging. I was talking about the ttpci driver. This drivers lives in drivers/media/pci/ttpci, not in staging, it implements the DVB audio/video/osd API, works great and has happy users. So the DVB video API _is already_ part of the linux userspace API. This pull request does not add anything to the already available in-kernel video API. > The staging policies include adding a TODO file describing the problems > that should be solved for the driver to be promoted. If such problems > aren't solved, the driver can be removed. Yes, of course. Therefore I added such TODO file and promised to solve these issues. > > For example, this year, we removed some lirc staging drivers because > no developers were interested (and/or had the hardware) to convert > them to use the RC core (with is a Kernel's internal API). > > In the case of saa716x, the issue is that it uses a deprecated > and undocumented userspace API, with is a way more serious issue. Unfortunately there is no other API available which provides _all_ the functionality of DVB audio/video/osd. And the TT S2-6400 hardware is developed in a way, so that it is as similar as possible to ttpci cards. In order that the vdr application can easily make use of it. So it is not surprising, that the saa716x_ff driver needs to implement the same APIs as the ttpci driver. > I'm ok to add this driver to staging if we can agree on what > should be fixed, and if someone commits to try fixing it, knowing, > in advance, that, if it doesn't get fixed on a reasonable time, it > can be removed on later Kernel versions. I already agreed on all these points. I already promised to fix whatever is necessary to get this driver out of staging, as long as the userspace API remains the same so that vdr continues to work with these cards. And once again, this API already is part of the kernel and not specific for this driver. The driver version in this pull request does not build anymore with linux-4.15-rc1. Shall I provide a new pull request with this fixed? Thanks, Soeren
Re: [GIT PULL] SAA716x DVB driver
On 16.09.2017 19:49, Mauro Carvalho Chehab wrote: > Em Sat, 16 Sep 2017 14:54:15 +0200 > Soeren Moch escreveu: > >> On 09.09.2017 23:20, Mauro Carvalho Chehab wrote: >>> Em Sat, 9 Sep 2017 14:52:18 +0200 >>> Soeren Moch escreveu: >>> >>>> You explicitly >>>> want to discourage new driver and application implementations. >>> Me? It is just the opposite: sticking with a poorly documented API >>> that almost nobody knows seems to be what discouraged new drivers >>> and applications. >> OK, then you are fine to keep the audio/video/osd API in this driver, great! > My current understanding is that keeping audio/video API doesn't make > any sense, for a couple of reasons: For me, keeping this interface makes a lot of sense. > 1. it was never fully documented; Nothing what prevents existing drivers to work, and new drivers to be written, as can be seen from this pull request. > 2. the only upstream hardware that supports them was developed on >about 17 years ago; But was sold for several years in lots of different versions, even hardware modifications were developed and applied by lots of users to improve the performance of these cards, and most important, these cards are still in use. > 3. the API is broken with regards to compat32 and Y2038 (see more >below); Not unique for this driver and, since this API has no business with wall clock time, not too complicated to fix. > 4. almost all (if not all) features they support are also supported >by V4L2 and ALSA; Here we come to the point. The DVB audio/video API just works, there are working drivers, working applications (vdr) and happy users. The audio/video/osd device nodes are nicely grouped below 1 adapter, so it is immediately clear, which devices belong together. It is very easy to implement the classic multimedia set-top box use case (audio and video decoding with menu overlays). For this use case it is the ideal interface. You propose V4L2/ALSA instead, what has "almost all features". May be, but "almost all" is not all, and a collection of features does not give us a working system. /dev/videoX device names are not stable across boots, it is even more complicated to find matching devices for different hardware with otherwise similar capabilities. With V4L2/ALSA there is no real A/V synchronisation, selected ALSA devices are reassigned during suspend or even HDMI hotplug. So audio gets lost when switching the monitor off and on again. So while audio/video/osd is an integrated multimedia interface with working drivers and happy users, for me V4L2/ALSA is not ready to immediately replace it. > 5. V4L2 supports a lot more features that video decoders support >than video API, like H.264 and other newer video standards, plus >HDMI setup features. The S2-6400 card also decodes H.264, and the API is not limited to any set of video coding standards. This card decodes frame synchronous audio and video and correctly signals audio/video formats in HDMI AVI frames (e.g. AC3 / PCM audio, video aspect ratios,...). You did not explain how this should work with V4L2/ALSA. For other use cases other types of v4l2 devices could be more appropriate. The two APIs coexist for years in mainline linux without problems. > In the past, we tried a lot to get documentation for those > DVB APIs, but, unfortunately, nobody that worked on its development > sent us patches addressing the API documentation. You probably know why the ttpci developers stopped sending patches to linux-media. > With regards to OSD, as no other documented API emerged to > fulfill what it does, it could make sense to keep it, if > someone properly documents it. > >>>> With linux core APIs for FF you probably mean some new >>>> API combination as successor of the audio/video/osd API. >>>> The S2-6400 unfortunately directly implements the old API >>>> in hardware and is therefore the worst possible match for >>>> such new driver generation. >>> It sounds weird that the API is directly implemented in hardware. >>> I can't tell much, though, as I didn't see the code yet. >> All the available code is in this pull request. > I know. I'll look on it if we reach an agreement. > >> I really don't understand your Kaffeine use case. Kaffeine is a media >> player, which displays the decoded video on a KDE/Gnome desktop. >> With the S2-6400 it is not possible to read the decoded video back, >> so it is not possible to display something in a desktop window. >> I cannot image what you want to do with this hardware and Kaffeine. > I see. > >>>>> One alternative we could do would be to add the proper APIs for the >>>>> driver and keep for a
Re: [GIT PULL] SAA716x DVB driver
On 09.09.2017 23:20, Mauro Carvalho Chehab wrote: > Em Sat, 9 Sep 2017 14:52:18 +0200 > Soeren Moch escreveu: > >> Hi Mauro, >> >> sorry for the late reply, unfortunately your email was filtered out as spam. > I'll focus talking about saa716x/av7110 here, as this is out of of > scope of the documentation patches. > >> On 27.08.2017 12:30, Mauro Carvalho Chehab wrote: >>> Em Fri, 21 Jul 2017 22:44:42 +0200 >>> Soeren Moch escreveu: >>> >>>> Hi Mauro, >>>> >>>> On 20.07.2017 07:49:36 -0300, Mauro Carvalho Chehab wrote: >>>>> Hi Soeren, >>>>> >>>>> Em Sun, 16 Jul 2017 20:34:23 +0200 >>>>> Soeren Moch escreveu: >>>>> >>>>>> This is a driver for DVB cards based on the SAA7160/62 PCIe bridges from >>>>>> Philips/NXP. The most important of these cards, at least for me, is the >>>>>> TechnoTrend S2-6400, a high-definition full-featured DVB-S2 card, the >>>>>> successor of the famous ttpci decoder cards. Other supported cards are: >>>>>> Avermedia H788 >>>>>> Avermedia HC82 Express-54 >>>>>> KNC One Dual S2 >>>>>> KWorld DVB-T PE310 >>>>>> Technisat SkyStar 2 eXpress HD >>>>>> Twinhan/Azurewave VP-1028 >>>>>> Twinhan/Azurewave VP-3071 >>>>>> Twinhan/Azurewave VP-6002 >>>>>> Twinhan/Azurewave VP-6090 >>>>>> >>>>>> The driver is taken from [1] with adaptations for current mainline, >>>>>> converted to git and moved to drivers/staging/media. See TODO for >>>>>> required cleanups (from my point of view, maybe more to come from >>>>>> additional code review by other developers). I added myself as driver >>>>>> maintainer to document my commitment to further development to get this >>>>>> out of staging, help from others welcome. >>>>>> >>>>>> This driver was licensed "GPL" from the beginning. S2-6400 firmware is >>>>>> available at [2]. >>>>>> >>>>>> I want to preserve the development history of the driver, since this >>>>>> is mainly work of Andreas Regel, Manu Abraham, and Oliver Endriss. >>>>>> Unfortunately Andreas seems not to take care of this driver anymore, he >>>>>> also did not answer my requests to integrate patches for newer kernel >>>>>> versions. So I send this upstream. >>>>>> >>>>>> With all the history this is a 280 part patch series, so I send this as >>>>>> pull request. Of course I can also send this as 'git send-email' series >>>>>> if desired. >>>>> Even on staging, reviewing a 280 patch series take a while ;) >>>>> >>>>> As the patches that make it build with current upstream are at the >>>>> end of the series, you need to be sure that the saa716x Makefile >>>>> won't be included until those fixes get applied. It seems you took >>>>> care of it already, with is good! >>>>> >>>>> >>>>> The hole idea of adding a driver to staging is that it will be moved >>>>> some day out of staging. That's why a TODO and an entry at MAINTAINERS >>>>> is required. >>>>> >>>>> By looking at the saa716x_ff_main: >>>>> >>>>> >>>> https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/saa716x_ff_main.c >>>> >>>>> I'm seeing that the main problem of this driver is that it still use >>>>> the API from the legacy ttpci driver, e. g. DVB audio, video and osd APIs. >>>>> >>>>> Those APIs were deprecated because they duplicate a functionality >>>>> provided by the V4L2 API, and are obscure, because they're not >>>>> properly documented. Also, no other driver uses it upstream. >>>>> >>>>> So, it was agreed several years ago that new full featured drivers >>>>> should use the V4L2 API for audio/video codecs. >>>>> >>>>> We have a some drivers that use V4L2 for MPEG audio/video decoding >>>>> and encoding. The best examples are ivtv and cx18 (as both are for >>>>> PCI devices). Currently, none of those drivers support the DVB
Re: [GIT PULL] SAA716x DVB driver
Hi Mauro, sorry for the late reply, unfortunately your email was filtered out as spam. On 27.08.2017 12:30, Mauro Carvalho Chehab wrote: > Em Fri, 21 Jul 2017 22:44:42 +0200 > Soeren Moch escreveu: > >> Hi Mauro, >> >> On 20.07.2017 07:49:36 -0300, Mauro Carvalho Chehab wrote: >>> Hi Soeren, >>> >>> Em Sun, 16 Jul 2017 20:34:23 +0200 >>> Soeren Moch escreveu: >>> >>>> This is a driver for DVB cards based on the SAA7160/62 PCIe bridges from >>>> Philips/NXP. The most important of these cards, at least for me, is the >>>> TechnoTrend S2-6400, a high-definition full-featured DVB-S2 card, the >>>> successor of the famous ttpci decoder cards. Other supported cards are: >>>> Avermedia H788 >>>> Avermedia HC82 Express-54 >>>> KNC One Dual S2 >>>> KWorld DVB-T PE310 >>>> Technisat SkyStar 2 eXpress HD >>>> Twinhan/Azurewave VP-1028 >>>> Twinhan/Azurewave VP-3071 >>>> Twinhan/Azurewave VP-6002 >>>> Twinhan/Azurewave VP-6090 >>>> >>>> The driver is taken from [1] with adaptations for current mainline, >>>> converted to git and moved to drivers/staging/media. See TODO for >>>> required cleanups (from my point of view, maybe more to come from >>>> additional code review by other developers). I added myself as driver >>>> maintainer to document my commitment to further development to get this >>>> out of staging, help from others welcome. >>>> >>>> This driver was licensed "GPL" from the beginning. S2-6400 firmware is >>>> available at [2]. >>>> >>>> I want to preserve the development history of the driver, since this >>>> is mainly work of Andreas Regel, Manu Abraham, and Oliver Endriss. >>>> Unfortunately Andreas seems not to take care of this driver anymore, he >>>> also did not answer my requests to integrate patches for newer kernel >>>> versions. So I send this upstream. >>>> >>>> With all the history this is a 280 part patch series, so I send this as >>>> pull request. Of course I can also send this as 'git send-email' series >>>> if desired. >>> Even on staging, reviewing a 280 patch series take a while ;) >>> >>> As the patches that make it build with current upstream are at the >>> end of the series, you need to be sure that the saa716x Makefile >>> won't be included until those fixes get applied. It seems you took >>> care of it already, with is good! >>> >>> >>> The hole idea of adding a driver to staging is that it will be moved >>> some day out of staging. That's why a TODO and an entry at MAINTAINERS >>> is required. >>> >>> By looking at the saa716x_ff_main: >>> >>> >> https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/saa716x_ff_main.c >>> I'm seeing that the main problem of this driver is that it still use >>> the API from the legacy ttpci driver, e. g. DVB audio, video and osd APIs. >>> >>> Those APIs were deprecated because they duplicate a functionality >>> provided by the V4L2 API, and are obscure, because they're not >>> properly documented. Also, no other driver uses it upstream. >>> >>> So, it was agreed several years ago that new full featured drivers >>> should use the V4L2 API for audio/video codecs. >>> >>> We have a some drivers that use V4L2 for MPEG audio/video decoding >>> and encoding. The best examples are ivtv and cx18 (as both are for >>> PCI devices). Currently, none of those drivers support the DVB >>> API, though, as they're used only on analog TV devices. >>> >>> It was also agreed that setup pipelines on more complex DVB >>> devices should use the media controller API (MC API). >>> >>> Yet, we don't have, currently, any full featured drivers upstream >>> (except for the legacy one). >>> >>> So, if we're willing to apply this driver, you should be committed >>> to do implement the media APIs properly, porting from DVB >>> audio/video/osd to V4L2 and MC APIs. >>> >>> That should also reflect its TODO: >>> >>> >> https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/TODO >> >> Thanks for your feedback. I understand all your concerns about the legacy >> API and your request to
Re: [PATCH 00/15] Improve DVB documentation and reduce its gap
On 04.09.2017 13:29, Mauro Carvalho Chehab wrote: > Em Mon, 4 Sep 2017 02:55:15 +0200 > Soeren Moch escreveu: > >> Hi Mauro, >> >> On 01.09.2017 11:32, Mauro Carvalho Chehab wrote: >>> Em Fri, 1 Sep 2017 10:40:28 +0200 >>> Honza Petrouš escreveu: >>> >>>> 2017-09-01 1:46 GMT+02:00 Mauro Carvalho Chehab >>>> : >>>>> The DVB documentation was negligected for a long time, with >>>>> resulted on several gaps between the API description and its >>>>> documentation. >>>>> >>>>> I'm doing a new reading at the documentation. As result of it, >>>>> this series: >>>>> >>>>> - improves the introductory chapter, making it more generic; >>>>> - Do some adjustments at the frontend API, using kernel-doc >>>>> when possible. >>>>> - Remove unused APIs at DVB demux. I suspect that the drivers >>>>> implementing such APIs were either never merged upstream, >>>>> or the API itself were never used or was deprecated a long >>>>> time ago. In any case, it doesn't make any sense to carry >>>>> on APIs that aren't properly documented, nor are used on the >>>>> upstream Kernel. >>>>> >>>>> With this patch series, the gap between documentation and >>>>> code is solved for 3 DVB APIs: >>>>> >>>>> - Frontend API; >>>>> - Demux API; >>>>> - Net API. >>>>> >>>>> There is still a gap at the CA API that I'll try to address when I >>>>> have some time[1]. >>>>> >>>>> [1] There's a gap also on the legacy audio, video and OSD APIs, >>>>> but, as those are used only by a single very old deprecated >>>>> hardware (av7110), it is probably not worth the efforts. >>>>> >> av7110 cards may be old, but there are still users of these cards. >> For instance I'm watching TV received and decoded with such card in this >> moment. >> So what do you mean with "deprecated hardware"? > Nobody is telling otherwise. What I mean by "deprecated" is that it is > not a product that you could got to a shop and buy a new one. Its > production stopped a long time ago. > >>>> I agree that av7110 is very very old piece of hw (but it is already >>>> in my hall of fame because of its Skystar 1 incarnation as >>>> first implementation of DVB in Linux) and it is sad that we still >>>> don't have at least one driver for any SoC with embedded DVB >>>> devices. >>> Yeah, av7110 made history. Please notice that this series doesn't >>> remove any API that it is used by it. All it removes are the APIs >>> that there's no Kernel driver using. >>> >>> Carry on APIs without client is usually a very bad idea, as nobody >>> could be certain about how to use it. It is even worse when such >>> APIs are not properly documented (with is the case here). >>> >>>> I understand that the main issue is that no any DVB-enabled >>>> SoC vendor is interested in upstreaming theirs code, but I still hope >>>> it will change in near future(*) >>> We have one driver for a SoC DVB hardware at: >>> drivers/media/platform/sti/c8sectpfe/ >>> >>> I guess it still doesn't cover the entire SoC, but this is a WiP. If I >>> remember well, at the midia part of the SoC, they started by submitting >>> the Remote Controller code. >>> >>>> Without having full-featured DVB device in vanilla, we surely don't >>>> get some parts of DVB API covered. I can imagine that when >>>> somebody comes with such full-featured device he wants to reinvent >>>> just removed bits. >>> Re-adding the removed bits is easy. However, the API defined for >>> av7110 is old and it is showing its age: it assumes a limited number >>> of possible inputs/outputs. Modern SoC has a lot more ways link the >>> audio/video IP blocks than what the API provides. On a modern SoC, >>> not only DVB is supported, but also analog inputs (to support things >>> like composite input), cameras, HDMI inputs and even analog TV. >>> All of them interconnected to a media ISP. The current FF API can't >>> represent such hardware. >>> >>> The best API to represent those pipelines that exist on SoC f
Re: [PATCH 00/15] Improve DVB documentation and reduce its gap
Hi Mauro, On 01.09.2017 11:32, Mauro Carvalho Chehab wrote: > Em Fri, 1 Sep 2017 10:40:28 +0200 > Honza Petrouš escreveu: > >> 2017-09-01 1:46 GMT+02:00 Mauro Carvalho Chehab : >>> The DVB documentation was negligected for a long time, with >>> resulted on several gaps between the API description and its >>> documentation. >>> >>> I'm doing a new reading at the documentation. As result of it, >>> this series: >>> >>> - improves the introductory chapter, making it more generic; >>> - Do some adjustments at the frontend API, using kernel-doc >>> when possible. >>> - Remove unused APIs at DVB demux. I suspect that the drivers >>> implementing such APIs were either never merged upstream, >>> or the API itself were never used or was deprecated a long >>> time ago. In any case, it doesn't make any sense to carry >>> on APIs that aren't properly documented, nor are used on the >>> upstream Kernel. >>> >>> With this patch series, the gap between documentation and >>> code is solved for 3 DVB APIs: >>> >>> - Frontend API; >>> - Demux API; >>> - Net API. >>> >>> There is still a gap at the CA API that I'll try to address when I >>> have some time[1]. >>> >>> [1] There's a gap also on the legacy audio, video and OSD APIs, >>> but, as those are used only by a single very old deprecated >>> hardware (av7110), it is probably not worth the efforts. >>> av7110 cards may be old, but there are still users of these cards. For instance I'm watching TV received and decoded with such card in this moment. So what do you mean with "deprecated hardware"? >> I agree that av7110 is very very old piece of hw (but it is already >> in my hall of fame because of its Skystar 1 incarnation as >> first implementation of DVB in Linux) and it is sad that we still >> don't have at least one driver for any SoC with embedded DVB >> devices. > Yeah, av7110 made history. Please notice that this series doesn't > remove any API that it is used by it. All it removes are the APIs > that there's no Kernel driver using. > > Carry on APIs without client is usually a very bad idea, as nobody > could be certain about how to use it. It is even worse when such > APIs are not properly documented (with is the case here). > >> I understand that the main issue is that no any DVB-enabled >> SoC vendor is interested in upstreaming theirs code, but I still hope >> it will change in near future(*) > We have one driver for a SoC DVB hardware at: > drivers/media/platform/sti/c8sectpfe/ > > I guess it still doesn't cover the entire SoC, but this is a WiP. If I > remember well, at the midia part of the SoC, they started by submitting > the Remote Controller code. > >> Without having full-featured DVB device in vanilla, we surely don't >> get some parts of DVB API covered. I can imagine that when >> somebody comes with such full-featured device he wants to reinvent >> just removed bits. > Re-adding the removed bits is easy. However, the API defined for > av7110 is old and it is showing its age: it assumes a limited number > of possible inputs/outputs. Modern SoC has a lot more ways link the > audio/video IP blocks than what the API provides. On a modern SoC, > not only DVB is supported, but also analog inputs (to support things > like composite input), cameras, HDMI inputs and even analog TV. > All of them interconnected to a media ISP. The current FF API can't > represent such hardware. > > The best API to represent those pipelines that exist on SoC for > multimedia is the media controller, where all IP blocks and their > links (whatever they are) can be represented, if needed. > > The audio and video DVB API is also too limited: it hasn't > evolved since when it was added. For audio, the ALSA API > allows a way more control of the hardware; for video, the > V4L2 API nowadays has all the bits to control video decoding > and encoding. Both APIs provide support for audio and video > inputs commonly found on those devices. The real advantage of the DVB audio/video/osd API is the possibility of frame synchronous audio/video/overlay output for high-quality audio/video playback, maybe with picture-in-picture functionality. Especially audio synchronization is not easy when the audio format changes from compressed audio (e.g. AC-3) to PCM (stereo), e.g. on HDMI output. While HDMI output hardware usually takes video frames and audio packets (and AVI info frames for audio/video format signalization) synchronously, V4L2 and ALSA rip these data blocks apart and push these through different pipelines with different buffering properties. This makes it very difficult for userspace applications. With the DVB API the hardware takes care of the synchronisation. > Also, nowadays, video decoding usually happens at the GPU on SoC. So, > in practice, a SoC FF would likely use the DRM subsystem to control the > video codecs. I think this is a common misunderstanding. Video is decoded on separate hardware blocks nowadays, not on a (3D-)GPU. GPU vendors
[GIT PULL RESEND] SAA716x DVB driver
ort for the second adapter saa716x: Initialize adapters on the budget device saa716x: Register only the relevant adapters for a specific device saa716x: Add Avermedia HC82 specific device configuration saa716x: Fix typo saa716x: Register an array of devices saa716x: Add support for the Avermedia H788 device saa716x: Add support for the Azurewave VP-6002 device saa716x: Usea separate frontend_attach for each of the devices saa716x: Use a separate IRQ handler for separate modules saa716x: Try to attach the demodulator saa716x: Fix typo in register definitions saa716x: Updates and Code simplification saa716x: Check device revision for I2C bus orderring saa716x: Add support for the NXP Atlantis reference design saa716x: Free IRQ before module unload saa716x: Code reorganization saa716x: Add support for the KNC1 Dual S2 device saa716x: Add support for the VP-3071 DVB-T dual device saa716x: Add GPIO control functions saa716x: Use power and reset controls within a sig\ngle loop saa716x: Use a configuration per adapter saa716x: VP-1028: add power, reset configuration saa716x: H788: Add power, reset configuration saa716x: HC82: Add power, reset configuration saa716x: Display Bus status saa716x: Bug: Address needs to be shifted one bit saa716x: Initial go at DMA routines saa716x: Print warning, if MSI module is not supported saa716x: Handle MSI in a generic manner saa716x: Add PHI port definitions saa716x: Initialize PHI bus saa716x: Add GREG routines saa716x: Reorganize CGU related routines saa716x: Do not initialize the CGU twice saa716x: Add more debug info, initialize handler count saa716x: Add/remove I2C MSI vectors saa716x: Add interrupt debugging saa716x: Return error on MSI enable failure saa716x: Initialize FPGI pagetables saa716x: Setup FGPI parameters saa716x: Use a separate module to handle Full fledged cards saa716x: NULL terminate PCI ID list saa716x: Read the mask bits instead saa716x: Reduce a bit of noise in the handler debug mode saa716x: Sleep a little while before enabling interrupts again saa716x: Use individual handlers saa716x: Transmit D is programmed, not S data saa716x: Print return values saa716x: Use adapter ordering saa716x: Disable debugging osd.h: Kickstart the TT S2 6400 Dual HD Premium - OSD update saa716x: Kickstart the TT S2 6400 Dual HD Premium saa716x: Code simplification, Overhaul, ROM dump saa716x: Set the default rate for the NEMO reference design saa716x: Code simplification, Overhauling, I2C related fixes saa716x: Try to attach the frontends saa716x: Don't cast pointers to 32 bit int saa716x: Partial rework of SPI I/O saa716x: Add video device support saa716x: S2-6400: Try to attach the frontend saa716x: Handle multiple I2C messages saa716x: Fix ROM parser saa716x: Setup default I2C rates saa716x: Fix BUS ordering saa716x: Fix swapped I2C buses saa716x: Print wait time, reduce number of loops saa716x: Fix missing address in single write operation saa716x: make register definitions specific to each of the modules saa716x: Fix register definition typo saa716x: Add function declaration saa716x: Fix FGPI internal clock divider state saa716x: Fix dmabuf allocation saa716x: Cleanup debug prints saa716x: Handle failure correctly saa716x: Handle proper buffer flush saa716x: FGPI DMA handling fixes saa716x: Finally! we have stream capture saa716x: Make the framework buildable saa716x: Fix build issues saa716x: Deinitialize I2C interrupts on exit saa716x: Factorize register/detach routines to common code saa716x: Start DMA engine as and when requested saa716x: Enable timeout for modules having no clock saa716x: Reset the frontend after powerup saa716x: GPIO fix saa716x: Fix powerup/reset saa716x: Use the correct I2C Bus saa716x: Code simplification saa716x: Try to attach frontend on the Nemo reference board saa716x: Do not report non-fatal errors to avoid issues with buggy BIOS's Oliver Endriss (3): saa716x_ff: Rename saa716x_ff.c to saa716x_ff_main.c saa716x_ff: Support remote control receiver saa716x: Use tasklet to transfer data to the demuxer (TT S2-6400) Soeren Moch (13): saa716x: i2c_del_adapter() fix saa716x_ff: init frontends to low-power mode saa716x_ff: Add linux-4.5 support saa716x_ff: Avoid sleeping in fifo_worker saa716x: remove unused saa716x_msi_handler saa716x: pci: Remove asm includes for compatibility with linux-4.6 saa716x: add linux-4.10 support saa716x: Remove broken
Re: [GIT PULL] SAA716x DVB driver
Hi Mauro, On 20.07.2017 07:49:36 -0300, Mauro Carvalho Chehab wrote: >Hi Soeren, > >Em Sun, 16 Jul 2017 20:34:23 +0200 >Soeren Moch escreveu: > >> This is a driver for DVB cards based on the SAA7160/62 PCIe bridges from >> Philips/NXP. The most important of these cards, at least for me, is the >> TechnoTrend S2-6400, a high-definition full-featured DVB-S2 card, the >> successor of the famous ttpci decoder cards. Other supported cards are: >> Avermedia H788 >> Avermedia HC82 Express-54 >> KNC One Dual S2 >> KWorld DVB-T PE310 >> Technisat SkyStar 2 eXpress HD >> Twinhan/Azurewave VP-1028 >> Twinhan/Azurewave VP-3071 >> Twinhan/Azurewave VP-6002 >> Twinhan/Azurewave VP-6090 >> >> The driver is taken from [1] with adaptations for current mainline, >> converted to git and moved to drivers/staging/media. See TODO for >> required cleanups (from my point of view, maybe more to come from >> additional code review by other developers). I added myself as driver >> maintainer to document my commitment to further development to get this >> out of staging, help from others welcome. >> >> This driver was licensed "GPL" from the beginning. S2-6400 firmware is >> available at [2]. >> >> I want to preserve the development history of the driver, since this >> is mainly work of Andreas Regel, Manu Abraham, and Oliver Endriss. >> Unfortunately Andreas seems not to take care of this driver anymore, he >> also did not answer my requests to integrate patches for newer kernel >> versions. So I send this upstream. >> >> With all the history this is a 280 part patch series, so I send this as >> pull request. Of course I can also send this as 'git send-email' series >> if desired. > >Even on staging, reviewing a 280 patch series take a while ;) > >As the patches that make it build with current upstream are at the >end of the series, you need to be sure that the saa716x Makefile >won't be included until those fixes get applied. It seems you took >care of it already, with is good! > > >The hole idea of adding a driver to staging is that it will be moved >some day out of staging. That's why a TODO and an entry at MAINTAINERS >is required. > >By looking at the saa716x_ff_main: > > https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/saa716x_ff_main.c > >I'm seeing that the main problem of this driver is that it still use >the API from the legacy ttpci driver, e. g. DVB audio, video and osd APIs. > >Those APIs were deprecated because they duplicate a functionality >provided by the V4L2 API, and are obscure, because they're not >properly documented. Also, no other driver uses it upstream. > >So, it was agreed several years ago that new full featured drivers >should use the V4L2 API for audio/video codecs. > >We have a some drivers that use V4L2 for MPEG audio/video decoding >and encoding. The best examples are ivtv and cx18 (as both are for >PCI devices). Currently, none of those drivers support the DVB >API, though, as they're used only on analog TV devices. > >It was also agreed that setup pipelines on more complex DVB >devices should use the media controller API (MC API). > >Yet, we don't have, currently, any full featured drivers upstream >(except for the legacy one). > >So, if we're willing to apply this driver, you should be committed >to do implement the media APIs properly, porting from DVB >audio/video/osd to V4L2 and MC APIs. > >That should also reflect its TODO: > > https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/TODO Thanks for your feedback. I understand all your concerns about the legacy API and your request to convert this to v4l2. For me the whole story looks a little bit different, though. The only application which makes use of the decoder part of this saa716x_ff driver is VDR (Video Disk Recorder by Klaus Schmidinger, [1] [2]) - if anybody else knows about a different use-case, please speak up! In fact the high-definition version of VDR (vdr-2.x) was co-developed with the S2-6400 hardware and this saa716x_ff driver. So it is no surprise, that this driver utilizes the - now legacy - DVB API of the ttpci cards, since VDR was originally developed with this API in mind. The missing API documentation, besides of course not being ideal, is therefore no real problem here, since driver and application are closely tied together. The S2-6400 card (the only hardware which saa716x_ff supports) only has two simple hardware interfaces for the decoder part, a transport stream interface for the video/audio decoder, and a DVB API command interface for osd. Th
[GIT PULL] SAA716x DVB driver
egister definition typo saa716x: Add function declaration saa716x: Fix FGPI internal clock divider state saa716x: Fix dmabuf allocation saa716x: Cleanup debug prints saa716x: Handle failure correctly saa716x: Handle proper buffer flush saa716x: FGPI DMA handling fixes saa716x: Finally! we have stream capture saa716x: Make the framework buildable saa716x: Fix build issues saa716x: Deinitialize I2C interrupts on exit saa716x: Factorize register/detach routines to common code saa716x: Start DMA engine as and when requested saa716x: Enable timeout for modules having no clock saa716x: Reset the frontend after powerup saa716x: GPIO fix saa716x: Fix powerup/reset saa716x: Use the correct I2C Bus saa716x: Code simplification saa716x: Try to attach frontend on the Nemo reference board saa716x: Do not report non-fatal errors to avoid issues with buggy BIOS's Oliver Endriss (3): saa716x_ff: Rename saa716x_ff.c to saa716x_ff_main.c saa716x_ff: Support remote control receiver saa716x: Use tasklet to transfer data to the demuxer (TT S2-6400) Soeren Moch (13): saa716x: i2c_del_adapter() fix saa716x_ff: init frontends to low-power mode saa716x_ff: Add linux-4.5 support saa716x_ff: Avoid sleeping in fifo_worker saa716x: remove unused saa716x_msi_handler saa716x: pci: Remove asm includes for compatibility with linux-4.6 saa716x: add linux-4.10 support saa716x: Remove broken MSI-X support saa716x: Use %zu printk format for sizeof return values saa716x_budget: Fix build in current mainline saa716x_hybrid: Fix build in current mainline saa716x: Hook up driver in staging/media saa716x: Add MAINTAINERS entry MAINTAINERS |6 + drivers/staging/media/Kconfig|2 + drivers/staging/media/Makefile |1 + drivers/staging/media/saa716x/Kconfig| 63 + drivers/staging/media/saa716x/Makefile | 27 + drivers/staging/media/saa716x/TODO |6 + drivers/staging/media/saa716x/saa716x_adap.c | 251 +++ drivers/staging/media/saa716x/saa716x_adap.h |9 + drivers/staging/media/saa716x/saa716x_aip.c | 20 + drivers/staging/media/saa716x/saa716x_aip.h |9 + drivers/staging/media/saa716x/saa716x_aip_reg.h | 62 + drivers/staging/media/saa716x/saa716x_boot.c | 319 drivers/staging/media/saa716x/saa716x_boot.h | 18 + drivers/staging/media/saa716x/saa716x_budget.c | 664 drivers/staging/media/saa716x/saa716x_budget.h | 15 + drivers/staging/media/saa716x/saa716x_cgu.c | 540 +++ drivers/staging/media/saa716x/saa716x_cgu.h | 63 + drivers/staging/media/saa716x/saa716x_cgu_reg.h | 178 +++ drivers/staging/media/saa716x/saa716x_dcs_reg.h | 56 + drivers/staging/media/saa716x/saa716x_dma.c | 308 drivers/staging/media/saa716x/saa716x_dma.h | 61 + drivers/staging/media/saa716x/saa716x_dma_reg.h | 201 +++ drivers/staging/media/saa716x/saa716x_ff.h | 187 +++ drivers/staging/media/saa716x/saa716x_ff_cmd.c | 433 + drivers/staging/media/saa716x/saa716x_ff_cmd.h | 16 + drivers/staging/media/saa716x/saa716x_ff_ir.c| 265 +++ drivers/staging/media/saa716x/saa716x_ff_main.c | 1859 ++ drivers/staging/media/saa716x/saa716x_ff_phi.c | 229 +++ drivers/staging/media/saa716x/saa716x_ff_phi.h | 14 + drivers/staging/media/saa716x/saa716x_fgpi.c | 386 + drivers/staging/media/saa716x/saa716x_fgpi.h | 92 ++ drivers/staging/media/saa716x/saa716x_fgpi_reg.h | 74 + drivers/staging/media/saa716x/saa716x_gpio.c | 140 ++ drivers/staging/media/saa716x/saa716x_gpio.h | 26 + drivers/staging/media/saa716x/saa716x_gpio_reg.h | 47 + drivers/staging/media/saa716x/saa716x_greg.c | 42 + drivers/staging/media/saa716x/saa716x_greg.h |9 + drivers/staging/media/saa716x/saa716x_greg_reg.h | 91 ++ drivers/staging/media/saa716x/saa716x_hybrid.c | 726 + drivers/staging/media/saa716x/saa716x_hybrid.h | 13 + drivers/staging/media/saa716x/saa716x_i2c.c | 728 + drivers/staging/media/saa716x/saa716x_i2c.h | 52 + drivers/staging/media/saa716x/saa716x_i2c_reg.h | 145 ++ drivers/staging/media/saa716x/saa716x_mod.h | 50 + drivers/staging/media/saa716x/saa716x_msi.c | 479 ++ drivers/staging/media/saa716x/saa716x_msi.h | 87 + drivers/staging/media/saa716x/saa716x_msi_reg.h | 143 ++ drivers/staging/media/saa716x/saa716x_pci.c | 222 +++ drivers/staging/media/saa716x/saa716x_phi.c | 23 + drivers/staging/media/saa716x/saa716x_phi.h |8 + drivers/staging/media/saa716x/saa716x_phi_reg.h | 94 ++ drivers/staging/media/saa716x/saa716x_priv.h | 193 +++
[PATCH v2] media: dvb_ringbuffer: Add memory barriers
Implement memory barriers according to Documentation/circular-buffers.txt:
- use smp_store_release() to update ringbuffer read/write pointers
- use smp_load_acquire() to load write pointer on reader side
- use ACCESS_ONCE() to load read pointer on writer side
This fixes data stream corruptions observed e.g. on an ARM Cortex-A9
quad core system with different types (PCI, USB) of DVB tuners.
Signed-off-by: Soeren Moch
Cc: sta...@vger.kernel.org # 3.14+
---
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Since smp_store_release() and smp_load_acquire() were introduced in linux-3.14,
a 3.14+ stable tag was added. Is it desired to apply a similar patch to older
stable kernels?
changes in v2:
- add comments for smp_store_release() and smp_load_acquire() calls
to avoid checkpatch warnings
---
drivers/media/dvb-core/dvb_ringbuffer.c | 74 +++--
1 file changed, 61 insertions(+), 13 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_ringbuffer.c
b/drivers/media/dvb-core/dvb_ringbuffer.c
index 1100e98..7df7fb3 100644
--- a/drivers/media/dvb-core/dvb_ringbuffer.c
+++ b/drivers/media/dvb-core/dvb_ringbuffer.c
@@ -55,7 +55,13 @@ void dvb_ringbuffer_init(struct dvb_ringbuffer *rbuf, void
*data, size_t len)
int dvb_ringbuffer_empty(struct dvb_ringbuffer *rbuf)
{
- return (rbuf->pread==rbuf->pwrite);
+ /* smp_load_acquire() to load write pointer on reader side
+* this pairs with smp_store_release() in dvb_ringbuffer_write(),
+* dvb_ringbuffer_write_user(), or dvb_ringbuffer_reset()
+*
+* for memory barriers also see Documentation/circular-buffers.txt
+*/
+ return (rbuf->pread == smp_load_acquire(&rbuf->pwrite));
}
@@ -64,7 +70,12 @@ ssize_t dvb_ringbuffer_free(struct dvb_ringbuffer *rbuf)
{
ssize_t free;
- free = rbuf->pread - rbuf->pwrite;
+ /* ACCESS_ONCE() to load read pointer on writer side
+* this pairs with smp_store_release() in dvb_ringbuffer_read(),
+* dvb_ringbuffer_read_user(), dvb_ringbuffer_flush(),
+* or dvb_ringbuffer_reset()
+*/
+ free = ACCESS_ONCE(rbuf->pread) - rbuf->pwrite;
if (free <= 0)
free += rbuf->size;
return free-1;
@@ -76,7 +87,11 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf)
{
ssize_t avail;
- avail = rbuf->pwrite - rbuf->pread;
+ /* smp_load_acquire() to load write pointer on reader side
+* this pairs with smp_store_release() in dvb_ringbuffer_write(),
+* dvb_ringbuffer_write_user(), or dvb_ringbuffer_reset()
+*/
+ avail = smp_load_acquire(&rbuf->pwrite) - rbuf->pread;
if (avail < 0)
avail += rbuf->size;
return avail;
@@ -86,14 +101,25 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf)
void dvb_ringbuffer_flush(struct dvb_ringbuffer *rbuf)
{
- rbuf->pread = rbuf->pwrite;
+ /* dvb_ringbuffer_flush() counts as read operation
+* smp_load_acquire() to load write pointer
+* smp_store_release() to update read pointer, this ensures that the
+* correct pointer is visible for subsequent dvb_ringbuffer_free()
+* calls on other cpu cores
+*/
+ smp_store_release(&rbuf->pread, smp_load_acquire(&rbuf->pwrite));
rbuf->error = 0;
}
EXPORT_SYMBOL(dvb_ringbuffer_flush);
void dvb_ringbuffer_reset(struct dvb_ringbuffer *rbuf)
{
- rbuf->pread = rbuf->pwrite = 0;
+ /* dvb_ringbuffer_reset() counts as read and write operation
+* smp_store_release() to update read pointer
+*/
+ smp_store_release(&rbuf->pread, 0);
+ /* smp_store_release() to update write pointer */
+ smp_store_release(&rbuf->pwrite, 0);
rbuf->error = 0;
}
@@ -119,12 +145,17 @@ ssize_t dvb_ringbuffer_read_user(struct dvb_ringbuffer
*rbuf, u8 __user *buf, si
return -EFAULT;
buf += split;
todo -= split;
- rbuf->pread = 0;
+ /* smp_store_release() for read pointer update to ensure
+* that buf is not overwritten until read is complete,
+* this pairs with ACCESS_ONCE() in dvb_ringbuffer_free()
+*/
+ smp_store_release(&rbuf->pread, 0);
}
if (copy_to_user(buf, rbuf->data+rbuf->pread, todo))
return -EFAULT;
- rbuf->pread = (rbuf->pread + todo) % rbuf->size;
+ /* smp_store_release() to update read pointer, see above */
+ smp_store_release(&rbuf->pread, (rbuf->pread + todo) % rbuf->size);
return len;
}
@@ -139,11 +170,16 @@ void dvb_ringbuffer_read(struct dvb_ringbuffer *rbuf, u8
*buf, size_t len)
Re: [PATCH] media: dvb_ringbuffer: Add memory barriers
Hi Mauro,
thanks for looking after this patch.
On 05/07/16 15:22, Mauro Carvalho Chehab wrote:
Hi Soeren,
Em Sun, 7 Feb 2016 20:22:36 +0100
Soeren Moch escreveu:
On 27.12.2015 21:41, Soeren Moch wrote:
Implement memory barriers according to Documentation/circular-buffers.txt:
- use smp_store_release() to update ringbuffer read/write pointers
- use smp_load_acquire() to load write pointer on reader side
- use ACCESS_ONCE() to load read pointer on writer side
This fixes data stream corruptions observed e.g. on an ARM Cortex-A9
quad core system with different types (PCI, USB) of DVB tuners.
Signed-off-by: Soeren Moch
Cc: sta...@vger.kernel.org # 3.14+
Mauro,
any news or comments on this?
Since this is a real fix for broken behaviour, can you pick this up, please?
The problem here is that I'm very reluctant to touch at the DVB core
without doing some tests myself, as things like locking can be
very sensible.
I agree. But this patch adds memory barriers (no locks) according to
Documentation/circular-buffers.txt. It should not be dangerous to
follow these guidelines.
Nevertheless, independent review and testing is always a good idea,
especially in core code.
I'll try to find some time to take a look on it for Kernel 4.8,
Thanks.
but I'd like to reproduce the bug locally.
>
Could you please provide me enough info to reproduce it (and
eventually some test MPEG-TS where you know this would happen)?
I used vdr with different types of DVB tuners on a TBS2910 board
(quad core ARM Cortex-A9, see arch/arm/boot/dts/imx6q-tbs2910.dts).
With more than one active cpu core I occasionally see data stream
corruptions in recorded ts streams. This is not the case for one
active cpu.
The problem occurs when dvb_dmxdev_buffer_write() and
dvb_dmxdev_buffer_read() are running simultaneously on different
cpu cores on architectures without strong write ordering (e.g.
on arm, not on x86). Here the write data pointer (written in
dvb_ringbuffer_write() ) can become visible to the other cpu core
(in dvb_ringbuffer_avail() ), before the actual ts packet data is
visible. dvb_ringbuffer_read_user() then can read old ts data,
although new ts data is already written into the ringbuffer
by the other cpu core.
With smp_store_release() and smp_load_acquire() the correct
write ordering is maintained, ts packet data is visible on the
reading cpu core before the updated write pointer.
I have two DekTek RF generators here, so I should be able to
play such TS and see what happens with and without the patch
on x86, arm32 and arm64.
On x86 you should not see any difference, since
smp_store_release() and smp_load_acquire() expand to
simple stores and loads there. On multi-core arm systems
you may see broken ts streams without patch, especially
when reading the dvr device very fast, so that the
dvb_ringbuffer is always close to empty.
Regards,
Soeren
Regards,
Mauro
Regards,
Soeren
---
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Since smp_store_release() and smp_load_acquire() were introduced in linux-3.14,
a 3.14+ stable tag was added. Is it desired to apply a similar patch to older
stable kernels?
---
drivers/media/dvb-core/dvb_ringbuffer.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_ringbuffer.c
b/drivers/media/dvb-core/dvb_ringbuffer.c
index 1100e98..58b5968 100644
--- a/drivers/media/dvb-core/dvb_ringbuffer.c
+++ b/drivers/media/dvb-core/dvb_ringbuffer.c
@@ -55,7 +55,7 @@ void dvb_ringbuffer_init(struct dvb_ringbuffer *rbuf, void
*data, size_t len)
int dvb_ringbuffer_empty(struct dvb_ringbuffer *rbuf)
{
- return (rbuf->pread==rbuf->pwrite);
+ return (rbuf->pread == smp_load_acquire(&rbuf->pwrite));
}
@@ -64,7 +64,7 @@ ssize_t dvb_ringbuffer_free(struct dvb_ringbuffer *rbuf)
{
ssize_t free;
- free = rbuf->pread - rbuf->pwrite;
+ free = ACCESS_ONCE(rbuf->pread) - rbuf->pwrite;
if (free <= 0)
free += rbuf->size;
return free-1;
@@ -76,7 +76,7 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf)
{
ssize_t avail;
- avail = rbuf->pwrite - rbuf->pread;
+ avail = smp_load_acquire(&rbuf->pwrite) - rbuf->pread;
if (avail < 0)
avail += rbuf->size;
return avail;
@@ -86,14 +86,15 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf)
void dvb_ringbuffer_flush(struct dvb_ringbuffer *rbuf)
{
- rbuf->pread = rbuf->pwrite;
+ smp_store_release(&rbuf->pread, smp_load_acquire(&rbuf->pwrite));
rbuf->error = 0;
}
EXPORT_SYMBOL(dvb_ringbuffer_flush);
void dvb_ringbuffer_reset(struct dvb_ringbuffer *rbuf)
{
- rbuf->pread = rbuf->pwrite = 0;
+ smp_store_release(&rbuf->pread, 0);
+ smp_store_release(
Re: [PATCH] media: dvb_ringbuffer: Add memory barriers
On 05/07/16 15:26, Mauro Carvalho Chehab wrote: Em Sat, 7 May 2016 10:22:35 -0300 Mauro Carvalho Chehab escreveu: Hi Soeren, Em Sun, 7 Feb 2016 20:22:36 +0100 Soeren Moch escreveu: On 27.12.2015 21:41, Soeren Moch wrote: Implement memory barriers according to Documentation/circular-buffers.txt: - use smp_store_release() to update ringbuffer read/write pointers - use smp_load_acquire() to load write pointer on reader side - use ACCESS_ONCE() to load read pointer on writer side This fixes data stream corruptions observed e.g. on an ARM Cortex-A9 quad core system with different types (PCI, USB) of DVB tuners. Signed-off-by: Soeren Moch Cc: sta...@vger.kernel.org # 3.14+ Mauro, any news or comments on this? Since this is a real fix for broken behaviour, can you pick this up, please? The problem here is that I'm very reluctant to touch at the DVB core without doing some tests myself, as things like locking can be very sensible. In addition, it is good if other DVB developers could also test it. Even being sent for some time, until now, nobody else tested it. I know that people from the german vdrportal.de also use this patch for quite some time now. Unfortunately they are not active on the linux-media mailing list. I'll try to find some time to take a look on it for Kernel 4.8, but I'd like to reproduce the bug locally. Could you please provide me enough info to reproduce it (and eventually some test MPEG-TS where you know this would happen)? I have two DekTek RF generators here, so I should be able to play such TS and see what happens with and without the patch on x86, arm32 and arm64. Ah, forgot to mention, but checkpatch.pl wants comments for the memory barriers: OK, when I wrote this patch (linux-4.4-rc6) checkpatch.pl did not complain about missing comments. I will send a version 2 of this patch to address these warnings. Regards, Soeren WARNING: memory barrier without comment #52: FILE: drivers/media/dvb-core/dvb_ringbuffer.c:58: + return (rbuf->pread == smp_load_acquire(&rbuf->pwrite)); WARNING: memory barrier without comment #70: FILE: drivers/media/dvb-core/dvb_ringbuffer.c:79: + avail = smp_load_acquire(&rbuf->pwrite) - rbuf->pread; WARNING: memory barrier without comment #79: FILE: drivers/media/dvb-core/dvb_ringbuffer.c:89: + smp_store_release(&rbuf->pread, smp_load_acquire(&rbuf->pwrite)); WARNING: memory barrier without comment #87: FILE: drivers/media/dvb-core/dvb_ringbuffer.c:96: + smp_store_release(&rbuf->pread, 0); WARNING: memory barrier without comment #88: FILE: drivers/media/dvb-core/dvb_ringbuffer.c:97: + smp_store_release(&rbuf->pwrite, 0); WARNING: memory barrier without comment #97: FILE: drivers/media/dvb-core/dvb_ringbuffer.c:123: + smp_store_release(&rbuf->pread, 0); WARNING: memory barrier without comment #103: FILE: drivers/media/dvb-core/dvb_ringbuffer.c:128: + smp_store_release(&rbuf->pread, (rbuf->pread + todo) % rbuf->size); WARNING: memory barrier without comment #112: FILE: drivers/media/dvb-core/dvb_ringbuffer.c:143: + smp_store_release(&rbuf->pread, 0); WARNING: memory barrier without comment #117: FILE: drivers/media/dvb-core/dvb_ringbuffer.c:147: + smp_store_release(&rbuf->pread, (rbuf->pread + todo) % rbuf->size); WARNING: memory barrier without comment #126: FILE: drivers/media/dvb-core/dvb_ringbuffer.c:162: + smp_store_release(&rbuf->pwrite, 0); WARNING: memory barrier without comment #130: FILE: drivers/media/dvb-core/dvb_ringbuffer.c:165: + smp_store_release(&rbuf->pwrite, (rbuf->pwrite + todo) % rbuf->size); WARNING: memory barrier without comment #139: FILE: drivers/media/dvb-core/dvb_ringbuffer.c:185: + smp_store_release(&rbuf->pwrite, 0); WARNING: memory barrier without comment #145: FILE: drivers/media/dvb-core/dvb_ringbuffer.c:190: + smp_store_release(&rbuf->pwrite, (rbuf->pwrite + todo) % rbuf->size); Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND] media: dvb_ringbuffer: Add memory barriers
Implement memory barriers according to Documentation/circular-buffers.txt:
- use smp_store_release() to update ringbuffer read/write pointers
- use smp_load_acquire() to load write pointer on reader side
- use ACCESS_ONCE() to load read pointer on writer side
This fixes data stream corruptions observed e.g. on an ARM Cortex-A9
quad core system with different types (PCI, USB) of DVB tuners.
Signed-off-by: Soeren Moch
Cc: sta...@vger.kernel.org # 3.14+
---
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Since smp_store_release() and smp_load_acquire() were introduced in linux-3.14,
a 3.14+ stable tag was added. Is it desired to apply a similar patch to older
stable kernels?
---
drivers/media/dvb-core/dvb_ringbuffer.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_ringbuffer.c
b/drivers/media/dvb-core/dvb_ringbuffer.c
index 1100e98..58b5968 100644
--- a/drivers/media/dvb-core/dvb_ringbuffer.c
+++ b/drivers/media/dvb-core/dvb_ringbuffer.c
@@ -55,7 +55,7 @@ void dvb_ringbuffer_init(struct dvb_ringbuffer *rbuf, void
*data, size_t len)
int dvb_ringbuffer_empty(struct dvb_ringbuffer *rbuf)
{
- return (rbuf->pread==rbuf->pwrite);
+ return (rbuf->pread == smp_load_acquire(&rbuf->pwrite));
}
@@ -64,7 +64,7 @@ ssize_t dvb_ringbuffer_free(struct dvb_ringbuffer *rbuf)
{
ssize_t free;
- free = rbuf->pread - rbuf->pwrite;
+ free = ACCESS_ONCE(rbuf->pread) - rbuf->pwrite;
if (free <= 0)
free += rbuf->size;
return free-1;
@@ -76,7 +76,7 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf)
{
ssize_t avail;
- avail = rbuf->pwrite - rbuf->pread;
+ avail = smp_load_acquire(&rbuf->pwrite) - rbuf->pread;
if (avail < 0)
avail += rbuf->size;
return avail;
@@ -86,14 +86,15 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf)
void dvb_ringbuffer_flush(struct dvb_ringbuffer *rbuf)
{
- rbuf->pread = rbuf->pwrite;
+ smp_store_release(&rbuf->pread, smp_load_acquire(&rbuf->pwrite));
rbuf->error = 0;
}
EXPORT_SYMBOL(dvb_ringbuffer_flush);
void dvb_ringbuffer_reset(struct dvb_ringbuffer *rbuf)
{
- rbuf->pread = rbuf->pwrite = 0;
+ smp_store_release(&rbuf->pread, 0);
+ smp_store_release(&rbuf->pwrite, 0);
rbuf->error = 0;
}
@@ -119,12 +120,12 @@ ssize_t dvb_ringbuffer_read_user(struct dvb_ringbuffer
*rbuf, u8 __user *buf, si
return -EFAULT;
buf += split;
todo -= split;
- rbuf->pread = 0;
+ smp_store_release(&rbuf->pread, 0);
}
if (copy_to_user(buf, rbuf->data+rbuf->pread, todo))
return -EFAULT;
- rbuf->pread = (rbuf->pread + todo) % rbuf->size;
+ smp_store_release(&rbuf->pread, (rbuf->pread + todo) % rbuf->size);
return len;
}
@@ -139,11 +140,11 @@ void dvb_ringbuffer_read(struct dvb_ringbuffer *rbuf, u8
*buf, size_t len)
memcpy(buf, rbuf->data+rbuf->pread, split);
buf += split;
todo -= split;
- rbuf->pread = 0;
+ smp_store_release(&rbuf->pread, 0);
}
memcpy(buf, rbuf->data+rbuf->pread, todo);
- rbuf->pread = (rbuf->pread + todo) % rbuf->size;
+ smp_store_release(&rbuf->pread, (rbuf->pread + todo) % rbuf->size);
}
@@ -158,10 +159,10 @@ ssize_t dvb_ringbuffer_write(struct dvb_ringbuffer *rbuf,
const u8 *buf, size_t
memcpy(rbuf->data+rbuf->pwrite, buf, split);
buf += split;
todo -= split;
- rbuf->pwrite = 0;
+ smp_store_release(&rbuf->pwrite, 0);
}
memcpy(rbuf->data+rbuf->pwrite, buf, todo);
- rbuf->pwrite = (rbuf->pwrite + todo) % rbuf->size;
+ smp_store_release(&rbuf->pwrite, (rbuf->pwrite + todo) % rbuf->size);
return len;
}
@@ -181,12 +182,12 @@ ssize_t dvb_ringbuffer_write_user(struct dvb_ringbuffer
*rbuf,
return len - todo;
buf += split;
todo -= split;
- rbuf->pwrite = 0;
+ smp_store_release(&rbuf->pwrite, 0);
}
status = copy_from_user(rbuf->data+rbuf->pwrite, buf, todo);
if (status)
return len - todo;
- rbuf->pwrite = (rbuf->pwrite + todo) % rbuf->size;
+ smp_store_release(&rbuf->pwrite, (rbuf->pwrite + todo) % rbuf->size);
return len;
}
-- 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] media: dvb_ringbuffer: Add memory barriers
Implement memory barriers according to Documentation/circular-buffers.txt:
- use smp_store_release() to update ringbuffer read/write pointers
- use smp_load_acquire() to load write pointer on reader side
- use ACCESS_ONCE() to load read pointer on writer side
This fixes data stream corruptions observed e.g. on an ARM Cortex-A9
quad core system with different types (PCI, USB) of DVB tuners.
Signed-off-by: Soeren Moch
Cc: sta...@vger.kernel.org # 3.14+
---
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Since smp_store_release() and smp_load_acquire() were introduced in linux-3.14,
a 3.14+ stable tag was added. Is it desired to apply a similar patch to older
stable kernels?
---
drivers/media/dvb-core/dvb_ringbuffer.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_ringbuffer.c
b/drivers/media/dvb-core/dvb_ringbuffer.c
index 1100e98..58b5968 100644
--- a/drivers/media/dvb-core/dvb_ringbuffer.c
+++ b/drivers/media/dvb-core/dvb_ringbuffer.c
@@ -55,7 +55,7 @@ void dvb_ringbuffer_init(struct dvb_ringbuffer *rbuf, void
*data, size_t len)
int dvb_ringbuffer_empty(struct dvb_ringbuffer *rbuf)
{
- return (rbuf->pread==rbuf->pwrite);
+ return (rbuf->pread == smp_load_acquire(&rbuf->pwrite));
}
@@ -64,7 +64,7 @@ ssize_t dvb_ringbuffer_free(struct dvb_ringbuffer *rbuf)
{
ssize_t free;
- free = rbuf->pread - rbuf->pwrite;
+ free = ACCESS_ONCE(rbuf->pread) - rbuf->pwrite;
if (free <= 0)
free += rbuf->size;
return free-1;
@@ -76,7 +76,7 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf)
{
ssize_t avail;
- avail = rbuf->pwrite - rbuf->pread;
+ avail = smp_load_acquire(&rbuf->pwrite) - rbuf->pread;
if (avail < 0)
avail += rbuf->size;
return avail;
@@ -86,14 +86,15 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf)
void dvb_ringbuffer_flush(struct dvb_ringbuffer *rbuf)
{
- rbuf->pread = rbuf->pwrite;
+ smp_store_release(&rbuf->pread, smp_load_acquire(&rbuf->pwrite));
rbuf->error = 0;
}
EXPORT_SYMBOL(dvb_ringbuffer_flush);
void dvb_ringbuffer_reset(struct dvb_ringbuffer *rbuf)
{
- rbuf->pread = rbuf->pwrite = 0;
+ smp_store_release(&rbuf->pread, 0);
+ smp_store_release(&rbuf->pwrite, 0);
rbuf->error = 0;
}
@@ -119,12 +120,12 @@ ssize_t dvb_ringbuffer_read_user(struct dvb_ringbuffer
*rbuf, u8 __user *buf, si
return -EFAULT;
buf += split;
todo -= split;
- rbuf->pread = 0;
+ smp_store_release(&rbuf->pread, 0);
}
if (copy_to_user(buf, rbuf->data+rbuf->pread, todo))
return -EFAULT;
- rbuf->pread = (rbuf->pread + todo) % rbuf->size;
+ smp_store_release(&rbuf->pread, (rbuf->pread + todo) % rbuf->size);
return len;
}
@@ -139,11 +140,11 @@ void dvb_ringbuffer_read(struct dvb_ringbuffer *rbuf, u8
*buf, size_t len)
memcpy(buf, rbuf->data+rbuf->pread, split);
buf += split;
todo -= split;
- rbuf->pread = 0;
+ smp_store_release(&rbuf->pread, 0);
}
memcpy(buf, rbuf->data+rbuf->pread, todo);
- rbuf->pread = (rbuf->pread + todo) % rbuf->size;
+ smp_store_release(&rbuf->pread, (rbuf->pread + todo) % rbuf->size);
}
@@ -158,10 +159,10 @@ ssize_t dvb_ringbuffer_write(struct dvb_ringbuffer *rbuf,
const u8 *buf, size_t
memcpy(rbuf->data+rbuf->pwrite, buf, split);
buf += split;
todo -= split;
- rbuf->pwrite = 0;
+ smp_store_release(&rbuf->pwrite, 0);
}
memcpy(rbuf->data+rbuf->pwrite, buf, todo);
- rbuf->pwrite = (rbuf->pwrite + todo) % rbuf->size;
+ smp_store_release(&rbuf->pwrite, (rbuf->pwrite + todo) % rbuf->size);
return len;
}
@@ -181,12 +182,12 @@ ssize_t dvb_ringbuffer_write_user(struct dvb_ringbuffer
*rbuf,
return len - todo;
buf += split;
todo -= split;
- rbuf->pwrite = 0;
+ smp_store_release(&rbuf->pwrite, 0);
}
status = copy_from_user(rbuf->data+rbuf->pwrite, buf, todo);
if (status)
return len - todo;
- rbuf->pwrite = (rbuf->pwrite + todo) % rbuf->size;
+ smp_store_release(&rbuf->pwrite, (rbuf->pwrite + todo) % rbuf->size);
return len;
}
--
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] media: dmxdev: remove dvb_ringbuffer_flush() on writer side
On 10.05.2013 21:39, Sakari Ailus wrote:
Hi Soeren,
Thanks for the patch!
On Sun, Apr 14, 2013 at 11:03:42AM +0200, Soeren Moch wrote:
In dvb_ringbuffer lock-less synchronizationof reader and writer threads is done
with separateread and write pointers. Since dvb_ringbuffer_flush() modifies the
read pointer, this function must not be called from the writer thread.
This patch removes the dvb_ringbuffer_flush() calls in the dmxdev ringbuffer
write functions, this fixes Oopses "Unable to handle kernel paging request"
I could observe for the call chain dvb_demux_read ->dvb_dmxdev_buffer_read ->
dvb_ringbuffer_read_user -> __copy_to_user (the reader side of the ringbuffer).
The flush calls at the write side are not necessary anyway since
ringbuffer_flush
is also called in dvb_dmxdev_buffer_read() when an error condition is set in the
ringbuffer.
This patch should also be applied to stable kernels.
Signed-off-by: Soeren Moch
CC:
While the change the patch does itself appears sound to me, I need to ask
you to resend the patch using git send-email (it won't apply as-is). I can
do that this time, too; let me know what works for you.
Please convert this patch to git format, thank you!
Reviewed-by: Sakari Ailus
And thanks for your rewiew, too.
Soeren
--- a/drivers/media/dvb-core/dmxdev.c 2013-04-05 21:21:15.0 +0200
+++ b/drivers/media/dvb-core/dmxdev.c 2013-04-14 09:01:58.0 +0200
@@ -377,10 +377,8 @@ static int dvb_dmxdev_section_callback(c
ret = dvb_dmxdev_buffer_write(&dmxdevfilter->buffer, buffer2,
buffer2_len);
}
- if (ret < 0) {
- dvb_ringbuffer_flush(&dmxdevfilter->buffer);
+ if (ret < 0)
dmxdevfilter->buffer.error = ret;
- }
if (dmxdevfilter->params.sec.flags & DMX_ONESHOT)
dmxdevfilter->state = DMXDEV_STATE_DONE;
spin_unlock(&dmxdevfilter->dev->lock);
@@ -416,10 +414,8 @@ static int dvb_dmxdev_ts_callback(const
ret = dvb_dmxdev_buffer_write(buffer, buffer1, buffer1_len);
if (ret == buffer1_len)
ret = dvb_dmxdev_buffer_write(buffer, buffer2, buffer2_len);
- if (ret < 0) {
- dvb_ringbuffer_flush(buffer);
+ if (ret < 0)
buffer->error = ret;
- }
spin_unlock(&dmxdevfilter->dev->lock);
wake_up(&buffer->queue);
return 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
[PATCH] media: dmxdev: remove dvb_ringbuffer_flush() on writer side
In dvb_ringbuffer lock-less synchronizationof reader and writer threads is done
with separateread and write pointers. Sincedvb_ringbuffer_flush() modifies the
read pointer, this function must not be called from the writer thread.
This patch removes the dvb_ringbuffer_flush() calls in the dmxdev ringbuffer
write functions, this fixes Oopses "Unable to handle kernel paging request"
I could observe for the call chaindvb_demux_read ->dvb_dmxdev_buffer_read ->
dvb_ringbuffer_read_user -> __copy_to_user (the reader side of the ringbuffer).
The flush calls at the write side are not necessary anyway since
ringbuffer_flush
is also called in dvb_dmxdev_buffer_read() when an error condition is set in the
ringbuffer.
This patch should also be applied to stable kernels.
Signed-off-by: Soeren Moch
CC:
--- a/drivers/media/dvb-core/dmxdev.c 2013-04-05 21:21:15.0 +0200
+++ b/drivers/media/dvb-core/dmxdev.c 2013-04-14 09:01:58.0 +0200
@@ -377,10 +377,8 @@ static int dvb_dmxdev_section_callback(c
ret = dvb_dmxdev_buffer_write(&dmxdevfilter->buffer, buffer2,
buffer2_len);
}
- if (ret < 0) {
- dvb_ringbuffer_flush(&dmxdevfilter->buffer);
+ if (ret < 0)
dmxdevfilter->buffer.error = ret;
- }
if (dmxdevfilter->params.sec.flags & DMX_ONESHOT)
dmxdevfilter->state = DMXDEV_STATE_DONE;
spin_unlock(&dmxdevfilter->dev->lock);
@@ -416,10 +414,8 @@ static int dvb_dmxdev_ts_callback(const
ret = dvb_dmxdev_buffer_write(buffer, buffer1, buffer1_len);
if (ret == buffer1_len)
ret = dvb_dmxdev_buffer_write(buffer, buffer2, buffer2_len);
- if (ret < 0) {
- dvb_ringbuffer_flush(buffer);
+ if (ret < 0)
buffer->error = ret;
- }
spin_unlock(&dmxdevfilter->dev->lock);
wake_up(&buffer->queue);
return 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
dmxdev: Unable to handle kernel paging request
Every few days/weeks I see Oopses like the attached one. I tried to track down the problem, but with added debug printk's the error didn't occur. I'm using em28xx and dib0700 based dvb sticks at an armv5te system (Marvell Kirkwood), the user application is vdr. Any ideas what is wrong or who can help here? Thanks, Soeren Mar 25 21:47:00 guruvdr kernel: Unable to handle kernel paging request at virtual address e2134000 Mar 25 21:47:00 guruvdr kernel: pgd = def2c000 Mar 25 21:47:00 guruvdr kernel: [e2134000] *pgd=1ef4b811, *pte=, *ppte= Mar 25 21:47:00 guruvdr kernel: Internal error: Oops: 7 [#1] PREEMPT ARM Mar 25 21:47:00 guruvdr kernel: Modules linked in: uap8xxx em28xx_dvb tda18271c2dd drxk tda18271 dvb_usb_dib0700 em28xx tveeprom videobuf_vmalloc videobuf_core Mar 25 21:47:00 guruvdr kernel: CPU: 0Not tainted (3.8.0-guruvdr #42) Mar 25 21:47:00 guruvdr kernel: PC is at memcpy+0x320/0x3a4 Mar 25 21:47:00 guruvdr kernel: LR is at 0x50100 Mar 25 21:47:00 guruvdr kernel: pc : []lr : [<00050100>]psr: 2013 Mar 25 21:47:00 guruvdr kernel: sp : dedabe50 ip : 616c4b05 fp : dedabe9c Mar 25 21:47:00 guruvdr kernel: r10: r9 : 2c6f6d69 r8 : 73736974 Mar 25 21:47:00 guruvdr kernel: r7 : 73657250 r6 : 206d4905 r5 : 0f756564 r4 : 404dd200 Mar 25 21:47:00 guruvdr kernel: r3 : r2 : 0020 r1 : e2133ff4 r0 : afffdf40 Mar 25 21:47:00 guruvdr kernel: Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Mar 25 21:47:00 guruvdr kernel: Control: 0005397f Table: 1ef2c000 DAC: 0015 Mar 25 21:47:00 guruvdr kernel: Process section handler (pid: 2110, stack limit = 0xdedaa1b8) Mar 25 21:47:00 guruvdr kernel: Stack: (0xdedabe50 to 0xdedac000) Mar 25 21:47:00 guruvdr kernel: be40: 049b afffde77 0189 e2133f1a Mar 25 21:47:00 guruvdr kernel: be60: afffde77 dedaa000 c017bff4 ddbcc7f4 ded50338 e17b9054 afffde77 Mar 25 21:47:00 guruvdr kernel: be80: 049b 0587 0587 0003 dedabeac dedabea0 c017c084 c017bf1c Mar 25 21:47:00 guruvdr kernel: bea0: dedabecc dedabeb0 c029a8d8 c017c074 e17b9054 afffdd8b 0587 dedaa000 Mar 25 21:47:00 guruvdr kernel: bec0: dedabf1c dedabed0 c0291dbc c029a820 0800 dedabee8 c07624c8 Mar 25 21:47:00 guruvdr kernel: bee0: c0745728 0013 0080 dedabf50 e17b9000 afffdd8b deed5180 Mar 25 21:47:00 guruvdr kernel: bf00: 0ffd 0003 e17b9070 0003 dedabf4c dedabf20 c0291f90 c0291c8c Mar 25 21:47:00 guruvdr kernel: bf20: dedabf80 1000 deed5180 afffdd88 dedabf80 c000dce4 dedaa000 Mar 25 21:47:00 guruvdr kernel: bf40: dedabf7c dedabf50 c008eba8 c0291e70 dedabf7c dedabf60 c00a82a0 deed5180 Mar 25 21:47:00 guruvdr kernel: bf60: 0001 afffdd88 1000 c000dce4 dedabfa4 dedabf80 c008ec6c c008eb00 Mar 25 21:47:00 guruvdr kernel: bf80: 002d 1000 afffdd88 0003 dedabfa8 Mar 25 21:47:00 guruvdr kernel: bfa0: c000db80 c008ec34 002d 1000 002d afffdd88 1000 1000 Mar 25 21:47:00 guruvdr kernel: bfc0: 002d 1000 afffdd88 0003 001270c8 0006 00d40d98 afffedb4 Mar 25 21:47:00 guruvdr kernel: bfe0: afffdcf8 b6f00f74 b6f00f84 8010 002d 1fffe831 1fffec31 Mar 25 21:47:00 guruvdr kernel: Backtrace: Mar 25 21:47:00 guruvdr kernel: [] (__copy_to_user_memcpy+0x0/0x158) from [] (__copy_to_user+0x20/0x24) Mar 25 21:47:00 guruvdr kernel: [] (__copy_to_user+0x0/0x24) from [] (dvb_ringbuffer_read_user+0xc8/0xfc) Mar 25 21:47:00 guruvdr kernel: [] (dvb_ringbuffer_read_user+0x0/0xfc) from [] (dvb_dmxdev_buffer_read.isra.8+0x140/0x19c) Mar 25 21:47:00 guruvdr kernel: r7:dedaa000 r6:0587 r5:afffdd8b r4:e17b9054 Mar 25 21:47:00 guruvdr kernel: [] (dvb_dmxdev_buffer_read.isra.8+0x0/0x19c) from [] (dvb_demux_read+0x130/0x180) Mar 25 21:47:00 guruvdr kernel: [] (dvb_demux_read+0x0/0x180) from [] (vfs_read+0xb8/0x134) Mar 25 21:47:00 guruvdr kernel: [] (vfs_read+0x0/0x134) from [] (sys_read+0x48/0x70) Mar 25 21:47:00 guruvdr kernel: r8:c000dce4 r7:1000 r6:afffdd88 r5:0001 r4:deed5180 Mar 25 21:47:00 guruvdr kernel: [] (sys_read+0x0/0x70) from [] (ret_fast_syscall+0x0/0x2c) Mar 25 21:47:00 guruvdr kernel: r7:0003 r6:afffdd88 r5:1000 r4:002d Mar 25 21:47:00 guruvdr kernel: Code: f5d1f07c e8b100f0 e1a03c2e e2522020 (e8b15300) Mar 25 21:47:00 guruvdr kernel: ---[ end trace ad119c47b9c422ea ]--- Mar 25 21:47:00 guruvdr kernel: note: section handler[2110] exited with preempt_count 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: SV: [linux-dvb] NOVA-TD exeriences?
Soeren Moch schrieb:
> > > Hi again. Just got my two new NOVA-TD's and at a first glance they
> > seemed to
> > > perform well. Closer inspections however revealed that I see
exactly
> > the same
> > > issues as Soeren. Watching live TV with VDR on one adaptor while
> > constantly
> > > retuning the other one using:
> > > while true;do tzap -x svt1;done
> > > gives a short glitch in the VDR stream on almost every tzap.
Another
> > 100EUR down
> > > the drain. I'll probably buy four NOVA-T's instead just like I
> > planned to at
> > > first.
> > >
> > > /Magnus H
> >
> > Slowly, slowly. Magnus, you want to support dibcom with another
100EUR for
> > there poor performance in fixing the firmware?
> > Please test my patches, the nova-td is running fine with these
patches,
> > at least for me.
> >
> > Patrick, any progress here? Will dibcom fix the firmware, or will you
> > integrate the
> > patches? Or what can I do to go on?
> >
> > Regards,
> > Soeren
> >
> >
>
> Thanks Soeren, maybe I jumped to the wrong conclusions here. I actually
> thought this came down to bad hardware design instead of a
driver/firmware
> issue. Unfortunately your patches made no difference here but I won't
give
> up that easily. If they made your problems disapperar there should be
hope
> for me too and I'll be glad to help in the development. I can live
with the
> glitches in the mean time if there's hope for improvement since I mostly
> watch DVB-S these days. I'm running the stock Ubuntu Karmic 2.6.31
kernel
> and standard linuxtv drivers from hg. I also have four TT S2-1600
cards in
> there.
> /Magnus
Magnus, can you send the USB-IDs of your nova-td-sticks, please?
Since I activated the workaround only for stk7700d_dib7000p_mt2266,
there might be another funtion to fix your sticks.
Soeren
OK, my nova-td device id is 2040:9580, for 2040:5200 the attached extended
patch version may help. (I have no access to such device.)
Please test.
Soeren
--- linux.orig/drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-11-20 23:39:51.0 +0100
+++ linux/drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-11-21 00:47:09.0 +0100
@@ -303,6 +303,9 @@ static int stk7700d_frontend_attach(stru
adap->fe = dvb_attach(dib7000p_attach, &adap->dev->i2c_adap,0x80+(adap->id << 1),
&stk7700d_dib7000p_mt2266_config[adap->id]);
+adap->props.streaming_ctrl = NULL;
+dib0700_streaming_ctrl(adap, 1);
+
return adap->fe == NULL ? -ENODEV : 0;
}
@@ -1710,12 +1713,20 @@ static int stk7070pd_frontend_attach0(st
}
adap->fe = dvb_attach(dib7000p_attach, &adap->dev->i2c_adap, 0x80, &stk7070pd_dib7000p_config[0]);
+
+adap->props.streaming_ctrl = NULL;
+dib0700_streaming_ctrl(adap, 1);
+
return adap->fe == NULL ? -ENODEV : 0;
}
static int stk7070pd_frontend_attach1(struct dvb_usb_adapter *adap)
{
adap->fe = dvb_attach(dib7000p_attach, &adap->dev->i2c_adap, 0x82, &stk7070pd_dib7000p_config[1]);
+
+adap->props.streaming_ctrl = NULL;
+dib0700_streaming_ctrl(adap, 1);
+
return adap->fe == NULL ? -ENODEV : 0;
}
@@ -1968,7 +1979,7 @@ MODULE_DEVICE_TABLE(usb, dib0700_usb_id_
.streaming_ctrl = dib0700_streaming_ctrl, \
.stream = { \
.type = USB_BULK, \
- .count = 4, \
+ .count = 1, \
.endpoint = ep, \
.u = { \
.bulk = { \
Re: SV: [linux-dvb] NOVA-TD exeriences?
> > > Hi again. Just got my two new NOVA-TD's and at a first glance they > > seemed to > > > perform well. Closer inspections however revealed that I see exactly > > the same > > > issues as Soeren. Watching live TV with VDR on one adaptor while > > constantly > > > retuning the other one using: > > > while true;do tzap -x svt1;done > > > gives a short glitch in the VDR stream on almost every tzap. Another > > 100EUR down > > > the drain. I'll probably buy four NOVA-T's instead just like I > > planned to at > > > first. > > > > > > /Magnus H > > > > Slowly, slowly. Magnus, you want to support dibcom with another 100EUR for > > there poor performance in fixing the firmware? > > Please test my patches, the nova-td is running fine with these patches, > > at least for me. > > > > Patrick, any progress here? Will dibcom fix the firmware, or will you > > integrate the > > patches? Or what can I do to go on? > > > > Regards, > > Soeren > > > > > > Thanks Soeren, maybe I jumped to the wrong conclusions here. I actually > thought this came down to bad hardware design instead of a driver/firmware > issue. Unfortunately your patches made no difference here but I won't give > up that easily. If they made your problems disapperar there should be hope > for me too and I'll be glad to help in the development. I can live with the > glitches in the mean time if there's hope for improvement since I mostly > watch DVB-S these days. I'm running the stock Ubuntu Karmic 2.6.31 kernel > and standard linuxtv drivers from hg. I also have four TT S2-1600 cards in > there. > /Magnus Magnus, can you send the USB-IDs of your nova-td-sticks, please? Since I activated the workaround only for stk7700d_dib7000p_mt2266, there might be another funtion to fix your sticks. Soeren -- 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: SV: [linux-dvb] NOVA-TD exeriences?
> > >
> > > Very strange. Playing of two different muxes is also no problem
for me,
> > as
> > > long
> > > as no new stream is started (of course after switching off one of the
> > > streams
> > > before). In the start moment of the new the stream the already
running
> > > stream
> > > is disturbed and I see a demaged group of pictures in the old stream.
> > After
> > > these few pictures the stream is running fine again.
> > >
> > > I cannot imagine that this is a specific problem of my stick,
however,
> > > thank you for testing!
> >
> >
> > Hmm - well I haven't made a close inspection (frame by frame) of every
> > frame during the startup of second player.
> > Kaffaine seems to have blocked screen refresh because Xorg gets locked
> > via starting mplayer.
> > So there is definitely frame skipping viewing experience - but that's
> > the flaw of Xorg - sound is played just fine.
> >
> > If I should check whether there are no TS stream errors only at the
> > moment of startup, I'll need to grab both streams and make a better
> > analysis. My current statement was purely based on the fact, that I
> > could watch both channels without any picture artefacts or sound
> > distorsion - but during startup there is surelly a period, when some
> > frames are not even visibile, because kaffeine cannot even refresh
> > playing window - but that's another story
> >
> >
> > Zdenek
>
>
> Hi again. Just got my two new NOVA-TD's and at a first glance they
seemed to
> perform well. Closer inspections however revealed that I see exactly
the same
> issues as Soeren. Watching live TV with VDR on one adaptor while
constantly
> retuning the other one using:
> while true;do tzap -x svt1;done
> gives a short glitch in the VDR stream on almost every tzap. Another
100EUR down
> the drain. I'll probably buy four NOVA-T's instead just like I
planned to at
> first.
>
> /Magnus H
Slowly, slowly. Magnus, you want to support dibcom with another 100EUR for
there poor performance in fixing the firmware?
Please test my patches, the nova-td is running fine with these patches,
at least for me.
Patrick, any progress here? Will dibcom fix the firmware, or will you
integrate the
patches? Or what can I do to go on?
Regards,
Soeren
--- drivers/media/common/tuners/mt2266.c.orig 2009-06-29 22:11:08.0 +0200
+++ drivers/media/common/tuners/mt2266.c 2009-06-29 22:21:01.0 +0200
@@ -137,7 +137,6 @@ static int mt2266_set_params(struct dvb_
freq = params->frequency / 1000; // Hz -> kHz
if (freq < 47 && freq > 23)
return -EINVAL; /* Gap between VHF and UHF bands */
- priv->bandwidth = (fe->ops.info.type == FE_OFDM) ? params->u.ofdm.bandwidth : 0;
priv->frequency = freq * 1000;
tune = 2 * freq * (8192/16) / (FREF/16);
@@ -145,21 +144,24 @@ static int mt2266_set_params(struct dvb_
if (band == MT2266_VHF)
tune *= 2;
- switch (params->u.ofdm.bandwidth) {
- case BANDWIDTH_6_MHZ:
- mt2266_writeregs(priv, mt2266_init_6mhz,
- sizeof(mt2266_init_6mhz));
- break;
- case BANDWIDTH_7_MHZ:
- mt2266_writeregs(priv, mt2266_init_7mhz,
- sizeof(mt2266_init_7mhz));
- break;
- case BANDWIDTH_8_MHZ:
- default:
- mt2266_writeregs(priv, mt2266_init_8mhz,
- sizeof(mt2266_init_8mhz));
- break;
- }
+if (priv->bandwidth != params->u.ofdm.bandwidth) {
+ priv->bandwidth = (fe->ops.info.type == FE_OFDM) ? params->u.ofdm.bandwidth : 0;
+ switch (params->u.ofdm.bandwidth) {
+ case BANDWIDTH_6_MHZ:
+mt2266_writeregs(priv, mt2266_init_6mhz,
+ sizeof(mt2266_init_6mhz));
+break;
+ case BANDWIDTH_7_MHZ:
+mt2266_writeregs(priv, mt2266_init_7mhz,
+ sizeof(mt2266_init_7mhz));
+break;
+ case BANDWIDTH_8_MHZ:
+ default:
+mt2266_writeregs(priv, mt2266_init_8mhz,
+ sizeof(mt2266_init_8mhz));
+break;
+ }
+}
if (band == MT2266_VHF && priv->band == MT2266_UHF) {
dprintk("Switch from UHF to VHF");
@@ -327,6 +329,7 @@ struct dvb_frontend * mt2266_attach(stru
priv->cfg = cfg;
priv->i2c = i2c;
+ priv->bandwidth= BANDWIDTH_8_MHZ;
priv->band = MT2266_UHF;
if (mt2266_readreg(priv, 0, &id)) {
--- drivers/media/dvb/dvb-usb/dib0700_devices.c.orig 2009-04-18 16:45:12.0 +0200
+++ drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-04-18 18:58:54.0 +0200
@@ -290,6 +290,9 @@ static int stk7700d_frontend_attach(stru
adap->fe = dvb_attach(dib7000p_attach, &adap->dev->i2c_adap,0x80+(adap->id << 1),
&stk7700d_dib7000p_mt2266_config[adap->id]);
+adap->props.streaming_ctrl = NULL;
+dib0700_streaming_ctrl(adap, 1);
+
return adap->fe == NULL ? -ENODEV : 0;
}
@@ -1414,7 +1417,7 @@ MODULE_DEVICE_TABLE(usb, dib0700_usb_id_
.streaming_ctrl = dib0700_streaming_ctrl, \
.stream = { \
.type = USB_BULK, \
- .count = 4, \
+ .cou
Re: [linux-dvb] NOVA-TD exeriences?
Zdenek Kabelac wrote: > 2009/11/3 Zdenek Kabelac : >> 2009/11/2 Soeren Moch : >>>>> Hi. I would be happy to hear if anyone has tried both the NOVA-TD and >>>>> the >>>>> NOVA-T. The NOVA-T has always worked perfectly here but I would like to >>>>> know >>>>> if the -TD will do the job of two NOVA-T's. And there also seems to be a >>>>> new >>>>> version out with two small antenna connectors instead of the previous >>>>> configuration. Anyone tried it? Does it come with an antenna adaptor >>>>> cable? >>>>> http://www.hauppauge.de/de/pics/novatdstick_top.jpg >>>>> Thankful for any info. >>>> Well I've this usb stick with these two small connectors - and it runs >>>> just fine. >>>> >>>> Though I think there is some problem with suspend/resume recently >>>> (2.6.32-rc5) and it needs some inspection. >>>> >>>> But it works just fine for dual dvb-t viewing. >>>> >>>> And yes - it contains two small antennas with small connectors and >>>> one adapter for normal antenna - i.e. 1 antenna input goes to 2 small >>>> antenna connectors. >>> zdenek, your nova-td stick works just fine for dual dvb-t viewing? >>> I always had this problem: >>> When one channel is streaming and the other channel is switched on, the >>> stream of the already running channel gets broken. >>> see also: >>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg06376.html >>> >>> Can you please test this case on your nova-td stick? >> I'll recheck in the evening whether there are no regression, but I've >> been able to get 3 dvb-t independent (different mux) TV streams (with >> the usage of the second stick Aver Hybrid Volar HX & proprietary Aver >> driver) with 2.6.29/30 vanilla kernels played at the same time on my >> C2D T61. >> > > > Ok - I could confirm, I'm able to play two different muxes at the same > time from this USB stick. And I do not experience any stream damage. > I'm running Fedora Rawhide with vanilla kernel 2.6.32-rc5, kaffeine > 0.8.7 for the first adapter and relatively fresh mplayer compilation > for the second adapter > > Thought there are things to be reported and fixed (some USB regression > I guess) - I'll handle this via lkml. > > > Anyway here is dmesg USB stick identification (labeled WinTV Nova-TD) > > USB device found, idVendor=2040, idProduct=5200 > USB device strings: Mfr=1, Product=2, SerialNumber=3 > Product: NovaT 500Stick > > Regards > > Zdenek > Very strange. Playing of two different muxes is also no problem for me, as long as no new stream is started (of course after switching off one of the streams before). In the start moment of the new the stream the already running stream is disturbed and I see a demaged group of pictures in the old stream. After these few pictures the stream is running fine again. I cannot imagine that this is a specific problem of my stick, however, thank you for testing! Regards, Soeren -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] NOVA-TD exeriences?
> > Hi. I would be happy to hear if anyone has tried both the NOVA-TD and the > > NOVA-T. The NOVA-T has always worked perfectly here but I would like to know > > if the -TD will do the job of two NOVA-T's. And there also seems to be a new > > version out with two small antenna connectors instead of the previous > > configuration. Anyone tried it? Does it come with an antenna adaptor cable? > > http://www.hauppauge.de/de/pics/novatdstick_top.jpg > > Thankful for any info. > > Well I've this usb stick with these two small connectors - and it runs > just fine. > > Though I think there is some problem with suspend/resume recently > (2.6.32-rc5) and it needs some inspection. > > But it works just fine for dual dvb-t viewing. > > And yes - it contains two small antennas with small connectors and > one adapter for normal antenna - i.e. 1 antenna input goes to 2 small > antenna connectors. zdenek, your nova-td stick works just fine for dual dvb-t viewing? I always had this problem: When one channel is streaming and the other channel is switched on, the stream of the already running channel gets broken. see also: http://www.mail-archive.com/linux-media@vger.kernel.org/msg06376.html Can you please test this case on your nova-td stick? Thanks, Soeren -- 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
dib0700 i2c problem / mt2266 patch
Patrick,
when you are discussing dib0700 issues with dibcom, there is an
additional one for the list:
When using dib0700 in dual mode (on my nova-td stick), from
time to time a tuner hangs up. I never observed this behavior in
single mode. It seems to me that there is no proper locking within
the dib0700 firmware when accessing both tuner i2c buses
"simultaneously".
Since I only need UHF channels, I use the attached patch to decrease
the number of i2c transactions and tuner registers, which are involved
in the channel switch. This solved the tuning problems.
Besides the i2c problem, maybe it might be a good idea to integrate
this patch into the mt2266 driver anyway, because it considerably
speeds up the channel switch.
Regards,
S:oren
--- drivers/media/common/tuners/mt2266.c.orig 2009-06-29 22:11:08.0 +0200
+++ drivers/media/common/tuners/mt2266.c 2009-06-29 22:21:01.0 +0200
@@ -137,7 +137,6 @@ static int mt2266_set_params(struct dvb_
freq = params->frequency / 1000; // Hz -> kHz
if (freq < 47 && freq > 23)
return -EINVAL; /* Gap between VHF and UHF bands */
- priv->bandwidth = (fe->ops.info.type == FE_OFDM) ? params->u.ofdm.bandwidth : 0;
priv->frequency = freq * 1000;
tune = 2 * freq * (8192/16) / (FREF/16);
@@ -145,21 +144,24 @@ static int mt2266_set_params(struct dvb_
if (band == MT2266_VHF)
tune *= 2;
- switch (params->u.ofdm.bandwidth) {
- case BANDWIDTH_6_MHZ:
- mt2266_writeregs(priv, mt2266_init_6mhz,
- sizeof(mt2266_init_6mhz));
- break;
- case BANDWIDTH_7_MHZ:
- mt2266_writeregs(priv, mt2266_init_7mhz,
- sizeof(mt2266_init_7mhz));
- break;
- case BANDWIDTH_8_MHZ:
- default:
- mt2266_writeregs(priv, mt2266_init_8mhz,
- sizeof(mt2266_init_8mhz));
- break;
- }
+if (priv->bandwidth != params->u.ofdm.bandwidth) {
+ priv->bandwidth = (fe->ops.info.type == FE_OFDM) ? params->u.ofdm.bandwidth : 0;
+ switch (params->u.ofdm.bandwidth) {
+ case BANDWIDTH_6_MHZ:
+mt2266_writeregs(priv, mt2266_init_6mhz,
+ sizeof(mt2266_init_6mhz));
+break;
+ case BANDWIDTH_7_MHZ:
+mt2266_writeregs(priv, mt2266_init_7mhz,
+ sizeof(mt2266_init_7mhz));
+break;
+ case BANDWIDTH_8_MHZ:
+ default:
+mt2266_writeregs(priv, mt2266_init_8mhz,
+ sizeof(mt2266_init_8mhz));
+break;
+ }
+}
if (band == MT2266_VHF && priv->band == MT2266_UHF) {
dprintk("Switch from UHF to VHF");
@@ -327,6 +329,7 @@ struct dvb_frontend * mt2266_attach(stru
priv->cfg = cfg;
priv->i2c = i2c;
+ priv->bandwidth= BANDWIDTH_8_MHZ;
priv->band = MT2266_UHF;
if (mt2266_readreg(priv, 0, &id)) {
Re: DVB USB stream parameters
I don't know exactly why (the USB/HW background for that is not present in my brain), but at some point having less than 39480B for one (high-level) URB for the dib0700 resulted in never having any URB returning from the USB stack. I chose 4 of them because .. I don't remember. It seems even 1 is working. I vote for a single high-level URB. Besides the memory savings this is the only way I could get my nova-td stick working. (see this thread: http://www.mail-archive.com/linux-media@vger.kernel.org/msg06376.html ) The patch runs flawlessly on my vdr system for months now. I remember someone telling me that this is due to something in the firmware. I need to wait for some people to be back from whereever they are to know exactly what's going on (that's why I haven't responded yet). I hope you can sort out the dib0700_streaming_ctrl problems... Soeren -- 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: dib0700 Nova-TD-Stick problem
Hi Patrick! Patrick Boettcher wrote: Hi Soeren, For a few weeks I use a Nova-TD-Stick and was annoyed with dvb stream errors, although the demod bit-error-rate (BER/UNC) was zero. I could track down this problem to dib0700_streaming_ctrl: When one channel is streaming and the other channel is switched on, the stream of the already running channel gets broken. I think this is a firmware bug and should be fixed there, but I attach a driver patch, which solved the problem for me. (Kernel 2.6.29.1, FW 1.20, Nova-T-Stick + Nova-TD-Stick used together). Since I had to reduce the urb count to 1, I consider this patch as quick hack, not a real solution. Probably the same problem exists with other dib0700 diversity/dual devices, without a firmware fix a similar driver patch may be helpful. Regards, Soeren Hi Patrick, do you see any chance that somebody will fix the firmware? :/ . If not, can you take into consideration to remove the dib0700_streaming_ctrl callback as in the (again) attached patch so solve the switch-on problem? I'd rather fix the streaming-enable command, which might be not correctly implemented. Need to check. :( Since the dib0700_streaming_ctrl is more or less a firmware interface only, I found nothing to patch there. I played with the enable bits but could not find any working solution. But of course you know the driver code (and maybe the firmware) better, and maybe somebody from dibcom can give any hint... Since the streaming_control implementation within the dib0700 seemed to be not fully usb compliant in the past (e.g. disconnect problem we have seen a few month ago), it may be not the worst idea to remove this callback entirely (after stream enable in the init phase). But I don't know for what side effect the firmware uses this call... The patch runs flawlessly on my vdr system for weeks now. There are no negative side effects from reducing the urb count to 1. Hmm, on fast systems certainly not, but once the system is loaded or old there might be data losses. My vdr system is based on a via epia board, so I use a C7 cpu (not known to be the fastest at the market) and via usb controller. I can use one or both of my dvb-t sticks (nova-t and nova-td) together at the same ehci controller, I can record up to 3 dvb-t TS-streams simultaneously, I can use PIP decoding to generate 100% cpu load (full-featured dvb card used for primary video decode). I never observed any usb data loss with urb count set to 1 (the fifo within the dib0700 (dib7000p?) seems to be big enough). In contrast to that, without the patch it is impossible to watch TV on one nova-td channel while vdr is constantly calling streaming_ctrl on/off for epg scan on the other nova-td channel. _Without_ the patch I see data loss/corruption. It would be nice to have other people trying this workaround on other cards so that we know that it really helps and not just solves the problem for you. Patrick. Of course it would be nice to have other people testing this patch. So far the urb count is reduced for all dib0700 devices while the streaming_ctrl callback is removed for the stk7700d family of devices (nova-td and friends) only. I used this patch in 2.6.27.x and 2.6.29.x environments so far. I will try to test 2.6.30 this weekend. If anybody else can confirm that this patch works (or not), please send a short report to the list. Thanks, S:oren -- 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: dib0700 Nova-TD-Stick problem
Soeren.Moch wrote:
For a few weeks I use a Nova-TD-Stick and was annoyed with dvb stream
errors, although the demod bit-error-rate (BER/UNC) was zero.
I could track down this problem to dib0700_streaming_ctrl:
When one channel is streaming and the other channel is switched on, the
stream of the already running channel gets broken.
I think this is a firmware bug and should be fixed there, but I attach a
driver patch, which solved the problem for me. (Kernel 2.6.29.1, FW
1.20, Nova-T-Stick + Nova-TD-Stick used together). Since I had to reduce
the urb count to 1, I consider this patch as quick hack, not a real
solution.
Probably the same problem exists with other dib0700 diversity/dual
devices, without a firmware fix a similar driver patch may be helpful.
Regards,
Soeren
Hi Patrick,
do you see any chance that somebody will fix the firmware? If not, can
you take
into consideration to remove the dib0700_streaming_ctrl callback as in the
(again) attached patch so solve the switch-on problem?
The patch runs flawlessly on my vdr system for weeks now. There are no
negative
side effects from reducing the urb count to 1.
If you prefer a patch that removes the callback for all dib0700 devices or
only for all dual devices, I can prepare that. But I can test it only with
Nova-T-Stick and Nova-TD-Stick.
Regards,
Soeren
--- drivers/media/dvb/dvb-usb/dib0700_devices.c.orig 2009-04-18 16:45:12.0 +0200
+++ drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-04-18 18:58:54.0 +0200
@@ -290,6 +290,9 @@ static int stk7700d_frontend_attach(stru
adap->fe = dvb_attach(dib7000p_attach, &adap->dev->i2c_adap,0x80+(adap->id << 1),
&stk7700d_dib7000p_mt2266_config[adap->id]);
+adap->props.streaming_ctrl = NULL;
+dib0700_streaming_ctrl(adap, 1);
+
return adap->fe == NULL ? -ENODEV : 0;
}
@@ -1414,7 +1417,7 @@ MODULE_DEVICE_TABLE(usb, dib0700_usb_id_
.streaming_ctrl = dib0700_streaming_ctrl, \
.stream = { \
.type = USB_BULK, \
- .count = 4, \
+ .count = 1, \
.endpoint = ep, \
.u = { \
.bulk = { \
Re: Nova-T 500 does not survive reboot
>>> Hi, >>>Any news on this? I'd like to try the URB patch someone mentioned, >>> but I >>> can't find the link. >> >> http://www.mail-archive.com/linux-media@vger.kernel.org/msg04643.html >> >> I am running a current dvb tree with this patch. >> >> so far so good. >> >> I did not find the time to check if I regained proper reboots, though. I >> know, sad excuse... >> >> nico >> >> > > I'll give it a try. Thanks for the tip! > Cheers, > Eduard Hi nico, Eduard, can you confirm that the patch solves your Nova-T 500 boot problem? In this case I would resend the buffer count part as separate patch to Patrick. S:oren -- 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: Nova-T 500 does not survive reboot
Apr 29 22:42:41 favia kernel: [ 72.272045] ehci_hcd :07:01.2: force halt; handhake c2666814 4000 -> -110 [...] Do you know if the issue is the same with a Nova-TD stick? If it is, then I could be able to use debugging as an excuse to buy one, and then add 2 tuners to the system when all is done :o) I had the same "ehci_hcd force halt" error when I was debugging the Nova-TD dual-stream-switchon-problem: http://www.mail-archive.com/linux-media@vger.kernel.org/msg04643.html Reducing the urb count to 1 (as included in the patch) solved the "ehci_hcd force halt" issue for me. S:oren -- 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: Nova-TD usb dual tuner issue
When I connect my Nova-TD dual tuner usb stick to my debian/sid box with 2.6.29.1 kernel I can only use the second tuner (mplayer dvb://2@). When trying to use the first one (dvb://1...@...) tuning is extremely bad and an image barely appears with many errors. I tried switching the antennas to no avail, the problem persists. Is this a know problem, or do I just have a bad stick ? Due to my experience the gain and frequency response of the internal amplifiers at both antenna inputs is different, so the same antenna can work fine at one port and not so good at the other, at least for some channel. I had problems with strong antenna signals, so I used an attenuator to improve reception. HTH, Soeren -- 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
dib0700 Nova-TD-Stick problem
For a few weeks I use a Nova-TD-Stick and was annoyed with dvb stream
errors, although the demod bit-error-rate (BER/UNC) was zero.
I could track down this problem to dib0700_streaming_ctrl:
When one channel is streaming and the other channel is switched on,
the stream of the already running channel gets broken.
I think this is a firmware bug and should be fixed there, but I attach
a driver patch, which solved the problem for me. (Kernel 2.6.29.1, FW
1.20, Nova-T-Stick + Nova-TD-Stick used together). Since I had to
reduce the urb count to 1, I consider this patch as quick hack, not a
real solution.
Probably the same problem exists with other dib0700 diversity/dual
devices, without a firmware fix a similar driver patch may be helpful.
Regards,
Soeren
--- drivers/media/dvb/dvb-usb/dib0700_devices.c.orig 2009-04-18 16:45:12.0 +0200
+++ drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-04-18 18:58:54.0 +0200
@@ -290,6 +290,9 @@ static int stk7700d_frontend_attach(stru
adap->fe = dvb_attach(dib7000p_attach, &adap->dev->i2c_adap,0x80+(adap->id << 1),
&stk7700d_dib7000p_mt2266_config[adap->id]);
+adap->props.streaming_ctrl = NULL;
+dib0700_streaming_ctrl(adap, 1);
+
return adap->fe == NULL ? -ENODEV : 0;
}
@@ -1414,7 +1417,7 @@ MODULE_DEVICE_TABLE(usb, dib0700_usb_id_
.streaming_ctrl = dib0700_streaming_ctrl, \
.stream = { \
.type = USB_BULK, \
- .count = 4, \
+ .count = 1, \
.endpoint = ep, \
.u = { \
.bulk = { \
