Re: HauppaugeTV-quadHD DVB-T mpeg risc op code errors
On Sun, Jul 30, 2017 at 8:55 AM, Dave Newman wrote: > I can confirm the problems with the cx23885 driver reported by Steven > Toth on 6 June 2017. He found that: > >> I tried the card in a different older Intel i7 board and it worked >> flawlessly. I then started to wonder if it was some new >> incompatibility introduced with Kaby Lake. I had tweaked the UEFI >> settings on the new Kaby Lake board to enable VT-d/VT-x since I wanted >> to run Linux as a host OS with Windows 10 running on top of qemu/KVM. >> Upon resetting the UEFI settings to their defaults (VT-d/VT-x >> disabled) the card worked without issue. > > Like him: > > - I have a recent Hauppauge WinTV-quadHD TV tuner PCIe card > > - I have a new fast multi-processor CPU. He found that there were no > problems on > > - Enabling debug output for the cx23885 driver *fixes* the issue > (options cx23885 debug=5), letting me run a scan of DVB channels. > > Unlike him: > > - my CPU is an 8 core Ryzen 1700 on a new Gigabyte AB350 motherboard. > > - turning off iommu does not fix the problem. > > I do not know the cx23885 code well enough to propose any patches, but I > am happy to do debugging and testing. One thing I noticed is that > i2cdetect output differs from that on > https://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-quadHD_(DVB-T/T2/C). > E.g. > > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f > 60: -- -- -- -- UU -- UU -- -- -- -- -- -- -- -- -- > 70: -- -- -- -- -- -- -- -- > > Anything from 60 and above is listed as UU. > > The motherboard is known to have problems with chained IRQs, so the latest > Ubuntu kernels use independent IRQs to avoid an interrupt storm on IRQ 7. > > Apart from that, let me know what else I should test. David, thanks for the report. Just to be clear, I didn't report the original issue, I merely attempted to repro it on a Sandy Bridge quad core. I'm the original cx23885/8 Linux driver developer, so I know the hardware well and have a vested interested in chasing down any obvious problems. I was unable to repro the issue. That being said, another user reported success after disabling VT-d/VT-x. Have you tried that? - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com
Re: [PATCH] Hauppauge HVR-1975 support
> Yes - it's a 1:1 forward port of the patch Hauppauge released for 3.19 > (apparently with the goal to support as many of their devices as > possible). Agreed. > >> the patch also contains materials that I >> suspect Silicon Labs would consider proprietary and confidential, its >> definitely derived works from proprietary SILABS drivers. > > Does anyone know for sure what the legal situation is when a HW > manufacturer releases a patch (as Hauppauge did) that is clearly > derived from GPL code yet at the same time derived from non-free code? > My interpretation is that by putting it out, they've released a GPL > derived work, which they can legally do only if they agree to comply > with the GPL, therefore any other license notice would be void. > But as I pointed out before I'm not a lawyer... You've raised a valid question, I don't know the answer. Others might. I'm not a lawyer either, but if Hauppauge are not careful then they may be violating an NDA, especially as the patch doesn't appear to come with a sign-off, and leans very heavily on intellectual property of Silicon Labs. I think in its current format the patch probably wouldn't be acceptable for merge unless Hauppauge themselves provide a sign-off. Side note: obviously the fact it's such a large patch would require it to be split into patches to each sub-system/card, but that's largely beside the point of my larger concern. Perhaps Hauppauge have legal approval to derive GPL drivers from proprietary ,aterials, in which case I'm just making noise and a sign-off will be soon to follow. I'll reach out to them and ask. -- Steven Toth - Kernel Labs http://www.kernellabs.com
Re: [PATCH] Hauppauge HVR-1975 support
(Resending)
Bernhard, thank you for sharing.
Mauro,
I've reviewed this patch, it has a host of problems.
Ignoring the fact it contains patches to all sorts of different cards
(saa7164, CX231xx, PVR-USB2)... the patch also contains materials that
I suspect Silicon Labs would consider proprietary and confidential,
its definitely derived works from proprietary SILABS drivers.
Proceed with caution.
- Steve
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
On Mon, Jul 3, 2017 at 5:57 AM, Bernhard Rosenkränzer
wrote:
> Hi,
> Hauppauge HVR-1975 is a USB DVB receiver box,
> http://www.hauppauge.co.uk/site/products/data_hvr1900.html
>
> It is currently not supported by v4l; Hauppauge provides a patch for
> kernel 3.19 at http://www.hauppauge.com/site/support/linux.html
>
> As expected, the patch doesn't work with more recent kernels, so I've
> ported it (verified to work on 4.11.8). Due to the size of the patch,
> I've uploaded my patch to
> http://lindev.ch/hauppauge-hvr-1975.patch
>
> While it works well, there's a potential license problem in one of the files:
> From drivers/media/dvb-frontend/silg.c:
>
> /* MODULE_LICENSE("Proprietary"); */
> /* GPL discussion for silg not finished. Set to GPL for internal usage only.
> */
> /* The module uses GPL functions and is rejected by the kernel build if the */
> /* license is set to 'Proprietary'. */
> MODULE_LICENSE("GPL");
>
> I'm not a lawyer, but my understanding is that by Hauppauge actually
> releasing that file to the public (and it being so clearly a derivate
> of GPL code that they even have to acknowledge it), their claim that
> it is anything but GPL is null and void - but we may have to make
> sure.
>
> ttyl
> bero
Re: HauppaugeTV-quadHD DVB-T mpeg risc op code errors
> One thing I was able to determine is that it appears to be related to > Intel VT-d/VT-x or whatever Intel's IOMMU/x86 virtualisation tech > thing is called. > > I tried the card in a different older Intel i7 board and it worked > flawlessly. I then started to wonder if it was some new > incompatibility introduced with Kaby Lake. I had tweaked the UEFI > settings on the new Kaby Lake board to enable VT-d/VT-x since I wanted > to run Linux as a host OS with Windows 10 running on top of qemu/KVM. > Upon resetting the UEFI settings to their defaults (VT-d/VT-x > disabled) the card worked without issue. Nice follow up, thx. That probably explains why I never saw the issues during my testing a few weeks ago then. -- Steven Toth - Kernel Labs http://www.kernellabs.com
Re: [GIT PULL] [PATCH] saa7164: Bug - Double fetch PCIe access condition
> Applied, thanks! Yay! > > Next time, please either send as a patch or use the command: > > $ git request-pull > > As otherwise I may miss it, as patchwork won't get it. Will do, thank you. -- Steven Toth - Kernel Labs http://www.kernellabs.com
Re: HauppaugeTV-quadHD DVB-T mpeg risc op code errors
On Fri, Apr 21, 2017 at 7:57 AM, Steven Toth wrote: >> Just a follow up on this. I had a bit more time to dig deeper into this >> today. >> >> Enabling debug output for the cx23885 driver *fixes* the issue. >> >> I added this to my kernel command line: cx23885.debug=8 > > The driver's been around a very long time and is very stable with > almost anything anyone has every added, or I originally added during > the early development. That being said. this sounds like the quad > is producing some kind of race condition, or the PLX bridge is in > someway not as transparent as everyone would like. I happen to have tip installed on a dev box, so I thought I'd install a quad-hd and test for the issues you'd mentioned. I do not see any of the issues you are describing, regardless of whether I tested with w_scan, tzap, dvbtraffic. No unusual module options used, everything 'default'. Everything looks fine to me, no fault found, Ubuntu 16.04 Kernel 4.12-rc1, 64bit. -- Steven Toth - Kernel Labs http://www.kernellabs.com
[GIT PULL] [PATCH] saa7164: Bug - Double fetch PCIe access condition
Mauro, A single commit. https://github.com/stoth68000/media-tree/commit/354dd3924a2e43806774953de536257548b5002c This pull request addresses the concern raised by Pengfei Wang via https://bugzilla.kernel.org/show_bug.cgi?id=195559 I've tested this patch with two different SAA7164 based cards in both analog and digital television modes for US and Europe, no regressions were found. $ git diff --stat master drivers/media/pci/saa7164/saa7164-bus.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) Thanks! - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com
Re: [PATCH 1/3] [media] si2157: get chip id during probing
>> ep: 81 l:9 08260080ff5901 >> >> here you see all the from the device. You need to be able to see the traffic on the physical I2C bus in order to help diagnose issues like this. You're going to want to see ACKS/NAKS, clocks and other I2C bus activity. You'll need to solder down scl/sda/gnd wiring to the PCB, I generally attached to the eeprom which tends to have larger pins (details on their respective datasheets). It's not hard to do, but does require a small investment in hardware. One the actual bus behavior is documented and understood, you'll likely get a better technical discussion going on. Send me a detailed picture of the PCB and I can probably help spot the I2C bus for you, if you have a low cost bus analyzer and a soldering iron. -- Steven Toth - Kernel Labs http://www.kernellabs.com
Re: HauppaugeTV-quadHD DVB-T mpeg risc op code errors
> Just a follow up on this. I had a bit more time to dig deeper into this today. > > Enabling debug output for the cx23885 driver *fixes* the issue. > > I added this to my kernel command line: cx23885.debug=8 The driver's been around a very long time and is very stable with almost anything anyone has every added, or I originally added during the early development. That being said. this sounds like the quad is producing some kind of race condition, or the PLX bridge is in someway not as transparent as everyone would like. -- Steven Toth - Kernel Labs http://www.kernellabs.com
Re: Broken cx231xx-i2c.c
On Wed, Jan 11, 2017 at 9:39 AM, Oleh Kravchenko wrote: > Hello! > > So, I tried to split i2c send messages to 5, 8, 16 bytes - that cause error: > cx231xx 3-1:1.1: cx231xx_send_usb_command: failed with status --32 > > This problem occurred only with Si2158 tuner, > demodulator Si2168 eats up to 15 bytes per i2c message. > > I think problem in cx231xx_send_vendor_cmd() function. > It's split reading, but not writing. > > PS: I use USB sniffer to capture traffic, please find it in attachment. Do you have a logic analyzer so you can inspect the I2C bus state? I'm speaking as someone who's done significant reverse engineering projects on many pieces of hardware, you'll get a much better understanding of platform specific I2C problems if you can see the bus directly. Any such issues tend to propagate upwards through micro-controller interfaces (cx231xx) and its much more obvious to deal with the controller problem when the state of the bus is absolutely known. I have no objections to a I2C bus controller implementation splitting reads and writes in a uniform and generic way, assuming windows is doing the same thing, providing that approach applies to all attached devices. We don't want board specific hacks infecting the various drivers. unless we're absolutely clear as to why.. and we don't want to see I2C controller limitations infecting I2C demod/tuner drivers where at all possible. If its true that send_vendor_cmd() splits reads but not writes, fix the function to be uniform for all boards. Don't do boards specific overrides. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] cx231xx: Initial support Evromedia USB Full Hybrid Full HD
On Wed, Jan 11, 2017 at 9:00 AM, Oleh Kravchenko wrote:
> On 11.01.17 15:53, Steven Toth wrote:
>>> diff --git a/drivers/media/usb/cx231xx/cx231xx-i2c.c
>>> b/drivers/media/usb/cx231xx/cx231xx-i2c.c
>>> index 35e9acf..60412ec 100644
>>> --- a/drivers/media/usb/cx231xx/cx231xx-i2c.c
>>> +++ b/drivers/media/usb/cx231xx/cx231xx-i2c.c
>>> @@ -171,6 +171,43 @@ static int cx231xx_i2c_send_bytes(struct i2c_adapter
>>> *i2c_adap,
>>> bus->i2c_nostop = 0;
>>> bus->i2c_reserve = 0;
>>>
>>> + } else if (dev->model == CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD
>>> + && msg->addr == dev->tuner_addr
>>> + && msg->len > 4) {
>>> + /* special case for Evromedia USB Full Hybrid Full HD tuner
>>> chip */
>>> + size = msg->len;
>>> + saddr_len = 1;
>>> +
>>> + /* adjust the length to correct length */
>>> + size -= saddr_len;
>>> +
>>> + buf_ptr = (u8*)(msg->buf + 1);
>>> +
>>> + do {
>>> + /* prepare xfer_data struct */
>>> + req_data.dev_addr = msg->addr;
>>> + req_data.direction = msg->flags;
>>> + req_data.saddr_len = saddr_len;
>>> + req_data.saddr_dat = msg->buf[0];
>>> + req_data.buf_size = size > 4 ? 4 : size;
>>> + req_data.p_buffer = (u8*)(buf_ptr + loop * 4);
>>> +
>>> + bus->i2c_nostop = (size > 4) ? 1 : 0;
>>> + bus->i2c_reserve = (loop == 0) ? 0 : 1;
>>> +
>>> + /* usb send command */
>>> + status = dev->cx231xx_send_usb_command(bus,
>>> &req_data);
>>> + loop++;
>>> +
>>> + if (size >= 4) {
>>> + size -= 4;
>>> + } else {
>>> + size = 0;
>>> + }
>>> + } while (size > 0);
>>> +
>>> + bus->i2c_nostop = 0;
>>> + bus->i2c_reserve = 0;
>>> } else {/* regular case */
>>>
>>> /* prepare xfer_data struct */
>> If the i2c functionality is broken in some way, I suggest its fixed
>> first, along with a correct patch description, as a separate piece of
>> work. Lets not group this in with a board profile.
>>
>> Almost certainly we should never see a "if board == X" in any i2c
>> implementation without proper discussion.
>>
> I'm interested in accepting this patch :) What I should do?
Lets start the conversion with what's wrong with the current
implementation that prevents it from working with the new design.
Lets discuss the I2C needs of the parts you need to communicate with,
and why the current design is broken.
Then, lets think about a better solution.
A BOARD == X is the wrong solution to the problem.
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] cx231xx: Initial support Evromedia USB Full Hybrid Full HD
> diff --git a/drivers/media/usb/cx231xx/cx231xx-i2c.c
> b/drivers/media/usb/cx231xx/cx231xx-i2c.c
> index 35e9acf..60412ec 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-i2c.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-i2c.c
> @@ -171,6 +171,43 @@ static int cx231xx_i2c_send_bytes(struct i2c_adapter
> *i2c_adap,
> bus->i2c_nostop = 0;
> bus->i2c_reserve = 0;
>
> + } else if (dev->model == CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD
> + && msg->addr == dev->tuner_addr
> + && msg->len > 4) {
> + /* special case for Evromedia USB Full Hybrid Full HD tuner
> chip */
> + size = msg->len;
> + saddr_len = 1;
> +
> + /* adjust the length to correct length */
> + size -= saddr_len;
> +
> + buf_ptr = (u8*)(msg->buf + 1);
> +
> + do {
> + /* prepare xfer_data struct */
> + req_data.dev_addr = msg->addr;
> + req_data.direction = msg->flags;
> + req_data.saddr_len = saddr_len;
> + req_data.saddr_dat = msg->buf[0];
> + req_data.buf_size = size > 4 ? 4 : size;
> + req_data.p_buffer = (u8*)(buf_ptr + loop * 4);
> +
> + bus->i2c_nostop = (size > 4) ? 1 : 0;
> + bus->i2c_reserve = (loop == 0) ? 0 : 1;
> +
> + /* usb send command */
> + status = dev->cx231xx_send_usb_command(bus,
> &req_data);
> + loop++;
> +
> + if (size >= 4) {
> + size -= 4;
> + } else {
> + size = 0;
> + }
> + } while (size > 0);
> +
> + bus->i2c_nostop = 0;
> + bus->i2c_reserve = 0;
> } else {/* regular case */
>
> /* prepare xfer_data struct */
If the i2c functionality is broken in some way, I suggest its fixed
first, along with a correct patch description, as a separate piece of
work. Lets not group this in with a board profile.
Almost certainly we should never see a "if board == X" in any i2c
implementation without proper discussion.
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Memory freeing when dmabuf fds are exported with VIDIOC_EXPBUF
> That's a good question. On one extreme an application trying to allocate 32 > 50MB buffers would seem suspicious to me, but on the other hand it would be > difficult to answer the question in a way that can be translated into code. 8k video in the ARGB 8bit 4:4:4 colorspace, would need a 126MB per frame buffer. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] dvb_frontend: create a new ops to help returning signals in dB
> add a new ops that will allow tuners to better report the > dB level of its AGC logic to the demod drivers. As the maximum > gain may vary from tuner to tuner, we'll be reversing the > logic here: instead of reporting the gain, let's report the > attenuation. This way, converting from it to the legacy DVBv3 > way is trivial. It is also easy to adjust the level of > the received signal to dBm, as it is just a matter of adding > an offset at the demod and/or at the bridge driver. Mauro, Have you verified this work with a detailed spectrum analysis study? If so then please share. For example, by measuring the I/F out of various tuners in a mix of use cases, with and without the AGC being driven by any downstream demodulator? Also, taking into consideration any external LNA variance. I'm concerned that a tuner AGC Gain is a meaningless measurement and in practice demodulators don't actually care, and tuners don't implement their gain reporting capabilities correctly at all. This feels like a solution to a problem that doesn't exist. -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: Raw ATSC Stream Capture
> on how to do this online. Could someone please send me some info on > how to do this, or at least point me in the right direction? > > Oh, I'm using a Hauppauge HDR-955Q tuner. v4l2-ctl isn't used for ATSC transmissions, its generally used for analog TV only. Take a look at the 'azap' and 'dvbtraffic' tools. These are what you need. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dear TV card experts - I need you help
> But the legal parts are of no concern to us, and we are already aware > of potential legal complexities, especially in western countries, but > fortunately there are many other countries outside of the western > hemisphere. There is also plenty of internet based providers that > already offers this, albeit with a less than ideal quality of service. > So consider that a non issue for now. You might, I don't. Good luck! -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dear TV card experts - I need you help
> It occurs to me that someone who is so cavalier with not paying legal > royalties would be pretty unlikely to pay bills for the advice and > support. +1. Indeed. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dear TV card experts - I need you help
(Please don't reply privately, keep all correspondence to this mailing list.) > Let me start of by presenting myself. I am a Computer Engineer and a > business man, looking to launch a service where TV channels from > primarily satellites will be made available to the public. You and 2 million other entrepreneurs, past, present and future. In most western countries, It's illegal to randomly redistribute television content unless you have specific paid-for negotiated rights with the content providers and the broadcasters. You should start by studying the law and contacting the content owners, negotiating contracts and seeking permission. Solve the legal contract / redistribution first, then the technology to make it happen is easily available. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cobalt & dma
> Is the cobalt or other pci v4l device have the chip datasheet > available so that we can do a reverse engineering and gain more > understanding about the register read/write for the dma transactions ? > I made a search but it seems that the PCIe chip datasheet for these > devices is not available anywhere. Generally you wouldn't need it, and I'm not sure it would help having it. Get to grips with the fundamentals and don't worry about cobalt registers. DMA programming is highly chip specific, but in general terms its highly similar in concept on any PCIe controller. Every driver+controller uses virtual/physical bus addresses that need to be understood, scatter gather list created and programmed into the h/w, interrupts serviced, buffer/transfer completion identification and transfer sizes. Look hard enough at any of the PCI/E drivers in the media tree and you'll see each of them implementing their own versions of the above. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
>> Hans is absolutely correct, don't make the mistake of going >> proprietary with your API. Take advantage of the massive amount of > Thank you very much for these valuable comments. > If I may ask one more on this issue: > Is there an example in linux tree, for a pci device which is used both > as a capture and a display device ? (I've made a search but did not > find any) > The PCIe device we are using will be both a capture device and output > video device (for display). An in-kernel open source PCIe device that you can feed frames (and presumably audio), have the device render and capture? Not that I'm aware of. I've done these kinds of driver projects in the past, on a commercial basis, for our clients. Contact me off list if you're looking for help. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
> No, use V4L2. What you do with the frame after it has been captured > into memory has no relevance to the API you use to capture into memory. Ran, I've built many open and closed source Linux drivers over the last 10 years - so I can speak with authority on this. Hans is absolutely correct, don't make the mistake of going proprietary with your API. Take advantage of the massive amount of video related frameworks the kernel has to offer. It will get you to market faster, assuming your goal is to build a driver that is open source. If your licensing prohibits an open source driver solution, you'll have no choice but to build your own proprietary API. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
On Mon, Oct 5, 2015 at 11:26 AM, Richard Tresidder wrote: > stage 1.. > Yep it works with accessing src directly.. had to reboot to verify that one. > Well at least the download says it worked and the image booted successfully. > > excuse my manual diff method.. > git and I don't agree... not sure how to get it to diff the media_build repo > I pulled the code from.. > my brain is stuck in subversion mode.. > > Still rebuilding the kernel to check the i2c Mux issue.. Good, that's the patch I had in mind. Thanks. Yes, you'd need to issue a complete PCIe reset (warm or cold boot) for the risc processor to reset, and for it to require a firmware to be loaded again. So, your comments make sense. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
>> Do you have a large number of other devices / drivers loaded? I >> suspect another driver is burning through kernel memory before the >> saa7164 has a chance to be initialized. > > Nope nothing I can see Its actually the only addon card I have in this > system.. > I'd be buggered If 4GB of RAM is fragmented enough early on in the boot > stage...? I agree. > I've hunted but can't find a nice way to determine what contiguous blocks > are available.. > Noted there was a simple module that could be compiled in to test such > things, I'll play with that and see what it turns up.. Let us know how that goes. > >> I took a quick look at saa7164-fw.c this morning, I see no reason why >> the allocation is required at all. With a small patch the function >> could be made to memcpy from 'src' directly, dropping the need to >> allocate srcbuf what-so-ever. This would remove the need for the 4MB >> temporary allocation, and might get you past this issue, likely on to >> the next (user buffer allocations are also large - as I recall). Note >> that the 4MB allocation is temporary, so its not a long term saving, >> but it might get you past the hump. > > That was my thoughts exactly.. but I took a minimal fiddling approach to > begin with.. > I wasn't sure if there was some requirement for the memcpy_toio requiring a > specially allocated source..? can't see why.. > Was going to dig into that next as a side job.. At this stage the code is 7-8 years old, so I don't recall the rationale for why I did that back in 2008(?) - but looking at it today, I think its needless and its a fairly trivial thing to remove and test. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
On Sun, Oct 4, 2015 at 9:59 PM, Richard Tresidder wrote: > Hi Steven >Nope standard x86_64 > kernel 3.10.0-229.14.1.el7.x86_64 Hmm. > > Was rather surprised as all my quick reading indicates that the kernel > should quite happily do this... > Though looks like its the largest chunk you can request? I'm not well enough > up to speed with the nitty gritty.. Yeah, 4MB is the upper limit IIRC. > > There is mention of something similar against this card on www linuxtv org > wiki index.php Hauppauge_WinTV-HVR-2200 > > > Note: Some kernels will not have enough free memory available for the > driver. The dmesg error will start with a message like this: > ] modprobe: page allocation failure: order:10, mode:0x2000d0 > followed by a stack trace and other debugging information. While the driver > will load, no devices will be registered. > The simple workaround is to allocate more memory for the kernel: > sudo /bin/echo 16384 > /proc/sys/vm/min_free_kbytes > sudo rmmod saa7164 > sudo modprobe saa7164 > Hmm. I wasn't aware people in the past has seen the issue either. I assume you've tried the above and its not helping, or in fact growing that number for experimentation purposes. Do you have a large number of other devices / drivers loaded? I suspect another driver is burning through kernel memory before the saa7164 has a chance to be initialized. I took a quick look at saa7164-fw.c this morning, I see no reason why the allocation is required at all. With a small patch the function could be made to memcpy from 'src' directly, dropping the need to allocate srcbuf what-so-ever. This would remove the need for the 4MB temporary allocation, and might get you past this issue, likely on to the next (user buffer allocations are also large - as I recall). Note that the 4MB allocation is temporary, so its not a long term saving, but it might get you past the hump. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
> Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c was failing.. > kept getting: kernel: modprobe: page allocation failure: order:10, > mode:0x10c0d0 I don't think I've ever seen or heard of that in the entire history of the driver. Are you running on traditional x86/x86 hardware, or something embedded/custom? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] saa7164: convert to the control framework
>>> but the default firmware with size 4919072 fails to work (image corrupt), >>> instead >>> I need to use the firmware with size 4038864 (v4l-saa7164-1.0.3-3.fw). >>> >>> For that I have to patch the driver. >> >> Take a look at your board, on the main large PCIe IC, its probably >> marked as either a REV2 or a REV3, or a -02 or -03, what do you have? >> >> I suspect you have a rev-02 chip. Not many of them go out into >> production. (A few thousand, compared to significantly more -03 >> chips). > > The text on the chip is: > > SAA7164E/2 > P60962.00 10 > ESG07271Y > > I suspect the /2 means REV2. Correct, thanks for confirming. I'll look into this. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] saa7164: convert to the control framework
>> but the default firmware with size 4919072 fails to work (image corrupt), >> instead >> I need to use the firmware with size 4038864 (v4l-saa7164-1.0.3-3.fw). > > That's v4l-saa7164-1.0.2-3.fw, sorry for the confusion. Right, you need to load the -02 firmware on a -02 board. > > Googling suggests that you have patches for this that never made it upstream. > Can you post it? I will. If you can confirm you have a -02 PCIe IC then I'll prep some firmware patches for testing. To be clear, I think the current in kernel tree is perfectly good for all -03 boards. For -02 boards (fewer of these in the field) it may be a problem, but I'll fix. I also plan to test the control framework changes, and the compliance patches (thanks btw). -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] saa7164: convert to the control framework
>> Send me your shipping address _privately_, I talk to Hauppauge about a >> replacement. >> > > No need, I managed to get it working if I use a PCI-to-PCIe adapter card. Very > strange, it won't work in the PCIe slot of my motherboard, but using the PCI > slot > and that adapter it works fine. Excellent. > > It's good that it was tested since the menu control creation code was wrong. Ahh. > > One thing that is very confusing to me: I have this board: > > [ 1878.280918] CORE saa7164[0]: subsystem: 0070:8900, board: Hauppauge > WinTV-HVR2200 [card=5,autodetected] > [ 1878.280928] saa7164[0]/0: found at :09:00.0, rev: 129, irq: 18, > latency: 0, mmio: 0xfb80 > [ 1878.327399] tveeprom 14-: Hauppauge model 89519, rev B2F2, serial# > 4029789519 > [ 1878.327405] tveeprom 14-: MAC address is 00:0d:fe:31:b5:4f > [ 1878.327409] tveeprom 14-: tuner model is NXP 18271C2_716x (idx 152, > type 4) > [ 1878.327413] tveeprom 14-: TV standards PAL(B/G) NTSC(M) PAL(I) > SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc) > [ 1878.327416] tveeprom 14-: audio processor is SAA7164 (idx 43) > [ 1878.327418] tveeprom 14-: decoder processor is CX23887A (idx 39) > [ 1878.327420] tveeprom 14-: has radio > [ 1878.327423] saa7164[0]: Hauppauge eeprom: model=89519 > > but the default firmware with size 4919072 fails to work (image corrupt), > instead > I need to use the firmware with size 4038864 (v4l-saa7164-1.0.3-3.fw). > > For that I have to patch the driver. Take a look at your board, on the main large PCIe IC, its probably marked as either a REV2 or a REV3, or a -02 or -03, what do you have? I suspect you have a rev-02 chip. Not many of them go out into production. (A few thousand, compared to significantly more -03 chips). > > Do you have an overview of which firmware is for which board? Generally, for a long time, I was recommending that everyone run NXP7164-2010-03-10.1.fw, this is actually the latest firmware. I've been told it isn't reliable on the REV2 hardware though. I'll go back to the windows driver and check how they're making the firmware load decision. I can bring this logic into the Linux driver and we can load the most appropriate f/w. > > There are a bunch of firmwares here: > > http://www.steventoth.net/linux/hvr22xx/firmwares > > but there are no instructions or an overview of which should be used. If the stock -inkernel driver is wrong for the -02 then we should fix that. It should be fine for the -03 though. > > I faintly remember asking you this before, but that's been a long time ago > and I can't find it in my mail archive. > > I'm willing to do some driver cleanup and fix v4l2-compliance issues, but > I'd really like to fix this firmware issue first. Noted. > > Regards, > > Hans Best, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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] saa7164: convert to the control framework
>>>> Has anyone tested the patch and validated each of the controls continue to >>>> work? >>> >>> As I said: my saa7146 card is no longer recognized (not sure why), so I was >>> hoping >>> you could test it. >> >> OK, will do. I probably won't get to this until the weekend, but I'll >> put this on my todo list. > > That's OK, there is no hurry. I tried to put my saa7164 in a different PC as > well, > but it seems to be really broken as nothing appears in lspci :-( Send me your shipping address _privately_, I talk to Hauppauge about a replacement. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] saa7164: convert to the control framework
On Sat, Aug 22, 2015 at 8:46 AM, Hans Verkuil wrote: > On 08/22/2015 02:06 PM, Steven Toth wrote: >> On Sat, Aug 22, 2015 at 6:47 AM, Hans Verkuil wrote: >>> On 08/22/2015 09:24 AM, Ricardo Ribalda Delgado wrote: >>>> Hello Hans >>>> >>>> With this patch I guess two of my previous patches are not needed. >>>> Shall i resend the patchset or you just cherry pick the appropriate >>>> ones? >>> >>> Let's see how long it takes before I get an Ack (or not) from Steve. If >>> that's >>> quick, then you can incorporate my patch in your patch series, if it takes >>> longer (I know he's busy), then we can proceed with your patch series and >>> I'll >>> rebase on top of that later. >> >> Hans, thanks for the work here. >> >> I've skimmed the patch buts its too much to eyeball to give a direct ack. >> >> Has anyone tested the patch and validated each of the controls continue to >> work? > > As I said: my saa7146 card is no longer recognized (not sure why), so I was > hoping > you could test it. OK, will do. I probably won't get to this until the weekend, but I'll put this on my todo list. Thx. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] saa7164: convert to the control framework
On Sat, Aug 22, 2015 at 6:47 AM, Hans Verkuil wrote: > On 08/22/2015 09:24 AM, Ricardo Ribalda Delgado wrote: >> Hello Hans >> >> With this patch I guess two of my previous patches are not needed. >> Shall i resend the patchset or you just cherry pick the appropriate >> ones? > > Let's see how long it takes before I get an Ack (or not) from Steve. If that's > quick, then you can incorporate my patch in your patch series, if it takes > longer (I know he's busy), then we can proceed with your patch series and I'll > rebase on top of that later. Hans, thanks for the work here. I've skimmed the patch buts its too much to eyeball to give a direct ack. Has anyone tested the patch and validated each of the controls continue to work? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
>> What happens if you revert this back to the code from my original >> patch, and include your changes listed below? >> >> IE: >> /* Tri-state the TS bus */ >> si2168_set_ts_mode(fe, 1); >> >> 1) Do you still lock no signal lock issues. > > MythTV says 'no lock' (though I don't know if such a message is reliable) >> >> 2) Do you see normal video as you'd typically expect? > > Nope, just a black screen. > Did not test it with TVheadend. > However, in MythTV (0.27.4) the line > > si2168_set_ts_mode(fe, 0); > > makes it work. >> >> >> Thanks for helping! :) >> > You're welcome. Thx. I'll spin up a couple of other si2168 boards I have and look at their status, pre-post patch. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Wed, Jul 22, 2015 at 3:15 AM, Tycho Lürsen wrote: > Hi Steven, > I'm happy to inform you that all failures have vanished. Thanks. > > Summarizing: > I compiled 4.2-RC3 with your patch and with > > /* Tri-state the TS bus */ > si2168_set_ts_mode(fe, 0); What happens if you revert this back to the code from my original patch, and include your changes listed below? IE: /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 1); 1) Do you still lock no signal lock issues. 2) Do you see normal video as you'd typically expect? Thanks for helping! :) -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Tue, Jul 21, 2015 at 2:59 PM, Tycho Lürsen wrote: > > > Op 21-07-15 om 20:07 schreef Tycho Lürsen: >> >> >> >> Op 21-07-15 om 18:19 schreef Steven Toth: >>> >>> On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen >>> wrote: >>>> >>>> Hi Steven, >>>> I was too curious to wait for you and Antti to settle your differences, >>>> so I >>>> tested again against a 4.2-RC2 >>>> I did not disable DVB-T/T2, instead I reordered the lot. MythTV just >>>> sees >>>> the first system in the .delsys line in si2168.c, >>>> so when it looks like this: >>>> SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 >>>> I'm good. >>> >>> We have no differences, its Antti's si2168 driver. If Antti doesn't >>> like the approach for tri-stating, he's free to suggest and >>> alternative. I suggested two alternatives yesterday. >>> >>>> Result: >>>> With your patch both MythTV and Tvheadend still can't tune. Without it, >>>> everything is ok. >>>> >>>> I'm not very interested in czap results, only in real use cases. For me >>>> that's MythTV, but just to be sure I also tested with TVheadend. >>> >>> That's pretty bizarre results, although thank you for testing. :) >>> >>> When you say it can't tune, do you mean the signal does not lock, or >>> that no video appears? >>> >> No lock, or partial lock. > > I've compiled a 4.2-RC3, this time without support for my TBS 6285 cards (so > no saa716x) and without dvbloopback kernel module (so no MythTV) > > > Result with your patch and only DVBSky T982 cards: TVheadend is fine with > it. Lock and tune are OK. > Going to test some more scenario's, I'll keep you informed. > Regards, > Tycho Thank you sir. In which case, please disregard my last email relating to changing: /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 1); - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Tue, Jul 21, 2015 at 2:07 PM, Tycho Lürsen wrote: > > > Op 21-07-15 om 18:19 schreef Steven Toth: >> >> On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen >> wrote: >>> >>> Hi Steven, >>> I was too curious to wait for you and Antti to settle your differences, >>> so I >>> tested again against a 4.2-RC2 >>> I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees >>> the first system in the .delsys line in si2168.c, >>> so when it looks like this: >>> SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 >>> I'm good. >> >> We have no differences, its Antti's si2168 driver. If Antti doesn't >> like the approach for tri-stating, he's free to suggest and >> alternative. I suggested two alternatives yesterday. >> >>> Result: >>> With your patch both MythTV and Tvheadend still can't tune. Without it, >>> everything is ok. >>> >>> I'm not very interested in czap results, only in real use cases. For me >>> that's MythTV, but just to be sure I also tested with TVheadend. >> >> That's pretty bizarre results, although thank you for testing. :) >> >> When you say it can't tune, do you mean the signal does not lock, or >> that no video appears? >> > No lock, or partial lock. Thanks. That's even worse than expected, given that the patch adjusts the TS interface, and has nothing to do with tuning, lock, rf or signal status. It still feels like something else is going on, some other unexpected race for example. I can't reproduce that behavior, but given that you can Can you please try this? in si2168.c, change: /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 1); to /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 0); ... recompile and retest? Thx. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen wrote: > Hi Steven, > I was too curious to wait for you and Antti to settle your differences, so I > tested again against a 4.2-RC2 > I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees > the first system in the .delsys line in si2168.c, > so when it looks like this: > SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 > I'm good. We have no differences, its Antti's si2168 driver. If Antti doesn't like the approach for tri-stating, he's free to suggest and alternative. I suggested two alternatives yesterday. > > Result: > With your patch both MythTV and Tvheadend still can't tune. Without it, > everything is ok. > > I'm not very interested in czap results, only in real use cases. For me > that's MythTV, but just to be sure I also tested with TVheadend. That's pretty bizarre results, although thank you for testing. :) When you say it can't tune, do you mean the signal does not lock, or that no video appears? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
>> We can agree or disagree about whether a part should be tri-stated in >> init/sleep() and under what circumstances, but why bother when someone >> has gone to the trouble of declaring a perfectly good tr-state >> interface in dvb-core, taht automatically asserts and de-asserts any >> dvb_frontend device from the bus, optionally. > > > Because I simply don't want to any new demod users for that callback unless > needed for some strange reason. I see, I understand your concern, perhaps you should have raised this in your first response. Are you the maintainer for dvb-core now? So two options come to mind: 1. The si2168_init() brings the part onto the bus, and _sleep() takes the device off the bus, regardless? Any by default, the device is not on the bus after attach takes place. 2. The bridge specifically calls ts_bus_control() on the si2168 fe ops, as and when the bridge requires it? This feels like a reasonable middle-ground approach. Your thoughts? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Mon, Jul 20, 2015 at 12:54 PM, Antti Palosaari wrote: > On 07/20/2015 07:45 PM, Devin Heitmueller wrote: >>> >>> Look at the em28xx driver and you will probably see why it does not work >>> as >>> expected. For my eyes, according to em28xx driver, it looks like that bus >>> control is aimed for bridge driver. You or em28xx is wrong. >> >> >> Neither are wrong. In some cases the call needs to be intercepted by >> the frontend in order to disable its TS output. In other cases it >> needs to be intercepted by the bridge to control a MUX chip which >> dictates which demodulator's TS output to route from (typically by >> toggling a GPIO). > > > Quickly looking the existing use cases and I found only lgdt3306a demod > which uses that callback to control its TS interface. All the rest seems to > be somehow more related to bridge driver, mostly changing bridge TS IF or > leds etc. The API is flexible enough to be used by either the bridge intercepting the dvb_frontent_open operation, or by allowing the demodulator itself to act upon it. The API itself specifically describes the "TS BUS CONTROL" access, and whether something upstream of the demodulator wants a downstream device attached, or detached from the transport electrical interface. I see little point adding more bridge glue to route each dvb frontend into the cx23885-bridge and making a judgement based on the board type, when dvb-core is already effectively doing this, and has been for sometime. The caveat to this, is if you find a use-case that breaks the current driver in the current tip kernel. I currently do not see that. > > I don't simply see that correct solution for disabling demod TS IF - there > is sleep() for this kind of things - and as I pointed out it does not even > work for me em28xx based device because em28xx uses that routine to switch > own TS mode. Asking a demodulator to sleep/wake is absolutely not the same thing as asking it to stop/start driving electrical signals on a bus. We can agree or disagree about whether a part should be tri-stated in init/sleep() and under what circumstances, but why bother when someone has gone to the trouble of declaring a perfectly good tr-state interface in dvb-core, taht automatically asserts and de-asserts any dvb_frontend device from the bus, optionally. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Mon, Jul 20, 2015 at 12:06 PM, Tycho Lürsen wrote: > Hi Steven, > I was not aware of the fact that your patch depends on dvb-core as in > 4.2-RC2 (and up, I guess) > I tested against 3.18.18 and 4.1.2. That might explain the failures. > Anyhow, as soon as Antti and you are on the same page regarding this patch, > I'll test again against a 4.2-RC>1 > Regards, > Tycho. Thank you Tycho. I specifically only tested on 4.2, with the entire tree. No attempt was made to backport or otherwise test in environments outside on prior kernels. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com > > Op 20-07-15 om 15:13 schreef Steven Toth: >> >> On Sun, Jul 19, 2015 at 3:34 AM, Tycho Lürsen >> wrote: >>> >>> Hi Steven, >>> >>> Tested your si2186 patch with my DVBSky T982 and TBS 6285 cards using >>> European DVB-C >>> Since MythTV can't handle multistandard frontends (yet), I've disabled >>> DVB-T/T2 like this (I always do that): >>> >>> sed -i 's/SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A/SYS_DVBC_ANNEX_A/' >>> drivers/media/dvb-frontends/si2168.c >>> >>> Result: both DVBSky T982 and TBS 6285 drivers are broken, meaning no >>> lock, >>> no tune. >>> >>> Regards, >>> Tycho. >>> >>> Op 19-07-15 om 00:21 schreef Steven Toth: >>>> >>>> http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275 >>>> >>>> Patches above are available for test. >>>> >>>> Antti, note the change to SI2168 to add support for enabling and >>>> disabling the SI2168 transport bus dynamically. >>>> >>>> I've tested with a combo card, switching back and forward between QAM >>>> and DVB-T, this works fine, just remember to select a different >>>> frontend as we have two frontends on the same adapter, >>>> adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2. >>>> >>>> If any testers have the ATSC or DVB-T, I'd expect these to work >>>> equally well, replease report feedback here. >>>> >>>> Thanks, >>>> >>>> - Steve >> >> Interesting, although I'm slightly confused. >> >> My patch mere added the ability for dvb-core to tri-state the tsport >> out bus, similar to other digital demodulator drivers in the tree >> and testing with both azap and tzap (and dvbtraffic) showed no tuning, >> lock or other issues. >> >> What happens if you tzap/czap a known good frequency, before and after >> my patch, without your sed replacement, leaving T/T2 and A fully >> enabled? >> >> - Steve >> > -- 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Mon, Jul 20, 2015 at 10:30 AM, Antti Palosaari wrote:
> On 07/19/2015 01:21 AM, Steven Toth wrote:
>>
>> http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275
>>
>> Patches above are available for test.
>>
>> Antti, note the change to SI2168 to add support for enabling and
>> disabling the SI2168 transport bus dynamically.
>>
>> I've tested with a combo card, switching back and forward between QAM
>> and DVB-T, this works fine, just remember to select a different
>> frontend as we have two frontends on the same adapter,
>> adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2.
>>
>> If any testers have the ATSC or DVB-T, I'd expect these to work
>> equally well, replease report feedback here.
>
>
> That does not work. I added debug to see what it does and result is that
> whole si2168_set_ts_mode() function is called only once - when frontend is
> opened first time. I used dvbv5-scan.
That works very reliably for me, in the 4.2 rc kernel, when using
azap, tzap and dvbtraffic. They're v3 api's of course, but dvb-core
should take care of the differences. Specifically, dvb_frontend.c
dvb_frontend_open() and dvb_frontend_release().
With additional debug added, I clearly saw the syncronization and
acquiring and releasing (via ts_bus_control) of the bus, with each
demodulator.
>
> I am not sure why you even want to that. Is it because of 2 demods are
> connected to same TS bus? So you want disable always another? Or is is just
> power-management, as leaving TS active leaks potentially some current.
Two demods are on the same bus, so we need to disable the non-active
demod, to ensure the active demodulator can correctly drive the
transport interface.
>
> Anyway, if you want control TS as runtime why you just don't add TS disable
> to si2168_sleep()? If you enable TS on si2168_init() then correct place to
> disable it is si2168_sleep().
That's what dvb-core does, today in:
dvb_frontend_open()
if (dvbdev->users == -1 && fe->ops.ts_bus_ctrl) {
if ((ret = fe->ops.ts_bus_ctrl(fe, 1)) < 0)
goto err0;
and in dvb_frontend_release()...
if (fe->ops.ts_bus_ctrl)
fe->ops.ts_bus_ctrl(fe, 0);
The first user of the device ensures ts_bus_control is called when its
enabled, bring the demodulator on to the bus.
The last user of the device ensures ts_bus_control is called when the
device is no longer required.
Why build tristating mode control into the demod specific driver when
its been supported in the core for a long time?
It won't prevent multiple callers from opening two different frontends
(0/1) at the same time, but lack of shared resource management has
been the case on dvb-core (and v4l2) for quite a while.
If you have use case that isn't working, I'm happy to discuss.
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Sun, Jul 19, 2015 at 3:34 AM, Tycho Lürsen wrote: > Hi Steven, > > Tested your si2186 patch with my DVBSky T982 and TBS 6285 cards using > European DVB-C > Since MythTV can't handle multistandard frontends (yet), I've disabled > DVB-T/T2 like this (I always do that): > > sed -i 's/SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A/SYS_DVBC_ANNEX_A/' > drivers/media/dvb-frontends/si2168.c > > Result: both DVBSky T982 and TBS 6285 drivers are broken, meaning no lock, > no tune. > > Regards, > Tycho. > > Op 19-07-15 om 00:21 schreef Steven Toth: >> >> http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275 >> >> Patches above are available for test. >> >> Antti, note the change to SI2168 to add support for enabling and >> disabling the SI2168 transport bus dynamically. >> >> I've tested with a combo card, switching back and forward between QAM >> and DVB-T, this works fine, just remember to select a different >> frontend as we have two frontends on the same adapter, >> adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2. >> >> If any testers have the ATSC or DVB-T, I'd expect these to work >> equally well, replease report feedback here. >> >> Thanks, >> >> - Steve Interesting, although I'm slightly confused. My patch mere added the ability for dvb-core to tri-state the tsport out bus, similar to other digital demodulator drivers in the tree and testing with both azap and tzap (and dvbtraffic) showed no tuning, lock or other issues. What happens if you tzap/czap a known good frequency, before and after my patch, without your sed replacement, leaving T/T2 and A fully enabled? - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Mon, Jul 20, 2015 at 2:00 AM, Tony Chang(Wincomm) wrote: > Dear : Steven > > Sorry for my poor english !! I don’t know how to install it > > According your feedback.. > > diff --git a/drivers/media/pci/cx23885/Kconfig > b/drivers/media/pci/cx23885/Kconfigindex 2e1b88c..3e6398f 100644 > > I don't how to use diff -- because can't see any drivers/media/ > > Please reference attached picture > > Is kernel not support ? > > Best Regards Tony / Jerry, You need to download the entire tree, based on branch hvr-1275, commit #91bd0a5bbbc3759bb3fd6516d8c322b030620b46, compile and install the entire kernel (which is a 4.2 rc). Its available for download from here: > http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275 After that it should be fine. The pictures you have show we're using the same hardware, but you're not running the newer kernel (including the new patches). - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275 Patches above are available for test. Antti, note the change to SI2168 to add support for enabling and disabling the SI2168 transport bus dynamically. I've tested with a combo card, switching back and forward between QAM and DVB-T, this works fine, just remember to select a different frontend as we have two frontends on the same adapter, adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2. If any testers have the ATSC or DVB-T, I'd expect these to work equally well, replease report feedback here. Thanks, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: www.kernellabs.com Contact: Hauppauge hvr1275 TV Tuner card linux problem
> Dear : Steven Toth > Thanks for your professional answer > Thanks a lot > Best Regards You are welcome! >> It looks like Hauppauge have released an updated HVR-1275 card, as >> indicated by the updated PCI-SubDevice ID 2A38. The hardware has >> changed and the driver needs to be modified to support these changes. >> >> Modprobing with option=19 isn't going to help. > > I've reached out to Hauppauge for comment on the new H/W. Stay tuned. A sample HVR-1275 arrived yesterday, thank you Hauppauge. I'll add driver support for this in the coming week, DTV only, its on my todo list. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: www.kernellabs.com Contact: Hauppauge hvr1275 TV Tuner card linux problem
>> sorry I don’t know how can I do .. can you help me to fix the >> problem? > > Please ensure that all communication include the linux media mailing list. > > It looks like Hauppauge have released an updated HVR-1275 card, as > indicated by the updated PCI-SubDevice ID 2A38. The hardware has > changed and the driver needs to be modified to support these changes. > > Modprobing with option=19 isn't going to help. I've reached out to Hauppauge for comment on the new H/W. Stay tuned. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: www.kernellabs.com Contact: Hauppauge hvr1275 TV Tuner card linux problem
Adding in the linux-media mailing list > Subject: > Hauppauge hvr1275 TV Tuner card linux problem > > Message: > I had one trouble about Hauppauge hvr1275 TV Tuner card > > Because of I want use tvtime app to play this TV Tuner card with ATI > V4900 VGA Card under centos 6.5 linux 2.6.32-431.el6.i686 > > First I have download Firmeare from: > > # wget > http://steventoth.net/linux/hvr1200/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip > > # wget http://steventoth.net/linux/hvr1200/extract.sh > > # /bin/sh extract.sh > > # sudo cp v4l-cx23885-enc.fw v4l-cx23885-avcore-01.fw > dvb-fe-tda10048-1.0.fw /lib/firmware > > Second create cx23885.conf in /etc/modprobe.d/ > > Options cx23885 card=19 > > Type modprobe cx23885 in terminal > > When I execute tvtime app always show can’t open /dev/video0 > > When I use dmesg in terminal show below > > Linux video capture interface: v2.00 > > cx23885 driver version 0.0.2 loaded > > cx23885 :04:00.0: PCI INT A -_ GSI 16 (level, low) -_ IRQ 16 > > CORE cx23885[0]: subsystem: 0070:2a38, board: Hauppauge WinTV-HVR1275 > [card=19,insmod option] > > IR NEC protocol handler initialized > > IR RC5(x) protocol handler initialized > > IR RC6 protocol handler initialized > > IR JVC protocol handler initialized > > IR Sony protocol handler initialized > > lirc_dev: IR Remote Control driver registered, major 248 > > IR LIRC bridge handler initialized > > tveeprom 11-0050: Hauppauge model 161100, rev A1I6, serial# 9140928 > > tveeprom 11-0050: MAC address is 00:0d:fe:8b:7a:c0 > > tveeprom 11-0050: tuner model is unknown (idx 186, type 4) > > tveeprom 11-0050: TV standards PAL(B/G) NTSC(M) PAL(I) SECAM(L/L') > PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc) > > tveeprom 11-0050: audio processor is CX23888 (idx 40) > > tveeprom 11-0050: decoder processor is CX23888 (idx 34) > > tveeprom 11-0050: has no radio, has IR receiver, has no IR > transmitter > > cx23885[0]: warning: unknown hauppauge model #161100 > > cx23885[0]: hauppauge eeprom: model=161100 > > cx23885_dvb_register() allocating 1 frontend(s) > > cx23885[0]: cx23885 based dvb card > > lgdt3305_attach: unable to detect LGDT3305 hardware > > cx23885[0]: frontend initialization failed > > cx23885_dvb_register() dvb_register failed err = -1 > > cx23885_dev_setup() Failed to register dvb on VID_C > > cx23885_dev_checkrevision() Hardware revision = 0xd0 > > cx23885[0]/0: found at :04:00.0, rev: 4, irq: 16, latency: 0, > mmio: 0xfbe0 > > cx23885 :04:00.0: setting latency timer to 64 > > alloc irq_desc for 34 on node -1 > > alloc kstat_irqs on node -1 > > if use dmesg | grep cx23885 in terminal show below > > cx23885 driver version 0.0.2 loaded > > cx23885 :05:00.0: PCI INT A -_ GSI 16 (level, low) -_ IRQ 16 > > CORE cx23885[0]: subsystem: 0070:2a38, board: Hauppauge WinTV-HVR1275 > [card=19,insmod option] > > cx23885[0]: warning: unknown hauppauge model #161100 > > cx23885[0]: hauppauge eeprom: model=161100 > > cx23885_dvb_register() allocating 1 frontend(s) > > cx23885[0]: cx23885 based dvb card > > cx23885[0]: frontend initialization failed > > cx23885_dvb_register() dvb_register failed err = -1 > > cx23885_dev_setup() Failed to register dvb on VID_C > > cx23885_dev_checkrevision() Hardware revision = 0xd0 > > cx23885[0]/0: found at :05:00.0, rev: 4, irq: 16, latency: 0, > mmio: 0xfbe0 > > cx23885 :05:00.0: setting latency timer to 64 > > cx23885 :05:00.0: irq 35 for MSI/MSI-X > > sorry I don’t know how can I do .. can you help me to fix the > problem? Please ensure that all communication include the linux media mailing list. It looks like Hauppauge have released an updated HVR-1275 card, as indicated by the updated PCI-SubDevice ID 2A38. The hardware has changed and the driver needs to be modified to support these changes. Modprobing with option=19 isn't going to help. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000C 0x14b4 status
>> An image of the top of the tuner clearly showing any manufacturing >> markings would be welcome - assuming its accessible. > > > It's a best picture I could find: > http://www.reviews.ru/clause/over/T7_2/image41.jpg Thanks. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000C 0x14b4 status
> Correct. These are not parts that have any form of default firmware > in their ROM mask (i.e. not like the silabs or micronas parts which > have a default firmware and the ability to patch the ROM via a > software loaded code update). The firmware must be loaded every time > the chip is brought out of reset or it won't work at all. An image of the top of the tuner clearly showing any manufacturing markings would be welcome - assuming its accessible. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Revert "[media] saa7164: Improvements for I2C handling"
On Sat, Jun 6, 2015 at 3:44 AM, Olli Salonen wrote: > This reverts commit ad90b6b0f10566d4a5546e27fe455ce3b5e6b6c7. > > This patch breaks I2C communication towards Si2168. After reverting and > applying the other patch in this series the I2C communication is > correct. Tested-By: Steven Toth Checked with a HVR-2205 and a HVR-2215, firmware loads as expected. Thanks for chasing this down Olli. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] saa7164: change Si2168 reglen to 0 bit
On Sat, Jun 6, 2015 at 3:44 AM, Olli Salonen wrote: > The i2c_reg_len for Si2168 should be 0 for correct I2C communication. > > Signed-off-by: Olli Salonen Tested-By: Steven Toth Checked with a HVR-2205 and a HVR-2215, firmware loads as expected. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge 2250 on Ubuntu 15.04
On Thu, Jun 11, 2015 at 2:58 PM, Jeff Allen wrote: > Thanks, I did that and it is working now. However, I ran into another > problem. The card will not scan any channels. I live in the Chicago area > and my cable provider is Wowway. Wowway requires a main set top box and > digital adapters for every other TV in the home. Cable ready TV's after > 2010 are suppose to work without the need for a digital adapter. I have a > feeling that the 2255 card I have will not work with my cable provider. > > Any thoughts? Cc'ing linux-media back in. I'm not aware of any US cable provider that the HVR2255 cannot tune/demodulate. I'd be highly surprised if your HVR2255 isn't delivering packets, unless its faulty. However, depending on your provider, those multiplexes may only contain encrypted tv channels - not watchable by you. I have a handful of channels from my provider that are watchable. 300+ are fully encrypted the data delivered by the card isn't that useful, for encrypted channels. I suggest you share the output from your scan tests with the mailing list and see if anyone can help. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][media] SI2168: Resolve unknown chip version errors with different HVR22x5 models
On Fri, Jun 5, 2015 at 9:40 AM, Olli Salonen wrote: > Hi Steven, > > It seems to me that that part of the code is identical to your driver, no? Sorry for the noise. I'm been swamped with a couple of things and just getting back to the ML now. You are correct. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge 2250 on Ubuntu 15.04
On Wed, Jun 10, 2015 at 1:23 PM, Jeff Allen wrote: > I am trying to get the firmware to load on a fresh install of Ubuntu 15.04 > desktop 64-bit on a new system. > > uname -a > Linux 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 > x86_64 x86_64 GNU/Linux That's not going to work. You need to pull tip, compile and install it for HVR2255 support. No amount of specifying card=X on the module load fixes these kinds of issues. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][media] SI2168: Resolve unknown chip version errors with different HVR22x5 models
On Thu, Jun 4, 2015 at 9:22 AM, Olli Salonen wrote: > I compiled an old HVR-2205 driver from my git tree: > https://github.com/trsqr/media_tree/tree/hvr2205 https://github.com/trsqr/media_tree/commit/61c2ef874b8a9620f498c9a4ab4138e97119462b That's the difference perhaps. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][media] SI2168: Resolve unknown chip version errors with different HVR22x5 models
>> This fix works well for me and properly enables DVB-T tuning behavior >> using tzap. >> >> Thanks to Peter Faulkner-Ball for describing his workaround. > > > hymm, I am not sure that patch at all. It is Olli who has been responsible > adding support for multiple chip revisions, so I will leave that for Olli. I > have only 2 Si2168 devices and both are B40 version. > > Anyhow, for me it looks like firmware major version is always increased when > new major revision of chip is made. Due to that I expected 5.0 after B > version 5.0. > A 1.0 > A 2.0 > A 3.0 > B 4.0 > C 5.0 ? > D 6.0 ? The other email describes the I2C reply from the part, its cleared a D40, not a D 6.0. > And how we could explain situation Olli has device that had been working > earlier, but now it does not? Could you Olli look back you old git tree and > test if it still works? One possible reason could be also PCIe interface I2C > adapter bug. Or timing issue. Unlikely a timing issues or an i2c bug. In my case I have multiple cards. The second card was acquired later and never tested, and exhibited the issue. Olli would need to speak for himself. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
> If the GPIOs aren't truly resetting the SI2168 and thus a warm boot > didn't flush the firmware, I suspect dropping the patches would have > no immediate effect until a full power-down took place. I'm wondering > whether the testing was invalid and indeed we have a problem in the > field, as well as a GPIO issue. Two potential issues. > > I'll schedule sometime later this week to fire up my HVR22xx dev > platform and re-validate the 2205. For the record, here's what happened. 1. The GPIO is working correctly, I've validated this with a meter. This wasn't a warm vs cold boot issue, or in any way Windows related. 2. I have multiple HVR22x5 cards. a HVR2205 and a HVR2215. The HVR2215 I obtained much later after prompting my Olli, it has a newer build date stamped on the demodulators and reports a newer chip version. These newer demods are not recognized by the current tip, the prior ones are. The solution was to patch the SI2168 to recognize the newer demodulator version. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
HVR22x5 I2C
Antti, for your records here's the I2C reply when the si2168 asks for the chip id from one of these newer D40 chips: 80 00 44 34 30 02 00 00 00 00 00 00 00 00 It might make sense to change the "unknown chip version Si21%d-%c%c%c" default message to include a hex dump of the first 5 bytes, to accelerate/aid future debugging issues. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][media] SI2168: Resolve unknown chip version errors with different HVR22x5 models
We're seeing a mix of SI2168 demodulators appearing on HVR2205 and HVR2215 cards, the chips are stamped with different build dates, verified on my cards. The si2168 driver detects some cards fine, others not at all. I can reproduce the working and non-working case. The fix, if we detect a newer card (D40) load the B firmware. This fix works well for me and properly enables DVB-T tuning behavior using tzap. Thanks to Peter Faulkner-Ball for describing his workaround. Signed-off-By: Steven Toth -- Steven Toth - Kernel Labs http://www.kernellabs.com d40.patch Description: Binary data
Re: Hauppauge WinTV-HVR2205 driver feedback
> I have a working solution (workaround) for the HVR2205/HVR2215 firmware
> loading issue.
>
>
> In the file:
>
> dvb-frontends/si2168.c
>
>
> change:
>
> #define SI2168_B40 ('B' << 24 | 68 << 16 | '4' << 8 | '0' << 0)
>
>
> to:
>
> #define SI2168_B40 (68 << 16 | '4' << 8 | '0' << 0)
>
>
> I do not know why this works, but this is the place where the new chip
> is not being detected correctly.
>
> In my case the chip is labelled as: SI2168 40
> When the firmware failed to load the error log reported as: si2168-x0040
>
> I hope this is helpful.
>
>
> I have 2x HVR2215 cards both working for DVB-T on OpenSuse13.2
So the hardware is reporting as a 'D' revision, and a prior firmware
is being loaded and its working nicely. Looks like an easy fix to the
2168 driver.
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
>> Many thanks to the developers for all of your hard work. > > > Let me guess they have changed Si2168 chip to latest "C" version. Driver > supports only A and B (A20, A30 and B40). I have never seen C version. I'll look in detail and report back shortly. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
On Wed, Jun 3, 2015 at 5:29 AM, Olli Salonen wrote: > I'm seeing the same issue as well. I thought that maybe some recent > Si2168 changes did impact this, but it does not seem to be the case. We've had a couple of people raise this so its highly likely we have an issue. I had some patches to the 2168 driver to add support for a new firmware revision. The last time I tested the HVR2205 I convinced myself those were not required, thus I discarded those and re-tested. Probably a warm boot. If the GPIOs aren't truly resetting the SI2168 and thus a warm boot didn't flush the firmware, I suspect dropping the patches would have no immediate effect until a full power-down took place. I'm wondering whether the testing was invalid and indeed we have a problem in the field, as well as a GPIO issue. Two potential issues. I'll schedule sometime later this week to fire up my HVR22xx dev platform and re-validate the 2205. Thanks for raising this. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Access to MPEG-TS?
On Sun, May 24, 2015 at 7:25 PM, wrote: > Hello, > > I'm working on an application that - among other things - should be able to > identify the programs in a MPEG transport stream broadcasted via DVB-C. This > is what I have figured out so far: > > 1. Open the DVB frontend. > 2. Fill struct dvb_frontend_parameters with transponder frequency etc. > 3. Apply struct dvb_frontend_parameters with FE_SET_FRONTEND ioctl call. > > After performing these steps, I call the FE_READ_STATUS ioctl and the status > is FE_HAS_LOCK. > > I should then parse the MPEG transport stream to identify the programs, pids > etc. but my problem is that I don't know how to access the transport stream? > I have tried to read the file descriptor returned from opening the frontend, > but no MPEG data is found there. > > Can anyone point me in the right direction? Open and configure the demux device, configure it for pid 0x2000 and read from it once your frontend indicates you have signal lock. Also, for your parsing needs, I suggest you don't re-invent the wheel. Take a look at libdvbpsi. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/11] saa7164: fix sparse warning
On Fri, May 22, 2015 at 9:59 AM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> drivers/media/pci/saa7164/saa7164-i2c.c:45:33: warning: Using plain integer
> as NULL pointer
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/pci/saa7164/saa7164-i2c.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/pci/saa7164/saa7164-i2c.c
> b/drivers/media/pci/saa7164/saa7164-i2c.c
> index 6ea9d4f..0342d84 100644
> --- a/drivers/media/pci/saa7164/saa7164-i2c.c
> +++ b/drivers/media/pci/saa7164/saa7164-i2c.c
> @@ -42,7 +42,7 @@ static int i2c_xfer(struct i2c_adapter *i2c_adap, struct
> i2c_msg *msgs, int num)
> retval = saa7164_api_i2c_read(bus,
> msgs[i].addr,
> 0 /* reglen */,
> - 0 /* reg */, msgs[i].len, msgs[i].buf);
> + NULL /* reg */, msgs[i].len, msgs[i].buf);
> } else if (i + 1 < num && (msgs[i + 1].flags & I2C_M_RD) &&
>msgs[i].addr == msgs[i + 1].addr) {
> /* write then read from same address */
Reviewed-By: Steven Toth
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:media_tree/master] saa7164: Fix CodingStyle issues added on previous patches
On Fri, May 1, 2015 at 6:33 AM, Mauro Carvalho Chehab
wrote:
> This is an automatic generated email to let you know that the following patch
> were queued at the
> http://git.linuxtv.org/cgit.cgi/media_tree.git tree:
>
> Subject: saa7164: Fix CodingStyle issues added on previous patches
> Author: Mauro Carvalho Chehab
> Date:Fri May 1 07:30:40 2015 -0300
>
> The patches that added support for HVR2255 and HVR2205 added
> some CodingStyle issues.
>
> Better to fix it sooner than latter.
>
> Cc: Steven Toth
> Signed-off-by: Mauro Carvalho Chehab
Acked-By: Steven Toth
>
> drivers/media/pci/saa7164/saa7164-api.c |3 +-
> drivers/media/pci/saa7164/saa7164-dvb.c | 34 ++
> 2 files changed, 22 insertions(+), 15 deletions(-)
>
> ---
>
> http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?id=3600433f19f59410010770d61ead509d785b8a6e
>
> diff --git a/drivers/media/pci/saa7164/saa7164-api.c
> b/drivers/media/pci/saa7164/saa7164-api.c
> index a992af6..e807703 100644
> --- a/drivers/media/pci/saa7164/saa7164-api.c
> +++ b/drivers/media/pci/saa7164/saa7164-api.c
> @@ -1467,7 +1467,8 @@ int saa7164_api_i2c_write(struct saa7164_i2c *bus, u8
> addr, u32 datalen,
> return -EIO;
> }
>
> - dprintk(DBGLVL_API, "%s() len = %d bytes unitid=0x%x\n", __func__,
> len, unitid);
> + dprintk(DBGLVL_API, "%s() len = %d bytes unitid=0x%x\n", __func__,
> + len, unitid);
>
> /* Prepare the send buffer */
> /* Bytes 00-03 dest register length
> diff --git a/drivers/media/pci/saa7164/saa7164-dvb.c
> b/drivers/media/pci/saa7164/saa7164-dvb.c
> index 0fdc944..c68ce26 100644
> --- a/drivers/media/pci/saa7164/saa7164-dvb.c
> +++ b/drivers/media/pci/saa7164/saa7164-dvb.c
> @@ -629,11 +629,13 @@ int saa7164_dvb_register(struct saa7164_port *port)
> if (port->dvb.frontend != NULL) {
>
> if (port->nr == 0) {
> - si2157_attach(port,
> &dev->i2c_bus[0].i2c_adap, port->dvb.frontend,
> - 0xc0,
> &hauppauge_hvr2255_tuner_config);
> + si2157_attach(port, &dev->i2c_bus[0].i2c_adap,
> + port->dvb.frontend, 0xc0,
> +
> &hauppauge_hvr2255_tuner_config);
> } else {
> - si2157_attach(port,
> &dev->i2c_bus[1].i2c_adap, port->dvb.frontend,
> - 0xc0,
> &hauppauge_hvr2255_tuner_config);
> + si2157_attach(port, &dev->i2c_bus[1].i2c_adap,
> + port->dvb.frontend, 0xc0,
> +
> &hauppauge_hvr2255_tuner_config);
> }
> }
> break;
> @@ -650,10 +652,11 @@ int saa7164_dvb_register(struct saa7164_port *port)
> info.addr = 0xc8 >> 1;
> info.platform_data = &si2168_config;
> request_module(info.type);
> - client_demod =
> i2c_new_device(&dev->i2c_bus[2].i2c_adap, &info);
> - if (client_demod == NULL || client_demod->dev.driver
> == NULL) {
> + client_demod =
> i2c_new_device(&dev->i2c_bus[2].i2c_adap,
> + &info);
> + if (!client_demod || !client_demod->dev.driver)
> goto frontend_detach;
> - }
> +
> if (!try_module_get(client_demod->dev.driver->owner))
> {
> i2c_unregister_device(client_demod);
> goto frontend_detach;
> @@ -668,8 +671,9 @@ int saa7164_dvb_register(struct saa7164_port *port)
> info.addr = 0xc0 >> 1;
> info.platform_data = &si2157_config;
> request_module(info.type);
> - client_tuner =
> i2c_new_device(&dev->i2c_bus[0].i2c_adap, &info);
> - if (client_tuner == NULL || client_tuner->dev.driver
> == NULL) {
> + client_tuner =
> i2c_new_device(&dev->i2c_bus[0].i2c_adap,
> + &info);
> + if (!client_tuner || !client_t
Re: [PATCH 02/12] dvbsky: use si2168 config option ts_clock_gapped
> Steven, thanks for your comment You are very welcome. > > So maybe this should also go into cx23885? > I'm in Europe and only have DVB-C My understanding is that it applies to all USB/PCIe bridges. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/12] dvbsky: use si2168 config option ts_clock_gapped
> I've also seen that the Hauppauge HVR-2205 Windows driver enables this > option, but it seems to me that that board works ok also without this. Olli, I found out why this is, I thought you'd appreciate the comment Apparently the issue only occurs with DVB streams faster than approximately 50Mbps, which standard DVB-T/T2, ATSC and QAM-B never are. The issue apparently, is with some QAM-A (DVB-C) streams in Europe. This explains why I've never seen it. That's being said, I do plan to add the gapped clock patch to the SAA7164 shortly - for safety. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
v4l2-compliance question
Hans, struct v4l2_capability has a version field described as: __u32version "Version number of the driver. Starting on kernel 3.1, the version reported is provided per V4L2 subsystem, following the same Kernel numberation scheme. However, it should not always return the same version as the kernel, if, for example, an stable or distribution-modified kernel uses the V4L2 stack from a newer kernel. The version number is formatted using the KERNEL_VERSION() macro..." fail_on_test((vcap.version >> 16) < 3); I have a driver that returns 0x00010703 and thus fails v4l2-compliance. My read on the documentation is that the major doesn't have to be 3 or higher, it doesn't specially call that out. Thoughts? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] hvr2205 / hvr2255 support and misc patches
Mauro, Please disregard my prior pull request for this patchset. As requested, this is a second pull request including the ATSC inversion fix mentioned earlier. Thx - Steve The following changes since commit 4708e452aa3109fc23e0c6b5a658ccc1b720dfa6: [media] saa7164: I2C improvements for upcoming HVR2255/2205 boards (2015-03-23 14:37:32 -0400) are available in the git repository at: git://git.linuxtv.org/stoth/media_tree.git saa7164-dev for you to fetch changes up to c77cfc0fb29c278cf45e9c226bac39434098ca07: [media] saa7164: fix HVR2255 ATSC inversion issue (2015-03-28 08:07:47 -0400) Steven Toth (6): [media] saa7164: Adding additional I2C debug. [media] saa7164: Improvements for I2C handling [media] saa7164: Add Digital TV support for the HVR2255 and HVR2205 [media] saa7164: Fixup recent querycap warnings [media] saa7164: Copyright update [media] saa7164: fix HVR2255 ATSC inversion issue drivers/media/pci/saa7164/saa7164-api.c | 21 ++- drivers/media/pci/saa7164/saa7164-buffer.c | 2 +- drivers/media/pci/saa7164/saa7164-bus.c | 2 +- drivers/media/pci/saa7164/saa7164-cards.c | 188 ++- drivers/media/pci/saa7164/saa7164-cmd.c | 2 +- drivers/media/pci/saa7164/saa7164-core.c| 2 +- drivers/media/pci/saa7164/saa7164-dvb.c | 232 +++--- drivers/media/pci/saa7164/saa7164-encoder.c | 5 +- drivers/media/pci/saa7164/saa7164-fw.c | 2 +- drivers/media/pci/saa7164/saa7164-i2c.c | 2 +- drivers/media/pci/saa7164/saa7164-reg.h | 2 +- drivers/media/pci/saa7164/saa7164-types.h | 2 +- drivers/media/pci/saa7164/saa7164-vbi.c | 5 +- drivers/media/pci/saa7164/saa7164.h | 7 +- 14 files changed, 440 insertions(+), 34 deletions(-) -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Adding HVR2205/HVR2255 support / misc cleanup
> Long awaited patches for the Hauppauge HVR2205 and HVR2255 in this patchset. > Along with a fix for the querycap warning being thrown on newer kernels. Mauro, I had a user point out that I'd missed a critical ATSC patch. You'll see an additional patch in this tree not mentioned in the original pull request "[media] saa7164: fix HVR2255 ATSC inversion issue" Please ensure this is also pulled. Thank you sir! - Steve+1.646.355.8490 -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] saa7164: Hauppauge HVR-2205 and HVR-2215 DVB-C/T/T2 tuners
> The HVR-2215 is sold in Australia, it's not a prototype card: > http://www.pccasegear.com/index.php?main_page=product_info&products_id=28385&cPath=172 Thanks for the URL. I've ordered a card. I'll look into the gapped clock. If it's not required on the HVR2205 (using 2168) then it shouldn't be required for the HVR2215 (using 2168), but that's speculation at this point. I also have the hardware schematics so I'll check those when the board arrives also. Thanks for the heads up. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] Adding HVR2205/HVR2255 support / misc cleanup
Mauro, Thank you for taking care of the git.linuxtv.org ssh issues earlier this week. Long awaited patches for the Hauppauge HVR2205 and HVR2255 in this patchset. Along with a fix for the querycap warning being thrown on newer kernels. Thanks, - Steve The following changes since commit 4708e452aa3109fc23e0c6b5a658ccc1b720dfa6: [media] saa7164: I2C improvements for upcoming HVR2255/2205 boards (2015-03-23 14:37:32 -0400) are available in the git repository at: git://git.linuxtv.org/stoth/media_tree.git saa7164-dev for you to fetch changes up to f40a40d48a9cacefd900314984cce887ddc23142: [media] saa7164: Copyright update (2015-03-23 15:08:15 -0400) Steven Toth (5): [media] saa7164: Adding additional I2C debug. [media] saa7164: Improvements for I2C handling [media] saa7164: Add Digital TV support for the HVR2255 and HVR2205 [media] saa7164: Fixup recent querycap warnings [media] saa7164: Copyright update drivers/media/pci/saa7164/saa7164-api.c | 21 +++-- drivers/media/pci/saa7164/saa7164-buffer.c | 2 +- drivers/media/pci/saa7164/saa7164-bus.c | 2 +- drivers/media/pci/saa7164/saa7164-cards.c | 188 +++- drivers/media/pci/saa7164/saa7164-cmd.c | 2 +- drivers/media/pci/saa7164/saa7164-core.c| 2 +- drivers/media/pci/saa7164/saa7164-dvb.c | 232 +++ drivers/media/pci/saa7164/saa7164-encoder.c | 5 +- drivers/media/pci/saa7164/saa7164-fw.c | 2 +- drivers/media/pci/saa7164/saa7164-i2c.c | 2 +- drivers/media/pci/saa7164/saa7164-reg.h | 2 +- drivers/media/pci/saa7164/saa7164-types.h | 2 +- drivers/media/pci/saa7164/saa7164-vbi.c | 5 +- drivers/media/pci/saa7164/saa7164.h | 7 +- 14 files changed, 440 insertions(+), 34 deletions(-) -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] saa7164: Hauppauge HVR-2205 and HVR-2215 DVB-C/T/T2 tuners
>> I did not require any 2168/2157 driver changes to make these devices >> work. (Antti please note). > > > There seems to be only minor TS config change (which is not even needed if > you set that bit to existing TS mode config value) for gapped/variable > length TS clock (which is in my understanding to leave TS valid line > unconnected). Its not required for the HVR2205 or the HVR2255, these are the only two models of the hardware shipping in production volumes to customers. Any other cards were advanced prototypes, that's my understanding. I'm not suggesting the gapped clock 2168 patch isn't useful for other bridges, you might want to pull Olli's patch for that, but its not required for the HVR2205/2255 support. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] saa7164: Hauppauge HVR-2205 and HVR-2215 DVB-C/T/T2 tuners
> I know there's parallel activity ongoing regarding these devices, but I > thought I'll submit my own version here as well. The maintainers of each > module can then make the call what to merge. http://git.linuxtv.org/cgit.cgi/stoth/media_tree.git/log/?h=saa7164-dev As mentioned previously, I've added support for the HVR2205 and HVR2255. I moved those patches from bitbucket.org into linuxtv.org a couple of days ago pending a pull request. It took a couple of days to get my git.linuxtv.org account back up and running. You've seen and commented on the patches when they were in bitbucket earlier this week, so your need to push our your own patches only confuses and concerns me. I did not require any 2168/2157 driver changes to make these devices work. (Antti please note). I plan to issue a pull request for my tree shortly. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR2205 / HVR2255 support
>> Mauro, what's the plan to pull the LGDT3306A branch into tip? The >> SAA7164/HVR2255 driver need this for demod support. > > Merged yesterday. Today, I added one fix from Olli to extend the > si2157 minimal frequency to match the ATSC tuner range (needed by > HVR-955Q - not sure if HVR2255 also uses si2157 as tuner). Thank you sir. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR2205 / HVR2255 support
On Wed, Mar 4, 2015 at 9:03 AM, Olli Salonen wrote: > Hello Steven, > > Great to hear! The LGDT3306A went into the media_tree yesterday as far > as I can see, together with my HVR-955Q patches. Oh, great. > > Coincidentally, I've been working with HVR-2205 and HVR-2215 as well > and have looked into the HVR-2255 a bit too. I'll also be travelling > (luckily on leisure) for next 10 days or so, but can submit the > HVR-2215 patches on top of your patches afterwards then unless you > have HVR-2215 support already. Its a long shot but If you happen to be in the UK on travel, I'd be happy to buy lunch. ... Or if any LinuxTV devs reading this are in the UK and would like to meet up, send me an email. I'll see what I can do. Other than this, the HVR2215 sounds good Olli. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
HVR2205 / HVR2255 support
Mauro, what's the plan to pull the LGDT3306A branch into tip? The SAA7164/HVR2255 driver need this for demod support. Hey folks, an update on this. So I have the green-light to release my HVR2205 and HVR2255 board related patches. I started merging them into tip earlier this week. The HVR2205 is operational for DVB-T, although I have not tested analog tv as yet. The HVR2255 is the next on the list, I expect this to be trivial once the HVR2205 work is complete. Annoyingly, I'm traveling on business for the next 10 days or so. I can't complete the work until I return - but I expect to complete this entire exercise by 21st of this month So hold on a little longer and keep watching this mailing list for further updates. Thanks, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCTV 800i
>> I have a pair of 800i's with the S5H1409 demodulator, probably from >> when I did the original 800i support (2008): >> http://marc.info/?l=linux-dvb&m=120032380226094&w=2 >> >> I don't have a 800i with a s5h1411, so I can't really help without it. >> > Dear John and Steven, > > Back in 2012 I twice submitted a patch that got my pctv 800i with an s5h1411 > working. Both times > either my email or something along the way wrapped lines and spoiled the > patch for testing. I've > patched several kernels since then, but not any very recently. I just > checked and that machine is running > Fedora 3.14.4-200.fc20.x86_64. > > I've attached what I believe is the patch I made then. Since then, I've just > edited the v4l source > whenever and built a modified module whenever I upgraded. I put instructions > on fedora forum back > then: http://forums.fedoraforum.org/showthread.php?t=281161 > > I hope this helps. Mack, thanks. I've seen this patch in the past. Its perfect for end users who only need to support the newer board, but isn't too helpful for the kernel as it disables support for the prior board. What the kernel needs is a single patch that (probably) reads the card eeprom and deterministically attaches the correct demodulator for the hardware, so users can mix'n'match old and new cards. If the eeprom doesn't help then we'll need to figure something else out. It's on my todo-list at somepoint. I traded a card with John a few weeks ago so I have everything I need to make it happen, other than time! Thanks again, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SMS / DVB / media_graph issue - tip fails to compile
Someone broke tip. CC [M] drivers/media/common/siano/smsdvb-main.o drivers/media/common/siano/smsdvb-main.c: In function ‘smsdvb_media_device_unregister’: drivers/media/common/siano/smsdvb-main.c:614:27: warning: unused variable ‘coredev’ [-Wunused-variable] struct smscore_device_t *coredev = client->coredev; ^ drivers/media/common/siano/smsdvb-main.c: In function ‘smsdvb_hotplug’: drivers/media/common/siano/smsdvb-main.c:1188:32: error: ‘struct smscore_device_t’ has no member named ‘media_dev’ dvb_create_media_graph(coredev->media_dev); ^ make[4]: *** [drivers/media/common/siano/smsdvb-main.o] Error 1 make[3]: *** [drivers/media/common/siano] Error 2 make[2]: *** [drivers/media/common] Error 2 -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] [media] saa7164: use an MSI interrupt when available
On Thu, Feb 26, 2015 at 6:29 PM, Brendan McGrath wrote: > From: Brendan McGrath > [media] saa7164: use an MSI interrupt when available > > Enhances driver to use an MSI interrupt when available. > > Adds the module option 'enable_msi' (type bool) which by default is enabled. > Can be set to 'N' to disable. > > Fixes (or can reduce the occurrence of) a crash which is most commonly > reported when multiple saa7164 chips are in use. > > Signed-off-by: Brendan McGrath Thank you Brendan. Reviewed-by: Steven Toth -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] saa7164: use an MSI interrupt when available
> I am under the impression it was against the spec to have a PCI-E card > without MSI support. Wouldn't the fallback code as well work in this > regard? Not if the motherboard MSI implementation is flakey, like we've seen in the past with other PCIe bridges and their interaction with root controllers. I've actually seen this with some commercial customers using the 7164. With this new patch MSI gets enabled, the 'solution' doesn't work properly and now we expect users to compile their own kernels, just to get back to a previously working solution. I'm happy to take the patch if the option can be disabled. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] saa7164: use an MSI interrupt when available
> I believe the root cause of the crash is due to a DMA/IRQ race condition. It > most commonly occurs when the saa7164 driver is dealing with more than one > saa7164 chip (the HVR-2200 and HVR-2250 for example have two - one for each > tuner). Given MSI avoids DMA/IRQ race conditions - this would explain why > the patch works as a fix. Brendan, thanks. With MSI I've had some people report complete success, others still have the issues. In my experience this does help with i2c timeout issues but not completely in every case. I've also seen it with single card instances so you descripton above is close - but not quiet accurate in all cases. While I'm generally OK with changing the driver behaviour to enable MSI by default, please add a module option to allow the behaviour to be disabled, reverting the driver back to existing behaviour. Once this is done, I'll be happy to Ack it. Thanks again. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] saa7164: free_irq before pci_disable_device
On Sat, Feb 21, 2015 at 4:45 PM, Olli Salonen wrote: > Free the IRQ before disabling the device. Otherwise errors like this when > unloading the module: > > [21135.458560] [ cut here ] > [21135.458569] WARNING: CPU: 4 PID: 1696 at > /home/apw/COD/linux/fs/proc/generic.c:521 remove_proc_entry+0x1a1/0x1b0() > [21135.458572] remove_proc_entry: removing non-empty directory 'irq/47', > leaking at least 'saa7164[0]' > > Signed-off-by: Olli Salonen Thx. Reviewed-by: Steven Toth -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] mn88472: reduce firmware download chunk size
>> I tried loading the driver with polling disabled and it fails completely: >> >> [ 5526.693563] mn88472 7-0018: downloading firmware from file >> 'dvb-demod-mn88472-02.fw' >> [ 5527.032209] mn88472 7-0018: firmware download failed=-32 >> [ 5527.033864] rtl2832 7-0010: i2c reg write failed -32 >> [ 5527.033874] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=05 len=1: >> 83 >> [ 5527.036014] rtl2832 7-0010: i2c reg write failed -32 >> >> I have no idea why the device behaves so counter-intuitively. Is there >> maybe some sorf of internal power-save mode the device enters when >> there is no i2c traffic for a while or something? > > > IR polling does not use I2C but some own commands. Could you make more > tests. Use rtl28xxu module parameter to disable IR and test. It will disable > both IR interrupts and polling. Then make some tests with different IR > polling intervals to see how it behaves. > > I have 3 mn88472 and 1 mn88473 device and all those seems to work fine for > me. I don't care to buy anymore devices to find out one which does not work. > Somehow root of cause should be find - it is not proper fix to repeat or > break I2C messages to multiple smaller ones. Ack. Its the job of the I2C controller to manage the I2C bus implementation, including any fragmentation needs, not the tuner/demod/other driver. Find and fix the resource contention bug in the bridge and the mn88472 will work as is. I suspect something is broken with I2C locking. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state
On Wed, Feb 18, 2015 at 11:04 PM, David Harty wrote: > On 02/17/2015 04:47 AM, dCrypt wrote: >> >> So the PCI Express change hasn't seemed to help either. Any other ideas? >> David -- > > > My system stops working at least once a day. Does anyone have any > suggestions to try? latest module builds? other firmwares? I notice there > are several up on the http://www.steventoth.net/linux/hvr22xx/ site, would > any of those work better? > > Is there a better card to use? the HVR-2200 and saa7164 are effectively > unusable at this point. I'm planning to release an updated saa7164 driver shortly, with support for the HVR2205 and the HVR2255. Additionally, it contains a fix (which for some people) has significantly reduced the I2C Timeout related errors. (Technically the risc processor crashes on the card, leading to all firmware commands timing out). I'll post a notice to this list once the driver is ready for download. Shortly, I hope. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [possible BUG, cx23885] Dual tuner TV card, works using one tuner only, doesn't work if both tuners are used
> To my knowledge the driver is now stable. There is still the occasional > kernel message that shouldn't be there which I am trying to track down, > but the driver crashes due to a vb2 race condition have been fixed. Thank you for the clarification Hans, and thanks for taking care of VB2 etc. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [possible BUG, cx23885] Dual tuner TV card, works using one tuner only, doesn't work if both tuners are used
I didn't see anything obvious in the logs :( Please don't send the hardware to the US unless you're willing to leave it with me permanently, I don't work on hardware for free if I don't get to keep the final hardware. I hope you understand. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com On Wed, Feb 4, 2015 at 3:30 AM, dcr...@telefonica.net wrote: > Too bad. I will check anyway the export cost, just to check if it makes sense. > > BTW, did you have the chance to look at the logs I attached, just to figure > out if something is wrong or something can be debugged at my side? I'm not > expert in V4L stuff, but I am a programmer and could test things by myself if > some advice or guidance is provided. Maybe there is a DVB/V4L programming > tutorial somewhere? > > BR > >> Mensaje original >>De : st...@kernellabs.com >>Fecha : 03/02/2015 - 22:40 (GMT) >>Para : dcr...@telefonica.net >>CC : linux-media@vger.kernel.org >>Asunto : Re: [possible BUG, cx23885] Dual tuner TV card, works using one >>tuner only, doesn't work if both tuners are used >> >>Hi, >> >>I'm based in the US :( >> >>- Steve >> >>-- >>Steven Toth - Kernel Labs >>http://www.kernellabs.com >> >>On Tue, Feb 3, 2015 at 4:39 PM, dCrypt wrote: >>> Thanks Steve. >>> >>> If sending it really helps you in your development, I will gladly pay for >>> the postage forth and back if you live in Europe. >>> >>> When my recently purchased HVR-2200 is stable in my PVR (I could still use >>> the Terratec disabling one tuner), I will consider donating the Terratec. >>> >>> BR >>> >>> >>>> -Mensaje original- >>>> De: Steven Toth [mailto:st...@kernellabs.com] >>>> Enviado el: martes, 03 de febrero de 2015 20:32 >>>> Para: dCrypt >>>> CC: Linux-Media >>>> Asunto: Re: [possible BUG, cx23885] Dual tuner TV card, works using one >>>> tuner only, doesn't work if both tuners are used >>>> >>>> While I am the maintainer of the cx23885 driver, its currently >>>> undergoing a significant amount of churn related to Han's recent VB2 >>>> and other changes. I consider the current driver broken until the >>>> feedback on the mailing list dies down. I'm reluctant to work on the >>>> driver while its considered unstable. >>>> >>>> If you want to send me a Terratec card then I'll try to fund an hour to >>>> investigate in the coming weeks. >>>> >>>> Best, >>>> >>>> - Steve >>>> >>>> -- >>>> Steven Toth - Kernel Labs >>>> http://www.kernellabs.com >>>> >>>> >>>> On Tue, Feb 3, 2015 at 2:26 PM, dCrypt wrote: >>>> > Steve, >>>> > >>>> > Maybe you can help me tracking down my other card's problem, as I saw >>>> you were owner of the (c) in the cx23885 source code. >>>> > >>>> > BR >>>> > >>>> >> -Mensaje original- >>>> >> De: linux-media-ow...@vger.kernel.org [mailto:linux-media- >>>> >> ow...@vger.kernel.org] En nombre de dCrypt >>>> >> Enviado el: jueves, 29 de enero de 2015 1:11 >>>> >> Para: linux-media@vger.kernel.org >>>> >> CC: st...@linuxtv.org >>>> >> Asunto: RE: [possible BUG, cx23885] Dual tuner TV card, works using >>>> one >>>> >> tuner only, doesn't work if both tuners are used >>>> >> >>>> >> Hi, >>>> >> >>>> >> I have attached four excerpts from /var/log/kern.log with debug=9 >>>> >> option for module cx23885. The test flow is the following: >>>> >> >>>> >> 0) Ubuntu 14.04/kernel 3.13 just installed, latest V4L source code >>>> >> compiled and installed Test 1.1) >>>> >> - Reboot >>>> >> - sudo tzap -a 0 -x -H -c channelsv3.conf "La 1 HD.", using >>>> first >>>> >> tuner, it locks and works >>>> >> - log excerpt extracted -> test1.1-adap0-ok.log >>>> >> >>>> >> Test 1.2) >>>> >> - sudo tzap -a 1 -x -H -c channelsv3.conf "La 1 HD.", using >>>> >> second tuner after first tuner lock, it doesn&#
Re: [possible BUG, cx23885] Dual tuner TV card, works using one tuner only, doesn't work if both tuners are used
Hi, I'm based in the US :( - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com On Tue, Feb 3, 2015 at 4:39 PM, dCrypt wrote: > Thanks Steve. > > If sending it really helps you in your development, I will gladly pay for the > postage forth and back if you live in Europe. > > When my recently purchased HVR-2200 is stable in my PVR (I could still use > the Terratec disabling one tuner), I will consider donating the Terratec. > > BR > > >> -Mensaje original- >> De: Steven Toth [mailto:st...@kernellabs.com] >> Enviado el: martes, 03 de febrero de 2015 20:32 >> Para: dCrypt >> CC: Linux-Media >> Asunto: Re: [possible BUG, cx23885] Dual tuner TV card, works using one >> tuner only, doesn't work if both tuners are used >> >> While I am the maintainer of the cx23885 driver, its currently >> undergoing a significant amount of churn related to Han's recent VB2 >> and other changes. I consider the current driver broken until the >> feedback on the mailing list dies down. I'm reluctant to work on the >> driver while its considered unstable. >> >> If you want to send me a Terratec card then I'll try to fund an hour to >> investigate in the coming weeks. >> >> Best, >> >> - Steve >> >> -- >> Steven Toth - Kernel Labs >> http://www.kernellabs.com >> >> >> On Tue, Feb 3, 2015 at 2:26 PM, dCrypt wrote: >> > Steve, >> > >> > Maybe you can help me tracking down my other card's problem, as I saw >> you were owner of the (c) in the cx23885 source code. >> > >> > BR >> > >> >> -Mensaje original- >> >> De: linux-media-ow...@vger.kernel.org [mailto:linux-media- >> >> ow...@vger.kernel.org] En nombre de dCrypt >> >> Enviado el: jueves, 29 de enero de 2015 1:11 >> >> Para: linux-media@vger.kernel.org >> >> CC: st...@linuxtv.org >> >> Asunto: RE: [possible BUG, cx23885] Dual tuner TV card, works using >> one >> >> tuner only, doesn't work if both tuners are used >> >> >> >> Hi, >> >> >> >> I have attached four excerpts from /var/log/kern.log with debug=9 >> >> option for module cx23885. The test flow is the following: >> >> >> >> 0) Ubuntu 14.04/kernel 3.13 just installed, latest V4L source code >> >> compiled and installed Test 1.1) >> >> - Reboot >> >> - sudo tzap -a 0 -x -H -c channelsv3.conf "La 1 HD.", using >> first >> >> tuner, it locks and works >> >> - log excerpt extracted -> test1.1-adap0-ok.log >> >> >> >> Test 1.2) >> >> - sudo tzap -a 1 -x -H -c channelsv3.conf "La 1 HD.", using >> >> second tuner after first tuner lock, it doesn't lock and doesn't >> work >> >> - log excerpt extracted -> test1.2-adap1-ko.log >> >> >> >> Test 2.1) >> >> - Reboot >> >> - sudo tzap -a 1 -x -H -c channelsv3.conf "La 1 HD.", using >> >> second tuner, it locks and works >> >> - log excerpt extracted -> test2.1-adap1-ok.log >> >> >> >> Test 2.2) >> >> - sudo tzap -a 0 -x -H -c channelsv3.conf "La 1 HD.", using >> first >> >> tuner after second tuner lock, it doesn't lock and doesn't work >> >> - log excerpt extracted -> test2.2-adap0-ko.log >> >> >> >> From the logs, I interpret that, after one tuner is used and locked >> the >> >> signal, trying to use the other tuner no IRQs are fired after >> >> cx23885_start_dma(), so the driver immediately cancels buffers and >> >> stops dma. However, I am not an expert and I can't follow the full >> >> workflow, so I could be wrong. >> >> >> >> I would like to help as much as I can, but I'm afraid I need some >> >> guidance. >> >> >> >> BR >> >> >> >> -Mensaje original- >> >> De: linux-media-ow...@vger.kernel.org [mailto:linux-media- >> >> ow...@vger.kernel.org] En nombre de dCrypt Enviado el: sábado, 17 de >> >> enero de 2015 1:26 >> >> Para: ja...@ejbdigital.com.au >> >> CC: linux-media@vger.kernel.org; hverk...@xs4all.nl >> >> Asunto: RE: [possible BUG, cx23885] Dual tuner TV card, works using >> one >> >> tuner only, doesn't work
Re: [possible BUG, cx23885] Dual tuner TV card, works using one tuner only, doesn't work if both tuners are used
While I am the maintainer of the cx23885 driver, its currently undergoing a significant amount of churn related to Han's recent VB2 and other changes. I consider the current driver broken until the feedback on the mailing list dies down. I'm reluctant to work on the driver while its considered unstable. If you want to send me a Terratec card then I'll try to fund an hour to investigate in the coming weeks. Best, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com On Tue, Feb 3, 2015 at 2:26 PM, dCrypt wrote: > Steve, > > Maybe you can help me tracking down my other card's problem, as I saw you > were owner of the (c) in the cx23885 source code. > > BR > >> -Mensaje original- >> De: linux-media-ow...@vger.kernel.org [mailto:linux-media- >> ow...@vger.kernel.org] En nombre de dCrypt >> Enviado el: jueves, 29 de enero de 2015 1:11 >> Para: linux-media@vger.kernel.org >> CC: st...@linuxtv.org >> Asunto: RE: [possible BUG, cx23885] Dual tuner TV card, works using one >> tuner only, doesn't work if both tuners are used >> >> Hi, >> >> I have attached four excerpts from /var/log/kern.log with debug=9 >> option for module cx23885. The test flow is the following: >> >> 0) Ubuntu 14.04/kernel 3.13 just installed, latest V4L source code >> compiled and installed Test 1.1) >> - Reboot >> - sudo tzap -a 0 -x -H -c channelsv3.conf "La 1 HD.", using first >> tuner, it locks and works >> - log excerpt extracted -> test1.1-adap0-ok.log >> >> Test 1.2) >> - sudo tzap -a 1 -x -H -c channelsv3.conf "La 1 HD.", using >> second tuner after first tuner lock, it doesn't lock and doesn't work >> - log excerpt extracted -> test1.2-adap1-ko.log >> >> Test 2.1) >> - Reboot >> - sudo tzap -a 1 -x -H -c channelsv3.conf "La 1 HD.", using >> second tuner, it locks and works >> - log excerpt extracted -> test2.1-adap1-ok.log >> >> Test 2.2) >> - sudo tzap -a 0 -x -H -c channelsv3.conf "La 1 HD.", using first >> tuner after second tuner lock, it doesn't lock and doesn't work >> - log excerpt extracted -> test2.2-adap0-ko.log >> >> From the logs, I interpret that, after one tuner is used and locked the >> signal, trying to use the other tuner no IRQs are fired after >> cx23885_start_dma(), so the driver immediately cancels buffers and >> stops dma. However, I am not an expert and I can't follow the full >> workflow, so I could be wrong. >> >> I would like to help as much as I can, but I'm afraid I need some >> guidance. >> >> BR >> >> -Mensaje original- >> De: linux-media-ow...@vger.kernel.org [mailto:linux-media- >> ow...@vger.kernel.org] En nombre de dCrypt Enviado el: sábado, 17 de >> enero de 2015 1:26 >> Para: ja...@ejbdigital.com.au >> CC: linux-media@vger.kernel.org; hverk...@xs4all.nl >> Asunto: RE: [possible BUG, cx23885] Dual tuner TV card, works using one >> tuner only, doesn't work if both tuners are used >> >> Hi, James. >> >> After searching for somebody posting some issues similar to mine, I >> think this one you posted to the mailing list can be related: >> >> https://www.mail-archive.com/linux- >> media%40vger.kernel.org/msg80078.html >> >> I'm having problems using both tuners in a dual tuner card (Terratec >> Cinergy T PCIe Dual), also based on cx23885, but it uses different >> frontends/tuners than yours. >> >> In summary, my problem is that I started getting signal/locking errors >> in VDR if I tuned one frontend, and VDR scanned EIT/EPG using the >> second tuner in the background; by disabling the second tuner it works. >> I managed to reproduce the problem by simply using dvbzap/dvbv5-zap in >> command line. And it suddenly started failing on the 1st of Dec 2014 >> (after a frequency change in DVB-T in Spain). I tested different Ubuntu >> distros wich previously worked, but I can't manage to make it work now >> using the default kernel included in the Ubuntu ISO image that I had >> installed. >> >> I am testing now with Ubuntu 15.04 nightly, kernel 3.18, in a separate >> hw platform. I also tested with MythTV and TVHedaend, but as I managed >> to reproduce it with the dvb command line tools, I don't test any GUI >> anymore. I've also tested it in Windows 7, and it works tuning both >> tuners simultaneously, so I discarded a hardware problem. I've also >> tested with
Re: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state
>>Basically, it starts working but after a while I get an "Event timed out" >>message and several i2c errors and VDR shuts down (some hours after reboot). >>As the web page mentions, I tested downgrading the PCIe bandwith from GEN2 to >>GEN1 without success. But after playing with different BIOS options, what did >>the trick was limiting the power-saving C-states. If I select "C7" as the >>maximum C-state, the card fails as described. After limiting the maximum >>C-state to "C6", it has been working for a whole weekend. Good feedback on the C7 vs C6 power state, thanks. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCTV 800i
> John replied off list: > > "http://linux-media.vger.kernel.narkive.com/kAviSkda/chipset-change-for-cx88-board-pinnacle-pctv-hd-800i > > Wonder if any code was ever integrated?" > > It looks like basics of a patch was developed to support the card but > it was incompatible with the existing cards and nobody took the time > to understand how to differentiate between the older 800i and the > newer 800i. So, the problem fell on the floor. > > I'll look through my card library. If I have an old _AND_ new rev then > I'll find an hour and see if I can find an acceptable solution. > > Summary: PCTV released a new 800i (quite a while ago) changing the > demodulator, which is why the existing driver doesn't work. I have a pair of 800i's with the S5H1409 demodulator, probably from when I did the original 800i support (2008): http://marc.info/?l=linux-dvb&m=120032380226094&w=2 I don't have a 800i with a s5h1411, so I can't really help without it. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCTV 800i
On Tue, Jan 27, 2015 at 12:25 AM, John Klug wrote: > I moved it to a dual boot system, and it works in windows, and the > same error in Linux. > > The chips are marked: > Conexant CX23880 > Samsung S5H1411 > Cirrus CS5340CZZ > Atmel ATMLH138 > > three out of four are a different part number than the Wiki. > > It is Board T1213044 stamped on back > PCTV 800i Rev 1.1 > Shield over tuner says "pctv systems" > > There are 5 APL1117 on both sides of the board. > > Since the tuner is probably under the shield I don't know a > non-destructive method to get the part number. > >>From: Steven Toth >>Date: Mon, Jan 26, 2015 at 6:44 AM >>Subject: Re: PCTV 800i >>To: John Klug >>Cc: Linux-Media > > >>On Mon, Jan 26, 2015 at 12:50 AM, John Klug wrote: >>> I have a new PCTV card with CX23880 (not CX23883 as shown in the picture): >>> >>> http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_HD_Card_(800i) >>> >>> The description is out of date with respect to my recent card. >>> >>> It did not work in 3.12.20, 3.17.7, and I finally downloaded the >>> latest GIT of media_build to no avail (I have a 2nd card that is CX18, >>> which is interspersed in the output). > >>The error messages suggest one or more of the components on the board, >>or their I2C addresses have changed, or that your hardware is bad. > >>Other than the Conexant PCI bridge, do the other components listed in >>the wiki page match the components on your physical device? >> John replied off list: "http://linux-media.vger.kernel.narkive.com/kAviSkda/chipset-change-for-cx88-board-pinnacle-pctv-hd-800i Wonder if any code was ever integrated?" It looks like basics of a patch was developed to support the card but it was incompatible with the existing cards and nobody took the time to understand how to differentiate between the older 800i and the newer 800i. So, the problem fell on the floor. I'll look through my card library. If I have an old _AND_ new rev then I'll find an hour and see if I can find an acceptable solution. Summary: PCTV released a new 800i (quite a while ago) changing the demodulator, which is why the existing driver doesn't work. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCTV 800i
On Mon, Jan 26, 2015 at 12:50 AM, John Klug wrote: > I have a new PCTV card with CX23880 (not CX23883 as shown in the picture): > > http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_HD_Card_(800i) > > The description is out of date with respect to my recent card. > > It did not work in 3.12.20, 3.17.7, and I finally downloaded the > latest GIT of media_build to no avail (I have a 2nd card that is CX18, > which is interspersed in the output). The error messages suggest one or more of the components on the board, or their I2C addresses have changed, or that your hardware is bad. Other than the Conexant PCI bridge, do the other components listed in the wiki page match the components on your physical device? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV HVR-2255 dvb tuner support?
> I have a hvr-2255 dvb tuner, but to my knowledge there is no support for > this newer hardware available on linux. Brian, if all goes to plan then I'm releasing our HVR2205/55 patches in the next 2-3 weeks. I have one last hurdle then everything can go public. So, stay tuned. If you (or anyone) have any specific needs, or questions, feel free to email me off-list. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ELC 2015 - March - San Jose
Is anyone planning to attend this year? - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Support for Elgato Game Capture HD / MStar MST3367CMK
Comments inline On Mon, Dec 22, 2014 at 4:07 PM, Tolga Cakir wrote: > Am 09.05.2014 um 14:38 schrieb Steven Toth: >> >> On Thu, May 8, 2014 at 9:48 PM, Tolga Cakir wrote: >>> >>> Hello everyone! >> >> Hi Tolga! >> >>> Over the past weeks, I've been busy capturing USB packets between the >>> Elgato >>> Game Capture HD and my PC. It's using the MStar MST3367CMK chip, which >>> seems >>> to have proprietary Linux support available only for hardware vendors in >>> form of an SDK. Problem is, that this SDK is strictly kept under an NDA, >>> making it kinda impossible for us to get our hands on. >> >> Thanks for raising the subject. >> >> While your comment is true, it would have been more appropriate to the >> development community to say that it truly uses the Fujitsu USB >> encoder, a fujitsu USB API along with a series of smaller subsystems >> for HDMI receivers and transmitters. Your capture logs indicate >> (largely) interaction with the Fujitsu USB bridge + integral encoder. >> The distinction is important. >> >> We outlined the architecture of the device (along with the brief tear >> down) here: http://www.kernellabs.com/blog/?p=1959 >> >>> So, I got my hands dirty and have found some very good stuff! First of >>> all, >>> in contrast to many sources, the Elgato Game Capture HD outputs >>> compressed >>> video and audio via USB! It's already encoded, so there is no need for >>> reencoding, this will save CPU power. For testing purposes, I've only >>> tried >>> capturing 720p data for now, but this should be more than enough. >> >> Have you posted any source code? I don't see any in the zips or on github. >> >> Paging through a 600MB usb capture to find an occasional comment >> (assuming you have inserted them) doesn't encourage me to contribute. >> >>> Basically, we need to read raw USB traffic, write an MPEG-TS file header, >>> put in the raw USB data and close the file. I'm not super experienced in >>> C / >>> kernel development (especially V4L), but I'll give my best to get this >>> project forward. My next step is getting a prototype working with libusb >>> in >>> userland; after that's done, I'll try porting it over to kernel / V4L >>> >>> Project page can be found here: >>> https://github.com/tolga9009/elgato-gchd >> >> I must be missing something. your repo contains a LICENSE file and >> README. Did you forget to checking a homebrew datasheet or working >> sample source code? >> >>> USB logs and docs: >>> v1.0 as 7zip: https://docs.google.com/file/d/0B29z6-xPIPLEQVBMTWZHbUswYjg >>> v1.0 as rar: https://docs.google.com/file/d/0B29z6-xPIPLEcENMWnh1MklPdTQ >>> v1.0 as zip: https://docs.google.com/file/d/0B29z6-xPIPLEQWtibWk3T3AtVjA >> >> Ahh, thank you for circulating the datasheets and images from our blog >> post, you are most welcome! The internet is a wonderful thing, I'm >> glad you found them useful. >> >>> Is anyone interested in getting involved / taking over? Overall, it seems >>> doable and not too complex. I'd be happy about any help! Also, if you >>> need >>> more information, just ask me. I'll provide you everything I have about >>> this >>> little device. >> >> How about instead of some usb dumps, pictures and pdfs, a working >> program and a description of the device protocol? This would help. >> >> I spent a few days late 2012 with the usb analyzer and brought >> together a primitive collection of personal notes on the API. Sadly >> I'm struggling to locate them currently. From memory, the device has >> an odd protocol which isn't exactly obvious. Its firmware like, not >> i2c based. You don't appear to control the HDMI rx/tx silicon by hand, >> the fijutsu firmware does this via firmware APIs. you would think, >> YAY! firmware API, easy, surprisingly not. A lot of byte guess to be >> done. If you have any significant homebrew documentation on the byte >> sequences that control the device, this would help. >> >> Part of the problem is that the device also streams (with the >> windows/osx drivers I was using) permanently on, making it difficult >> to see the wood from the noise. So, even when you are not 'using it', >> its streaming payload via USB to the host. Urgh. I hope they've fixed >> this. >> >> The device outputs native ISO1381
Re: [PATCH] cx23885: Split Hauppauge WinTV Starburst from HVR4400 card entry
> In my understanding Starburst is HVR-4400, but only satellite tuner is > installed to PCB - whilst terrestrial/cable is left out. I went back through my engineering notes from my Hauppauge engineering days, this statement is correct. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cx23885: Split Hauppauge WinTV Starburst from HVR4400 card entry
>> Please change CX23885_BOARD_HAUPPAUGE_STARBURST to >> CX23885_BOARD_HAUPPAUGE_HVR5500. >> >> Thanks, >> > Hi Steven, > > thank you for your feedback. > > I rechecked the names and this are the more or less supported devices: > * Starburst supports DVB-S2 only > * HVR-4400 supports DVB-S2 + DVB-T (Si2161) > * HVR-5500 supports DVB-S2 + DVB-C/T (Si2165) > > As starburst has only one demod and HVR-4400/HVR-5500 have two, there is > one card entry for HVR-4400/HVR-5500 and a second one with different > name for the Sturburst. > > Checking hauppauge homepage I directly get to the WinTV-Starburst: > http://www.hauppauge.de/site/products/data_starburst.html > > So I see this is an official product name. Why not show this name? You are correct. I was assuming you were attempting to add HVR5500 support. Please disregard my previous request, CX23885_BOARD_HAUPPAUGE_STARBURST is fine. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cx23885: Split Hauppauge WinTV Starburst from HVR4400 card entry
On Sun, Dec 21, 2014 at 2:59 PM, Matthias Schwarzott wrote: > Unconditionally attaching Si2161/Si2165 demod driver > breaks Hauppauge WinTV Starburst. > So create own card entry for this. > > Add card name comments to the subsystem ids. > > Signed-off-by: Matthias Schwarzott Matthias, Thank you for your work. However, nobody knows or cares what 'STARBURST' is. When I created the original driver I was careful to name the card identified to match the actual hardware names that were sold in retail, this eases future maintenance for people with no knowledge of the hardware and makes Linux support for the HVR550 much more obvious in google. Please change CX23885_BOARD_HAUPPAUGE_STARBURST to CX23885_BOARD_HAUPPAUGE_HVR5500. Thanks, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WinTV HVR 2200 radio
On Fri, Oct 31, 2014 at 2:13 PM, shacky wrote: > 2014-10-31 19:05 GMT+01:00 Steven Toth : >> FM is not supported. > > Hi Steven, > thank you very much for your answer. > > Do you know any PCI-Express FM tuner supported by Linux? Not off-hand. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WinTV HVR 2200 radio
FM is not supported. -- Steven Toth - Kernel Labs http://www.kernellabs.com On Fri, Oct 31, 2014 at 2:01 PM, shacky wrote: > Hi. > > I see that the Hauppauge WinTV-HVR-2200 is supported on Linux > (http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-2200) but I > cannot understand if its FM radio receiver is also supported by Linux. > > I'm looking for a low profile PCI-Express FM receiver which works on > Linux with which I can listen and record FM programmings. > > Could you help me please? > > Thank you very much. > Bye > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
