Re: Hauppauge WinTV-HVR2205 driver feedback
My card has been always installed in a machine that does not have Windows, so any interference with the Windows driver should not be an issue. I found some old console logs from February 21 when I was trying to put together a driver for the board. It shows that the Si2168 chip on my board was at that time correctly detected as Si2168-B40 by the si2168 driver and the 4.0.11 firmware was loaded ok. [ 28.646668] DVB: registering new adapter (saa7164) [ 28.646671] saa7164 :07:00.0: DVB: registering adapter 1 frontend 0 (Silicon Labs Si2168)... [ 28.648633] i2c i2c-4: Added multiplexed i2c bus 6 [ 28.648638] si2168 4-0066: Silicon Labs Si2168 successfully attached [ 28.658000] si2157 6-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached [ 28.658439] DVB: registering new adapter (saa7164) [ 28.658442] saa7164 :07:00.0: DVB: registering adapter 2 frontend 0 (Silicon Labs Si2168)... [ 28.732812] init: plymouth-splash main process (1305) terminated with status 1 [ 35.214858] random: nonblocking pool is initialized [ 582.391928] si2168 3-0064: found a 'Silicon Labs Si2168-B40' [ 582.392289] si2168 3-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' [ 584.946560] si2168 3-0064: firmware version: 4.0.11 [ 584.984386] si2157 5-0060: found a 'Silicon Labs Si2157-A30' [ 585.058396] si2157 5-0060: firmware version: 3.0.5 I have some w_scan logs from that day that show that the card was indeed working. Cheers, -olli On 3 June 2015 at 21:46, Antti Palosaari wrote: > On 06/03/2015 10:08 PM, Olli Salonen wrote: >> >> I cold booted my number cruncher after a hiatus of a couple of weeks, >> applied a couple of extra dev_dbg printouts in the si2168_cmd_execute >> and installed the newly built module. The results: >> >> [ 663.147757] si2168 2-0066: Silicon Labs Si2168 successfully attached >> [ 663.151735] si2157 1-0060: Silicon Labs Si2147/2148/2157/2158 >> successfully attached >> [ 663.152436] DVB: registering new adapter (saa7164) >> [ 663.152441] saa7164 :07:00.0: DVB: registering adapter 1 >> frontend 0 (Silicon Labs Si2168)... >> [ 678.690104] si2168:si2168_init: si2168 2-0064: >> [ 678.690111] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 13, rlen: 0 >> [ 678.690115] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: c0 >> 12 00 0c 00 0d 16 00 00 00 00 00 00 >> [ 678.693331] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 8, rlen: 1 >> [ 678.693337] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: c0 >> 06 01 0f 00 20 20 01 >> [ 678.701914] si2168:si2168_cmd_execute: si2168 2-0064: i2c read: 80 >> [ 678.701920] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution >> took 6 ms >> [ 678.701923] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 1, rlen: 13 >> [ 678.701926] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: 02 >> [ 678.708631] si2168:si2168_cmd_execute: si2168 2-0064: i2c read: 80 >> 00 44 34 30 02 00 00 00 00 00 00 00 >> [ 678.708636] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution >> took 2 ms >> [ 678.708639] si2168 2-0064: unknown chip version Si2168- >> [ 678.714777] si2168:si2168_init: si2168 2-0064: failed=-22 >> [ 678.727424] si2157 0-0060: found a 'Silicon Labs Si2157-A30' >> [ 678.783587] si2157 0-0060: firmware version: 3.0.5 >> >> The answer to the 02 command seems really odd. You can see it is a >> Si2168, version 40, but I'd expect the second octet to say 42 instead >> of 00. > > > Yeah, very odd. That byte should be letter A (0x41) or B (0x42) or likely C > (0x43) in future when current C revision chips are seen. > > Are you really sure it has returned (and worked) 0x42 earlier? Have you used > Windows driver - I speculate if it could make permanent upgrade to chip to > change it. > > Timing issues are also possible. Maybe you could test with some extra > sleeps, like adding 100ms delay between command request and reply. > > Unfortunately value of those 3 bytes are really important as driver selects > firmware to download according them. > > regards > Antti > > -- > http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] [media] gspca: sn9c2028: remove an unneeded condition
We already know status is negative because of the earlier check so there
is no need to check again.
Signed-off-by: Dan Carpenter
diff --git a/drivers/media/usb/gspca/sn9c2028.c
b/drivers/media/usb/gspca/sn9c2028.c
index c75b738..4f2050a 100644
--- a/drivers/media/usb/gspca/sn9c2028.c
+++ b/drivers/media/usb/gspca/sn9c2028.c
@@ -140,7 +140,7 @@ static int sn9c2028_long_command(struct gspca_dev
*gspca_dev, u8 *command)
status = sn9c2028_read1(gspca_dev);
if (status < 0) {
pr_err("long command status read error %d\n", status);
- return (status < 0) ? status : -EIO;
+ return status;
}
memset(reading, 0, 4);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] [media] gspca: sn9c2028: remove an unneeded condition
Hi,
On 04-06-15 10:52, Dan Carpenter wrote:
We already know status is negative because of the earlier check so there
is no need to check again.
Signed-off-by: Dan Carpenter
Makes sense:
Acked-by: Hans de Goede
Mauro, can you pick this one up directly please?
Regards,
Hans
diff --git a/drivers/media/usb/gspca/sn9c2028.c
b/drivers/media/usb/gspca/sn9c2028.c
index c75b738..4f2050a 100644
--- a/drivers/media/usb/gspca/sn9c2028.c
+++ b/drivers/media/usb/gspca/sn9c2028.c
@@ -140,7 +140,7 @@ static int sn9c2028_long_command(struct gspca_dev
*gspca_dev, u8 *command)
status = sn9c2028_read1(gspca_dev);
if (status < 0) {
pr_err("long command status read error %d\n", status);
- return (status < 0) ? status : -EIO;
+ return status;
}
memset(reading, 0, 4);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] treewide: Fix typo compatability -> compatibility
On 27 May 2015 at 16:05, Laurent Pinchart wrote: > Even though 'compatability' has a dedicated entry in the Wiktionary, > it's listed as 'Mispelling of compatibility'. Fix it. > > Signed-off-by: Laurent Pinchart > --- > drivers/net/wireless/ipw2x00/ipw2100.h | 2 +- > Acked-by: Stanislav Yakovlev for ipw2100 part. Stanislav. -- 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
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
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
Re: [PATCH][media] SI2168: Resolve unknown chip version errors with different HVR22x5 models
On 06/04/2015 03:38 PM, Steven Toth wrote: 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. 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 ? 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. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][media] SI2168: Resolve unknown chip version errors with different HVR22x5 models
I'll test it with my old code I should have hanging around still somewhere. I'm sure the chip on my card has been previously been identified as Si2168-B40 by the code (I posted the logs already earlier) and it definitely has not turned into a Si2168-D40 chip somehow. I don't think there's version D here. The third byte in the answer from the demod indicates which Si21xx chip is being used. For Si2168 there should be decimal value 68, for Si2157 there's value 57, etc. This how every single Silabs chip I've seen so far indicates it. I think it is just the fact that the ASCII value of letter D is 68 that caused you to assume that there's revision D now. In addition there's the firmware version numbering that Antti points out. I do have Si2168 devices that have the A20, A30 and B40 firmwares. Also, for all these chips I can find some references in the internet. There's nothing regarding a Si2168-D40 (which is not a conclusive proof that one would not exist, of course). Cheers, -olli On 4 June 2015 at 14:47, Antti Palosaari wrote: > On 06/04/2015 03:38 PM, Steven Toth wrote: >> >> 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. > > > 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 ? > > > 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. > > > regards > Antti > > > -- > http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][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: [PATCH][media] SI2168: Resolve unknown chip version errors with different HVR22x5 models
I compiled an old HVR-2205 driver from my git tree: https://github.com/trsqr/media_tree/tree/hvr2205 And kaboom, the device is identified correctly and correct firmware is loaded: [ 882.227379] si2168 1-0064: found a 'Silicon Labs Si2168-B40' [ 882.227763] si2168 1-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' [ 884.784024] si2168 1-0064: firmware version: 4.0.11 [ 884.822457] si2157 3-0060: found a 'Silicon Labs Si2157-A30' [ 884.898296] si2157 3-0060: firmware version: 3.0.5 I also added some additional debug to printout the chip id string returned by command 02: [ 1169.056353] si2168 1-0064: chip id string: 80 42 44 34 30 02 00 00 00 00 00 00 01 However, the current media_tree driver makes the card return the following value: 80 00 44 34 30 02 00 00 00 00 00 00 00 There is something wrong here. Why is the second byte 00 with the current driver and 42 with my old driver? I don't think we should work around this issue with the patch suggested. Cheers, -olli On 4 June 2015 at 14:57, Olli Salonen wrote: > I'll test it with my old code I should have hanging around still > somewhere. I'm sure the chip on my card has been previously been > identified as Si2168-B40 by the code (I posted the logs already > earlier) and it definitely has not turned into a Si2168-D40 chip > somehow. > > I don't think there's version D here. The third byte in the answer > from the demod indicates which Si21xx chip is being used. For Si2168 > there should be decimal value 68, for Si2157 there's value 57, etc. > This how every single Silabs chip I've seen so far indicates it. I > think it is just the fact that the ASCII value of letter D is 68 that > caused you to assume that there's revision D now. > > In addition there's the firmware version numbering that Antti points > out. I do have Si2168 devices that have the A20, A30 and B40 > firmwares. Also, for all these chips I can find some references in the > internet. There's nothing regarding a Si2168-D40 (which is not a > conclusive proof that one would not exist, of course). > > Cheers, > -olli > > > On 4 June 2015 at 14:47, Antti Palosaari wrote: >> On 06/04/2015 03:38 PM, Steven Toth wrote: >>> >>> 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. >> >> >> 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 ? >> >> >> 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. >> >> >> regards >> Antti >> >> >> -- >> http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][media] SI2168: Resolve unknown chip version errors with different HVR22x5 models
I suspect saa7164 driver. It has some strange looking I2C hacks. It has even some logic to split register and data - which I2C adapter should not be aware at all - it just should transfer bulk bytes. regards Antti On 06/04/2015 04:22 PM, Olli Salonen wrote: I compiled an old HVR-2205 driver from my git tree: https://github.com/trsqr/media_tree/tree/hvr2205 And kaboom, the device is identified correctly and correct firmware is loaded: [ 882.227379] si2168 1-0064: found a 'Silicon Labs Si2168-B40' [ 882.227763] si2168 1-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' [ 884.784024] si2168 1-0064: firmware version: 4.0.11 [ 884.822457] si2157 3-0060: found a 'Silicon Labs Si2157-A30' [ 884.898296] si2157 3-0060: firmware version: 3.0.5 I also added some additional debug to printout the chip id string returned by command 02: [ 1169.056353] si2168 1-0064: chip id string: 80 42 44 34 30 02 00 00 00 00 00 00 01 However, the current media_tree driver makes the card return the following value: 80 00 44 34 30 02 00 00 00 00 00 00 00 There is something wrong here. Why is the second byte 00 with the current driver and 42 with my old driver? I don't think we should work around this issue with the patch suggested. Cheers, -olli On 4 June 2015 at 14:57, Olli Salonen wrote: I'll test it with my old code I should have hanging around still somewhere. I'm sure the chip on my card has been previously been identified as Si2168-B40 by the code (I posted the logs already earlier) and it definitely has not turned into a Si2168-D40 chip somehow. I don't think there's version D here. The third byte in the answer from the demod indicates which Si21xx chip is being used. For Si2168 there should be decimal value 68, for Si2157 there's value 57, etc. This how every single Silabs chip I've seen so far indicates it. I think it is just the fact that the ASCII value of letter D is 68 that caused you to assume that there's revision D now. In addition there's the firmware version numbering that Antti points out. I do have Si2168 devices that have the A20, A30 and B40 firmwares. Also, for all these chips I can find some references in the internet. There's nothing regarding a Si2168-D40 (which is not a conclusive proof that one would not exist, of course). Cheers, -olli On 4 June 2015 at 14:47, Antti Palosaari wrote: On 06/04/2015 03:38 PM, Steven Toth wrote: 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. 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 ? 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. regards Antti -- http://palosaari.fi/ -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][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: [RFC] v4l: omap4iss: DT bindings development
Thank you for the replies. Laurent I have started using the platform
data to see if I can determine whether I have a software problem or a
hardware problem. One thing that is confusing me, is how are memory
resources are supposed to be properly mapped to a kernel module in a
DT enabled kernel using the hwmod abstraction layer.
It seems that the omap4iss driver in the mainline is expecting
resources to be declared in the format that was changed around about
this commit:
https://www.gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/8304f13d002dfaf618473a551dbbc35cfcdc2742
In the driver in the mainline, these resources are acquired in the
probe function by this loop here from iss.c:1397
for (i = 1; i < OMAP4_ISS_MEM_LAST; i++) { ret =
iss_map_mem_resource(pdev, iss, i); if (ret) goto error_iss; }
However the definitions of these registers have completely disappeared
in the mainline, nor are they in the master branches of linux-media or
linux-omap (see arch/arm/mach-omap2/devices.c / h). Interesting enough
the definitions for the OMAP3 ISP are still there. Furthermore looking
at the omap_hwmod_44xx_data.c in these branches I can see the hwmod
layer is only declaring the first 0xff bytes of address space starting
at 0x5200, this obviously doesn't include the CSIA/B registers nor
the CAMERARX registers which are all at addresses >0x52ff.
TLDR: omap4iss seems somewhat broken in the mainline (3.17),
linux-media (master) and linux-omap (master), which repo/branch are
you using for testing? Or what happened to the omap4_iss_resources
array?
All the best,
Michael Allwright
PhD Student
Paderborn Institute for Advanced Studies in Computer Science and Engineering
University of Paderborn
Office-number 02-47
Zukunftsmeile 1
33102 Paderborn
Germany
On 2 June 2015 at 18:22, Laurent Pinchart
wrote:
> On Tuesday 02 June 2015 09:12:25 Tony Lindgren wrote:
>> * Michael Allwright [150602 01:41]:
>> > Hi Everyone,
>> >
>> > I'm working on the DT bindings for the OMAP4 ISS at the moment, but I
>> > am unable to capture any data in my test setup. As detailed below, it
>> > seems that everything has been configured correctly however I never
>> > get any interrupts from the ISS unless I do something drastic like
>> > removing one of the wires from the clock differential pair which
>> > results in constant complex IO error interrupts from CSIA until I
>> > restore the physical connection.
>> >
>> > My test setup includes a OV6540 sensor camera module (MIPI) from
>> > Lepoard Imaging, an Duovero COM from Gumstix and breakout boards
>> > forming an interconnect between the two. The sensor is connected to
>> > CSI21 on the OMAP4 using a clock lane (on position 1, default
>> > polarity) and a single data lane (on position 2, default polarity),
>> > the sensor input clock XVCLK uses the OMAP4 auxclk1_ck channel (rounds
>> > to 19.2MHz when asked for 24MHz).
>> >
>> > The relevant parts of my device tree can be seen here:
>> > https://gist.github.com/allsey87/fdf1feb6eb6a94158638 - I'm actually
>> > somewhat unclear what effect stating the ti,hwmod="iss" parameter has.
>> > Does anything else need to be done here? As far as I can tell I think
>> > all clocks and power has been switched on. I do make two function
>> > calls to the PM API in the ISS probe function, i.e.:
>> >
>> > pm_runtime_enable(&pdev->dev);
>> > r = pm_runtime_get_sync(&pdev->dev);
>>
>> The ti,hwmod = "iss" hooks up the device with the PM runtime, see
>> omap_hwmod_44xx_data.c for "iss".
>>
>> > Regarding my debugging, this is what I have checked so far
>> >
>> > * Changing the pixel rate of the sensor - this lead me to discover a
>> > possible bug in iss.c or perhaps my ov5640 driver, as the
>> > V4L2_CID_PIXEL_RATE control was always returning zero. I patched this
>> > by copying what Laurent has done in the OMAP3ISP driver which now
>> > works.
>> > * As I only have a 100MHz scope, I had to slow down the camera
>> > significantly (MIPI clock => 10-12MHz range) to verify that I was
>> > getting reasonable output from the sensor (i.e. signals that were
>> > characteristic of CSI2/MIPI). I checked the calculations and made sure
>> > these updated values came across via the V4L2_CID_PIXEL_RATE control
>> > and ended up in the THS_TERM and THS_SETTLE fields of register 0.
>> > * Using the omapconf tool, I have manually and one by one pulled up
>> > the CSI2 pins and verified multiple times all connections to the
>> > sensor module and have even manually tried swapping the DP/DN pairs in
>> > case they were still somehow backwards despite previous testing
>> > * Verified that the interrupt service routine is called by generating
>> > a test interrupt HS_VS from inside the ISS i.e.
>> >
>> > ./omapconf write ISS_HL_IRQENABLE_SET_5 0x0002
>> > ./omapconf write ISS_HL_IRQSTATUS_RAW_5 0x0002
>> >
>> > * Verified that the default CMA region is being used, it ends up in
>> > the ping-pong resisters of the ISS.
>> >
>> > Additional information:
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
Vinod, On 06/02/2015 03:55 PM, Vinod Koul wrote: > On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote: >> On 05/29/2015 01:18 PM, Vinod Koul wrote: >>> On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote: On Fri, May 29, 2015 at 11:33 AM, Vinod Koul wrote: > On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote: >> dma_request_slave_channel_compat() 'eats' up the returned error codes >> which >> prevents drivers using the compat call to be able to do deferred probing. >> >> The new wrapper is identical in functionality but it will return with >> error >> code in case of failure and will pass the -EPROBE_DEFER to the caller in >> case dma_request_slave_channel_reason() returned with it. > This is okay but am worried about one more warpper, how about fixing > dma_request_slave_channel_compat() Then all callers of dma_request_slave_channel_compat() have to be modified to handle ERR_PTR first. The same is true for (the existing) dma_request_slave_channel_reason() vs. dma_request_slave_channel(). >>> Good point, looking again, I think we should rather fix >>> dma_request_slave_channel_reason() as it was expected to return err code and >>> add new users. Anyway users of this API do expect the reason... >> >> Hrm, they are for different use.dma_request_slave_channel()/_reason() is for >> drivers only working via DT or ACPI while >> dma_request_slave_channel_compat()/_reason() is for drivers expected to run >> in >> DT/ACPI or legacy mode as well. >> >> I added the dma_request_slave_channel_compat_reason() because OMAP/daVinci >> drivers are using this to request channels - they need to support DT and >> legacy mode. > I think we should hide these things behind the API and do this behind the > hood for ACPI/DT systems. > > Also it makes sense to use right API and mark rest as depricated So to convert the dma_request_slave_channel_compat() and not to create _reason variant? Or to have single API to request channel? The problem with that is that we need different parameters for legacy and DT for example. >> >> But it is doable to do this for both the non _compat and _compat version: >> 1. change all users to check IS_ERR_OR_NULL(chan) >> return the PTR_ERR if not NULL, or do whatever the driver was doing in case >> of chan == NULL. >> 2. change the non _compat and _compat versions to do the same as the _reason >> variants, #define the _reason ones to the non _reason names >> 3. Rename the _reason use to non _reason function in drivers >> 4. Remove the #defines for the _reason functions >> 5. Change the IS_ERR_OR_NULL(chan) to IS_ERR(chan) in all drivers >> The result: >> Both dma_request_slave_channel() and dma_request_slave_channel_compat() will >> return ERR_PTR in case of failure or in success they will return the pinter >> to >> chan. >> >> Is this what you were asking? >> It is a bit broader than what this series was doing: taking care of >> OMAP/daVinci drivers for deferred probing regarding to dmaengine ;) > Yes but it would make sense right? I know it is a larger work but then we > wouldn't want another dma_request_slave_xxx API, at some point we have stop > it exapnding, perhpas now :) Yes, it make sense to get rid if the _reason() things and have the dma_request_slave_channel() and dma_request_slave_channel_compat() return with error code One thing we need to do for this is to change the error codes coming back from the _dt() and _acpi() calls when we boot in legacy mode. Right now the only error code which comes back is -ENODEV and -EPROBE_DEFER. We need to differentiate between 'real' errors and from the fact that we did not booted with DT or the ACPI is not available. IMHO if we boot with DT and the channel request fails with other than -EPROBE_DEFER we should not go and try to get the channel via legacy API. > Yes I am all ears to stage this work and not do transition gardually.. > -- Péter -- 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: si2168/dvbsky - blind-scan for DVB-T2 with PLP fails
How can I enable debug-output to get the log-messages like
http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/dvb-frontends/si2168.c#n164
?
Am 28.05.2015 07:26, schrieb Antti Palosaari:
On 05/28/2015 01:27 AM, Hurda wrote:
Hello.
I think I came across a bug in either of the drivers si2168 and dvbsky
regarding
blind-scanning DVB-T2-frequencies.
HW: Technotrend CT2-4400v2 (afaik based on or the same as DVBSky T330)
demod: Si2168-B40
tuner: Si2158-A20
OS: Ubuntu 15.04 (kernel 3.19)
In Austria, the DVB-T2-service "SimpliTV" is currently airing up to four
muxes, next to one or two DVB-T-muxes.
In my region, the frequencies are 490MHz, 546MHz, 690MHz, 714MHz for
DVB-T2,
and 498MHz for DVB-T.
These numbers might be of interest when reading the logs.
The peculiar aspect of these T2-muxes is that they're aired on PLP 1
without
there being a PLP 0. I think this is also the root of my problem.
dvbv5-scan is working, but w_scan not?
Could you hack si2168.c file and test?
if (c->delivery_system == SYS_DVBT2) {
/* select PLP */
cmd.args[0] = 0x52;
cmd.args[1] = c->stream_id & 0xff;
//cmd.args[2] = c->stream_id == NO_STREAM_ID_FILTER ? 0 : 1;
cmd.args[2] = 0;
cmd.wlen = 3;
cmd.rlen = 1;
ret = si2168_cmd_execute(client, &cmd);
if (ret)
goto err;
}
Antti
When doing a blind-scan using w_scan 20140727 on Ubuntu 15.04 (kernel
3.19),
w_scan does not find any of these four DVB-T2-muxes.
It just finds the DVB-T-mux.
Logs:
media-tree_dmesg_lsusb.txt http://pastebin.com/0ixFPMSA
media-tree_w_scan.txt http://pastebin.com/yyG3jSwj
The found transponder:
initial_v3_media_build_trunk.conf http://pastebin.com/LmFQavpy
initial_v5.conf http://pastebin.com/Jx6kymVt
I also tried a fresh checkout from git.linuxtv.org as of last weekend
and the
most recent w_scan version (20141122).
As you can see, w_scan tries to tune(?) the DVB-T2-frequencies, but
ultimately doesn't find anything on them.
Then I tried the DVBSky-linux-driver[1]
(media_build-bst-20150322.tar.gz)[2]
from their site, which is using a binary called sit2 for this card.
Using this driver, w_scan found all four DVB-T2-muxes and the DVB-T-mux.
Additionally, it found the DVB-T2-muxes during the DVB-T-scan.
Logs:
media_build-bst_dmesg_lsusb.txt http://pastebin.com/vJeDMxtu
media_build-bst_w_scan.txt http://pastebin.com/yhwAYjen
Found transponders:
initial_v3_bst.conf http://pastebin.com/ECKQvRWX
initial_v5_bst.conf http://pastebin.com/CbhY6Hpz
Of course, doing a channel-scan using dvbv5-scan on these transponders
worked
too:
dvbv5_sit2.conf http://pastebin.com/3W52bbhv
dvbv5_sit2.log http://pastebin.com/nc66PTkt
Afterwards, I tried to do a channel-scan with the same initial tuning-file
using the opensource-driver, which also worked:
dvbv5_si2168.conf http://pastebin.com/A6FbqUL1
dvbv5_si2168.log http://pastebin.com/ewyVPJR2
This should verify that tuning PLP 1 without there being PLP 0 is not
the issue.
Additionally, if you compare the two channel-lists, you find interesting
differences:
The scan with si2168 has AUTO for "MODULATION" and "INVERSION" for
DVB-T2-channels, and for "CODE_RATE_LP" and "INVERSION" for DVB-T-channels.
The scan with sit2 has the respective values in the channel-list.
The dvbv5-scan-logs also differ, as using sit2 also displays the signal
quality
during tuning.
I know that there were changes regarding DVB-T2-scanning[3], but as the
blog-
article specifically mentions si2168 and w_scan to be fully dvbv5-compliant
and good for using with DVB-T2, I thought you should know about this
particular problem.
In the attachment I've packed the previously linked logs, for archival
reasons.
Thank you for your attention.
[1] http://www.dvbsky.net/Support_linux.html
[2] http://www.dvbsky.net/download/linux/media_build-bst-150322.tar.gz
[3] http://blog.palosaari.fi/2014/09/linux-dvb-t2-tuning-problems.html
PS: Interesting comments regarding auto-detection for si2168:
http://blog.palosaari.fi/2014/09/linux-dvb-t2-tuning-problems.html?showComment=1427233615765#c8591459871945922951
http://blog.palosaari.fi/2014/09/linux-dvb-t2-tuning-problems.html?showComment=1427234034259#c6500661729983566638
--
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: si2168/dvbsky - blind-scan for DVB-T2 with PLP fails
On 06/04/2015 08:36 PM, Hurda wrote:
How can I enable debug-output to get the log-messages like
http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/dvb-frontends/si2168.c#n164
?
Compile kernel with dynamic debugs. After that you could enable debugs:
modprobe si2168; echo -n 'module si2168 =pft' >
/sys/kernel/debug/dynamic_debug/control
Antti
Am 28.05.2015 07:26, schrieb Antti Palosaari:
On 05/28/2015 01:27 AM, Hurda wrote:
Hello.
I think I came across a bug in either of the drivers si2168 and dvbsky
regarding
blind-scanning DVB-T2-frequencies.
HW: Technotrend CT2-4400v2 (afaik based on or the same as DVBSky T330)
demod: Si2168-B40
tuner: Si2158-A20
OS: Ubuntu 15.04 (kernel 3.19)
In Austria, the DVB-T2-service "SimpliTV" is currently airing up to four
muxes, next to one or two DVB-T-muxes.
In my region, the frequencies are 490MHz, 546MHz, 690MHz, 714MHz for
DVB-T2,
and 498MHz for DVB-T.
These numbers might be of interest when reading the logs.
The peculiar aspect of these T2-muxes is that they're aired on PLP 1
without
there being a PLP 0. I think this is also the root of my problem.
dvbv5-scan is working, but w_scan not?
Could you hack si2168.c file and test?
if (c->delivery_system == SYS_DVBT2) {
/* select PLP */
cmd.args[0] = 0x52;
cmd.args[1] = c->stream_id & 0xff;
//cmd.args[2] = c->stream_id == NO_STREAM_ID_FILTER ? 0 : 1;
cmd.args[2] = 0;
cmd.wlen = 3;
cmd.rlen = 1;
ret = si2168_cmd_execute(client, &cmd);
if (ret)
goto err;
}
Antti
When doing a blind-scan using w_scan 20140727 on Ubuntu 15.04 (kernel
3.19),
w_scan does not find any of these four DVB-T2-muxes.
It just finds the DVB-T-mux.
Logs:
media-tree_dmesg_lsusb.txt http://pastebin.com/0ixFPMSA
media-tree_w_scan.txt http://pastebin.com/yyG3jSwj
The found transponder:
initial_v3_media_build_trunk.conf http://pastebin.com/LmFQavpy
initial_v5.conf http://pastebin.com/Jx6kymVt
I also tried a fresh checkout from git.linuxtv.org as of last weekend
and the
most recent w_scan version (20141122).
As you can see, w_scan tries to tune(?) the DVB-T2-frequencies, but
ultimately doesn't find anything on them.
Then I tried the DVBSky-linux-driver[1]
(media_build-bst-20150322.tar.gz)[2]
from their site, which is using a binary called sit2 for this card.
Using this driver, w_scan found all four DVB-T2-muxes and the DVB-T-mux.
Additionally, it found the DVB-T2-muxes during the DVB-T-scan.
Logs:
media_build-bst_dmesg_lsusb.txt http://pastebin.com/vJeDMxtu
media_build-bst_w_scan.txt http://pastebin.com/yhwAYjen
Found transponders:
initial_v3_bst.conf http://pastebin.com/ECKQvRWX
initial_v5_bst.conf http://pastebin.com/CbhY6Hpz
Of course, doing a channel-scan using dvbv5-scan on these transponders
worked
too:
dvbv5_sit2.conf http://pastebin.com/3W52bbhv
dvbv5_sit2.log http://pastebin.com/nc66PTkt
Afterwards, I tried to do a channel-scan with the same initial
tuning-file
using the opensource-driver, which also worked:
dvbv5_si2168.conf http://pastebin.com/A6FbqUL1
dvbv5_si2168.log http://pastebin.com/ewyVPJR2
This should verify that tuning PLP 1 without there being PLP 0 is not
the issue.
Additionally, if you compare the two channel-lists, you find interesting
differences:
The scan with si2168 has AUTO for "MODULATION" and "INVERSION" for
DVB-T2-channels, and for "CODE_RATE_LP" and "INVERSION" for
DVB-T-channels.
The scan with sit2 has the respective values in the channel-list.
The dvbv5-scan-logs also differ, as using sit2 also displays the signal
quality
during tuning.
I know that there were changes regarding DVB-T2-scanning[3], but as the
blog-
article specifically mentions si2168 and w_scan to be fully
dvbv5-compliant
and good for using with DVB-T2, I thought you should know about this
particular problem.
In the attachment I've packed the previously linked logs, for archival
reasons.
Thank you for your attention.
[1] http://www.dvbsky.net/Support_linux.html
[2] http://www.dvbsky.net/download/linux/media_build-bst-150322.tar.gz
[3] http://blog.palosaari.fi/2014/09/linux-dvb-t2-tuning-problems.html
PS: Interesting comments regarding auto-detection for si2168:
http://blog.palosaari.fi/2014/09/linux-dvb-t2-tuning-problems.html?showComment=1427233615765#c8591459871945922951
http://blog.palosaari.fi/2014/09/linux-dvb-t2-tuning-problems.html?showComment=1427234034259#c6500661729983566638
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] clk: change clk_ops' ->round_rate() prototype
Hi folks just a brief comment on this one: On Thu, 30 Apr 2015, Boris Brezillon wrote: > Clock rates are stored in an unsigned long field, but ->round_rate() > (which returns a rounded rate from a requested one) returns a long > value (errors are reported using negative error codes), which can lead > to long overflow if the clock rate exceed 2Ghz. > > Change ->round_rate() prototype to return 0 or an error code, and pass the > requested rate as a pointer so that it can be adjusted depending on > hardware capabilities. ... > diff --git a/Documentation/clk.txt b/Documentation/clk.txt > index 0e4f90a..fca8b7a 100644 > --- a/Documentation/clk.txt > +++ b/Documentation/clk.txt > @@ -68,8 +68,8 @@ the operations defined in clk.h: > int (*is_enabled)(struct clk_hw *hw); > unsigned long (*recalc_rate)(struct clk_hw *hw, > unsigned long parent_rate); > - long(*round_rate)(struct clk_hw *hw, > - unsigned long rate, > + int (*round_rate)(struct clk_hw *hw, > + unsigned long *rate, > unsigned long *parent_rate); > long(*determine_rate)(struct clk_hw *hw, > unsigned long rate, I'd suggest that we should probably go straight to 64-bit rates. There are already plenty of clock sources that can generate rates higher than 4GiHz. - Paul -- 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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri Jun 5 04:02:25 CEST 2015 git branch: test git hash: c1c3c85ddf60a6d97c122d57d385b4929fcec4b3 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-i686: WARNINGS linux-4.1-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: WARNINGS linux-4.1-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5] [media] saa7164: use an MSI interrupt when available
This has been plaguing users for years (there's a number of threads on
the Ubuntu board). I've been using revision 1 of the patch without
issue since early February. This is from having to constantly reboot
the system to flawless recording. If something has been outstanding
from Brendan, please let me know and I'll happily make the requested
changes.
Can we please merge this? There are at-least three consumers in this
thread alone that have confirmed this fixes the saa7164 driver for the
HVR-2250 device.
Kyle.
PS: I can't seem to source out who owns this in the MAINTAINERS file?
On Thu, Apr 9, 2015 at 11:39 PM, Brendan McGrath
wrote:
> 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 both digital tuners of the saa7164 chip is in use. A
> reported example can be found here:
> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/83948
>
> Reviewed-by: Steven Toth
> Signed-off-by: Brendan McGrath
> ---
> Changes since v4:
> - improved readability by taking on suggestions made by Mauro
> - the msi variable in the saa7164_dev structure is now a bool
>
> Thanks Mauro - good suggestions and I think I've taken on board all of them.
>
> drivers/media/pci/saa7164/saa7164-core.c | 66
>
> drivers/media/pci/saa7164/saa7164.h | 1 +
> 2 files changed, 60 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/pci/saa7164/saa7164-core.c
> b/drivers/media/pci/saa7164/saa7164-core.c
> index 9cf3c6c..5e4a9f0 100644
> --- a/drivers/media/pci/saa7164/saa7164-core.c
> +++ b/drivers/media/pci/saa7164/saa7164-core.c
> @@ -85,6 +85,11 @@ module_param(guard_checking, int, 0644);
> MODULE_PARM_DESC(guard_checking,
> "enable dma sanity checking for buffer overruns");
>
> +static bool enable_msi = true;
> +module_param(enable_msi, bool, 0444);
> +MODULE_PARM_DESC(enable_msi,
> + "enable the use of an msi interrupt if available");
> +
> static unsigned int saa7164_devcount;
>
> static DEFINE_MUTEX(devlist);
> @@ -1184,6 +1189,39 @@ static int saa7164_thread_function(void *data)
> return 0;
> }
>
> +static bool saa7164_enable_msi(struct pci_dev *pci_dev, struct saa7164_dev
> *dev)
> +{
> + int err;
> +
> + if (!enable_msi) {
> + printk(KERN_WARNING "%s() MSI disabled by module parameter
> 'enable_msi'"
> + , __func__);
> + return false;
> + }
> +
> + err = pci_enable_msi(pci_dev);
> +
> + if (err) {
> + printk(KERN_ERR "%s() Failed to enable MSI interrupt."
> + " Falling back to a shared IRQ\n", __func__);
> + return false;
> + }
> +
> + /* no error - so request an msi interrupt */
> + err = request_irq(pci_dev->irq, saa7164_irq, 0,
> + dev->name, dev);
> +
> + if (err) {
> + /* fall back to legacy interrupt */
> + printk(KERN_ERR "%s() Failed to get an MSI interrupt."
> + " Falling back to a shared IRQ\n", __func__);
> + pci_disable_msi(pci_dev);
> + return false;
> + }
> +
> + return true;
> +}
> +
> static int saa7164_initdev(struct pci_dev *pci_dev,
>const struct pci_device_id *pci_id)
> {
> @@ -1230,13 +1268,22 @@ static int saa7164_initdev(struct pci_dev *pci_dev,
> goto fail_irq;
> }
>
> - err = request_irq(pci_dev->irq, saa7164_irq,
> - IRQF_SHARED, dev->name, dev);
> - if (err < 0) {
> - printk(KERN_ERR "%s: can't get IRQ %d\n", dev->name,
> - pci_dev->irq);
> - err = -EIO;
> - goto fail_irq;
> + /* irq bit */
> + if (saa7164_enable_msi(pci_dev, dev)) {
> + dev->msi = true;
> + } else {
> + /* if we have an error (i.e. we don't have an interrupt)
> +or msi is not enabled - fallback to shared interrupt
> */
> +
> + err = request_irq(pci_dev->irq, saa7164_irq,
> + IRQF_SHARED, dev->name, dev);
> +
> + if (err < 0) {
> + printk(KERN_ERR "%s: can't get IRQ %d\n", dev->name,
> + pci_dev->irq);
> + err = -EIO;
> + goto fail_irq;
> + }
> }
>
> pci_set_drvdata(pci_dev, dev);
> @@ -1439,6 +1486,11 @@ static void saa7164_finidev(struct pci_dev *pci_dev)
> /* unregister stuff */
> free_irq(pci_dev->irq, dev);
>
> + if (dev->msi) {
> + pci_disable_msi(pci_dev);
> + dev->msi = false;
> + }
>
Re: [PATCHv5] [media] saa7164: use an MSI interrupt when available
Hi Kyle,
Great to hear you haven't had any problems since applying this patch!
I'm looking forward to seeing it in the Linux master branch too.
Version 5 of the patch has been accepted and committed to the media tree
by Mauro:
http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?id=77978089ddc90347644cc057e6b6cd169ac9abd4
I'm guessing it will therefore go in to the main Linux tree with the
release of kernel version v4.2? (or it can be submitted as a fix for
v4.1 - but I have no idea how a patch is selected on that criteria).
Hopefully someone can confirm or elaborate.
Regards,
Brendan McGrath
On 05/06/15 14:42, Kyle Sanderson wrote:
This has been plaguing users for years (there's a number of threads on
the Ubuntu board). I've been using revision 1 of the patch without
issue since early February. This is from having to constantly reboot
the system to flawless recording. If something has been outstanding
from Brendan, please let me know and I'll happily make the requested
changes.
Can we please merge this? There are at-least three consumers in this
thread alone that have confirmed this fixes the saa7164 driver for the
HVR-2250 device.
Kyle.
PS: I can't seem to source out who owns this in the MAINTAINERS file?
On Thu, Apr 9, 2015 at 11:39 PM, Brendan McGrath
wrote:
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 both digital tuners of the saa7164 chip is in use. A
reported example can be found here:
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/83948
Reviewed-by: Steven Toth
Signed-off-by: Brendan McGrath
---
Changes since v4:
- improved readability by taking on suggestions made by Mauro
- the msi variable in the saa7164_dev structure is now a bool
Thanks Mauro - good suggestions and I think I've taken on board all of them.
drivers/media/pci/saa7164/saa7164-core.c | 66
drivers/media/pci/saa7164/saa7164.h | 1 +
2 files changed, 60 insertions(+), 7 deletions(-)
diff --git a/drivers/media/pci/saa7164/saa7164-core.c
b/drivers/media/pci/saa7164/saa7164-core.c
index 9cf3c6c..5e4a9f0 100644
--- a/drivers/media/pci/saa7164/saa7164-core.c
+++ b/drivers/media/pci/saa7164/saa7164-core.c
@@ -85,6 +85,11 @@ module_param(guard_checking, int, 0644);
MODULE_PARM_DESC(guard_checking,
"enable dma sanity checking for buffer overruns");
+static bool enable_msi = true;
+module_param(enable_msi, bool, 0444);
+MODULE_PARM_DESC(enable_msi,
+ "enable the use of an msi interrupt if available");
+
static unsigned int saa7164_devcount;
static DEFINE_MUTEX(devlist);
@@ -1184,6 +1189,39 @@ static int saa7164_thread_function(void *data)
return 0;
}
+static bool saa7164_enable_msi(struct pci_dev *pci_dev, struct saa7164_dev
*dev)
+{
+ int err;
+
+ if (!enable_msi) {
+ printk(KERN_WARNING "%s() MSI disabled by module parameter
'enable_msi'"
+ , __func__);
+ return false;
+ }
+
+ err = pci_enable_msi(pci_dev);
+
+ if (err) {
+ printk(KERN_ERR "%s() Failed to enable MSI interrupt."
+ " Falling back to a shared IRQ\n", __func__);
+ return false;
+ }
+
+ /* no error - so request an msi interrupt */
+ err = request_irq(pci_dev->irq, saa7164_irq, 0,
+ dev->name, dev);
+
+ if (err) {
+ /* fall back to legacy interrupt */
+ printk(KERN_ERR "%s() Failed to get an MSI interrupt."
+ " Falling back to a shared IRQ\n", __func__);
+ pci_disable_msi(pci_dev);
+ return false;
+ }
+
+ return true;
+}
+
static int saa7164_initdev(struct pci_dev *pci_dev,
const struct pci_device_id *pci_id)
{
@@ -1230,13 +1268,22 @@ static int saa7164_initdev(struct pci_dev *pci_dev,
goto fail_irq;
}
- err = request_irq(pci_dev->irq, saa7164_irq,
- IRQF_SHARED, dev->name, dev);
- if (err < 0) {
- printk(KERN_ERR "%s: can't get IRQ %d\n", dev->name,
- pci_dev->irq);
- err = -EIO;
- goto fail_irq;
+ /* irq bit */
+ if (saa7164_enable_msi(pci_dev, dev)) {
+ dev->msi = true;
+ } else {
+ /* if we have an error (i.e. we don't have an interrupt)
+or msi is not enabled - fallback to shared interrupt */
+
+ err = request_irq(pci_dev->irq, saa7164_irq,
+ IRQF_SHARED, dev->name, dev);
+
+ if (err < 0) {
+ printk(KERN_ERR "%s: can't get IRQ %d\n", dev->name,
+
[PATCHv2] Improve Y16 color setup
Currently the colors for the Y16 and Y16_BE pixelformats are in the range 0x-0xff00. So pure white (0x) is never created. Improve this by making white really white. For other colors the lsb remains 0 so vivid can be used to detect endian problems. Signed-off-by: Hans Verkuil diff --git a/drivers/media/platform/vivid/vivid-tpg.c b/drivers/media/platform/vivid/vivid-tpg.c index b1147f2..1b94503 100644 --- a/drivers/media/platform/vivid/vivid-tpg.c +++ b/drivers/media/platform/vivid/vivid-tpg.c @@ -900,12 +900,19 @@ static void gen_twopix(struct tpg_data *tpg, buf[0][offset] = r_y; break; case V4L2_PIX_FMT_Y16: - buf[0][offset] = 0; + /* +* Ideally both bytes should be set to r_y, but then you won't +* be able to detect endian problems. So keep it 0 except for +* the corner case where r_y is 0xff so white really will be +* white (0x). +*/ + buf[0][offset] = r_y == 0xff ? r_y : 0; buf[0][offset+1] = r_y; break; case V4L2_PIX_FMT_Y16_BE: + /* See comment for V4L2_PIX_FMT_Y16 above */ buf[0][offset] = r_y; - buf[0][offset+1] = 0; + buf[0][offset+1] = r_y == 0xff ? r_y : 0; break; case V4L2_PIX_FMT_YUV422P: case V4L2_PIX_FMT_YUV420: -- 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
