Re: [PATCH] media: ddbridge: better handle optional spin locks at the code
appen based on the same > > condition ([input|output]->dma != NULL). Though I agree having the > > locking inside a condition in it's current form isn't optimal, too, and > > I also already thought about this in the past. > > > > I'd rather try to fix this by checking for the dma ptrs at the > > beginning of the four functions and immediately return if the ptr is > > invalid. Though I don't know if this may cause side effects as there's > > data written to the regs pointed by the TS_CONTROL() macros even if > > there's no dma ptr present. TS_CONTROL only controls the output itself and does not need to have DMA. > > > > I'd like to hear Ralph's opinion on this, and also like to have this > > changed (in whatever way) in the upstream (dddvb) repository, too. > > > > Please refrain from applying this patch until we agreed on a proper > > solution that works for everyone. > > Yeah, sure. > > Btw, does ddbridge driver works without DMA? On a quick look, it > seems that it is enabled all the times. > DMA is not used with the OctopusNet and only partially on the OctopusNetPro. Both are ARM based network streaming devices. The OctopusNet has no DMA at all and can only stream directly to CI or network. The Pro version has DMA and will support streaming and/or DMA on the each channel. DMA channel assignment was at one point planned to be done dynamically. It also is PCIe based. So, this is part of ddbridge-main.c and not octonet-main.c. But support for those devices and some PCIe cards is not part of the kernel driver anyway. So, you could of course through all of this DMA checking out of the kernel version. It might have to be added back in for future/other cards. But that problems already exists with other features. Regards, Ralph
Re: [PATCH V2 0/3] Add timers to en50221 protocol driver
Hi Jasmin, Jasmin J. writes: > Hallo Ralph! > > > 1. The SW bit is cleared too early during the whole buffer size > > negotiation. > > This should be fixed. > I will look into this when I have time again. Probably end of next week. > > > 2. IRQEN = CMDREG_DAIE = 0x80 is always set in the command register. > > So, they should probably only be used if both the host and module say they > > support it. > How can we know that in the driver? > I haven't seen an API for this. The flags parameter of dvb_ca_en50221_init() allow these values: #define DVB_CA_EN50221_FLAG_IRQ_CAMCHANGE 1 #define DVB_CA_EN50221_FLAG_IRQ_FR 2 #define DVB_CA_EN50221_FLAG_IRQ_DA 4 but only DVB_CA_EN50221_FLAG_IRQ_CAMCHANGE seems to be used in dvb_ca_en50221.c. Support for this was seemingly planned but never implemented. Annex G.2 of http://www.ci-plus.com/data/ci-plus_specification_v1.3.pdf contains details about how support is announced in the CIS. > There is the flag "da_irq_supported", which might be used to set the IRQEN > bit it the bit is set. Sure, e.g. to store the result from the CIS parsing. The current use is not much help. It is set if an interrupt occured with DA bit set, which is a little too late. > Any suggestions how to proceed with item 2? Check the CIS for support by the CAM and ca->flags for support by the host. If both support it, set CMDREG_FRIE and/or CMDREG_DAIE in command reg. Regards, Ralph
Re: [PATCH V2 0/3] Add timers to en50221 protocol driver
Hi Jasmin, Jasmin J. writes: > Hi! > > Please hold on in merging this series, because I have to investigate a hint > I got related to the buffer size handshake of the protocol driver: > https://www.linuxtv.org/pipermail/linux-dvb/2007-July/019116.html > > BR, >Jasmin So, there seem to be two bugs: 1. The SW bit is cleared too early during the whole buffer size negotiation. This should be fixed. 2. IRQEN = CMDREG_DAIE = 0x80 is always set in the command register. DAIE and FRIE were introduced as recommendation in Cenelec R06-001:1998 and are a requirement for CI+. They could cause problems if the IRQ line goes high and the interrupt is enabled but not handled. They should not cause a problem if the host ignores the interrupt or if the CAM does not support it, but one never knows with some CAMs ... So, they should probably only be used if both the host and module say they support it. R06 does not mention it but CI+ also requires a CIS entry to be present in modules supporting this feature. Regards, Ralph
[PATCH 0/2] Support Physical Layer Scrambling
Athanasios Oikonomou writes: > A new property DTV_SCRAMBLING_SEQUENCE_INDEX introduced to control > the gold sequence that several demods support. > > Also the DVB API was increased in order userspace to be aware of the > changes. > > The stv090x driver was changed to make use of the new property. > > Those commits based on discussion previously made on the mailling list. > https://www.mail-archive.com/linux-media@vger.kernel.org/msg122600.html > > I would like to thanks Ralph Metzler (r...@metzlerbros.de) for the > great help and ideas he provide me in order create those patches. > > Athanasios Oikonomou (2): > media: dvb_frontend: add physical layer scrambling support > media: stv090x: add physical layer scrambling support > > .../media/uapi/dvb/fe_property_parameters.rst | 18 > ++ > .../uapi/dvb/frontend-property-satellite-systems.rst | 2 ++ > drivers/media/dvb-core/dvb_frontend.c | 12 > drivers/media/dvb-core/dvb_frontend.h | 5 + > drivers/media/dvb-frontends/stv090x.c | 16 > include/uapi/linux/dvb/frontend.h | 5 - > include/uapi/linux/dvb/version.h | 2 +- > 7 files changed, 58 insertions(+), 2 deletions(-) > > -- > 2.1.4 Acked-by: Ralph Metzler We had some thoughts about having a: #define NO_SCRAMBLING_CODE (~0U) But DVB-S2 is always scrambling (with default index 0) and other delivery systems can ignore this property. Or do you think it is needed? One could add a define for AUTO or AUTO_S2X for the standard 7 indices to be tested in DVB-S2X. But either dvb_frontend.c or the demod driver would have to support this in software. I don't think there is a demod which supports this in hardware yet? Regards, Ralph
[bug report] drx: add initial drx-d driver
Hello Dan Carpenter,
Dan Carpenter writes:
> Hello Ralph Metzler,
>
> The patch 126f1e618870: "drx: add initial drx-d driver" from Mar 12,
> 2011, leads to the following static checker warning:
>
> drivers/media/dvb-frontends/drxd_hard.c:1305 SC_WaitForReady()
> info: return a literal instead of 'status'
>
> drivers/media/dvb-frontends/drxd_hard.c
> 1298 static int SC_WaitForReady(struct drxd_state *state)
> 1299 {
> 1300 int i;
> 1301
> 1302 for (i = 0; i < DRXD_MAX_RETRIES; i += 1) {
> 1303 int status = Read16(state, SC_RA_RAM_CMD__A, NULL,
> 0);
> 1304 if (status == 0)
> 1305 return status;
> ^
> The register is set to zero when ready? The answer should obviously be
> yes, but it wouldn't totally surprise me if this function just always
> looped 1000 times... Few of the callers check the return. Anyway, it's
> more clear to just "return 0;"
>
> 1306 }
> 1307 return -1;
>^^
> -1 is not a proper error code.
>
> 1308 }
>
> regards,
> dan carpenter
I think I wrote the driver more than 10 years ago and somebody later submitted
it
to the kernel.
I don't know if there is a anybody still maintaining this. Is it even used
anymore?
I could write a patch but cannot test it (e.g. to see if it really always
loops 1000 times ...)
Regards,
Ralph Metzler
--
--
Re: [PATCH 0/2] Add timers to en50221 protocol driver
Yes, acked-by: Ralph Metzler Jasmin J. writes: > Hi! > > > I don't know if you are also waiting for a comment from me. > All positive ones are welcome ;) > > > I am fine with those changes. They are even desperately needed > > to get some "problem CAMs" working. > THX, so we can interpret this as an "Acked-by"? > > BR, >Jasmin -- --
Re: [PATCH 0/2] Add timers to en50221 protocol driver
Hi, I don't know if you are also waiting for a comment from me. I am fine with those changes. They are even desperately needed to get some "problem CAMs" working. Regards, Ralph Jasmin J. writes: > Ping 2! > > On 10/15/2017 03:59 PM, Jasmin J. wrote: > > Ping! > > -- --
Re: DVB-S2 and S2X API extensions
Hi, Mauro Carvalho Chehab writes: > Em Thu, 9 Nov 2017 16:28:18 +0100 > Ralph Metzler escreveu: > > > Hi, > > > > I have a few RFCs regarding new needed enums and > > properties for DVB-S2 and DVB-S2X: > > > > - DVB-S2/X physical layer scrambling > > > > I currently use the inofficial DTV_PLS for setting the scrambling > > sequence index (cf. ETSI EN 300 468 table 41) of > > the physical layer scrambling in DVB-S2 and DVB-S2X. > > Some drivers already misuse bits 8-27 of the DTV_STREAM_ID > > for setting this. They also differentiate between gold, root > > and combo codes. > > The gold code is the actual scrambling sequence index. > > The root code is just an intermediate calculation > > accepted by some chips, but derived from the gold code. > > It can be easily mapped one-to-one to the gold code. > > (see https://github.com/DigitalDevices/dddvb/blob/master/apps/pls.c, > > A more optimized version of this could be added to dvb-math.c) > > The combo code does not really exist but is a by-product > > of the buggy usage of a gold to root code conversion in ST chips. > > > > So, I would propose to officially introduce a property > > for the scrambling sequence index (=gold code). > > Should it be called DTV_PLS (which I already used in the dddvb package) > > or rather DTV_SSI? > > I realized PLS can be confused with physical layer signalling which > > uses the acronym PLS in the DVB-S2 specs. > > Yes, it makes sense to have a DTV property for the PLS gold code. > > I would prefer to use a clearer name, like DTV_PLS_GOLD_CODE, > to make easier to identify what it means. > > At documentation, we should point to EN 302 307 section 5.5.4 and > to EN 300 468 table 41, with a good enough description to make > clear that it is the gold code, and not the root code (or > a chipset-specific "combo" code). If we use a long descriptive name, DTV_SCRAMBLING_SEQUENCE_INDEX might be better because it is the actual name used for it in the documentation and SI fields. And, to make it absolutely clear, the combo code is not just a chipset-specific code, it is utter BS! Here is why (sorry for the lengthy explanation): The STV090X/0910 chips have 3 8-bit registers for setting the root code called PLROOT0, PLROOT1 and PLROOT2. The code has 18 bits. So PLROOT0, PLROOT1 and the lower 2 bits (bits 0 and 1) of PLROOT2 are the root code. Bits 2 and 3 of PLROOT2 determine a mode with the following 3 possible values: 0 = the 18 bits are the root code 1 = the 18 bits are the gold code 2 = if you write the gold code to the 18 bits, they will be converted to the root code and you can then read them back, mode will be changed to 0 after conversion This mode 2 is what somebody called "combo code". But why is it seen as a different code? It should behave just identical to writing a gold code! Because some Linux drivers, probably also some Windows drivers, first write PLROOT2, then PLROOT1 and PLROOT0, also in the case of mode 2. Writing the 2 in the mode bits actually triggers the gold->root conversion and this conversion takes some time! So, the conversion is triggered by the write to PLROOT2 even though PLROOT1 and PLROOT0 have not yet been written. Depending on many factors like I2C write speed, the computer speed, other tasks running, etc. and especially also the previous values of PLROOT1 and PLROOT2, you will get varying results after the conversion. The length of the conversion also depends on the size of the gold code. For small gold codes the conversion is so fast that it is finished before PLROOT1 and PLROOT2 are written. The lower 16 bits of the conversion results will actually be overwritten again! For larger gold codes only the lower 8 bits, etc. Think about all the race conditions and wrong initial values in this process and everybody please forget about "combo code"! > > DVB-S2X also defines 7 preferred scrambling code sequences > > (EN 302 307-2 5.5.4) which should be checked during tuning. > > If the demod does not do this, should the DVB kernel layer or > > application do this? > > IMHO, it should be up to the kernel to check if the received > gold code is one of those 7 codes from EM 302 307 part 2 spec, > if the delivery system is DVB_S2X (btw, we likely need to add it > to the list of delivery systems). Not sure what would be the > best way to implement it. Perhaps via some ancillary routine > that the demods would be using. > > > - slices > > > > DVB-S2 and DVB-C2, additionally to ISI/PLP, also can have > > slicing. For DVB-C2 I currently use bits 8-15 of DTV_STREAM_ID as slice id. > > Better to use a separate prop
DVB-S2 and S2X API extensions
Hi, I have a few RFCs regarding new needed enums and properties for DVB-S2 and DVB-S2X: - DVB-S2/X physical layer scrambling I currently use the inofficial DTV_PLS for setting the scrambling sequence index (cf. ETSI EN 300 468 table 41) of the physical layer scrambling in DVB-S2 and DVB-S2X. Some drivers already misuse bits 8-27 of the DTV_STREAM_ID for setting this. They also differentiate between gold, root and combo codes. The gold code is the actual scrambling sequence index. The root code is just an intermediate calculation accepted by some chips, but derived from the gold code. It can be easily mapped one-to-one to the gold code. (see https://github.com/DigitalDevices/dddvb/blob/master/apps/pls.c, A more optimized version of this could be added to dvb-math.c) The combo code does not really exist but is a by-product of the buggy usage of a gold to root code conversion in ST chips. So, I would propose to officially introduce a property for the scrambling sequence index (=gold code). Should it be called DTV_PLS (which I already used in the dddvb package) or rather DTV_SSI? I realized PLS can be confused with physical layer signalling which uses the acronym PLS in the DVB-S2 specs. DVB-S2X also defines 7 preferred scrambling code sequences (EN 302 307-2 5.5.4) which should be checked during tuning. If the demod does not do this, should the DVB kernel layer or application do this? - slices DVB-S2 and DVB-C2, additionally to ISI/PLP, also can have slicing. For DVB-C2 I currently use bits 8-15 of DTV_STREAM_ID as slice id. For DVB-S2/X the misuse of bits 8-27 by some drivers for selecting the scrambling sequence index code could cause problems. Should there be a new property for slice selection? It is recommended that slice id and ISI/PLP id are identical but they can be different. - new DVB-S2X features DVB-S2X needs some more roll-offs, FECs and modulations. I guess adding those should be no problem? Do we need FE_CAN_SLICES, FE_CAN_3G_MODULATION, etc? Or would a new delivery system type for S2X make sense? -DVB-S2 base band frame support There are some older patches which allowed to switch the demod to a raw BB frame mode (if it and the bridge support this) and have those parsed in the DVB layer. See https://patchwork.linuxtv.org/patch/10402/ or https://linuxtv.org/pipermail/linux-dvb/2007-December/022217.html Chris Lee seems to have a tree based on those: https://bitbucket.org/updatelee/v4l-updatelee Another method to support this is to wrap the BB frames into sections and deliver them as a normal transport stream. Some demods and/or PCIe bridges support this in hardware. This has the advantage that it would even work with SAT>IP. How should the latter method be supported in the DVB API? With a special stream id or separate porperty? Switching to this mode could even be done automatically in case of non-TS streams. Regards, Ralph
[PATCH] [media] dvb-frontends/stv0910: prevent consecutive mutex_unlock()'s
Daniel Scheller writes: > From: Daniel Scheller > > When calling gate_ctrl() with enable=0 if previously the mutex wasn't > locked (ie. on enable=1 failure and subdrivers not handling this properly, > or by otherwise badly behaving drivers), the i2c_lock could be unlocked I think drivers and subdrivers should rather be fixed so that this cannot happen. But to do this we will first need to define exactly how a failure in gate_ctrl() is supposed to be handled, both inside gate_ctrl() and by calling drivers. > consecutively which isn't allowed. Prevent this by keeping track of the > lock state, and actually call mutex_unlock() only when certain the lock > is held. Why not use mutex_is_locked()? And there should be a debug message if it (tried double unlocking) happens. Regards, Ralph
Re: [PATCH] [media] ddbridge: add IOCTLs
Daniel Scheller writes: > Am Sun, 20 Aug 2017 08:53:56 -0300 > schrieb Mauro Carvalho Chehab : > > > Em Sun, 20 Aug 2017 13:08:55 +0200 > > Daniel Scheller escreveu: > > > > > From: Daniel Scheller > > > > > > This patch adds back the IOCTL API/functionality which is present > > > in the upstream dddvb driver package. In comparison, the IOCTL > > > handler has been factored to a separate object (and with that, some > > > functionality from -core has been moved there aswell), the IOCTLs > > > are defined in an include in the uAPI, and ioctl-number.txt is > > > updated to document that there are IOCTLs present in this driver. > > > > > > Signed-off-by: Daniel Scheller > > > --- > > > This patch depends on the ddbridge-0.9.29 bump, see [1]. The > > > functionality was part of the driver before. > > > > > > [1] http://www.spinics.net/lists/linux-media/msg119911.html > > > > > > Documentation/ioctl/ioctl-number.txt| 1 + > > > MAINTAINERS | 1 + > > > drivers/media/pci/ddbridge/Makefile | 2 +- > > > drivers/media/pci/ddbridge/ddbridge-core.c | 111 + > > > drivers/media/pci/ddbridge/ddbridge-ioctl.c | 334 > > > > > > drivers/media/pci/ddbridge/ddbridge-ioctl.h | 32 +++ > > > include/uapi/linux/ddbridge-ioctl.h | 110 + 7 files > > > changed, 481 insertions(+), 110 deletions(-) create mode 100644 > > > drivers/media/pci/ddbridge/ddbridge-ioctl.c create mode 100644 > > > drivers/media/pci/ddbridge/ddbridge-ioctl.h create mode 100644 > > > include/uapi/linux/ddbridge-ioctl.h > > > > > > diff --git a/Documentation/ioctl/ioctl-number.txt > > > b/Documentation/ioctl/ioctl-number.txt index > > > 3e3fdae5f3ed..d78d1cd092d2 100644 --- > > > a/Documentation/ioctl/ioctl-number.txt +++ > > > b/Documentation/ioctl/ioctl-number.txt @@ -215,6 +215,7 @@ Code > > > Seq#(hex)Include FileComments 'c' > > > A0-AF arch/x86/include/asm/msr.h conflict! 'd' > > > 00-FFlinux/char/drm/drm.hconflict! 'd' > > > 02-40pcmcia/ds.h conflict! +'d' > > > 00-0Blinux/ddbridge-ioctl.h conflict! > > > > That's where the problem with this patch starts: we don't add > > conflicts here :-) > > > > We need more discussions with regards to the features added by this > > patchset. > > Understood. The "good" thing is that this isn't a requirement to drive > any tuner boards (at the moment), however we shouldn't lose track on > this. Since this is the only complaint for now: > > - We need to clear with Ralph if changing the MAGIC to something > different is an option. In the end, if we change the userspace apps > to include the uAPI header from mainline if available (else fallback > to what ie. dddvb carries), I don't see an issue with this. But if > userspace apps keep on using private stuff, this will break ofc. > - Other option: Fork dddvb and change userspace apps accordingly, and > keep them in sync with upstream. Since we already have to care about > the kernel part, this option is rather suboptimal. > > Ralph, Ping :-) Changing to something different from 'd' should be fine. Is there anything still free?
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Mauro Carvalho Chehab writes: > Em Mon, 26 Jun 2017 11:45:08 +0200 > Ralph Metzler escreveu: > > > Mauro Carvalho Chehab writes: > > > Em Thu, 22 Jun 2017 23:35:27 +0200 > > > Ralph Metzler escreveu: > > > > > > > Daniel Scheller writes: > > > > > Am Tue, 20 Jun 2017 16:10:43 -0300 > > > > > schrieb Mauro Carvalho Chehab : > > > > > ... > > > > > > > - Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of > > > > > > > cards/modules. This mainly involves a new demod driver > > (stv0910) and > > > > > > > a new tuner driver (stv6111). Permissions for this are > > cleared with > > > > > > > Ralph already. The glue code needed in ddbridge is rather > > easy, and > > > > > > > as some ground work (mostly the MachXO2 support from the > > 2841 series) > > > > > > > is now in, the changes are quite small. Patches are ready so > > far but > > > > > > > need more cleanup (checkpatch fixes, camel case and such > > things). > > > > > > > > > > > > Please try to sync it with Ralph, in a way that his code won't > > > > > > diverge from the upstream one, as this will make easier for both > > > > > > sides to keep the Kernel in track with driver improvements. > > > > > > > > > > This is not going to work. DD (Ralph and Manfred Voelkel) sort of > > maintain a shared code base between their Windows > > > > > driver and the Linux kernel driver sources. While they didn't > > explicitely stated this, this can be noticed by the > > > > > remarks and commented code in their OSS code, and the commit > > messages in their dddvb GIT (e.g. "sync with windows driver"). > > > > > I've already cleaned up a lot of this (I believe no one wants to > > see such stuff in the linux kernel tree). If we're > > > > > additionally going to replace all things camel case, with some > > more cleaning and maybe code shuffling after like a V4 > > > > > patch series, those two sources are out of sync in a way that no > > automatic sync by applying patches will be possible > > > > > anymore. So, pushing from vendor's upstream to the kernel seems to > > be the only option, and in fact, if the whole > > > > > driver/package stack completely lives in the kernel sources, maybe > > DD even decide to directly commit upstream (kernel) again. > > > > > > Ralph, do you share Linux code with Windows, or are you just getting > > > drivers from the manufacturer and converting them to Linux at dddvb > > > tree? > > > > It differs from case to case. > > Digital Devices gets drivers and/or documetation from the manufacturer. > > Sometimes from this a Windows driver is written which we convert > > to Linux or a Linux driver is written directly. > > > > > > > > > Would it be possible to change things at the dddvb tree to make > > > it to use our coding style (for example, replacing CamelCase by the > > > kernel_style), in order to minimize the amount of work to sync from > > > your tree? > > > > Yes > > Good! With that, it should be easier to keep both versions containing > the same stuff. > > > > > > > I also already told Daniel about our concerns regarding the CXD > > drivers in private mail. > > > > Sony did not want us to use their code directly and we had to get our > > code approved > > > > before publishing it. I do not know how the arrangement is regarding > > the in-kernel driver. > > > > DVB-C2 support also seems to be missing in this. > > > > > > Sony recently started submitting CXD drivers to us directly (for > > cxd2880). > > > > > > The upstream verson for cx2841 came from NetUP. I guess they develop > > > the drivers themselves, but not really sure. > > > > > > Perhaps we can ask Sony's help to make easier add the features that are > > > missing at the existing driver in a way that DDbridge could also use > > > the upstream driver, or to do some other sort of agreement that would > > > make possible for us to use the same driver as you
Re: [PATCH 00/14] ddbridge: bump to ddbridge-0.9.29
Daniel Scheller writes: > Am Mon, 10 Jul 2017 10:11:01 +0200 > schrieb Ralph Metzler : > > > Daniel Scheller writes: > > > Stripped functionality compared to dddvb: > > > > > > - DVB-C modulator card support removed (requires DVB core API) > > > > not really besides one device name entry. > > ... and a header :-) Maybe we should start another thread on this for a > probable follow-up project. > > > > - OctoNET SAT>IP server/box support removed (requires API aswell) > > > - with this, GT link support was removed (only on OctoNET > > > hardware) > > > > There is other PCIe based hardware which uses/will use this. > > Umm, good to know - thus better shouldn't (even accidentally) > throw away the remove-revert of the GTL support for future cards. > > > > drivers/media/pci/ddbridge/ddbridge-core.c | 4242 > > > ++-- > > > drivers/media/pci/ddbridge/ddbridge-hw.c | 299 ++ > > > drivers/media/pci/ddbridge/ddbridge-hw.h | 52 + > > > drivers/media/pci/ddbridge/ddbridge-i2c.c | 310 ++ > > > drivers/media/pci/ddbridge/ddbridge-io.h | 71 + > > > drivers/media/pci/ddbridge/ddbridge-irq.c | 161 ++ > > > drivers/media/pci/ddbridge/ddbridge-main.c | 393 +++ > > > drivers/media/pci/ddbridge/ddbridge-regs.h | 138 +- > > > drivers/media/pci/ddbridge/ddbridge.h | 355 ++- > > > > I thought we settled on core, i2c, main, (and mod, ns, which you do > > not include). This will diverge then from my code. > > IIRC this was -main.c, and basically the code split, but no specific > file. However, each of the additionals (hw, io, irq) were done with a > reason (please also see their commit messages at patches 4-6): > > -io.h is there since the comparably complex functions in the original > ddbridge.h sort of scared me off and IMHO shouldn't live together with > struct definitions and such, so I moved them to a separate object > first. With the GTL things removed, the remainder was rather small, and > Jasmin pointed me in the "make it static inline in a header instead" > direction. When eventually GTL gets added back, it should go into it's > own object/module. > > -hw.c/h moves all things hardware-definition/info related like regmaps > into one single place, currently it's spread out into -main and -core, > which might make things difficult to find. > > -irq.c gets rid of the need of additional ifdefs related to > CONFIG_PCI_MSI, in that "defined but unused function" warnings are > generated if this isn't defined. Again, also makes it easier to find, > rather than search through ~3800 lines of -core :) > > If you're comfortable with this, I will propose it via a GitHub PR as > well (alongside the other things I'd like to push out to you). For the > in-kernel code, I'd prefer to keep it like this. As I wrote before, changes like this will break other things like the OctopusNet build tree. So, I cannot use them like this or without changes at other places. And even if I wanted to, I cannot pull anything into the public dddvb repository.
[PATCH 1/4] [media] dvb-frontends: MaxLinear MxL5xx DVB-S/S2 tuner-demodulator driver
Daniel Scheller writes: > From: Daniel Scheller > > This adds the frontend driver for the MaxLinear MxL5xx family of tuner- > demodulators, as used on Digital Devices MaxS4/8 four/eight-tuner cards. > > The driver was picked from the dddvb vendor driver package and - judging > solely from the diff - has undergone a 100% rework: > > - Silly #define's used to pass multiple values to functions were >expanded. This resulted in macro/register names not being usable >anymore for such occurences, but makes the code WAY more read-, >understand- and maintainable. OK, but why did you also replace all kinds of register value defines with numerical values? This makes the driver much less comprehensible.
[PATCH 10/14] [media] ddbridge: remove unreachable code
Daniel Scheller writes:
> From: Daniel Scheller
>
> >From smatch:
>
> drivers/media/pci/ddbridge/ddbridge-core.c:3490 snr_store() info: ignoring
> unreachable code.
>
> In fact, the function immediately returns zero, so remove it and update
> ddb_attrs_snr[] to not reference it anymore.
>
> Cc: Ralph Metzler
> Signed-off-by: Daniel Scheller
> ---
> drivers/media/pci/ddbridge/ddbridge-core.c | 27 ---
> 1 file changed, 4 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c
> b/drivers/media/pci/ddbridge/ddbridge-core.c
> index 8981795b0819..3756b9961fcd 100644
> --- a/drivers/media/pci/ddbridge/ddbridge-core.c
> +++ b/drivers/media/pci/ddbridge/ddbridge-core.c
> @@ -3236,25 +3236,6 @@ static ssize_t snr_show(struct device *device,
> return sprintf(buf, "%s\n", snr);
> }
>
> -
> -static ssize_t snr_store(struct device *device, struct device_attribute
> *attr,
> - const char *buf, size_t count)
> -{
> -struct ddb *dev = dev_get_drvdata(device);
> -int num = attr->attr.name[3] - 0x30;
> -u8 snr[34] = { 0x01, 0x00 };
> -
> -return 0; /* NOE: remove completely? */
> -if (count > 31)
> -return -EINVAL;
> -if (dev->port[num].type >= DDB_TUNER_XO2)
> -return -EINVAL;
> -memcpy(snr + 2, buf, count);
> -i2c_write(&dev->i2c[num].adap, 0x57, snr, 34);
> -i2c_write(&dev->i2c[num].adap, 0x50, snr, 34);
> -return count;
> -}
> -
> static ssize_t bsnr_show(struct device *device,
> struct device_attribute *attr, char *buf)
> {
> @@ -3394,10 +3375,10 @@ static struct device_attribute ddb_attrs_fan[] = {
> };
>
> static struct device_attribute ddb_attrs_snr[] = {
> -__ATTR(snr0, 0664, snr_show, snr_store),
> -__ATTR(snr1, 0664, snr_show, snr_store),
> -__ATTR(snr2, 0664, snr_show, snr_store),
> -__ATTR(snr3, 0664, snr_show, snr_store),
> +__ATTR_MRO(snr0, snr_show),
> +__ATTR_MRO(snr1, snr_show),
> +__ATTR_MRO(snr2, snr_show),
> +__ATTR_MRO(snr3, snr_show),
> };
>
> static struct device_attribute ddb_attrs_ctemp[] = {
> --
> 2.13.0
snr_store was disabled to prevent people from accidentally overwriting serial
numbers.
Maybe it should be a driver/compile option.
[PATCH 09/14] [media] ddbridge: fix possible buffer overflow in ddb_ports_init()
Daniel Scheller writes:
> From: Daniel Scheller
>
> Report from smatch:
>
> drivers/media/pci/ddbridge/ddbridge-core.c:2659 ddb_ports_init() error:
> buffer overflow 'dev->port' 32 <= u32max
>
> Fix by making sure "p" is greater than zero before checking for
> "dev->port[].type == DDB_CI_EXTERNAL_XO2".
>
> Cc: Ralph Metzler
> Signed-off-by: Daniel Scheller
> ---
> drivers/media/pci/ddbridge/ddbridge-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c
> b/drivers/media/pci/ddbridge/ddbridge-core.c
> index aba53fd27f3e..8981795b0819 100644
> --- a/drivers/media/pci/ddbridge/ddbridge-core.c
> +++ b/drivers/media/pci/ddbridge/ddbridge-core.c
> @@ -2551,7 +2551,7 @@ void ddb_ports_init(struct ddb *dev)
> port->dvb[0].adap = &dev->adap[2 * p];
> port->dvb[1].adap = &dev->adap[2 * p + 1];
>
> -if ((port->class == DDB_PORT_NONE) && i &&
> +if ((port->class == DDB_PORT_NONE) && i && p > 0 &&
> dev->port[p - 1].type == DDB_CI_EXTERNAL_XO2) {
> port->class = DDB_PORT_CI;
> port->type = DDB_CI_EXTERNAL_XO2_B;
> --
> 2.13.0
p cannot be 0 if i is not.
So, checking for both is redundant.
smatch seems to look a things very locally.
[PATCH 3/4] [media] ddbridge: fix buffer overflow in max_set_input_unlocked()
Daniel Scheller writes:
> From: Daniel Scheller
>
> Picked up code parts introduced one smatch error:
>
> drivers/media/pci/ddbridge/ddbridge-maxs8.c:163 max_set_input_unlocked()
> error: buffer overflow 'dev->link[port->lnr].lnb.voltage' 4 <= 255
>
> Fix this by clamping the .lnb.voltage array access to 0-3 by "& 3"'ing
> dvb->input.
>
> Cc: Ralph Metzler
> Signed-off-by: Daniel Scheller
> ---
> drivers/media/pci/ddbridge/ddbridge-maxs8.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/pci/ddbridge/ddbridge-maxs8.c
> b/drivers/media/pci/ddbridge/ddbridge-maxs8.c
> index a9dc5f9754da..10716ee8cf59 100644
> --- a/drivers/media/pci/ddbridge/ddbridge-maxs8.c
> +++ b/drivers/media/pci/ddbridge/ddbridge-maxs8.c
> @@ -187,11 +187,12 @@ static int max_set_input_unlocked(struct dvb_frontend
> *fe, int in)
> return -EINVAL;
> if (dvb->input != in) {
> u32 bit = (1ULL << input->nr);
> -u32 obit = dev->link[port->lnr].lnb.voltage[dvb->input] & bit;
> +u32 obit =
> +dev->link[port->lnr].lnb.voltage[dvb->input & 3] & bit;
>
> -dev->link[port->lnr].lnb.voltage[dvb->input] &= ~bit;
> +dev->link[port->lnr].lnb.voltage[dvb->input & 3] &= ~bit;
> dvb->input = in;
> -dev->link[port->lnr].lnb.voltage[dvb->input] |= obit;
> +dev->link[port->lnr].lnb.voltage[dvb->input & 3] |= obit;
> }
> res = dvb->set_input(fe, in);
> return res;
> --
> 2.13.0
dvb->input cannot become > 3.
If it does, it would be caused by some other error, data corruption, etc.
"& 3" just turns one arbitrarily wrong value into another.
[PATCH 00/14] ddbridge: bump to ddbridge-0.9.29
Daniel Scheller writes: > Stripped functionality compared to dddvb: > > - DVB-C modulator card support removed (requires DVB core API) not really besides one device name entry. > - OctoNET SAT>IP server/box support removed (requires API aswell) > - with this, GT link support was removed (only on OctoNET hardware) There is other PCIe based hardware which uses/will use this. > drivers/media/pci/ddbridge/ddbridge-core.c | 4242 > ++-- > drivers/media/pci/ddbridge/ddbridge-hw.c | 299 ++ > drivers/media/pci/ddbridge/ddbridge-hw.h | 52 + > drivers/media/pci/ddbridge/ddbridge-i2c.c | 310 ++ > drivers/media/pci/ddbridge/ddbridge-io.h | 71 + > drivers/media/pci/ddbridge/ddbridge-irq.c | 161 ++ > drivers/media/pci/ddbridge/ddbridge-main.c | 393 +++ > drivers/media/pci/ddbridge/ddbridge-regs.h | 138 +- > drivers/media/pci/ddbridge/ddbridge.h | 355 ++- I thought we settled on core, i2c, main, (and mod, ns, which you do not include). This will diverge then from my code. Regards, Ralph
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Daniel Scheller writes: > Am Mon, 26 Jun 2017 11:59:20 +0200 > schrieb Ralph Metzler : > > > Mauro Carvalho Chehab writes: > > > > > > Splitting it is OK. Including a *.c file no. It shouldn't be hard > > > to > > [...] > > > change the makefile to: > > > obj-ddbridge = ddbridge-main.o ddbridge-core.o > > > ddbridge-i2c.o \ ddbridge-modulator.o and ddbridge-ns.o > > > > > > The only detail is that "ddbridge.c" should be renamed to > > > ddbridge-core.c (or something similar) and some *.h files will > > > be needed. > > > > Hmm, ddbridge -> ddbridge-main would be fine. > > Funny, that's exactly the naming I had in mind when thinking about this > in the past :) > > So, I'll propose a rough todo (commit list) for me (I will do and > care about this) then: > > - 1/4: (Step 0) Since dddvb-0.9.9b besides the split also involved > reordering the functions in the code, this will be repeated with the > current mainline driver (helps keeping the diff with the actual code > bump cleaner) > - 2/4: Do the split like done in 0.9.9 with the mainline driver, but do > it by having multiple objects in the makefile, adding header files > with prototypes where required > - 3/4: Bump the driver code with what is already there (means, the > pre-cleaned variant w/o modulator and netstream/octonet stuff) > - 4/4 (or 4/x): Apply any additional patches (like the "enable msi by > default Kconf opt, marked EXPERIMENTAL" thing I did to work around > the still problematic MSI IRQ stuff to let users have a better > experience) > > When done, I'll post the patches for early review, but they'll have a > hard dependency on the stv0910/stv6111 demod/tuner drivers (don't feel > like ripping this out since we want that support anyway). > > Additionally,I can do this for dddvb and submit it to the DigitalDevices > dddvb > repository (GitHub Pull Request) so we're at least in-sync wrt > building the driver. > > Ralph, Mauro, are you ok with this? I cannot promise which changes I will accept and when. Some will likely break other things like building the OctopusNet image. The public DigitalDevices repository also is not the one I am using for development. So, changes will first go into our private repository and will only go upstream for releases. Regards, Ralph
Re: [PATCH 4/9] [media] dvb-frontends/stv0910: Fix signal strength reporting
Mauro Carvalho Chehab writes: > Em Mon, 26 Jun 2017 10:55:34 +0200 > Ralph Metzler escreveu: > > > Daniel Scheller writes: > > > From: Daniel Scheller > > > > > > Original code at least has some signed/unsigned issues, resulting in > > > values like 32dBm. > > > > I will look into that. > > > > > Change signal strength readout to work without asking > > > the attached tuner, and use a lookup table instead of log calc. Values > > > > How can you determine the exact strength without knowing what the tuner > > did? > > At least the stv6111 does its own AGC which has to be added. > > I remember I had to solve this issue on some other driver[1][2][3]. What I > did was to get the AGC gain from the tuner using a callback, > then I added it to the main gain. > > [1] https://www.spinics.net/lists/linux-media/msg101836.html > [2] https://www.spinics.net/lists/linux-media/msg101838.html > [3] https://www.spinics.net/lists/linux-media/msg101842.html > > I don't remember why it was not merged upstream, though. Perhaps because > I was in doubt about reporting it as "rf_attenuation" or as "agc gain". > > Anyway, with something like that, any demod could check for such > callback. If defined, add it to its AGC own gain, in order to get > the total AGC gain. I misused get_rf_strength for this in my versions of stv6111.c/stv0910.c. But get_rf_attenuation would be exactly what we need. Daniel now removed the get_rf_strength() call from stv0910.c and ignores the correction from the tuner. That was what I was commenting on. Regards, Ralph
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Mauro Carvalho Chehab writes: > Em Sun, 25 Jun 2017 19:52:59 +0200 > Daniel Scheller escreveu: > > > Am Sat, 24 Jun 2017 13:50:01 -0300 > > schrieb Mauro Carvalho Chehab : > > > > > Em Thu, 22 Jun 2017 23:35:27 +0200 > > > Ralph Metzler escreveu: > > > > > > Would it be possible to change things at the dddvb tree to make > > > it to use our coding style (for example, replacing CamelCase by the > > > kernel_style), in order to minimize the amount of work to sync from > > > your tree? > > > > Note that this mostly (if not only) applies to the demodulator drivers. > > ddbridge itself is okay in this regard and has only some minors like > > indent, whitespace and such. There's one bigger thing though I'm not sure > > of if it needs to be changed: Beginning with the 0.9.9-tarball release, > > functionality was split from ddbridge-core.c into ddbridge.c, > > ddbridge-i2c.c, ddbridge-mod.c and ddbridge-ns.c (the two latter being > > modulator and netstream/octonet related code, which we don't need at this > > time). The issue is that this wasn't done by updating the build system to > > build multiple objects, but rather build from ddbridge.c which then does > > '#include "ddbridge-core.c"', and in that file '#include > > "ddbridge-i2c.c"'. See [1] for how it actually looks like in the file. > > Mauro, do you think this is acceptable? > > Splitting it is OK. Including a *.c file no. It shouldn't be hard to The main reason for using includes at the time were that the OctopusNet driver (see https://github.com/DigitalDevices/dddvb/blob/master/ddbridge/octonet.c) was using the same files but with different defines set. Those differences are pretty much gone now. > change the makefile to: > obj-ddbridge = ddbridge-main.o ddbridge-core.o ddbridge-i2c.o \ > ddbridge-modulator.o and ddbridge-ns.o > > The only detail is that "ddbridge.c" should be renamed to > ddbridge-core.c (or something similar) and some *.h files will > be needed. Hmm, ddbridge -> ddbridge-main would be fine. Renaming ddbridge to ddbridge-core and ddbridge-core to something else would be confusing. Regards, Ralph
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Mauro Carvalho Chehab writes: > Em Thu, 22 Jun 2017 23:35:27 +0200 > Ralph Metzler escreveu: > > > Daniel Scheller writes: > > > Am Tue, 20 Jun 2017 16:10:43 -0300 > > > schrieb Mauro Carvalho Chehab : > > > ... > > > > > - Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of > > > > > cards/modules. This mainly involves a new demod driver (stv0910) > > and > > > > > a new tuner driver (stv6111). Permissions for this are cleared > > with > > > > > Ralph already. The glue code needed in ddbridge is rather easy, > > and > > > > > as some ground work (mostly the MachXO2 support from the 2841 > > series) > > > > > is now in, the changes are quite small. Patches are ready so far > > but > > > > > need more cleanup (checkpatch fixes, camel case and such things). > > > > > > > > > > Please try to sync it with Ralph, in a way that his code won't > > > > diverge from the upstream one, as this will make easier for both > > > > sides to keep the Kernel in track with driver improvements. > > > > > > This is not going to work. DD (Ralph and Manfred Voelkel) sort of > > maintain a shared code base between their Windows driver and the Linux > > kernel driver sources. While they didn't explicitely stated this, this can > > be noticed by the remarks and commented code in their OSS code, and the > > commit messages in their dddvb GIT (e.g. "sync with windows driver"). I've > > already cleaned up a lot of this (I believe no one wants to see such stuff > > in the linux kernel tree). If we're additionally going to replace all > > things camel case, with some more cleaning and maybe code shuffling after > > like a V4 patch series, those two sources are out of sync in a way that no > > automatic sync by applying patches will be possible anymore. So, pushing > > from vendor's upstream to the kernel seems to be the only option, and in > > fact, if the whole driver/package stack completely lives in the kernel > > sources, maybe DD even decide to directly commit upstream (kernel) again. > > Ralph, do you share Linux code with Windows, or are you just getting > drivers from the manufacturer and converting them to Linux at dddvb > tree? It differs from case to case. Digital Devices gets drivers and/or documetation from the manufacturer. Sometimes from this a Windows driver is written which we convert to Linux or a Linux driver is written directly. > Would it be possible to change things at the dddvb tree to make > it to use our coding style (for example, replacing CamelCase by the > kernel_style), in order to minimize the amount of work to sync from > your tree? Yes > > I also already told Daniel about our concerns regarding the CXD drivers in > > private mail. > > Sony did not want us to use their code directly and we had to get our code > > approved > > before publishing it. I do not know how the arrangement is regarding the > > in-kernel driver. > > DVB-C2 support also seems to be missing in this. > > Sony recently started submitting CXD drivers to us directly (for cxd2880). > > The upstream verson for cx2841 came from NetUP. I guess they develop > the drivers themselves, but not really sure. > > Perhaps we can ask Sony's help to make easier add the features that are > missing at the existing driver in a way that DDbridge could also use > the upstream driver, or to do some other sort of agreement that would > make possible for us to use the same driver as you at the upstream Kernel. > > (c/c Takiguchi-san and Tim Bird from Sony) All I know is that they were strict with Digital Devices. We could not use their code directly. That's why I am surprised the Netup code contains Sony code. > > > > - you'll still need to patch DD tree, as I'm pretty sure there are > > > > changes on the upstream driver that will need to be ported there; > > > > > > The same as for the stv0910 code applies here, in addition that it's > > not sure if DD even wants this. DD even has KERNEL_VERSION_CODE ifdefs in > > some places. And - most importantly - they carry around an old version of > > the DVB core API (from what it looks, around linux-3.10, not exactly sure) > > which even was modified by some IOCTLs, vars, defines and the netstream > > and modulator support. I managed to remove all core API change deps from > > everything tu
[PATCH 4/9] [media] dvb-frontends/stv0910: Fix signal strength reporting
Daniel Scheller writes:
> From: Daniel Scheller
>
> Original code at least has some signed/unsigned issues, resulting in
> values like 32dBm.
I will look into that.
> Change signal strength readout to work without asking
> the attached tuner, and use a lookup table instead of log calc. Values
How can you determine the exact strength without knowing what the tuner did?
At least the stv6111 does its own AGC which has to be added.
> +struct SLookup padc_lookup[] = {
> +{0, 118000 }, /* PADC=+0dBm */
> +{ -100, 93600 }, /* PADC=-1dBm */
> +{ -200, 74500 }, /* PADC=-2dBm */
> +{ -300, 59100 }, /* PADC=-3dBm */
> +{ -400, 47000 }, /* PADC=-4dBm */
> +{ -500, 37300 }, /* PADC=-5dBm */
> +{ -600, 29650 }, /* PADC=-6dBm */
> +{ -700, 23520 }, /* PADC=-7dBm */
> +{ -900, 14850 }, /* PADC=-9dBm */
> +{ -1100, 9380 }, /* PADC=-11dBm */
> +{ -1300, 5910 }, /* PADC=-13dBm */
> +{ -1500, 3730 }, /* PADC=-15dBm */
> +{ -1700, 2354 }, /* PADC=-17dBm */
> +{ -1900, 1485 }, /* PADC=-19dBm */
> +{ -2000, 1179 }, /* PADC=-20dBm */
> +{ -2100, 1000 }, /* PADC=-21dBm */
> +};
...
> -if (bbgain < (s32) *strength)
> -*strength -= bbgain;
> -else
> -*strength = 0;
> +padc = TableLookup(padc_lookup, ARRAY_SIZE(padc_lookup), Power) + 352;
>
Where does the padc_lookup table come from?
I saw it before in CrazyCat github tree.
Is he or you the original source/author or somebody else?
Regards,
Ralph
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Daniel Scheller writes: > Am Tue, 20 Jun 2017 16:10:43 -0300 > schrieb Mauro Carvalho Chehab : > ... > > > - Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of > > > cards/modules. This mainly involves a new demod driver (stv0910) and > > > a new tuner driver (stv6111). Permissions for this are cleared with > > > Ralph already. The glue code needed in ddbridge is rather easy, and > > > as some ground work (mostly the MachXO2 support from the 2841 series) > > > is now in, the changes are quite small. Patches are ready so far but > > > need more cleanup (checkpatch fixes, camel case and such things). > > > > Please try to sync it with Ralph, in a way that his code won't > > diverge from the upstream one, as this will make easier for both > > sides to keep the Kernel in track with driver improvements. > > This is not going to work. DD (Ralph and Manfred Voelkel) sort of maintain a > shared code base between their Windows driver and the Linux kernel driver > sources. While they didn't explicitely stated this, this can be noticed by > the remarks and commented code in their OSS code, and the commit messages in > their dddvb GIT (e.g. "sync with windows driver"). I've already cleaned up a > lot of this (I believe no one wants to see such stuff in the linux kernel > tree). If we're additionally going to replace all things camel case, with > some more cleaning and maybe code shuffling after like a V4 patch series, > those two sources are out of sync in a way that no automatic sync by > applying patches will be possible anymore. So, pushing from vendor's > upstream to the kernel seems to be the only option, and in fact, if the > whole driver/package stack completely lives in the kernel sources, maybe DD > even decide to directly commit upstream (kernel) again. > > Putting Ralph into "To:", really like to hear an opinion from him on this > whole subject. Regarding divergence in the tuner/demod drivers I see some concerns. The TDA18212 driver as they are presently in kernel and Daniel's github tree still seems to be missing features like calibration and spur avoidance. This problem was already discussed here a few years ago. I would not want to move to these versions if those features are still missing. I also already told Daniel about our concerns regarding the CXD drivers in private mail. Sony did not want us to use their code directly and we had to get our code approved before publishing it. I do not know how the arrangement is regarding the in-kernel driver. DVB-C2 support also seems to be missing in this. > > - you'll still need to patch DD tree, as I'm pretty sure there are > > changes on the upstream driver that will need to be ported there; > > The same as for the stv0910 code applies here, in addition that it's not > sure if DD even wants this. DD even has KERNEL_VERSION_CODE ifdefs in some > places. And - most importantly - they carry around an old version of the DVB > core API (from what it looks, around linux-3.10, not exactly sure) which > even was modified by some IOCTLs, vars, defines and the netstream and > modulator support. I managed to remove all core API change deps from > everything tuner related (and thats the reason things work in harmony with > and in current kernels), but getting all this over to DD or even merge > things from DD into the media subsystem will get "interesting". We certainly will want to keep supporting older kernels via KERNEL_VERSION. But I can change the dvb core version in dddvb to a newer version. Also, some of the new tuning defines and properties are generally useful and should be added to the kernel. e.g.: - adding SYS_DVBC2 to fe_delivery_system - DTV_INPUT to select an input on cards were demods can choose from several inputs - DTV_PLS to set the gold code used for DVB-S2 physical layer scrambling. (btw. the sometimes used root and combo codes are redundant) Some driver mods misuse the upper bits of DTV_STREAM_ID (which is for MIS in DVB-S2) for this, but PLS and MIS are independent. I know that the netstream and modulator support are proprietary but we will of course also need to keep them dddvb package. Btw., are there any standard APIs for modulator cards in the kernel now? Regards, Ralph
Re: [media-workshop] [ANNOUNCE] Linux Kernel Media mini-summit on Oct, 16-17 in Düsseldorf, Germany
Guennadi Liakhovetski writes: > I'll likely be able to attend too. ATM I'm working on camera support in > Android. I think Hans discussed related topics at the previous summit in > the US too, which I didn't manage to attend unfortunately. I'll try to > double-check results of those discussions and see which topics I'd be > interested in discussing further. I'll also try to be there for the mini-summit. So, if anybody wants to discuss APIs for DVB-T2/C2, CI, modulators, DVB network streaming or anything else related to DVB drivers ... > On a related note, since I live something like 80km from the venue, I was > thinking about possibly helping to organise a media event in my town - in > Aachen, or in Düsseldorf itself or in neighbouring Cologne (Köln). Let me > know if there's interest. We could use Saturday the 18th of October for > that. I also live just 50km from the venue. 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: ddbridge -- kernel 3.15.6
Antti Palosaari writes: > Most hardest part mainlining all that stuff is absolutely API issues. > Designing new APIs is a lot of work. Due to that I decided remove all > the problematic stuff in order to proceed. > > API related issues: > * DVB modulator API Yes, we definitely need a general API for this. > * some unusual CI stuff This is only the extra CI (formerly misused SEC) device which has no API, just basic read/write. > * network streaming > * own device node (I left it as for now as it was there already) Mainly for firmware updates and debugging. > * DVB-C2 API (it is still there, but if it looks hard to specify I will > disable it too) Needs some extending for proper scanning but is good enough for basic tuning. > Driver related issues: > * MaxLinear MxL5x, demod + tuner driver needs to be upstreamed > * STMicroelectronics STV0910, demod + tuner driver needed. Should be > study if existing kernel drivers could be changed easily to support that > chip too, if not upstream drivers. STV090x shares many features but has many slight differences in registers and handling. Could be worth merging but might turn out to need many conditionals. 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
DVB Modulator API
Hi,
Dave Chapman writes:
> Given the recent patches by Maik Broemme adding support for a DVB-C
> modulator, I thought I would mention that I'm working on a driver for a
> DVB-T modulator and would like to open a discussion regarding how to
> integrate modulator support into the existing DVB API and kernel sub-system.
>
> The device I'm working with is a $169 (USD) USB DVB-T modulator based on
> the it9507 ASIC from ITE. ITE provide a GPL'd Linux driver, but this is
> 40K+ lines of code and is based on their generic cross-platform SDK
> supporting a range of devices.
>
> The device can be purchased here in various incarnations:
>
> http://www.idealez.com/hides/product-gallery/en_US/1-0/554
My driver is for this DVB-C modulator called Resi DVB-C:
http://www.digitaldevices.de/english/Resi_DVB-C_Modulator.html
It can modulate 10 DVB-C channels. They can have different modulations (QAM16
to QAM256) but have a fixed symbol rate (6.9 Msymbols) and have to
be next to each other in one 80MHz block (10 times 8 MHz).
> The hardware also has hardware PID filtering (allowing both whitelisting
> and blacklisting of data being transferred from the demod to the mod)
> and also the ability to insert SI packets into the modulated stream at
> user-definited intervals. Again, my driver doesn't support these
> features yet.
The Resi does not support PID filtering but some other features like
filling up the TS with filler packets if the output rate is larger than
the rate of the TS you want to send.
It can also correct the PCR according to the added TS packets.
> Regarding the API, I've looked at the ddbridge driver here:
>
> http://www.metzlerbros.de/dddvb/dddvb-0.9.10.tar.bz2
>
> and from what I can understand, this adds a new "mod0" device to access
> the DVB-C modulator. The API is as follows:
>
> struct dvb_mod_params {
> __u32 base_frequency;
> __u32 attenuator;
> };
>
> struct dvb_mod_channel_params {
> enum fe_modulation modulation;
>
> __u32 rate_increment;
>
> };
>
> #define DVB_MOD_SET _IOW('o', 208, struct dvb_mod_params)
> #define DVB_MOD_CHANNEL_SET _IOW('o', 209, struct
> dvb_mod_channel_params)
>
> I've no idea what "rate_increment" is.
It is for adjusting the the rate of filler packet insertion.
It shuld probably go into a separae ioctl.
I could use something like your DVBMOD_SET_PARAMETERS with differnt
parameters (those for DVB-C instead of DVB-T). I just would have to
reject most of them because only modulation can be set.
> Looking in the docs/modulator file, there also appears to be some
> ability to redirect data from a demod to a mod via
> /sys/class/ddbridge/ddbridge0/redirect
>
>
This is kind of a hack inside the ddbridge driver (the modulator shares the
DMA block with CI output on other ddbridge cards) which redirects
DMA from one card to another.
I am sure this can be solved more cleanly with the media controller stuff
but for now this has to suffice.
> The it9507 driver uses a software attenuation, and the range is
> dependent (but only very slightly - +/- a couple of dB at either end of
> the scale) on the frequency. So I've currently implemented a
> DVBMOD_GET_RF_GAIN_RANGE ioctl to get the available gain range for a
> specific frequency, but it wouldn't be a big loss to change the driver
> to just limit the gain to the subset that works on all frequencies,
> removing that call from the API.
Your DVBMOD_SET_RF_GAIN would be my attenuator setting above.
> I haven't had chance yet to seriously consider a generic modulator API,
> but with one modulator driver now being considered for inclusion I
> wanted to make those considering the API aware of my work.
>
> It seems clear however that neither my current API, nor that included
> with the ddbridge DVB-C modulator is generic enough at the moment.
Sure.
We will need one generic enough to support all delivery systems and also
special hardware features like rate adjustment, PCR correction, PID filtering,
packet insertion, etc.
There are also cards which do the modulation in software and accept I/Q pairs,
e.g.
the DekTec cards. But I only use those for testing demods for delivery systems
I cannot receive directly. We could add an I/Q mode for those kinds of cards.
The modulation part would have to go into user space.
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: DVB-C2
Antti Palosaari writes: > On 03.11.2013 13:31, Mauro Carvalho Chehab wrote: > > Em Wed, 23 Oct 2013 00:57:47 +0200 > > Ralph Metzler escreveu: > >> I am wondering if anybody looked into API extensions for DVB-C2 yet? > >> Obviously, we need some more modulations, guard intervals, etc. > >> even if the demod I use does not actually let me set those (only auto). > >> > >> But I do need to set the PLP and slice ID. > >> I currently set them (8 bit each) by combining them into the 32 bit > >> stream_id (DTV_STREAM_ID parameter). > > > > I don't like the idea of combining them into a single field. One of the > > reasons is that we may have endianness issues. > > > > So, IMHO, the better is to add a new property for slice ID. > > I tried to understand what that data slice is. So what I understand, it > is layer to group PLPs, in order to get one wide OFDM channel as OFDM is > more efficient when channel bw increases. > > So, in order to tune "stream" channel on DVB-C2 system, you *must* know > (in a order from radio channel to upper layers): > frequency > bandwidth > slice ID > PLP ID > > Is that right? Yes, if you do not want to parse L1 data you need the frequency of the slice, bandwidth, slice ID and PLP ID. If you parse L1 data, you do not need the slice ID because the PLP should be unique in one channel. > I wonder if PLP IDs are defined so that there could not be overlapping > PLP IDs in a system... But if not, then defining slice ID is likely > needed. And if and when slice ID is needed to know before PLP ID, it is > even impossible to resolve slice ID from PLP ID. See above, you can resolve it, but then you need to get the L1 data. But PLPs can even be spread over several slices to get higher bandwidth for one PLP. This is probably not used for broadcast TV though. You will also need one tuner/demod per slice then. So, basically you only need any frequency for the "channel" (can be spread over up to 450MHz, but avoid notches) and the bandwith. Tune until a L1 lock, get L1 data from demod (up to 4 KB), parse for the PLP id you want, get the corresponding slice (or slices), tune to the slice frequency with slice ID set and PLP id set and wait for a full lock ... 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/12] DDBridge 0.9.10 driver updates
Maik Broemme writes: > Hi Mauro, > > Mauro Carvalho Chehab wrote: > > Em Sun, 3 Nov 2013 01:22:35 +0100 > > Maik Broemme escreveu: > > > > > I've updated the current DDBridge to latest version 0.9.10 from Ralph > > > Metzler available at: > > > > > > http://www.metzlerbros.de/dddvb/dddvb-0.9.10.tar.bz2 > > > > > > I've merged the driver to work with current v4l/dvb tree and I will > > > maintain the driver for v4l/dvb in future. > > > > Works for me. > > > > > The coming patch series is > > > the first version and I explicitly want to get feedback and hints if > > > some parts are merged at wrong places, etc... The following changes > > > were made: > > > > > > - MSI enabled by default (some issues left with i2c timeouts) > > > - no support for Digital Devices Octonet > > > - no support for DVB Netstream > > > - removed unused module parameters 'tt' and 'vlan' (used by Octonet) > > > - removed unused registers to cleanup code (might be added later again > > > if needed) > > > > Be sure to not remove any feature that are currently needed for the > > already supported devices to work. > > Of course I won't do. The Octonet and DVB Netstream weren't supported in > current driver. MSI is already supported but was not enabled by default > because the old 0.5 version currently in kernel had some problems with > it. However new one works fine with MSI - at least for me I'm using the > patchset myself already - but needs some further testing. Some people still have problems with MSI. I am not sure if it depends on the board type and/or BIOS version, etc. 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 01/12] dvb-frontends: Support for DVB-C2 to DVB frontends
Mauro Carvalho Chehab writes:
> Em Sun, 3 Nov 2013 01:24:25 +0100
> Maik Broemme escreveu:
>
> > Added support for DVB-C2 to DVB frontends. It will be required
> > by cxd2843 and tda18212dd (Digital Devices) frontends.
> >
> > Signed-off-by: Maik Broemme
> > ---
> > include/uapi/linux/dvb/frontend.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/include/uapi/linux/dvb/frontend.h
> > b/include/uapi/linux/dvb/frontend.h
> > index c56d77c..98648eb 100644
> > --- a/include/uapi/linux/dvb/frontend.h
> > +++ b/include/uapi/linux/dvb/frontend.h
> > @@ -410,6 +410,7 @@ typedef enum fe_delivery_system {
> >SYS_DVBT2,
> >SYS_TURBO,
> >SYS_DVBC_ANNEX_C,
> > + SYS_DVBC2,
> > } fe_delivery_system_t;
> >
> > /* backward compatibility */
>
> Please update also the documentation, at Documentation/DocBook/media/dvb.
>
> Doesn't DVB-C2 provide any newer property? If so, please add it there as
> well, and at frontend.h.
>
I asked about this on linux-media a week or so ago. The main question was
concerning STREAM_ID. I asked if it would be fine to combine PLP and
slice id (each 8 bit) into stream_id or if there should be a separate
new property. And for which one, PLP or slice id?
Probably slice id, because stream_id is also used for PLP in T2?
I combined them into stream_id for now (but that was after the 0.9.10 version
of the dddvb package).
There are also many new qam types, etc. but, as I said back then, it was not
urgent for me to add those because the Sony demod does not allow setting those.
At least it is not documented how to do it.
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
DVB-C2
Hi, I am wondering if anybody looked into API extensions for DVB-C2 yet? Obviously, we need some more modulations, guard intervals, etc. even if the demod I use does not actually let me set those (only auto). But I do need to set the PLP and slice ID. I currently set them (8 bit each) by combining them into the 32 bit stream_id (DTV_STREAM_ID parameter). By using the stream id like this and not having (or being able) to set the rest of the new parameters I only have to add SYS_DVBC2 to the delivery systems right now. But the new parameters should be added for completeness and if we want to be able to scan we will need calls to read out L1 signalling information. Any thoughts? 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: ddbridge v0.8
Oliver Schinagl writes: > On 02/11/13 23:20, Martin Vidovic wrote: > > Hi, > > > > Is there any plan to include ddbridge driver version 0.8 in mainline kernel > > (currently it's 0.5). I really see no reason it's in the vacuum like now > > for almost a year. No sign of pushing it into mainline. Why is that so? > > It's a good driver. > You should ask Ralph Metzler (added to CC) as he wrote the driver I > think or atleast maintains it. I wrote the driver but I never submitted it to the kernel myself. I got frustrated with that process years ago. Oliver Endriss took care of it and necessary coding style adjustments etc. in the last few years. (Many thanks again!) But now he also stopped to pass it into the kernel due to some complications with other changes upstream. I usually distribute a package with own versions of dvb-core, frontend and ddbridge drivers now. When the next major restructuring due to the DVB-C modulator card and the stand-alone hardware network streamer (octopus net) support is done, I will make it publically available. The current driver is version 0.9.7. It should be up to kernel coding style and can be easily copied over into a current kernel. But I am not about to take it apart into little patches. 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: [dvb] Question on dvb-core re-structure
Mauro Carvalho Chehab writes: > Em Thu, 10 Jan 2013 13:49:52 +0200 > "Hamad Kadmany" escreveu: > > > On 01/10/2013 1:13 PM, Antti Palosaari wrote: > > > I could guess that even for the SoCs there is some bus used internally. > > > If it is not one of those already existing, then create new directly just > > like one of those existing and put it there. > > > > Thanks for the answer. I just wanted to clarify - it's integrated into the > > chip and accessed via memory mapped registers, so I'm not sure which > > category to give the new directory (parallel to pci/mms/usb). Should I just > > put the adapter's sources directory directly under media directory? > > That's the case of all other drivers under drivers/media/platform: they're > IP blocks inside the SoC chip. I think that all arch-dependent drivers are > there. > > The menu needs to be renamed to "Media platform drivers" when the first DVB > driver arrives there (it currently says V4L, as there's no DVB driver there > yet). Feel free to add such patch on your patch series at the time you > submit your driver, if nobody else submit any DVB platform driver earlier > than yours. What about DVB cores which can be used via different busses? E.g. ddbridge initially only used PCIe. Now we also use the same function blocks (I2C, DVB input, etc.) connected to a SoC via an EBI (extension bus interface) and register it as a platform device. Because a lot of code can be shared I do not want to split it over several directories. 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
[PATCH 1/2] [media] drxk: Make the QAM demodulator command configurable.
Martin Blumenstingl writes: > Currently there are two different commands: the old command which takes > 4 parameters, and a newer one with just takes 2 parameters. Hi, are you sure about this? >From what I have been told, the 2 parameter command is in the firmware ROM and older loadable/patch firmwares. Newer firmwares provided the 4 parameter command. 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
linux-media@vger.kernel.org
Dan Carpenter writes: > On Sat, Jun 09, 2012 at 10:47:32AM +0300, Dan Carpenter wrote: > > The test here is never true because '&' was used instead of '|'. It was > > the same as: > > > >if (status & ((1<<16) & (1<<17)) ... > > > > Signed-off-by: Dan Carpenter > > --- > > I don't have this hardware and this one really should be tested or > > checked by someone who knows the spec. It could be that the intent was > > to do: > > > >if ((status & SOLO_IIC_STATE_TRNS) && > >(status & SOLO_IIC_STATE_SIG_ERR) || ... > > > > It should be this, yes? For other similar mistakes it was meant to > be this way. Yes, looks ok. 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: [media] DRX-K: Initial check-in
Dan Carpenter writes:
> On Sun, Jun 10, 2012 at 09:42:22PM +0200, Ralph Metzler wrote:
> > Dan Carpenter writes:
> > > Hello Ralph Metzler,
> > >
> > > The patch 43dd07f758d8: "[media] DRX-K: Initial check-in" from Jul 3,
> > > 2011, leads to the following warning:
> > > drivers/media/dvb/frontends/drxk_hard.c:2980 ADCSynchronization()
> > > warn: suspicious bitop condition
> > >
> > > 2977 status = read16(state, IQM_AF_CLKNEG__A,
> > &clkNeg);
> > > 2978 if (status < 0)
> > > 2979 goto error;
> > > 2980 if ((clkNeg | IQM_AF_CLKNEG_CLKNEGDATA__M) ==
> > > 2981
> > IQM_AF_CLKNEG_CLKNEGDATA_CLK_ADC_DATA_POS) {
> > >
> > > IQM_AF_CLKNEG_CLKNEGDATA__M is 2.
> > > IQM_AF_CLKNEG_CLKNEGDATA_CLK_ADC_DATA_POS is 0.
> > > So this condition can never be true.
> >
> > It seems this should be & instead of |. The mistake was also present in
> > the windows driver.
> >
>
> Good deal. Do you want me to send a patch, or are you going to
> handle it? Could I get a Reported-by cookie?
Please send a patch.
I am not maintaining the kernel version.
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: [media] DRX-K: Initial check-in
Dan Carpenter writes:
> Hello Ralph Metzler,
>
> The patch 43dd07f758d8: "[media] DRX-K: Initial check-in" from Jul 3,
> 2011, leads to the following warning:
> drivers/media/dvb/frontends/drxk_hard.c:2980 ADCSynchronization()
> warn: suspicious bitop condition
>
> 2977 status = read16(state, IQM_AF_CLKNEG__A, &clkNeg);
> 2978 if (status < 0)
> 2979 goto error;
> 2980 if ((clkNeg | IQM_AF_CLKNEG_CLKNEGDATA__M) ==
> 2981 IQM_AF_CLKNEG_CLKNEGDATA_CLK_ADC_DATA_POS) {
>
> IQM_AF_CLKNEG_CLKNEGDATA__M is 2.
> IQM_AF_CLKNEG_CLKNEGDATA_CLK_ADC_DATA_POS is 0.
> So this condition can never be true.
It seems this should be & instead of |. The mistake was also present in the
windows driver.
>
> 2982 clkNeg &= (~(IQM_AF_CLKNEG_CLKNEGDATA__M));
> 2983 clkNeg |=
> 2984
> IQM_AF_CLKNEG_CLKNEGDATA_CLK_ADC_DATA_NEG;
> 2985 } else {
> 2986 clkNeg &= (~(IQM_AF_CLKNEG_CLKNEGDATA__M));
> 2987 clkNeg |=
> 2988
> IQM_AF_CLKNEG_CLKNEGDATA_CLK_ADC_DATA_POS;
>
> clkNeg |= 0; <-- doesn't make much sense to the unenlightened.
>
> 2989 }
This is perfectly normal since those defines were automatically created from
the
firmware source code. It is better to leave the code as it is. If there ever is
a firmware update
and these bits change their values it will be much harder to adjust the driver.
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: DVB nGene CI : TS Discontinuities issues
Anssi Hannula writes: > > I had it running for an hour and had no discontinuities (except at > > restarts, might have to look into buffer flushing). > > I tested it with nGene and Octopus boards on an Asus ION2 board and on a > > Marvell Kirkwood based ARM board. > > Should your test code (quoted below) work with e.g. Octopus DDBridge on > vanilla 3.2.6 kernel, without any additional initialization needed > through ca0 or so? > > When I try it here like that, the reader thread simply blocks > indefinitely on the first read, while the writer thread continues to > write packets into the device. > Am I missing something, or is this a bug? Yes, it should work as it is. I assume you adjusted the adapter numbers of course. 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] [media] hdpvr: update picture controls to support firmware versions > 0.15
On Wed, Dec 21, 2011 at 5:14 PM, Taylor Ralph wrote: > On Mon, Nov 7, 2011 at 7:54 PM, Taylor Ralph wrote: >> On Mon, Nov 7, 2011 at 7:21 AM, Mauro Carvalho Chehab >> wrote: >>> Em 21-10-2011 01:33, Taylor Ralph escreveu: >>>> On Thu, Oct 20, 2011 at 3:26 PM, Taylor Ralph >>>> wrote: >>>>> On Thu, Oct 20, 2011 at 2:14 PM, Devin Heitmueller >>>>> wrote: >>>>>> On Thu, Oct 20, 2011 at 1:08 PM, Janne Grunau wrote: >>>>>>> I think such scenario is unlikely but I don't know it for sure and >>>>>>> I don't want to force anyone to test every firmware version. >>>>>>> Ignoring them for firmware version < 16 should be safe since we assume >>>>>>> they had no effect. Returning -EINVAL might break API-ignoring >>>>>>> applications written with the HD PVR in mind but I think it's a better >>>>>>> approach than silently ignoring those controls. >>>>>> >>>>>> At this point, let's just make it so that the old behavior is >>>>>> unchanged for old firmwares, meaning from both an API standpoint as >>>>>> well as what the values are. Â At some point if somebody cares enough >>>>>> to go back and fix the support so that the controls actually work with >>>>>> old firmwares, they can take that up as a separate task. Â In reality, >>>>>> it is likely that nobody will ever do that, as the "easy answer" is >>>>>> just to upgrade to firmware 16. >>>>>> >>>>>> Taylor, could you please tweak your patch to that effect and resubmit? >>>>>> >>>>> >>>>> Sure, I'll try to get to it tonight and have it tested. >>>>> >>>> >>>> OK, I've updated the patch per your requests. I made this patch >>>> against the latest kernel source but I'm unable to test since my >>>> 2.6.32 kernel has symbol issues with the new v4l code. >>> >>> Please, add your Signed-off-by: to the patch. This is a requirement for >>> it to be accepted upstream[1]. >>> >>> Thanks, >>> Mauro >>> >>> [1] See: >>> http://linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Developer.27s_Certificate_of_Origin_1.1 >>> >>>> >>>> Regards. >>>> -- >>>> Taylor >>> >>> >> >> Sorry about that. The updated patch is attached. >> >> Thanks. >> -- >> Taylor > > Ping. Has this patch been committed yet? > PING. Again, has the patch been committed? It's needed for new firmware that is shipping from Hauppauge. Thanks. -- Taylor -- 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: CI/CAM support for offline (from file) decoding
Kovacs Balazs writes: > Yes, i thought about that, but i need the Hardware CAM + CI, because > it's chip paired encryption. It means in my situation that the EMM and > ECM is also encrypted so it's hard to use in a SoftCam configuration. > > I hope there's a solution in the DVB driver space. > > I receive the signal via RF or IP. If via RF i think it can be decoded > via the HW, and the record it to disk, but i need the full TS > decrypted, and i think it's not possible (to decrypt all the encrypted > ES which can be 20-30-40 in real time when i receive the signal). In > IP configuration it's also not possible. So i have the recorded full > TS pieces and somehow i have to decrypt with a CAM+Card paired to each > other. Of course i know that the decryption is only possible if the > Smartcard has the authorization in those date ranges when the files > was recorded. I have seen this kind of solution in Windows, but i need > it on Linux now. Yes, you can do that, but only if the hardware supports it. Most cards with CAM/CI are hardwired in such a way that the transport stream comes from the demodulator, goes through the CAM/CI and then into the PCIe/PCI bridge. There are only a few cards where you can send a TS from memory to the CAM/CI and back. -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] [media] hdpvr: update picture controls to support firmware versions > 0.15
On Mon, Nov 7, 2011 at 7:54 PM, Taylor Ralph wrote: > On Mon, Nov 7, 2011 at 7:21 AM, Mauro Carvalho Chehab > wrote: >> Em 21-10-2011 01:33, Taylor Ralph escreveu: >>> On Thu, Oct 20, 2011 at 3:26 PM, Taylor Ralph >>> wrote: >>>> On Thu, Oct 20, 2011 at 2:14 PM, Devin Heitmueller >>>> wrote: >>>>> On Thu, Oct 20, 2011 at 1:08 PM, Janne Grunau wrote: >>>>>> I think such scenario is unlikely but I don't know it for sure and >>>>>> I don't want to force anyone to test every firmware version. >>>>>> Ignoring them for firmware version < 16 should be safe since we assume >>>>>> they had no effect. Returning -EINVAL might break API-ignoring >>>>>> applications written with the HD PVR in mind but I think it's a better >>>>>> approach than silently ignoring those controls. >>>>> >>>>> At this point, let's just make it so that the old behavior is >>>>> unchanged for old firmwares, meaning from both an API standpoint as >>>>> well as what the values are. Â At some point if somebody cares enough >>>>> to go back and fix the support so that the controls actually work with >>>>> old firmwares, they can take that up as a separate task. Â In reality, >>>>> it is likely that nobody will ever do that, as the "easy answer" is >>>>> just to upgrade to firmware 16. >>>>> >>>>> Taylor, could you please tweak your patch to that effect and resubmit? >>>>> >>>> >>>> Sure, I'll try to get to it tonight and have it tested. >>>> >>> >>> OK, I've updated the patch per your requests. I made this patch >>> against the latest kernel source but I'm unable to test since my >>> 2.6.32 kernel has symbol issues with the new v4l code. >> >> Please, add your Signed-off-by: to the patch. This is a requirement for >> it to be accepted upstream[1]. >> >> Thanks, >> Mauro >> >> [1] See: >> http://linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Developer.27s_Certificate_of_Origin_1.1 >> >>> >>> Regards. >>> -- >>> Taylor >> >> > > Sorry about that. The updated patch is attached. > > Thanks. > -- > Taylor Ping. Has this patch been committed yet? Thanks. -- Taylor -- 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] hdpvr: update picture controls to support firmware versions > 0.15
On Mon, Nov 7, 2011 at 7:21 AM, Mauro Carvalho Chehab wrote: > Em 21-10-2011 01:33, Taylor Ralph escreveu: >> On Thu, Oct 20, 2011 at 3:26 PM, Taylor Ralph wrote: >>> On Thu, Oct 20, 2011 at 2:14 PM, Devin Heitmueller >>> wrote: >>>> On Thu, Oct 20, 2011 at 1:08 PM, Janne Grunau wrote: >>>>> I think such scenario is unlikely but I don't know it for sure and >>>>> I don't want to force anyone to test every firmware version. >>>>> Ignoring them for firmware version < 16 should be safe since we assume >>>>> they had no effect. Returning -EINVAL might break API-ignoring >>>>> applications written with the HD PVR in mind but I think it's a better >>>>> approach than silently ignoring those controls. >>>> >>>> At this point, let's just make it so that the old behavior is >>>> unchanged for old firmwares, meaning from both an API standpoint as >>>> well as what the values are. Â At some point if somebody cares enough >>>> to go back and fix the support so that the controls actually work with >>>> old firmwares, they can take that up as a separate task. Â In reality, >>>> it is likely that nobody will ever do that, as the "easy answer" is >>>> just to upgrade to firmware 16. >>>> >>>> Taylor, could you please tweak your patch to that effect and resubmit? >>>> >>> >>> Sure, I'll try to get to it tonight and have it tested. >>> >> >> OK, I've updated the patch per your requests. I made this patch >> against the latest kernel source but I'm unable to test since my >> 2.6.32 kernel has symbol issues with the new v4l code. > > Please, add your Signed-off-by: to the patch. This is a requirement for > it to be accepted upstream[1]. > > Thanks, > Mauro > > [1] See: > http://linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Developer.27s_Certificate_of_Origin_1.1 > >> >> Regards. >> -- >> Taylor > > Sorry about that. The updated patch is attached. Thanks. -- Taylor hdpvr_v3.diff Description: Binary data
RE: [DVB] Digital Devices Cine CT V6 support
Sébastien RAILLARD (COEXSI) writes: > CineS2 v6 + 2 CAM Readers > > ++ > Tuner 0 -> Input 0 -> || > | Port 0 - TAB 1 | -> Output 0 > Tuner 1 -> Input 1 -> | DVB-S2 | > ++ > Input 2 -> || > | Port 1 - TAB 2 | -> Output 1 > Input 3 -> || > ++ > CAM 0 -> Input 4 -> || > | Port 2 - TAB 3 | -> Output 2 -> CAM 0 > Input 5 -> | CAM | > ++ > CAM 1 -> Input 6 -> || > | Port 3 - TAB 4 | -> Output 3 -> CAM 1 > Input 7 -> | CAM | > ++ > > Two redirections to set : > > * "X0 X2" (input #0 to port #2) > * "X1 X3" (input #1 to port #3) > > Where X is the device number. Correct, except that the CineS2 V6 only has TAB2 and TAB3 on board. Btw., I also added the module parameter adapter_alloc, which lets you specifiy how many adapters are to be allocated: 0 = one adapter per io if modules are present 1 = one adapter for each tab on which a module was detected 2 = one per tab even if no modules were detected 3 = one adapter for all devices of one card If you use adapter_alloc=3 for a config like above (2 tuners 2 CAMS) you will get all the devices in one /dev/dvb/adapterX/ and most programs should now work with CI out of the box (at least with the first tuner) if the redirections are set properly. 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: [DVB] Digital Devices Cine CT V6 support
Sébastien RAILLARD (COEXSI) writes: > I've seen a new parameter "ts_loop", can you explain how it's working? > Is-it for sending the stream from the demodulator directly to the CAM > reader? No, it is mainly for testing. It declares one TAB as loopback, which means that the data output is directly connected to the input. For redirecting a stream through a CI see the "redirect" attribute. I don't know if my small redirect readme was included in the package I sent to Oliver. So, I attached it below. -Ralph Redirection of TS streams through CI modules is now supported through /sys/class/ddbridge/ddbridge0/redirect. It only works with cards based on the ddbridge PCIe bridge, not with nGene based cards. It is set up in such a way that you can write "AB CD" to a "redirect" attribute and data from input B of card A is then piped through port D (meaning TAB (D+1) which uses output D and input 2*D for CI io) of card C and then shows up in the demux device belonging to input B (input (B&1) of TAB (B/2+1)) of card A. E.g.: echo "00 01" > /sys/class/ddbridge/ddbridge0/redirect will pipe input 0 of card 0 through CI at port 1 (TAB 2) of card 0. Redirection should only be done right after loading the driver (or booting if the driver is built-in) and before using the devices in any way. -- 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] hdpvr: update picture controls to support firmware versions > 0.15
On Thu, Oct 20, 2011 at 3:26 PM, Taylor Ralph wrote:
> On Thu, Oct 20, 2011 at 2:14 PM, Devin Heitmueller
> wrote:
>> On Thu, Oct 20, 2011 at 1:08 PM, Janne Grunau wrote:
>>> I think such scenario is unlikely but I don't know it for sure and
>>> I don't want to force anyone to test every firmware version.
>>> Ignoring them for firmware version < 16 should be safe since we assume
>>> they had no effect. Returning -EINVAL might break API-ignoring
>>> applications written with the HD PVR in mind but I think it's a better
>>> approach than silently ignoring those controls.
>>
>> At this point, let's just make it so that the old behavior is
>> unchanged for old firmwares, meaning from both an API standpoint as
>> well as what the values are. Â At some point if somebody cares enough
>> to go back and fix the support so that the controls actually work with
>> old firmwares, they can take that up as a separate task. Â In reality,
>> it is likely that nobody will ever do that, as the "easy answer" is
>> just to upgrade to firmware 16.
>>
>> Taylor, could you please tweak your patch to that effect and resubmit?
>>
>
> Sure, I'll try to get to it tonight and have it tested.
>
OK, I've updated the patch per your requests. I made this patch
against the latest kernel source but I'm unable to test since my
2.6.32 kernel has symbol issues with the new v4l code.
Regards.
--
Taylor
diff --git a/drivers/media/video/hdpvr/hdpvr-core.c b/drivers/media/video/hdpvr/hdpvr-core.c
index 441dacf..687282d 100644
--- a/drivers/media/video/hdpvr/hdpvr-core.c
+++ b/drivers/media/video/hdpvr/hdpvr-core.c
@@ -154,10 +154,20 @@ static int device_authorization(struct hdpvr_device *dev)
}
#endif
+ dev->fw_ver = dev->usbc_buf[1];
+
v4l2_info(&dev->v4l2_dev, "firmware version 0x%x dated %s\n",
- dev->usbc_buf[1], &dev->usbc_buf[2]);
+ dev->fw_ver, &dev->usbc_buf[2]);
+
+ if (dev->fw_ver > 0x15) {
+ dev->options.brightness = 0x80;
+ dev->options.contrast = 0x40;
+ dev->options.hue = 0xf;
+ dev->options.saturation = 0x40;
+ dev->options.sharpness = 0x80;
+ }
- switch (dev->usbc_buf[1]) {
+ switch (dev->fw_ver) {
case HDPVR_FIRMWARE_VERSION:
dev->flags &= ~HDPVR_FLAG_AC3_CAP;
break;
@@ -169,7 +179,7 @@ static int device_authorization(struct hdpvr_device *dev)
default:
v4l2_info(&dev->v4l2_dev, "untested firmware, the driver might"
" not work.\n");
- if (dev->usbc_buf[1] >= HDPVR_FIRMWARE_VERSION_AC3)
+ if (dev->fw_ver >= HDPVR_FIRMWARE_VERSION_AC3)
dev->flags |= HDPVR_FLAG_AC3_CAP;
else
dev->flags &= ~HDPVR_FLAG_AC3_CAP;
@@ -270,6 +280,8 @@ static const struct hdpvr_options hdpvr_default_options = {
.bitrate_mode = HDPVR_CONSTANT,
.gop_mode = HDPVR_SIMPLE_IDR_GOP,
.audio_codec = V4L2_MPEG_AUDIO_ENCODING_AAC,
+ /* original picture controls for firmware version <= 0x15 */
+ /* updated in device_authorization() for newer firmware */
.brightness = 0x86,
.contrast = 0x80,
.hue = 0x80,
diff --git a/drivers/media/video/hdpvr/hdpvr-video.c b/drivers/media/video/hdpvr/hdpvr-video.c
index 087f7c0..36bb057 100644
--- a/drivers/media/video/hdpvr/hdpvr-video.c
+++ b/drivers/media/video/hdpvr/hdpvr-video.c
@@ -722,21 +722,39 @@ static const s32 supported_v4l2_ctrls[] = {
};
static int fill_queryctrl(struct hdpvr_options *opt, struct v4l2_queryctrl *qc,
- int ac3)
+ int ac3, int fw_ver)
{
int err;
+ if (fw_ver > 0x15) {
+ switch (qc->id) {
+ case V4L2_CID_BRIGHTNESS:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ case V4L2_CID_CONTRAST:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x40);
+ case V4L2_CID_SATURATION:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x40);
+ case V4L2_CID_HUE:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0x1e, 1, 0xf);
+ case V4L2_CID_SHARPNESS:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ }
+ } else {
+ switch (qc->id) {
+ case V4L2_CID_BRIGHTNESS:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x86);
+ case V4L2_CID_CONTRAST:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ case V4L2_CID_SATURATION:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ case V4L2_CID_HUE:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ case V4L2_CID_SHARPNESS:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ }
+ }
+
switch (qc->id) {
- case V4L2_CID_BRIGHTNESS:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x86);
- case V4L2_CID_CONTRAST:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
- case V4L2_CID_SATURATION:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
- case V4L2_CID_HUE:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff
Re: [PATCH] [media] hdpvr: update picture controls to support firmware versions > 0.15
On Thu, Oct 20, 2011 at 2:14 PM, Devin Heitmueller wrote: > On Thu, Oct 20, 2011 at 1:08 PM, Janne Grunau wrote: >> I think such scenario is unlikely but I don't know it for sure and >> I don't want to force anyone to test every firmware version. >> Ignoring them for firmware version < 16 should be safe since we assume >> they had no effect. Returning -EINVAL might break API-ignoring >> applications written with the HD PVR in mind but I think it's a better >> approach than silently ignoring those controls. > > At this point, let's just make it so that the old behavior is > unchanged for old firmwares, meaning from both an API standpoint as > well as what the values are. Â At some point if somebody cares enough > to go back and fix the support so that the controls actually work with > old firmwares, they can take that up as a separate task. Â In reality, > it is likely that nobody will ever do that, as the "easy answer" is > just to upgrade to firmware 16. > > Taylor, could you please tweak your patch to that effect and resubmit? > Sure, I'll try to get to it tonight and have it tested. Regards. -- Taylor -- 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] hdpvr: update picture controls to support firmware versions > 0.15
On Thu, Oct 20, 2011 at 11:30 AM, Devin Heitmueller wrote: > On Thu, Oct 20, 2011 at 11:24 AM, Taylor Ralph wrote: >> I've attached a patch that correctly sets the max/min/default values >> for the hdpvr picture controls. The reason the current values didn't >> cause a problem until now is because any firmware <= 0.15 didn't >> support them. The latest firmware releases properly support picture >> controls and the values in the patch are derived from the windows >> driver using SniffUSB2.0. >> >> Thanks to Devin Heitmueller for helping me. >> >> Regards. >> -- >> Taylor > > Hi Taylor, > > What worries me here is the assertion that the controls didn't work at > all in previous firmware and driver versions. Â Did you downgrade the > firmware and see that the controls had no effect when using v4l2-ctl? > I have 2 HD-PVRs. I ran one with 0x17 and one with 0x15. Using v4l2-ctl to control the 0x15 unit produced zero changes. It has been reported by mythtv users in the past the picture control changes did not work for the HD-PVR. Regards. -- Taylor -- 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] hdpvr: update picture controls to support firmware versions > 0.15
I've attached a patch that correctly sets the max/min/default values
for the hdpvr picture controls. The reason the current values didn't
cause a problem until now is because any firmware <= 0.15 didn't
support them. The latest firmware releases properly support picture
controls and the values in the patch are derived from the windows
driver using SniffUSB2.0.
Thanks to Devin Heitmueller for helping me.
Regards.
--
Taylor
diff -r abd3aac6644e linux/drivers/media/video/hdpvr/hdpvr-core.c
--- a/linux/drivers/media/video/hdpvr/hdpvr-core.c Fri Jul 02 00:38:54 2010 -0300
+++ b/linux/drivers/media/video/hdpvr/hdpvr-core.c Thu Oct 20 11:14:25 2011 -0400
@@ -262,10 +262,10 @@
.bitrate_mode = HDPVR_CONSTANT,
.gop_mode = HDPVR_SIMPLE_IDR_GOP,
.audio_codec = V4L2_MPEG_AUDIO_ENCODING_AAC,
- .brightness = 0x86,
- .contrast = 0x80,
- .hue = 0x80,
- .saturation = 0x80,
+ .brightness = 0x80,
+ .contrast = 0x40,
+ .hue = 0xf,
+ .saturation = 0x40,
.sharpness = 0x80,
};
diff -r abd3aac6644e linux/drivers/media/video/hdpvr/hdpvr-video.c
--- a/linux/drivers/media/video/hdpvr/hdpvr-video.c Fri Jul 02 00:38:54 2010 -0300
+++ b/linux/drivers/media/video/hdpvr/hdpvr-video.c Thu Oct 20 11:14:25 2011 -0400
@@ -731,13 +731,13 @@
switch (qc->id) {
case V4L2_CID_BRIGHTNESS:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x86);
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
case V4L2_CID_CONTRAST:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x40);
case V4L2_CID_SATURATION:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x40);
case V4L2_CID_HUE:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ return v4l2_ctrl_query_fill(qc, 0x0, 0x1e, 1, 0xf);
case V4L2_CID_SHARPNESS:
return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
case V4L2_CID_MPEG_AUDIO_ENCODING:
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Oliver Endriss writes: > > Both ngene and ddbrige calls dvb_attach once for drxk_attach. > > The logic used there, and by tda18271c2dd driver is different > > from similar logic on other frontends. > > > > The right fix is to change them to use the same logic, but, > > while we don't do that, we need to patch em28xx-dvb in order > > to do cope with ngene/ddbridge magic. > > I disagree: The right fix is to extend the framework, and drop the > secondary frondend completely. The current way of supporting > multi-standard tuners is abusing the DVB API. > Yes, exactly what I wanted to say. I am just working on yet another C/T combo. This time stv0367 and TDA18212. For both there are existing drivers and our own version again. I am trying to merge them so that there is not yet another discussion regarding new driver versions (but the very first version might still come out with separate drivers). At the same time I want to add delivery system properties to support everything in one frontend device. Adding a parameter to select C or T as default should help in most cases where the application does not support switching yet. 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
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 Devin, Devin Heitmueller writes: > On Sun, Jul 3, 2011 at 12:31 PM, Oliver Endriss 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: DVB nGene CI : TS Discontinuities issues
Issa Gorissen writes:
> On 11/05/11 15:12, Issa Gorissen wrote:
> > From: Ralph Metzler
> >> Issa Gorissen writes:
> >> > Could you please take a look at the cxd2099 issues ?
> >> >
> >> > I have attached a version with my changes. I have tested a lot of
> >> > different settings with the help of the chip datasheet.
> >> >
> >> > Scrambled programs are not handled correctly. I don't know if it is the
> >> > TICLK/MCLKI which is too high or something, or the sync detector ?
> >> Also,
> >> > as we have to set the TOCLK to max of 72MHz, there are way too much
> >> null
> >> > packets added. Is there a way to solve this ?
> >>
> >> I do not have any cxd2099 issues.
> >> I have a simple test program which includes a 32bit counter as payload
> >> and can pump data through the CI with full speed and have no packet
> >> loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
> >> but also had no problems with this.
> >>
> >> Please take care not to write data faster than it is read. Starting two
> >> dds will not guarantee this. To be certain you could write a small
> >> program which never writes more packets than input buffer size minus
> >> the number of read packets (and minus the stuffing null packets on ngene).
> >>
> >> Before blaming packet loss on the CI data path also please make
> >> certain that you have no buffer overflows in the input part of
> >> the sec device.
> >> In the ngene driver you can e.g. add a printk in tsin_exchange():
> >>
> >> if (dvb_ringbuffer_free(&dev->tsin_rbuf) > len) {
> >> ...
> >> } else
> >> printk ("buffer overflow \n");
> >>
> >>
> >> Regards,
> >> Ralph
> Ralph,
>
OB > Done some more tests, from by test tool, I found out that I have to skip
> (rather often) bytes to find the sync one when reading from sec0. I
> thought I only needed to do that at the start of the stream, not in the
> middle; because I always read/write 188 bytes from it.
This should not happen.
Is there any difference regarding this alignment problem if the CI is inserted
or not?
> Could you share your test code ? I'm finding it difficult to interact
> with this sec0 implementation.
Below my test code. You just need to adjust the device name.
I had it running for an hour and had no discontinuities (except at
restarts, might have to look into buffer flushing).
I tested it with nGene and Octopus boards on an Asus ION2 board and on a
Marvell Kirkwood based ARM board.
Btw., what hardware exactly are you using?
Which DVB card version, CI type, motherboard chipset?
Regards,
Ralph
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
uint8_t fill[188]={0x47, 0x1f, 0xff, 0x10,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff };
uint8_t ts[188]={0x47, 0x0a, 0xaa, 0x00 };
void proc_buf(uint8_t *buf, uint32_t *d)
{
uint32_t c;
if (buf[1]==0x1f && buf[2]==0xff) {
//printf("fill\n");
return;
}
if (buf[1]==0x9f && buf[2]==0xff) {
//printf("fill\n");
return;
}
if (buf[1]!=0x0a || buf[2]!=0xaa)
return;
c=(buf[4]<<24)|(buf[5]<<16)|(buf[6]<<8)|buf[7];
if (c!=*d) {
printf("CONT ERROR %08x %08x\n", c, *d);
*d=c;
} else {
if (memcmp(ts+8, buf+8, 180))
printf("error\n");
if (!(c&
multiple delivery systems in one device
Hi, since it seems devices with several delivery systems can be queried with one command: Andreas Oberritter writes: > > Of course it does since it is not feasible to use the same adapter > > number even on the same card when it provides multi-standard > > frontends which share dvr and demux devices. E.g., frontend0 and > > frontend1 can belong to the same demod which can be DVB-C and -T > > (or other combinations, some demods can even do DVB-C/T/S2). > > There's absolutely no need to have more than one frontend device per > demod. Just add two commands, one to query the possible delivery systems > and one to switch the system. Why would you need more than one device > node at all, if you can only use one delivery system at a time? can somebody tell me how this is done and how it has to be supported in the demod driver? All I could find regarding this is http://www.linuxquestions.org/questions/linux-kernel-70/dvb-adapter-driver-dvb-c-dvb-t-switching-linux-dvb-api-v5-803503/ 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] Ngene cam device name
Andreas Oberritter writes: > > Of course it does since it is not feasible to use the same adapter > > number even on the same card when it provides multi-standard > > frontends which share dvr and demux devices. E.g., frontend0 and > > frontend1 can belong to the same demod which can be DVB-C and -T > > (or other combinations, some demods can even do DVB-C/T/S2). > > There's absolutely no need to have more than one frontend device per > demod. Just add two commands, one to query the possible delivery systems > and one to switch the system. Why would you need more than one device > node at all, if you can only use one delivery system at a time? Maybe because there is no proper documentation for this. > > Or is there a standard way this is supposed to be handled? > > Yes. Since ages. The ioctl is called DMX_SET_SOURCE. This does make no sense regarding my question. > > There are no mechanism to connect a frontend with specific dvr or > > demux devices in the current API. But you demand it for the caio device. > > See above. Ok, wrong formulation. There is no API to indicate which can connect to which. > > A ca/caio pair is completely independent by design and should not get > > mixed with > > other devices. > > I guess you're right, but I'm questioning your design. How else can an independent CI interface be designed? And this is how the hardware is. I cannot change this in software. > > > It's ugly to force random policies on drivers. Please create a proper > > > interface instead! > > > > > > > Then the whole API should first get proper interfaces. See above. > > Already done. See above. And no proper documentation. > Of course, you shouldn't invent fake frontends. But, if you decide to > plug a frontend into your octopus card later on, then the frontend > device should appear under the same adapter number. Right? No, it does not right now. > > > At least on embedded devices, it simply isn't feasible to copy a TS to > > > userspace from a demux, just to copy it back to the kernel and again > > > back to userspace through a caio device, when live streaming. > > > > Then do not use it on embedded devices. > > But this is how this hardware works and APIs will not change the hardware. > > In a similar way, I could propose to not use vanilla kernels, if you > don't want to come up with a good API. Why? The driver works fine on top of vanilla kernels. I do not really care if the driver itself gets into the kernel anymore. -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] Ngene cam device name
Andreas Oberritter writes: > > - ca0 would be reached from /dev/dvb/adapter0/ca0 > > - ca[12], depending on if they are connected to the same physical adapter > > (PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or > > /dev/dvb/adapter1/ca1 and /dev/dvb/adapter2/ca2 and there respective caio > > devices. > > Of course I'm referring to devices connected to the same physical > adapter. Otherwise they would all be called ca0. Device enumeration > always starts at 0, for each adapter. What you're describing just > doesn't make sense. Of course it does since it is not feasible to use the same adapter number even on the same card when it provides multi-standard frontends which share dvr and demux devices. E.g., frontend0 and frontend1 can belong to the same demod which can be DVB-C and -T (or other combinations, some demods can even do DVB-C/T/S2). frontend0 and frontend1 could then be DVB-C/T of demod 0 frontend2 and frontend3 would be DVB-C/T of demod 1. frontend4 might be a DVB-S frontend of demod 2, frontend5 DVB-S of demod 3. How do I know then which frontends belong to the 4 demux/dvr devices? Or is there a standard way this is supposed to be handled? There are no mechanism to connect a frontend with specific dvr or demux devices in the current API. But you demand it for the caio device. > > - If the 3 ca devices are on the same adapter, then the driver writer > > should > > take care of the order of the mapping so that ca1 always map caio1 and > > ca2/caio2, ...; and if this is not feasable, then the driver writer should > > span the ca/caio devices on different /dev/dvb/adapter folders. > > You can't create caio1 without creating caio0 first. Of course, you > could require driver writers to register those ca devices first that > have caio devices. But that conflicts with other policies the driver > author might already have chosen, e.g. to map the ca (descrambler) > device numbers to demux and dvr numbers, which seems way more intuitive > to me, because demux hardware usually comes with built-in descramblers. A ca/caio pair is completely independent by design and should not get mixed with other devices. > > It's ugly to force random policies on drivers. Please create a proper > interface instead! > Then the whole API should first get proper interfaces. See above. > Last but not least, using a different adapter number wouldn't fit > either, because a DVB adapter is supposed to > - be one independent piece of hardware > - provide at least a frontend and a demux device If you only plug in CI adapter modules in the octopus cards there are no frontend and demux devices. So, should we invent frontend and demux devices so that we are allowed to use the DVB API? Or should we create a new independent API for this? Even if we copy 99% of the existing ca API? > At least on embedded devices, it simply isn't feasible to copy a TS to > userspace from a demux, just to copy it back to the kernel and again > back to userspace through a caio device, when live streaming. Then do not use it on embedded devices. But this is how this hardware works and APIs will not change the hardware. > But you > may want to provide a way to use the caio device for > offline-descrambling. Unless you want to force users to buy multiple > modules and multiple subscriptions for a single receiver, which in turn > would need multiple CI slots, you need a way to make sure caio can not > be used during live streaming. If this dependency is between different > adapters, then something is really, really wrong. What dependency are you talking about? > > Why don't you just create a new device, e.g. ciX, deprecate the use of > caX for CI devices, inherit CI-related existing ioctls from the CA API, > translate the existing read and write funtions to ioctls and then use > read and write for TS I/O? IIRC, Ralph suggested something similar. I'm > pretty sure this can be done without too much code and in a backwards > compatible way. This would require changing all en50221 related user space code. I only mentioned it would have been nice to have it this way from the beginning. Now it would be too late since one usually gets loud screaming from everywhere if user space API changes (not extensions) are even thought about. -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] Ngene cam device name
Hi, since I just saw cxd2099 appear in staging in the latest git kernel, a simple question which has been pointed out to me before: Why is cxd2099.c in staging regarding the device name question? It has nothing to do with the naming. 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] Ngene cam device name
Andreas Oberritter writes: > > They should be in different adapterX directories. > > Even on the cards where you can connect up to 4 dual frontends or CAM > > adapters > > I currently use one adapter directory for every frontend and CAM. > > That looks like a hack to me, that may work well for your PC style > adapter, e.g frontends and CAMs attached to PCI or USB. But how would Exactly what I want to support with this. > you integrate audio and video decoders and hardware demux devices into > that scenario? Would you expect adapterN's frontend to be able to feed a > TS into adapterN+1's hardware demux and then into adapterN+2's video > decoder? This would be up to the application since there is no hardware stream routing on these cards and no general stream routing protocol for DVB in the kernel. > > If you want to "save" adapters one could put them in the same > > directory and caX would belong to camX. > > More ca than cam devices could only occur on cards with mixed old and > > new style hardware. I am not aware of such cards. > > DVB descramblers use ca devices, too. So it's certainly possible to occur. Not in the same adapter directory. > And even if no hardware exists that uses CAM slots with such different > capabilities, we should be prepared when such hardware appears. Then we also should not use the current API (or any) for the same reason? > > I think there are cards with dual frontend and two CAM adapters where > > normally data from frontendX is passed through caX (they are in the same > > adapter > > directory) but the paths can also be switched. I do not now how this is > > handled. > > On our STB platform. we have four frontends and four CAM slots. > Frontends and CAM slots get connected on demand or even chained to allow > multiple CAMs to try to decode parts of the same TS. I don't see how > multiple adapters could fit in that situation. Is this routing in hardware? If yes, it is totally different because your devices are not independent. How do you support this with the current API? 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] Ngene cam device name
Andreas Oberritter writes: > On 03/11/2011 10:44 PM, Martin Vidovic wrote: > > Andreas Oberritter wrote: > >> It's rather unintuitive that some CAMs appear as ca0, while others as > >> cam0. > >> > > Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used > > as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write > > transport stream. To me it looks like an extension of the current API. > > I see. This raises another problem. How to find out, which ca device > cam0 relates to, in case there are more ca devices than cam devices? > They should be in different adapterX directories. Even on the cards where you can connect up to 4 dual frontends or CAM adapters I currently use one adapter directory for every frontend and CAM. If you want to "save" adapters one could put them in the same directory and caX would belong to camX. More ca than cam devices could only occur on cards with mixed old and new style hardware. I am not aware of such cards. I think there are cards with dual frontend and two CAM adapters where normally data from frontendX is passed through caX (they are in the same adapter directory) but the paths can also be switched. I do not now how this is handled. 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] Ngene cam device name
Andreas Oberritter writes: > > Unless you want to move the writing to/reading from the CI module into > > ioctls of the ci device you need another node. > > Even nicer would be having the control messages moved to ioctls and the > > TS IO in read/write of ci, but this would break the old interface. > > It's possible to keep compatibility. Just add ioctls to get and set the > interface version. Default to the current version, not supporting TS > I/O. If the version is set to e.g. 1, switch from the current interface > to the new one, using ioctls for control messages. A possibility, but also requires rewrites in existing software like libdvben50221. Right now you can e.g. tune with /dev/dvb/adapter0/frontend0, point an unchanged libdvben50221 to /dev/dvb/adapter1/ci0 (separate adapter since it can even be on a different card) and pipe all PIDs of cam_pmt of the program you are watching through /dev/dvb/adapter1/sec0(cam0) and it is decoded. 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] Ngene cam device name
Andreas Oberritter writes: > >> On 03/10/2011 04:29 PM, Issa Gorissen wrote: > > Now, according to Mauro comments, he has put this code into staging > > because of > > the usage of sec0 name for a cam device. > > > > Please comment on Oliver's explanations from this thread > > > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg26901.html > > Oliver explained that he's not going to put work into this driver, > because he's not using it. > > Until now, I haven't heard any reasons for just adding another device > node other than it being easier than defining a proper interface. The > fact that a solution "just works as is" is not sufficient to move a > driver from staging. IMO the CI driver should not have been included at > all in its current shape. Unless you want to move the writing to/reading from the CI module into ioctls of the ci device you need another node. Even nicer would be having the control messages moved to ioctls and the TS IO in read/write of ci, but this would break the old interface. What kind of proper interface were you thinking about? Regarding usage of dvr/demux mentioned in the linked thread above, this would add major overhead and lots more nodes. You would need dvr0/demux0 for output and dvr1/demux1 for input and both would PID-filter the stream yet again although it probably already was when being read from the demux or dvr device belonging to the tuner. 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
Sony CXD2099AR support
Issa Gorissen writes: > I have read that this CI chip driver is in staging because some questions on > how to handle it are still not answered. > > I volunteer to handle this one. I'm a regular java developer, but I'm willing > to put effort in learning linux drivers writing. > > So Ralph, can you give me some pointers on where the discussion should resume > ? > AFAIR, the only problem was that the old "sec"-Device name was abused. I do not see a problem in just adding a "cam" or whatever device in dvb-core and use that. Or just rename "sec" since it is no longer used. Regarding the interface I think it should just remain being like a pipe. Using the dvr and demux devices for this just adds overhead. -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
cx88: IR code causing excessive interrupts during idle
I've recently assembled a core i3 system and attempted to reduce the power consumed by using powertop. I noticed that during idle with no applications running (including Xorg) that the idle power state (C6) average residency was less than 5ms. The top offender was interrupts generated by the cx88 module. I mentioned this to Devin on IRC and he mentioned to comment out line 3533 of cx88-cards.c: //cx88_ir_init(core, pci); With this patch applied the interrupts disappeared and the idle state average residency jumped to more than 60ms. This obviously allows much better power efficiency as it avoids the power consumed by exiting idle states. I don't use the IR interface on my Pinnacle 800i cards and the driver doesn't have an option to disable IR. Just thought I'd bring this up on the list in case it interests anyone. Thanks. -- Taylor -- 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: cx23885
On Mon, Feb 15, 2010 at 11:56:52PM +0100, Michael wrote:
>
> If anybody can give me a hint, what to include in a patch and what was old
> stuff that has jsut changed in 2.6.31, I'd be grateful.
Their source tree contains a .hg_archival.txt file which looks like
it can be used to identify the original v4l-dvb tree they used.
Attached is a diff from that v4l version to the MPX-885 tree.
cx23885/cx23885-cards.c| 90
cx23885/cx23885-dvb.c | 30 +
cx23885/cx23885-video.c|2
cx23885/cx23885.h |1
cx25840/cx25840-core.c | 248 +++--
cx25840/cx25840-firmware.c |4
6 files changed, 338 insertions(+), 37 deletions(-)
Hope it helps...
-R
diff -uNr v4l-dvb/linux/drivers/media/video/cx23885/cx23885-cards.c
MPX-885/linux/v4l-dvb/linux/drivers/media/video/cx23885/cx23885-cards.c
--- v4l-dvb/linux/drivers/media/video/cx23885/cx23885-cards.c 2010-02-15
18:19:26.0 -0500
+++ MPX-885/linux/v4l-dvb/linux/drivers/media/video/cx23885/cx23885-cards.c
2009-11-11 09:36:16.0 -0500
@@ -216,6 +216,29 @@
.name = "Compro VideoMate E800",
.portc = CX23885_MPEG_DVB,
},
+ [CX23885_BOARD_MPX885] = {
+ .name = "MPX-885",
+.porta = CX23885_ANALOG_VIDEO,
+.portb = CX23885_MPEG_ENCODER,
+.portc = CX23885_MPEG_DVB,
+.input = {{
+.type = CX23885_VMUX_COMPOSITE1,
+.vmux = CX25840_VIN1_CH1,
+.gpio0 = 0,
+}, {
+.type = CX23885_VMUX_COMPOSITE2,
+.vmux = CX25840_VIN2_CH1,
+.gpio0 = 0,
+}, {
+.type = CX23885_VMUX_COMPOSITE3,
+.vmux = CX25840_VIN3_CH1,
+.gpio0 = 0,
+}, {
+.type = CX23885_VMUX_COMPOSITE4,
+.vmux = CX25840_VIN4_CH1,
+.gpio0 = 0,
+} },
+},
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -351,7 +374,11 @@
.subvendor = 0x1858,
.subdevice = 0xe800,
.card = CX23885_BOARD_COMPRO_VIDEOMATE_E800,
- },
+ }, {
+ .subvendor = 0x0,
+.subdevice = 0x0,
+.card = CX23885_BOARD_MPX885,
+},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -798,6 +825,37 @@
/* CX24228 GPIO */
/* Connected to IF / Mux */
break;
+case CX23885_BOARD_MPX885:
+ /* GPIO-0 656_CLK */
+ /* GPIO-1 656_D0 */
+ /* GPIO-2 8295A Reset */
+ /* GPIO-3-10 cx23417 data0-7 */
+ /* GPIO-11-14 cx23417 addr0-3 */
+ /* GPIO-15-18 cx23417 READY, CS, RD, WR */
+ /* GPIO-19 IR_RX */
+
+ /* CX23417 GPIO's */
+ /* EIO15 Zilog Reset */
+ /* EIO14 S5H1409/CX24227 Reset */
+ mc417_gpio_enable(dev, GPIO_15 | GPIO_14, 1);
+
+ /* Put the demod into reset and protect the eeprom */
+ mc417_gpio_clear(dev, GPIO_15 | GPIO_14);
+ mdelay(100);
+
+ /* Bring the demod and blaster out of reset */
+ mc417_gpio_set(dev, GPIO_15 | GPIO_14);
+ mdelay(100);
+
+ /* Force the TDA8295A into reset and back */
+ cx23885_gpio_enable(dev, GPIO_2, 1);
+ cx23885_gpio_set(dev, GPIO_2);
+ mdelay(20);
+ cx23885_gpio_clear(dev, GPIO_2);
+ mdelay(20);
+ cx23885_gpio_set(dev, GPIO_2);
+ mdelay(20);
+ break;
}
}
@@ -827,6 +885,8 @@
case CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP:
request_module("ir-kbd-i2c");
break;
+case CX23885_BOARD_MPX885:
+break;
}
return ret;
@@ -887,6 +947,10 @@
if (dev->i2c_bus[0].i2c_rc == 0)
hauppauge_eeprom(dev, eeprom+0xc0);
break;
+case CX23885_BOARD_MPX885:
+ if (dev->i2c_bus[0].i2c_rc == 0)
+ hauppauge_eeprom(dev, eeprom+0xc0);
+break;
}
switch (dev->board) {
@@ -938,6 +1002,22 @@
ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
+case CX23885_BOARD_MPX885:
+ /* Defaults for VID B - Analog encoder */
+ /* DREQ_POL, SMODE, PUNC_CLK, MCLK_POL Serial bus + punc clk */
+ ts1->gen_ctrl_val= 0x10e;
+ ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
+ ts1->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
+
+ /* APB_TSVALERR_POL (active low)*/
+ ts1->vld_misc_val= 0x
Re: cx23885 oops during loading, WinTV-HVR-1850 card -- SOLVED
On Fri, Jan 08, 2010 at 09:06:01PM -0500, Devin Heitmueller wrote:
>
> The cx23885 driver doesn't work with tvtime, due to bugs in the v4l
> controls in the driver. Michael Krufky has some patches but they need
> some more work before they can go in the mainline. Even if they were
> committed though, there is currently no support for raw audio, so
> tvtime would not be a good application to use for this device.
Thanks for the tip. I've tried all the other clients I could get my
hands on, including xawtv, mplayer, and xine. Unfortunately, I have
not managed to get a picture (or even an empty window) out of them.
Is there a way to get it working?
Mplayer plays local media files and DVDs happily, but when I
try to input from /dev/video, or use the tv:// args, it complains:
v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0
over and over again. The other clients just hang or exit.
I'm not sure what to try next. Here is a typical log, I have tried
many variations, but the end result is always the same.
$ mplayer tv://4 -tv norm=NTSC-M:chanlist=us-bcast
MPlayer SVN-r29800-4.4.2 (C) 2000-2009 MPlayer Team
[...]
Playing tv://4.
STREAM: [tv] tv://4
STREAM: Description: TV Input
STREAM: Author: Benjamin Zores, Albeu
STREAM: Comment:
TV file format detected.
Selected driver: v4l2
name: Video 4 Linux 2 input
author: Martin Olschewski
comment: first try, more to come ;-)
Selected device: Hauppauge WinTV-HVR1850
Tuner cap: STEREO LANG1 LANG2
Tuner rxs: MONO LANG2
Capabilites: video capture tuner read/write streaming
supported norms: 0 = NTSC-M; 1 = NTSC-M-JP; 2 = NTSC-443; 3 = PAL-BG; 4 =
PAL-I; 5 = PAL-DK; 6 = PAL-M; 7 = PAL-N; 8 = PAL-Nc; 9 = PAL-60; 10 = SECAM-DK;
11 = SECAM-L;
inputs:
Current input: 0
Format unknown (0x4745504d) ( 0 bits, MPEG): Unknown 0x4745504d
Current format: unknown (0x4745504d)
v4l2: current audio mode is : LANG1
v4l2: set format: YVU420
v4l2: set input: 0
v4l2: ioctl enum input failed: Invalid argument
Selected norm : NTSC-M
v4l2: set norm: NTSC-M
Selected channel list: us-bcast (including 82 channels)
Requested channel: 4
Selected channel: 4 (freq: 67.250)
Current frequency: 1076 (67.250)
Current frequency: 1076 (67.250)
==> Found video stream: 0
v4l2: get format: unknown (0x4745504d)
v4l2: get fps: 29.970030
v4l2: get width: 720
v4l2: get height: 480
Using a ring buffer for maximum 2 frames, 0 MB total size.
v4l2: ioctl query control failed: Invalid argument
v4l2: ioctl query control failed: Invalid argument
v4l2: ioctl query control failed: Invalid argument
v4l2: ioctl query control failed: Invalid argument
[V] filefmt:9 fourcc:0x4745504D size:720x480 fps:29.970 ftime:=0.0334
[vdpau] Could not open dynamic library libvdpau.so.1
X11 opening display: :0.0
vo: X11 color mask: FF (R:FF G:FF00 B:FF)
vo: X11 running at 848x480 with depth 24 and 32 bpp (":0.0" => local display)
[x11] Detected wm supports NetWM.
[x11] Detected wm supports FULLSCREEN state.
[x11] Detected wm supports ABOVE state.
[x11] Detected wm supports BELOW state.
[x11] Current fstype setting honours FULLSCREEN ABOVE BELOW X atoms
[VO_XV] Using Xv Adapter #0 (Intel(R) Textured Video)
[xv common] Drawing no colorkey.
[xv common] Maximum source image dimensions: 2048x2048
==
Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
VDec: vo config request - 720 x 480 (preferred colorspace: Mpeg PES)
Trying filter chain: vo
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
SwScale params: -1 x -1 (-1=no scaling)
Trying filter chain: scale vo
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.
VDecoder init failed :(
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Unsupported PixelFormat -1
INFO: libavcodec init OK!
Selected video codec: [ffmpeg1] vfm: ffmpeg (FFmpeg MPEG-1)
==
Audio: no sound
Freeing 0 unused audio chunks.
Starting playback...
v4l2: going to capture
v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0
v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0
v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0
v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0
v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0
v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0
v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0
v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0
v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0
v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0
v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0
v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0
v4l2: ioctl dequeue buffer failed: Input/output error, idx =
Re: cx23885 oops during loading, WinTV-HVR-1850 card -- SOLVED
On Fri, Jan 08, 2010 at 02:14:59PM -0500, Ralph Siemsen wrote: > > I tried replacing only the cx23885.ko driver, as well as installing all > of the v4l-dvb drivers -- behaviour seemed to be the same. With all > drivers installed, system bootup does not complete, udev hangs, but I > see the same kernel oops from cx23885. Solved this part, the oops was caused by the missing sysfs NULL, already reported at http://patchwork.kernel.org/patch/70126/ Now the driver loads, and I follow it up with "modprobe tuner". Unfortunately, no luck yet using tvtime, it just reports: videoinput: No inputs available on video4linux2 device '/dev/video0'. But I suspect that is a different issue! -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
cx23885 oops during loading, WinTV-HVR-1850 card
I picked up an HVR-1800 but the box contained an 1850. Encouraged by other reports of success on this list, I plunged ahead and tried it. However, the driver oopses during loading, and oddly, after that point my terminal loses job control (can't ^C or ^Z anymore... weird.) System is running Fedora 12 with kernel 2.6.31.9-174.fc12.i686.PAE. Stock driver in fedora works, but does not reckognize the 1850. Motherboard is an Intel DG45FC with a Core 2 Duo. So I compiled v4l-dvb from HG against the fedora headers and loaded the new modules, that's when the opps happens. Details below. I tried replacing only the cx23885.ko driver, as well as installing all of the v4l-dvb drivers -- behaviour seemed to be the same. With all drivers installed, system bootup does not complete, udev hangs, but I see the same kernel oops from cx23885. Question: should I be trying this against vanilla kernel? Or should I try investigating the oops to see if I can figure out what's wrong? Any other debug/diagnostics I can provide? Thanks! -Ralph cx23885 driver version 0.0.2 loaded cx23885 :02:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 CORE cx23885[0]: subsystem: 0070:8541, board: Hauppauge WinTV-HVR1850 [card=24,autodetected] tveeprom 6-0050: Hauppauge model 85021, rev C5F5, serial# 6396039 tveeprom 6-0050: MAC address is 00-0D-FE-61-98-87 tveeprom 6-0050: tuner model is NXP 18271C2 (idx 155, type 54) tveeprom 6-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) tveeprom 6-0050: audio processor is CX23888 (idx 40) tveeprom 6-0050: decoder processor is CX23888 (idx 34) tveeprom 6-0050: has radio, has IR receiver, has no IR transmitter cx23885[0]: hauppauge eeprom: model=85021 cx25840 8-0044: cx25 0-21 found @ 0x88 (cx23885[0]) cx25840 8-0044: firmware: requesting v4l-cx23885-avcore-01.fw cx25840 8-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) cx23885[0]: registered device video0 [mpeg] cx23885_dvb_register() allocating 1 frontend(s) cx23885[0]: cx23885 based dvb card tda18271 6-0060: creating new instance TDA18271HD/C2 detected @ 6-0060 DVB: registering new adapter (cx23885[0]) DVB: registering adapter 0 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)... cx23885_dev_checkrevision() Hardware revision = 0xd0 cx23885[0]/0: found at :02:00.0, rev: 4, irq: 19, latency: 0, mmio: 0xff40 cx23885 :02:00.0: setting latency timer to 64 IRQ 19/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs input: cx23885 IR (Hauppauge WinTV-HVR as /devices/pci:00/:00:1c.3/:02:00.0/input/input13 Creating IR device irrcv0 BUG: unable to handle kernel paging request at 72727563 IP: [] strcmp+0xf/0x22 *pdpt = 33195001 *pde = Oops: [#1] SMP last sysfs file: /sys/module/i2c_core/initstate Modules linked in: tda18271 s5h1411 cx25840 cx23885(+) ir_common ir_core fuse nfs lockd fscache nfs_acl auth_rpcgss coretemp sunrpc ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath uinput snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer cx2341x videobuf_dma_sg v4l2_common snd videodev v4l1_compat soundcore videobuf_dvb i2c_i801 iTCO_wdt iTCO_vendor_support dvb_core videobuf_core btcx_risc tveeprom e1000e snd_page_alloc serio_raw i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: cx23885] Pid: 1778, comm: insmod Not tainted (2.6.31.9-174.fc12.i686.PAE #1) EIP: 0060:[] EFLAGS: 00010286 CPU: 1 EIP is at strcmp+0xf/0x22 EAX: c08db475 EBX: f312c030 ECX: c050a5e0 EDX: 72727563 ESI: c08db4d3 EDI: 72727563 EBP: f39f3d34 ESP: f39f3d2c DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process insmod (pid: 1778, ti=f39f2000 task=f31472c0 task.ti=f39f2000) Stack: 72727563 f312c150 f39f3d44 c050a80f f312c150 f39f3d80 f39f3d54 c050a8f1 <0> f39f3d80 f312c150 f39f3d74 c050af25 f39f3d74 f39f3d80 f312c000 f39f3d80 <0> f312c150 fff4 f39f3d9c c050a48c f312c000 f312c000 Call Trace: [] ? sysfs_find_dirent+0x1b/0x2c [] ? __sysfs_add_one+0x18/0x72 [] ? sysfs_add_one+0x18/0xc2 [] ? sysfs_add_file_mode+0x4a/0x68 [] ? internal_create_group+0xbd/0x122 [] ? sysfs_create_group+0x11/0x16 [] ? ir_register_class+0x70/0xa2 [ir_core] [] ? ir_input_register+0x1ca/0x217 [ir_core] [] ? cx23888_ir_rx_s_parameters+0x283/0x28d [cx23885] [] ? mutex_lock+0x22/0x3c [] ? cx23885_input_init+0x241/0x27c [cx23885] [] ? cx23885_initdev+0xa40/0xa8c [cx23885] [] ? cx25840_s_frequency+0x0/0x1c [cx25840] [] ? local_pci_probe+0x13/0x15 [] ? pci_device_probe+0x48/0x6b [] ? driver_probe_device+0xbc/0x1b8 [] ? __driver_attach+0x48/0x64 [] ? bus_for_each_dev+0x42/0x6c [] ? driver_attach+0x19/0x1b [] ? __driver_attach+0x0/0x64 [] ? bus_add_driver+0xd0/0x211 [] ? kset_find_obj+0x23/0x4f [] ? driver_register+0x7e/0xe5 [] ? __pci_register_driver+0x3d/0x9a [] ? cx23885_init+0x0/0x29 [cx23885] [] ? cx23885_init+0x27/0x29 [cx23885] [] ? do_one_initcall
Kernel 2.6.29 breaks DVB-T ASUSTeK Tiger LNA Hybrid Capture Device
ASUSTeK Tiger LNA Hybrid Capture Device PCI - Analog/DVB-T card Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1) Works perfectly with kernel 2.6.28.4 (or older). Recently, I have switched to 2.6.29 (same .config as 2.6.28.4) and now, at boot time, I get the message: IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs Signal strength is very low and Kaffeine is unable to tune in any channel. Same problem with kernel 2.6.29.1 - Messages from /var/log/dmesg saa7134 :03:0a.0: PCI INT A -> Link[APC3] -> GSI 18 (level, low) -> \ IRQ 18 saa7133[0]: found at :03:0a.0, rev: 209, irq: 18, latency: 32, mmio: \ 0xfdefe000 saa7133[0]: subsystem: 1043:4871, board: ASUS P7131 4871 \ [card=111,autodetected] saa7133[0]: board init: gpio is 0 IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]: i2c eeprom 00: 43 10 71 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 02 03 00 01 03 08 ff 00 cf ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 22 15 50 ff ff ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner' 2-004b: chip found @ 0x96 (saa7133[0]) tda829x 2-004b: setting tuner address to 61 tda829x 2-004b: type set to tda8290+75a saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 dvb_init() allocating 1 frontend DVB: registering new adapter (saa7133[0]) DVB: registering adapter 0 frontend -32769 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 48MHz sampling clock tda1004x: timeout waiting for DSP ready tda1004x: found firmware revision 0 -- invalid tda1004x: trying to boot from eeprom tda1004x: timeout waiting for DSP ready tda1004x: found firmware revision 0 -- invalid tda1004x: waiting for firmware upload... saa7134 :03:0a.0: firmware: requesting dvb-fe-tda10046.fw tda1004x: found firmware revision 29 -- ok saa7134 ALSA driver for DMA sound loaded IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]/alsa: saa7133[0] at 0xfdefe000 irq 18 registered as card -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
