Re: [PATCH 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene
On Sun, Jul 3, 2011 at 12:31 PM, Oliver Endriss o.endr...@gmx.de wrote: [PATCH 01/16] tda18271c2dd: Initial check-in [PATCH 02/16] tda18271c2dd: Lots of coding-style fixes Oliver, Why the new driver for the 18271c2? There is already such a driver, and in the past we've rejected multiple drivers for the same chip unless there is a *very* compelling reason to do such. The existing 18271 driver supports the C2 and is actively maintained. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene
Hi Devin, Devin Heitmueller writes: On Sun, Jul 3, 2011 at 12:31 PM, Oliver Endriss o.endr...@gmx.de wrote: [PATCH 01/16] tda18271c2dd: Initial check-in [PATCH 02/16] tda18271c2dd: Lots of coding-style fixes Oliver, Why the new driver for the 18271c2? There is already such a driver, and in the past we've rejected multiple drivers for the same chip unless there is a *very* compelling reason to do such. The existing 18271 driver supports the C2 and is actively maintained. AFAIR, there were at least 2 reasons. One was that the existing driver does not accept 2 (or even 4) tuners with the same address (but behind different demods) on the same I2C bus which is the case on duoflex C/T addon cards. The other was that it does not give back the intermediate frequency which the demod needs. (This is currently done by misusing get_frequency() but I added a get_if() call in newer internal versions which should be added to dvb-core/dvb_frontend.h) Feel free to change ngene/ddbridge to use the existing driver but it will need some major changes in tda18271_attach() and a few other places. Regards, Ralph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene
Hi Ralph, Good to hear from you. AFAIR, there were at least 2 reasons. One was that the existing driver does not accept 2 (or even 4) tuners with the same address (but behind different demods) on the same I2C bus which is the case on duoflex C/T addon cards. Do you mean that you are relying solely on the i2c gates on the other demods being closed so that the tuners associated with the other inputs do not receive the commands? If so, that would definitely create the need for some weird locking structure (since today demods typically do not manage their i2c gates in tandem). The other was that it does not give back the intermediate frequency which the demod needs. (This is currently done by misusing get_frequency() but I added a get_if() call in newer internal versions which should be added to dvb-core/dvb_frontend.h) Generally speaking with other devices the IF is configured for the tuner depending on the target modulation (there is a tda18271_config struct passed at attach time containing the IF for various modes). Then the demod driver is also configured for a particular IF. Are you changing the IF based on something other than the target modulation type? Or do you need to vary the IF based on different frequencies within the same modulation? Feel free to change ngene/ddbridge to use the existing driver but it will need some major changes in tda18271_attach() and a few other places. If there are indeed good reasons, then so be it. But it feels like we are working around deficiencies in the core DVB framework that would apply to all drivers, and it would be good if we could avoid the maintenance headaches associated with two different drivers for the same chip. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene
Devin Heitmueller writes: Hi Ralph, Good to hear from you. AFAIR, there were at least 2 reasons. One was that the existing driver does not accept 2 (or even 4) tuners with the same address (but behind different demods) on the same I2C bus which is the case on duoflex C/T addon cards. Do you mean that you are relying solely on the i2c gates on the other demods being closed so that the tuners associated with the other inputs do not receive the commands? If so, that would definitely create the need for some weird locking structure (since today demods typically do not manage their i2c gates in tandem). Yes, gate openings are locked against each other in the bridge drivers. The other was that it does not give back the intermediate frequency which the demod needs. (This is currently done by misusing get_frequency() but I added a get_if() call in newer internal versions which should be added to dvb-core/dvb_frontend.h) Generally speaking with other devices the IF is configured for the tuner depending on the target modulation (there is a tda18271_config struct passed at attach time containing the IF for various modes). Then the demod driver is also configured for a particular IF. You mean the optional struct tda18271_std_map *std_map;? That would be a possibility. But then you have to handle IF tables for all kinds of tuners and demods in the bridge driver. Letting the tuner choose the IF and have a way to tell the demod (a simple get_if() call) is much easier. Are you changing the IF based on something other than the target modulation type? Or do you need to vary the IF based on different frequencies within the same modulation? No. Feel free to change ngene/ddbridge to use the existing driver but it will need some major changes in tda18271_attach() and a few other places. If there are indeed good reasons, then so be it. But it feels like we are working around deficiencies in the core DVB framework that would apply to all drivers, and it would be good if we could avoid the maintenance headaches associated with two different drivers for the same chip. I know. At the time I was also just porting the DRX-K and only wanted to get it working based on the known to work Windows driver combination and not wrestle with other problems. I guess it whould not be too hard to adapt the old driver now. Another problem that keeps showing up in the existing drivers is that some tuner/demod combinations let the tuner call gate_ctrl, others only call it in the demod. This leads to problems when trying to use them in new combinations. Either the gate is not opened/closed at all or twice. In the latter case this can even lead to lockups if also using locking. Regards, Ralph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene
Hi Ralph and Devin, Em 11-07-2011 13:27, Devin Heitmueller escreveu: Hi Ralph, Good to hear from you. AFAIR, there were at least 2 reasons. One was that the existing driver does not accept 2 (or even 4) tuners with the same address (but behind different demods) on the same I2C bus which is the case on duoflex C/T addon cards. I2C core has now support for I2C switches, but I never used it. I'm not against of merging the tda18271c2 at the short term, but the both driver maintainers need to work on merging them into one driver at the long term, to avoid duplicated maintenance efforts. Do you mean that you are relying solely on the i2c gates on the other demods being closed so that the tuners associated with the other inputs do not receive the commands? If so, that would definitely create the need for some weird locking structure (since today demods typically do not manage their i2c gates in tandem). The other was that it does not give back the intermediate frequency which the demod needs. (This is currently done by misusing get_frequency() but I added a get_if() call in newer internal versions which should be added to dvb-core/dvb_frontend.h) Generally speaking with other devices the IF is configured for the tuner depending on the target modulation (there is a tda18271_config struct passed at attach time containing the IF for various modes). Then the demod driver is also configured for a particular IF. Yeah, with the current way, it is possible to make it work, by binding tda18271 3 times (one for analog, one for DVB-T and another for DVB-C). Some care should be taken at the frontend, to avoid it to create one private instance of its management struct for each binding, but it works fine. The hybrid_tuner_request_state() call does such trick. It also works fine when analog is enabled. Are you changing the IF based on something other than the target modulation type? Or do you need to vary the IF based on different frequencies within the same modulation? Feel free to change ngene/ddbridge to use the existing driver but it will need some major changes in tda18271_attach() and a few other places. If there are indeed good reasons, then so be it. But it feels like we are working around deficiencies in the core DVB framework that would apply to all drivers, and it would be good if we could avoid the maintenance headaches associated with two different drivers for the same chip. Agreed. Ralph, Could you please check if my patches didn't break for ngene/ddbridge? I don't have any ngene/ddbrige here for testing. In special, I had to add a fix for drxk module rmmod due to the way dvb_attach() works. Thanks! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene
On Mon, Jul 11, 2011 at 1:15 PM, Ralph Metzler r...@metzlerbros.de wrote: Generally speaking with other devices the IF is configured for the tuner depending on the target modulation (there is a tda18271_config struct passed at attach time containing the IF for various modes). Then the demod driver is also configured for a particular IF. You mean the optional struct tda18271_std_map *std_map;? That would be a possibility. But then you have to handle IF tables for all kinds of tuners and demods in the bridge driver. Letting the tuner choose the IF and have a way to tell the demod (a simple get_if() call) is much easier. The downside of the approach you've suggested is it prevents the tuner driver from varying the IF based on the demod it is interacting with. By having the information defined in the bridge driver, the IF can be defined by the driver developer based on the attached demod. Also, in some cases the IF needs to different because of the PCB layout (rather than just the chosen modulation or what demod it is attached to), which there is no way a tuner driver could know that based solely on what tuner/demod is being used. In other words, in some cases the optimal IF for a given hardware design is determined by cycling through the various possible values with a spectrum analyzer attached, and that is the sort of optimization that is defined in the bridge driver where it is known exactly what product is being used. If there are indeed good reasons, then so be it. But it feels like we are working around deficiencies in the core DVB framework that would apply to all drivers, and it would be good if we could avoid the maintenance headaches associated with two different drivers for the same chip. I know. At the time I was also just porting the DRX-K and only wanted to get it working based on the known to work Windows driver combination and not wrestle with other problems. I guess it whould not be too hard to adapt the old driver now. I can certainly appreciate this, as I've done this myself at times. That said though, for upstream inclusion we generally want to clean up such issues. Another problem that keeps showing up in the existing drivers is that some tuner/demod combinations let the tuner call gate_ctrl, others only call it in the demod. This leads to problems when trying to use them in new combinations. Either the gate is not opened/closed at all or twice. In the latter case this can even lead to lockups if also using locking. Yeah, this is a bit of a mess. Whether it's done in the demod or the tuner is typically dictated by what driver the developer happened to have copied as skeleton code. There are certainly merits to both approaches under certain conditions, but the inconsistency across drivers is very annoying. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene
On Monday 04 July 2011 18:41:10 Hans von Marwijk wrote: In which GIT or HG repository can I find these patches. They are not in any of my public repositories yet. If you need a working driver, I recommend one of the following repositories: For kernel = 2.6.32: http://linuxtv.org/hg/~endriss/media_build_experimental For kernel 2.6.36, you might also use http://linuxtv.org/hg/~endriss/ngene-octopus-test They are equivalent and well tested. The patchsets contain the same code, except that the code was reformatted for kernel codingstyle. There is a small risk that this processing introduced bugs. ;-( CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene
Hi In which GIT or HG repository can I find these patches. drivers/media/dvb/ngene/ngene-core.c ... Regards Eckhard -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Oliver Endriss Sent: 03 July 2011 18:31 To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab Subject: [PATCH 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene [PATCH 01/16] tda18271c2dd: Initial check-in [PATCH 02/16] tda18271c2dd: Lots of coding-style fixes [PATCH 03/16] DRX-K: Initial check-in [PATCH 04/16] DRX-K: Shrink size of drxk_map.h [PATCH 05/16] DRX-K: Tons of coding-style fixes [PATCH 06/16] DRX-K, TDA18271c2: Add build support [PATCH 07/16] get_dvb_firmware: Get DRX-K firmware for Digital Devices DVB-CT cards [PATCH 08/16] ngene: Support Digital Devices DuoFlex CT [PATCH 09/16] ngene: Coding style fixes [PATCH 10/16] ngene: Fix return code if no demux was found [PATCH 11/16] ngene: Fix name of Digital Devices PCIe/miniPCIe [PATCH 12/16] ngene: Support DuoFlex CT attached to CineS2 and SaTiX-S2 [PATCH 13/16] cxd2099: Update to latest version [PATCH 14/16] cxd2099: Codingstyle fixes [PATCH 15/16] ngene: Update for latest cxd2099 [PATCH 16/16] ngene: Strip dummy packets inserted by the driver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
