Re: [patch][saa7134] do not change mute state for capturing audio
23.07.2011 05:28, Mauro Carvalho Chehab wrote: Mplayer was just one example of an application that I know it doesn't call V4L2_CID_AUDIO_MUTE to unmute. I would suggest fixing all such an apps, even if we are not going to change that in the driver. Your approach of moving it to VIDIOC_S_FREQUENCY (if I understood well) won't work, as, every time someone would change the channel, it will be unmuted, causing troubles on applications like scantv (part of xawtv). But how can scantv (or anything else) rely on the fact that the board was muted when that app starts? I guess it can't, and mutes it explicitly first, no? -- 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] add support for the dvb-t part of CT-3650 v3
On Sábado, 23 de Julio de 2011 00:23:05 Antti Palosaari escribió:
On 07/23/2011 12:49 AM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 20:12:20 Jose Alberto Reguero escribió:
On Viernes, 22 de Julio de 2011 18:46:24 Antti Palosaari escribió:
On 07/22/2011 07:25 PM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 18:08:39 Antti Palosaari escribió:
On 07/22/2011 07:02 PM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 13:32:53 Antti Palosaari escribió:
Have you had to time test these?
And about I2C adapter, I don't see why changes are needed. As far
as I understand it is already working with TDA10023 and you have
done changes for TDA10048 support. I compared TDA10048 and
TDA10023 I2C functions and those are ~similar. Both uses most
typical access, for reg write {u8 REG, u8 VAL} and for reg read
{u8 REG}/{u8 VAL}.
regards
Antti
I just finish the testing. The changes to I2C are for the tuner
tda827x. The MFE fork fine. I need to change the code in tda10048
and ttusb2. Attached is the patch for CT-3650 with your MFE patch.
You still pass tda10023 fe pointer to tda10048 for I2C-gate control
which is wrong. Could you send USB sniff I can look what there really
happens. If you have raw SniffUSB2 logs I wish to check those, other
logs are welcome too if no raw SniffUSB2 available.
Youre chnage don't work. You need to change the function i2c gate of
tda1048 for the one of tda1023, but the parameter of this function
must be the fe pointer of tda1023. If this is a problem, I can
duplicate tda1023 i2c gate in ttusb2 code and pass it to the
tda10048. It is done this way in the first patch of this thread.
Yes I now see why it cannot work - since FE is given as a parameter to
i2c_gate_ctrl it does not see correct priv and used I2C addr is read
from priv. You must implement own i2c_gate_ctrl in ttusb2 driver.
Implement own ct3650_i2c_gate_ctrl and override tda10048 i2c_gate_ctrl
using that. Then call tda10023 i2c_gate_ctrl but instead of tda10048 FE
use td10023 FE. Something like
static int ct3650_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)
{
return adap-mfe[0]-ops.i2c_gate_ctrl(POINTER_TO_TDA10023_FE,
enable);
}
/* tuner is behind TDA10023 I2C-gate */
adap-mfe[1]-ops.i2c_gate_ctrl = ct3650_i2c_gate_ctrl;
Could you still send USB logs? I don't see it correct behaviour you
need to change I2C-adaper when same tuner is used for DVB-T because it
was already working in DVB-C mode.
regards
Antti
Thanks, I try to implement that. I attach a processed log. It prints the
first line of a usb command and the first line of the returned byes. If
you want the full log I can upload it where you want.
Jose Alberto
New version with Antti's sugestion.
GOOD! As you can see implementing things correctly drops also much lines
of code! No more ugly hacks in TDA10048 driver.
But now you must fix that I2C-adapter. I looked sniffs and tda827x
driver. I2C is rather clear. tda827x uses a little bit unusual I2C read.
Normally reads are done as I2C write+read combination, that tuner, as
many other NXP tuners, uses only single read and it is starting always
from reg 0.
It looked for my eyes that it will never do read operation as in read
there is num = 1, msg[0].flags = I2C_M_RD
ttusb2_i2c_xfer():
for (i = 0; i num; i++) {
read = i+1 num (msg[i+1].flags I2C_M_RD);
But in the case it have been working for DVB-C I don't understand why it
does not work for DVB-T. And thus I really suspect your changes to
I2C-adapter are not needed. So whats the problem using original I2C
adapter? What does it print when debugs are enabled. Is there some
errors in log?
Also looking from sniffs, it seems that this could be wrong:
(rlen 0 r[3] != rlen)) {
warn(there might have been an error during control message
transfer.
(rlen = %d, was %d),rlen,r[3]);
regards
Antti
The problem is in i2c read in tda827x_probe_version. Without the fix sometimes,
when changing the code the tuner is detected as tda827xo instead of tda827xa.
That is because the variable where i2c read should store the value is
initialized, and sometimes it works.
Jose Alberto
--
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] cxd2820r: fix possible out-of-array lookup
On Sat, 2011-07-23 at 01:47 +0200, HoP wrote: 2011/7/23 Antti Palosaari cr...@iki.fi: On 07/23/2011 02:31 AM, Antti Palosaari wrote: On 07/23/2011 02:01 AM, HoP wrote: 2011/7/23 Antti Palosaaricr...@iki.fi: But now I see what you mean. msg2[1] is set as garbage fields in case of incoming msg len is 1. True, but it does not harm since it is not used in that case. In case of write, cxd2820r_tuner_i2c_xfer() gets msg[] parameter with only one element, true? If so, then my patch is correct. Yes it is true but nonsense. It is also wrong to make always msg2 as two element array too, but those are just simpler and generates most likely some code less. Could you see it can cause problem in some case? Now I thought it more, could it crash if it point out of memory area? Arrays are not fussy they will read anything, just don't poke them :-) I see you finally understood what I wanted to do :-) I'm surprised that it not crashed already. I thought I have to missed something. It does not crash because num is constant throughout, when the number of messages is one the second element isn't transferred. -- 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] add support for the dvb-t part of CT-3650 v3
On 07/23/2011 11:26 AM, Jose Alberto Reguero wrote:
On Sábado, 23 de Julio de 2011 00:23:05 Antti Palosaari escribió:
On 07/23/2011 12:49 AM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 20:12:20 Jose Alberto Reguero escribió:
On Viernes, 22 de Julio de 2011 18:46:24 Antti Palosaari escribió:
On 07/22/2011 07:25 PM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 18:08:39 Antti Palosaari escribió:
On 07/22/2011 07:02 PM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 13:32:53 Antti Palosaari escribió:
Have you had to time test these?
And about I2C adapter, I don't see why changes are needed. As far
as I understand it is already working with TDA10023 and you have
done changes for TDA10048 support. I compared TDA10048 and
TDA10023 I2C functions and those are ~similar. Both uses most
typical access, for reg write {u8 REG, u8 VAL} and for reg read
{u8 REG}/{u8 VAL}.
regards
Antti
I just finish the testing. The changes to I2C are for the tuner
tda827x. The MFE fork fine. I need to change the code in tda10048
and ttusb2. Attached is the patch for CT-3650 with your MFE patch.
You still pass tda10023 fe pointer to tda10048 for I2C-gate control
which is wrong. Could you send USB sniff I can look what there really
happens. If you have raw SniffUSB2 logs I wish to check those, other
logs are welcome too if no raw SniffUSB2 available.
Youre chnage don't work. You need to change the function i2c gate of
tda1048 for the one of tda1023, but the parameter of this function
must be the fe pointer of tda1023. If this is a problem, I can
duplicate tda1023 i2c gate in ttusb2 code and pass it to the
tda10048. It is done this way in the first patch of this thread.
Yes I now see why it cannot work - since FE is given as a parameter to
i2c_gate_ctrl it does not see correct priv and used I2C addr is read
from priv. You must implement own i2c_gate_ctrl in ttusb2 driver.
Implement own ct3650_i2c_gate_ctrl and override tda10048 i2c_gate_ctrl
using that. Then call tda10023 i2c_gate_ctrl but instead of tda10048 FE
use td10023 FE. Something like
static int ct3650_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)
{
return adap-mfe[0]-ops.i2c_gate_ctrl(POINTER_TO_TDA10023_FE,
enable);
}
/* tuner is behind TDA10023 I2C-gate */
adap-mfe[1]-ops.i2c_gate_ctrl = ct3650_i2c_gate_ctrl;
Could you still send USB logs? I don't see it correct behaviour you
need to change I2C-adaper when same tuner is used for DVB-T because it
was already working in DVB-C mode.
regards
Antti
Thanks, I try to implement that. I attach a processed log. It prints the
first line of a usb command and the first line of the returned byes. If
you want the full log I can upload it where you want.
Jose Alberto
New version with Antti's sugestion.
GOOD! As you can see implementing things correctly drops also much lines
of code! No more ugly hacks in TDA10048 driver.
But now you must fix that I2C-adapter. I looked sniffs and tda827x
driver. I2C is rather clear. tda827x uses a little bit unusual I2C read.
Normally reads are done as I2C write+read combination, that tuner, as
many other NXP tuners, uses only single read and it is starting always
from reg 0.
It looked for my eyes that it will never do read operation as in read
there is num = 1, msg[0].flags = I2C_M_RD
ttusb2_i2c_xfer():
for (i = 0; i num; i++) {
read = i+1 num (msg[i+1].flags I2C_M_RD);
But in the case it have been working for DVB-C I don't understand why it
does not work for DVB-T. And thus I really suspect your changes to
I2C-adapter are not needed. So whats the problem using original I2C
adapter? What does it print when debugs are enabled. Is there some
errors in log?
Also looking from sniffs, it seems that this could be wrong:
(rlen 0 r[3] != rlen)) {
warn(there might have been an error during control message
transfer.
(rlen = %d, was %d),rlen,r[3]);
regards
Antti
The problem is in i2c read in tda827x_probe_version. Without the fix sometimes,
when changing the code the tuner is detected as tda827xo instead of tda827xa.
That is because the variable where i2c read should store the value is
initialized, and sometimes it works.
struct i2c_msg msg = { .addr = priv-i2c_addr, .flags = I2C_M_RD,
.buf = data, .len = 1 };
rc = tuner_transfer(fe, msg, 1);
:-( Could you read what I write. It is a little bit annoying to find out
everything for you. You just answer every time something like it does
not work and I should always find out what's problem.
As I pointed out read will never work since I2C adapter supports only
read done in WRITE+READ combination. Driver uses read which is single
READ without write.
You should implement new read. You can look example from af9015 or other
drivers using tda827x
This have been never worked thus I Cc Guy Martin who have added DVB-C
support for that device.
regards
Antti
--
Re: [PATCH] add support for the dvb-t part of CT-3650 v3
On Sábado, 23 de Julio de 2011 11:42:58 Antti Palosaari escribió:
On 07/23/2011 11:26 AM, Jose Alberto Reguero wrote:
On Sábado, 23 de Julio de 2011 00:23:05 Antti Palosaari escribió:
On 07/23/2011 12:49 AM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 20:12:20 Jose Alberto Reguero escribió:
On Viernes, 22 de Julio de 2011 18:46:24 Antti Palosaari escribió:
On 07/22/2011 07:25 PM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 18:08:39 Antti Palosaari escribió:
On 07/22/2011 07:02 PM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 13:32:53 Antti Palosaari escribió:
Have you had to time test these?
And about I2C adapter, I don't see why changes are needed. As far
as I understand it is already working with TDA10023 and you have
done changes for TDA10048 support. I compared TDA10048 and
TDA10023 I2C functions and those are ~similar. Both uses most
typical access, for reg write {u8 REG, u8 VAL} and for reg read
{u8 REG}/{u8 VAL}.
regards
Antti
I just finish the testing. The changes to I2C are for the tuner
tda827x. The MFE fork fine. I need to change the code in tda10048
and ttusb2. Attached is the patch for CT-3650 with your MFE patch.
You still pass tda10023 fe pointer to tda10048 for I2C-gate control
which is wrong. Could you send USB sniff I can look what there
really happens. If you have raw SniffUSB2 logs I wish to check
those, other logs are welcome too if no raw SniffUSB2 available.
Youre chnage don't work. You need to change the function i2c gate of
tda1048 for the one of tda1023, but the parameter of this function
must be the fe pointer of tda1023. If this is a problem, I can
duplicate tda1023 i2c gate in ttusb2 code and pass it to the
tda10048. It is done this way in the first patch of this thread.
Yes I now see why it cannot work - since FE is given as a parameter
to i2c_gate_ctrl it does not see correct priv and used I2C addr is
read from priv. You must implement own i2c_gate_ctrl in ttusb2
driver. Implement own ct3650_i2c_gate_ctrl and override tda10048
i2c_gate_ctrl using that. Then call tda10023 i2c_gate_ctrl but
instead of tda10048 FE use td10023 FE. Something like
static int ct3650_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)
{
return adap-mfe[0]-ops.i2c_gate_ctrl(POINTER_TO_TDA10023_FE,
enable);
}
/* tuner is behind TDA10023 I2C-gate */
adap-mfe[1]-ops.i2c_gate_ctrl = ct3650_i2c_gate_ctrl;
Could you still send USB logs? I don't see it correct behaviour you
need to change I2C-adaper when same tuner is used for DVB-T because
it was already working in DVB-C mode.
regards
Antti
Thanks, I try to implement that. I attach a processed log. It prints
the first line of a usb command and the first line of the returned
byes. If you want the full log I can upload it where you want.
Jose Alberto
New version with Antti's sugestion.
GOOD! As you can see implementing things correctly drops also much lines
of code! No more ugly hacks in TDA10048 driver.
But now you must fix that I2C-adapter. I looked sniffs and tda827x
driver. I2C is rather clear. tda827x uses a little bit unusual I2C read.
Normally reads are done as I2C write+read combination, that tuner, as
many other NXP tuners, uses only single read and it is starting always
from reg 0.
It looked for my eyes that it will never do read operation as in read
there is num = 1, msg[0].flags = I2C_M_RD
ttusb2_i2c_xfer():
for (i = 0; i num; i++) {
read = i+1 num (msg[i+1].flags I2C_M_RD);
But in the case it have been working for DVB-C I don't understand why it
does not work for DVB-T. And thus I really suspect your changes to
I2C-adapter are not needed. So whats the problem using original I2C
adapter? What does it print when debugs are enabled. Is there some
errors in log?
Also looking from sniffs, it seems that this could be wrong:
(rlen 0 r[3] != rlen)) {
warn(there might have been an error during control message
transfer.
(rlen = %d, was %d),rlen,r[3]);
regards
Antti
The problem is in i2c read in tda827x_probe_version. Without the fix
sometimes, when changing the code the tuner is detected as tda827xo
instead of tda827xa. That is because the variable where i2c read should
store the value is initialized, and sometimes it works.
struct i2c_msg msg = { .addr = priv-i2c_addr, .flags = I2C_M_RD,
.buf = data, .len = 1 };
rc = tuner_transfer(fe, msg, 1);
:-( Could you read what I write. It is a little bit annoying to find out
everything for you. You just answer every time something like it does
not work and I should always find out what's problem.
As I pointed out read will never work since I2C adapter supports only
read done in WRITE+READ combination. Driver uses read
s2-liplianin - dib0700 causes kernel oops!
Hello, I tried to install s2-liplianin on changing kernel-versions. All in common is, that my Hauppauge Nova-T USB-Stick causes a kernel oops when plugged in. The devices are generated, but it does not tune. lsusb freezes. Here is my kernel.log: http://pastebin.com/03hxKvme The drivers from 2011-02-05 does not run, but the drivers from 2010-10-16 runs perfectly. Regards, Sven -- 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] add support for the dvb-t part of CT-3650 v3
On 07/23/2011 01:21 PM, Jose Alberto Reguero wrote:
On Sábado, 23 de Julio de 2011 11:42:58 Antti Palosaari escribió:
On 07/23/2011 11:26 AM, Jose Alberto Reguero wrote:
The problem is in i2c read in tda827x_probe_version. Without the fix
sometimes, when changing the code the tuner is detected as tda827xo
instead of tda827xa. That is because the variable where i2c read should
store the value is initialized, and sometimes it works.
struct i2c_msg msg = { .addr = priv-i2c_addr, .flags = I2C_M_RD,
.buf =data, .len = 1 };
rc = tuner_transfer(fe,msg, 1);
:-( Could you read what I write. It is a little bit annoying to find out
everything for you. You just answer every time something like it does
not work and I should always find out what's problem.
As I pointed out read will never work since I2C adapter supports only
read done in WRITE+READ combination. Driver uses read which is single
READ without write.
You should implement new read. You can look example from af9015 or other
drivers using tda827x
This have been never worked thus I Cc Guy Martin who have added DVB-C
support for that device.
regards
Antti
I don't understand you. I think that you don' see the fix, but the old code.
Old code:
read = i+1 num (msg[i+1].flags I2C_M_RD);
Fix:
read1 = i+1 num (msg[i+1].flags I2C_M_RD); for the tda10023 and tda10048
read2 = msg[i].flags I2C_M_RD; for the tda827x
Jose Alberto
First of all I must apologize of blaming you about that I2C adapter,
sorry, I should going to shame now. It was me who doesn't read your
changes as should :/
Your changes are logically OK and implements correctly single reading as
needed. Some comments still;
* consider renaming read1 and read2 for example write_read and read
* obuf[1] contains WRITE len. your code sets that now as READ len.
Probably it should be 0 always in single write since no bytes written.
* remove useless checks from end of the if (foo) if (foo);
if (read1 || read2) {
if (read1) {
[...]
} else if (read2)
If you store some variables at the beginning, olen, ilen, obuf, ibuf,
you can increase i++ for write+read and rest of the code in function can
be same (no more if read or write + read). But maybe it is safe to keep
closer original than change such much.
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] Add support for PCTV452E.
On Tue, 24 May 2011 21:51:22 +0200 Hans Petter Selasky hsela...@c2i.net wrote: NOTES: Sources were taken from the following repositorium as of today: http://mercurial.intuxication.org/hg/s2-liplianin/ And depend on the zig-zag fix posted today. Did a first test on the patch. [ 96.780040] usb 1-8: new high speed USB device using ehci_hcd and address 5 [ 97.376058] dvb_usb_pctv452e: Unknown symbol ttpci_eeprom_decode_mac (err 0) Looks like this patch didn't make it into patchwork - Mauro can you check that ? I think the patch for ttpci-eeprom.c is missing this: --- linux/drivers/media/dvb/ttpci/ttpci-eeprom.c.orig 2011-07-23 11:00:49.0 + +++ linux/drivers/media/dvb/ttpci/ttpci-eeprom.c2011-07-23 11:04:00.0 + @@ -165,6 +165,7 @@ int ttpci_eeprom_parse_mac(struct i2c_ad } EXPORT_SYMBOL(ttpci_eeprom_parse_mac); +EXPORT_SYMBOL(ttpci_eeprom_decode_mac); MODULE_LICENSE(GPL); MODULE_AUTHOR(Ralph Metzler, Marcus Metzler, others); -- 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][saa7134] do not change mute state for capturing audio
Em 23-07-2011 04:44, Stas Sergeev escreveu: 23.07.2011 05:28, Mauro Carvalho Chehab wrote: Mplayer was just one example of an application that I know it doesn't call V4L2_CID_AUDIO_MUTE to unmute. I would suggest fixing all such an apps, even if we are not going to change that in the driver. If application needs to change due to a patch, this is a regression, as it will break binary compatibility with non-patched versions. NACK. Your approach of moving it to VIDIOC_S_FREQUENCY (if I understood well) won't work, as, every time someone would change the channel, it will be unmuted, causing troubles on applications like scantv (part of xawtv). But how can scantv (or anything else) rely on the fact that the board was muted when that app starts? I guess it can't, and mutes it explicitly first, no? Even if it mutes, every time a channel is changed, it will be unmuted, if you put such unmute logic at VIDIOC_S_FREQUENCY. Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
23.07.2011 17:06, Mauro Carvalho Chehab wrote: I would suggest fixing all such an apps, even if we are not going to change that in the driver. If application needs to change due to a patch, this is a regression, I said even if we are not going to change that in the driver, which, imho, removes any ambiguity from my phrase. But how can scantv (or anything else) rely on the fact that the board was muted when that app starts? I guess it can't, and mutes it explicitly first, no? Even if it mutes, every time a channel is changed, it will be unmuted, if you put such unmute logic at VIDIOC_S_FREQUENCY. As I said, I propose the automute state to be a separate, _third_ state. mute/unmute/automute. Automute state is only set initially, but if the app explicitly sets any other state, it is no longer affected. Since an app can't rely on the state before it was started, it should set the mute state explicitly first. In this case, it will not be autounmuted after tuning. -- 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][saa7134] do not change mute state for capturing audio
Em 23-07-2011 10:20, Stas Sergeev escreveu: 23.07.2011 17:06, Mauro Carvalho Chehab wrote: I would suggest fixing all such an apps, even if we are not going to change that in the driver. If application needs to change due to a patch, this is a regression, I said even if we are not going to change that in the driver, which, imho, removes any ambiguity from my phrase. But how can scantv (or anything else) rely on the fact that the board was muted when that app starts? I guess it can't, and mutes it explicitly first, no? Even if it mutes, every time a channel is changed, it will be unmuted, if you put such unmute logic at VIDIOC_S_FREQUENCY. As I said, I propose the automute state to be a separate, _third_ state. mute/unmute/automute. Automute state is only set initially, but if the app explicitly sets any other state, it is no longer affected. Since an app can't rely on the state before it was started, it should set the mute state explicitly first. In this case, it will not be autounmuted after tuning. Hard to tell about your solution without seeing a patch. Not sure if this will be consistent, especially if PA restarts for whatever reason (X restart? manual restart?). Anyway, we're discussing a lot for a kernel fix for PA, while the right thing to do is to fix PA itself. Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cxd2820r: fix possible out-of-array lookup
2011/7/23 Malcolm Priestley tvbox...@gmail.com: On Sat, 2011-07-23 at 01:47 +0200, HoP wrote: 2011/7/23 Antti Palosaari cr...@iki.fi: On 07/23/2011 02:31 AM, Antti Palosaari wrote: On 07/23/2011 02:01 AM, HoP wrote: 2011/7/23 Antti Palosaaricr...@iki.fi: But now I see what you mean. msg2[1] is set as garbage fields in case of incoming msg len is 1. True, but it does not harm since it is not used in that case. In case of write, cxd2820r_tuner_i2c_xfer() gets msg[] parameter with only one element, true? If so, then my patch is correct. Yes it is true but nonsense. It is also wrong to make always msg2 as two element array too, but those are just simpler and generates most likely some code less. Could you see it can cause problem in some case? Now I thought it more, could it crash if it point out of memory area? Arrays are not fussy they will read anything, just don't poke them :-) Are you sure about not crashing? On every architecture on which linux can run? Even if it not crash kernel, I hope we can agree that it is incorrect and need to be fixed. I see you finally understood what I wanted to do :-) I'm surprised that it not crashed already. I thought I have to missed something. It does not crash because num is constant throughout, when the number of messages is one the second element isn't transferred. Sure, that is evident. My fix was about not do read access outside of input array msg[]. I still don't understand the NACK. /Honza -- 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][saa7134] do not change mute state for capturing audio
23.07.2011 19:09, Mauro Carvalho Chehab wrote: As I said, I propose the automute state to be a separate, _third_ state. mute/unmute/automute. Automute state is only set initially, but if the app explicitly sets any other state, it is no longer affected. Since an app can't rely on the state before it was started, it should set the mute state explicitly first. In this case, it will not be autounmuted after tuning. Hard to tell about your solution without seeing a patch. I can try making this patch now only if we agree on the technique first. Not sure if this will be consistent, especially if PA restarts for whatever reason (X restart? manual restart?). I mean, this automute is set initially for every new opening of the device node. So on every start it will still have an automute mode. Anyway, we're discussing a lot for a kernel fix for PA, while the right thing to do is to fix PA itself. I think both parts will better be fixed ideally, but right now PA will probably not be fixed soon. If we can agree on the logic, then I may take a look into coding the patch itself. -- 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][saa7134] do not change mute state for capturing audio
23.07.2011 19:09, Mauro Carvalho Chehab wrote: Anyway, we're discussing a lot for a kernel fix for PA, Please note that right now we are discussing the fix for mplayer or anything else that forgets to just explicitly enable/disable the audio! IMHO, that should better be fixed first. -- 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] add support for the dvb-t part of CT-3650 v3
On Sábado, 23 de Julio de 2011 12:37:53 Antti Palosaari escribió:
On 07/23/2011 01:21 PM, Jose Alberto Reguero wrote:
On Sábado, 23 de Julio de 2011 11:42:58 Antti Palosaari escribió:
On 07/23/2011 11:26 AM, Jose Alberto Reguero wrote:
The problem is in i2c read in tda827x_probe_version. Without the fix
sometimes, when changing the code the tuner is detected as tda827xo
instead of tda827xa. That is because the variable where i2c read should
store the value is initialized, and sometimes it works.
struct i2c_msg msg = { .addr = priv-i2c_addr, .flags = I2C_M_RD,
.buf =data, .len = 1 };
rc = tuner_transfer(fe,msg, 1);
:-( Could you read what I write. It is a little bit annoying to find out
everything for you. You just answer every time something like it does
not work and I should always find out what's problem.
As I pointed out read will never work since I2C adapter supports only
read done in WRITE+READ combination. Driver uses read which is single
READ without write.
You should implement new read. You can look example from af9015 or other
drivers using tda827x
This have been never worked thus I Cc Guy Martin who have added DVB-C
support for that device.
regards
Antti
I don't understand you. I think that you don' see the fix, but the old
code. Old code:
read = i+1 num (msg[i+1].flags I2C_M_RD);
Fix:
read1 = i+1 num (msg[i+1].flags I2C_M_RD); for the tda10023 and
tda10048 read2 = msg[i].flags I2C_M_RD; for the tda827x
Jose Alberto
First of all I must apologize of blaming you about that I2C adapter,
sorry, I should going to shame now. It was me who doesn't read your
changes as should :/
Your changes are logically OK and implements correctly single reading as
needed. Some comments still;
* consider renaming read1 and read2 for example write_read and read
* obuf[1] contains WRITE len. your code sets that now as READ len.
Probably it should be 0 always in single write since no bytes written.
* remove useless checks from end of the if (foo) if (foo);
if (read1 || read2) {
if (read1) {
[...]
} else if (read2)
If you store some variables at the beginning, olen, ilen, obuf, ibuf,
you can increase i++ for write+read and rest of the code in function can
be same (no more if read or write + read). But maybe it is safe to keep
closer original than change such much.
regards
Antti
There are a second i2c read, but less important.It is in:
tda827xa_set_params
buf[0] = 0xa0;
buf[1] = 0x40;
msg.len = 2;
rc = tuner_transfer(fe, msg, 1);
if (rc 0)
goto err;
msleep(11);
msg.flags = I2C_M_RD;
rc = tuner_transfer(fe, msg, 1);
if (rc 0)
goto err;
msg.flags = 0;
buf[1] = 4;
I supposed that buf[0] is the register to read and they read the value in
buf[1]. The code now seem to work ok but perhaps is wrong.
Jose Alberto
--
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] add support for the dvb-t part of CT-3650 v3
On 07/23/2011 06:41 PM, Jose Alberto Reguero wrote:
On Sábado, 23 de Julio de 2011 12:37:53 Antti Palosaari escribió:
On 07/23/2011 01:21 PM, Jose Alberto Reguero wrote:
On Sábado, 23 de Julio de 2011 11:42:58 Antti Palosaari escribió:
On 07/23/2011 11:26 AM, Jose Alberto Reguero wrote:
The problem is in i2c read in tda827x_probe_version. Without the fix
sometimes, when changing the code the tuner is detected as tda827xo
instead of tda827xa. That is because the variable where i2c read should
store the value is initialized, and sometimes it works.
struct i2c_msg msg = { .addr = priv-i2c_addr, .flags = I2C_M_RD,
.buf =data, .len = 1 };
rc = tuner_transfer(fe,msg, 1);
:-( Could you read what I write. It is a little bit annoying to find out
everything for you. You just answer every time something like it does
not work and I should always find out what's problem.
As I pointed out read will never work since I2C adapter supports only
read done in WRITE+READ combination. Driver uses read which is single
READ without write.
You should implement new read. You can look example from af9015 or other
drivers using tda827x
This have been never worked thus I Cc Guy Martin who have added DVB-C
support for that device.
regards
Antti
I don't understand you. I think that you don' see the fix, but the old
code. Old code:
read = i+1num(msg[i+1].flagsI2C_M_RD);
Fix:
read1 = i+1 num (msg[i+1].flags I2C_M_RD); for the tda10023 and
tda10048 read2 = msg[i].flags I2C_M_RD; for the tda827x
Jose Alberto
First of all I must apologize of blaming you about that I2C adapter,
sorry, I should going to shame now. It was me who doesn't read your
changes as should :/
Your changes are logically OK and implements correctly single reading as
needed. Some comments still;
* consider renaming read1 and read2 for example write_read and read
* obuf[1] contains WRITE len. your code sets that now as READ len.
Probably it should be 0 always in single write since no bytes written.
* remove useless checks from end of the if (foo) if (foo);
if (read1 || read2) {
if (read1) {
[...]
} else if (read2)
If you store some variables at the beginning, olen, ilen, obuf, ibuf,
you can increase i++ for write+read and rest of the code in function can
be same (no more if read or write + read). But maybe it is safe to keep
closer original than change such much.
regards
Antti
There are a second i2c read, but less important.It is in:
tda827xa_set_params
buf[0] = 0xa0;
buf[1] = 0x40;
msg.len = 2;
rc = tuner_transfer(fe,msg, 1);
if (rc 0)
goto err;
msleep(11);
msg.flags = I2C_M_RD;
rc = tuner_transfer(fe,msg, 1);
if (rc 0)
goto err;
msg.flags = 0;
buf[1]= 4;
I supposed that buf[0] is the register to read and they read the value in
buf[1]. The code now seem to work ok but perhaps is wrong.
This one is as translated to normal C we usually use;
write_reg(0xa0, 0x40); // write one reg
read_regs(2); // read 2 regs
example from the sniff
AA B0 31 05 C2 02 00 A0 40ª°1.Â.. @
55 B0 31 03 C2 02 00 4A 44 08 00 00 00 71 AC EC U°1.Â..JDq¬ì
AA B1 31 05 C2 02 00 30 11ª±1.Â..0.
55 B1 31 03 C2 02 00 4A 44 08 00 00 00 71 AC EC U±1.Â..JDq¬ì
AA USB direction to device
B1 USB msg seq
31 USB cmd
05 USB data len (4+5=9, 4=hdr len, 5=data len, 9=total)
C2 I2C addr (addr 1)
02 I2C write len
00 I2C read len
30 I2C data [0]
11 I2C data [1]
So it seems actually to write 30 11 and then read 4a 44 as reply. But if
you read driver code it does not write 30 11 instead just reads. Maybe
buggy I2C adap implementation or buggy tuner driver (Linux driver or
driver where sniff taken). Try to read without write and with write and
compare if there is any difference.
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, RESEND] uvcvideo: Add FIX_BANDWIDTH quirk to HP Webcam found on HP Mini 5103 netbook
Hi Laurent, All, On Sat, Jul 23, 2011 at 01:12:11AM +0200, Laurent Pinchart wrote: Hi Kirill, On Saturday 23 July 2011 00:25:20 Kirill Smelkov wrote: On Sat, Jul 23, 2011 at 12:03:57AM +0200, Laurent Pinchart wrote: On Friday 22 July 2011 16:47:22 Kirill Smelkov wrote: [ Cc'ing Andrew Morton -- Andrew, could you please pick this patch, in case there is no response from maintainers again? Thanks beforehand. ] Hello up there, My first posting was 1 month ago, and a reminder ~ 2 weeks ago. All without a reply. v3.0 is out and they say the merge window will be shorter this time, so in oder not to miss it, I've decided to resend my patch on lowering USB periodic bandwidth allocation topic. I'm very very sorry for missing the patch (and worse, twice :-/). Nevermind. I'm curious though, whether I did something wrong or anything else? I mean how to avoid such long delays next time? It was all my fault, mails piled up in my mailbox and for some reason I marked yours as processed while they were not. I certainly hope it won't happen again. I see, thanks. Yes let's hope mail won't do such surprises next time. Could this simple patch be please applied? Yes it can. I see that Andrew already applied it to his tree. Mauro, should it go through there, or through your tree ? I've pushed it to my tree at git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-stable, so you can already pull. You've applied the patch from my first posting, but actually in the RESEND one I've added reference to EHCI-tweaking patch -- it is already merged into Greg's USB tree (it was not when I first posted), so could you please reapply? (sorry for confusion). Sure. That should now be fixed. Thanks. Thanks for replying and for uvcvideo, You're more than welcome. Thank you for the patch, and thank you for keeping on pushing :-) :) Thanks again. I suppose it would be better for my patch to enter the mainline through v4l tree then, because it's the normal path for uvc bits. Thanks, Kirill P.S. And thanks Andrew for backing me up. -- 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] pwc: precedence bug in pwc_init_controls()
'!' has higher precedence than '' so we need parenthesis here. Signed-off-by: Dan Carpenter erro...@gmail.com diff --git a/drivers/media/video/pwc/pwc-v4l.c b/drivers/media/video/pwc/pwc-v4l.c index e9a0e94..8c70e64 100644 --- a/drivers/media/video/pwc/pwc-v4l.c +++ b/drivers/media/video/pwc/pwc-v4l.c @@ -338,7 +338,7 @@ int pwc_init_controls(struct pwc_device *pdev) if (pdev-restore_factory) pdev-restore_factory-flags = V4L2_CTRL_FLAG_UPDATE; - if (!pdev-features FEATURE_MOTOR_PANTILT) + if (!(pdev-features FEATURE_MOTOR_PANTILT)) return hdl-error; /* Motor pan / tilt / reset */ -- 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] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Jul 23 19:01:41 CEST 2011 git hash:f0a21151140da01c71de636f482f2eddec2840cc gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification 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: [PATCH] add support for the dvb-t part of CT-3650 v3
On Sábado, 23 de Julio de 2011 19:47:27 Antti Palosaari escribió:
On 07/23/2011 06:41 PM, Jose Alberto Reguero wrote:
On Sábado, 23 de Julio de 2011 12:37:53 Antti Palosaari escribió:
On 07/23/2011 01:21 PM, Jose Alberto Reguero wrote:
On Sábado, 23 de Julio de 2011 11:42:58 Antti Palosaari escribió:
On 07/23/2011 11:26 AM, Jose Alberto Reguero wrote:
The problem is in i2c read in tda827x_probe_version. Without the fix
sometimes, when changing the code the tuner is detected as tda827xo
instead of tda827xa. That is because the variable where i2c read
should store the value is initialized, and sometimes it works.
struct i2c_msg msg = { .addr = priv-i2c_addr, .flags = I2C_M_RD,
.buf =data, .len = 1 };
rc = tuner_transfer(fe,msg, 1);
:-( Could you read what I write. It is a little bit annoying to find
:out
everything for you. You just answer every time something like it does
not work and I should always find out what's problem.
As I pointed out read will never work since I2C adapter supports only
read done in WRITE+READ combination. Driver uses read which is single
READ without write.
You should implement new read. You can look example from af9015 or
other drivers using tda827x
This have been never worked thus I Cc Guy Martin who have added DVB-C
support for that device.
regards
Antti
I don't understand you. I think that you don' see the fix, but the old
code. Old code:
read = i+1num(msg[i+1].flagsI2C_M_RD);
Fix:
read1 = i+1 num (msg[i+1].flags I2C_M_RD); for the tda10023
and tda10048 read2 = msg[i].flags I2C_M_RD; for the tda827x
Jose Alberto
First of all I must apologize of blaming you about that I2C adapter,
sorry, I should going to shame now. It was me who doesn't read your
changes as should :/
Your changes are logically OK and implements correctly single reading as
needed. Some comments still;
* consider renaming read1 and read2 for example write_read and read
* obuf[1] contains WRITE len. your code sets that now as READ len.
Probably it should be 0 always in single write since no bytes written.
* remove useless checks from end of the if (foo) if (foo);
if (read1 || read2) {
if (read1) {
[...]
} else if (read2)
If you store some variables at the beginning, olen, ilen, obuf, ibuf,
you can increase i++ for write+read and rest of the code in function can
be same (no more if read or write + read). But maybe it is safe to keep
closer original than change such much.
regards
Antti
There are a second i2c read, but less important.It is in:
tda827xa_set_params
buf[0] = 0xa0;
buf[1] = 0x40;
msg.len = 2;
rc = tuner_transfer(fe,msg, 1);
if (rc 0)
goto err;
msleep(11);
msg.flags = I2C_M_RD;
rc = tuner_transfer(fe,msg, 1);
if (rc 0)
goto err;
msg.flags = 0;
buf[1]= 4;
I supposed that buf[0] is the register to read and they read the value in
buf[1]. The code now seem to work ok but perhaps is wrong.
This one is as translated to normal C we usually use;
write_reg(0xa0, 0x40); // write one reg
read_regs(2); // read 2 regs
example from the sniff
AA B0 31 05 C2 02 00 A0 40ª°1.Â.. @
55 B0 31 03 C2 02 00 4A 44 08 00 00 00 71 AC EC U°1.Â..JDq¬ì
AA B1 31 05 C2 02 00 30 11ª±1.Â..0.
55 B1 31 03 C2 02 00 4A 44 08 00 00 00 71 AC EC U±1.Â..JDq¬ì
AA USB direction to device
B1 USB msg seq
31 USB cmd
05 USB data len (4+5=9, 4=hdr len, 5=data len, 9=total)
C2 I2C addr (addr 1)
02 I2C write len
00 I2C read len
30 I2C data [0]
11 I2C data [1]
So it seems actually to write 30 11 and then read 4a 44 as reply. But if
you read driver code it does not write 30 11 instead just reads. Maybe
buggy I2C adap implementation or buggy tuner driver (Linux driver or
driver where sniff taken). Try to read without write and with write and
compare if there is any difference.
regards
Antti
Read without write work as with write. Attached updated patch.
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
Jose Alberto
diff -ur linux/drivers/media/dvb/dvb-usb/ttusb2.c linux.new/drivers/media/dvb/dvb-usb/ttusb2.c
--- linux/drivers/media/dvb/dvb-usb/ttusb2.c 2011-01-10 16:24:45.0 +0100
+++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c 2011-07-23 23:12:29.341385243 +0200
@@ -30,6 +30,7 @@
#include tda826x.h
#include tda10086.h
#include tda1002x.h
+#include tda10048.h
#include tda827x.h
#include lnbp21.h
@@ -82,7 +83,7 @@
{
struct dvb_usb_device *d = i2c_get_adapdata(adap);
static u8 obuf[60], ibuf[60];
- int i,read;
+ int i, write_read, read;
[PATCH] Fix regression introduced which broke the Hauppauge USBLive 2
The following patch addresses the regression introduced in the cx231xx
driver which stopped the Hauppauge USBLive2 from working.
Confirmed working by both myself and the user who reported the issue
on the KernelLabs blog (Robert DeLuca).
cx231xx: Fix regression introduced which broke the Hauppauge USBLive 2
From: Devin Heitmueller dheitmuel...@kernellabs.com
At some point during refactoring of the cx231xx driver, the USBLive 2 device
became broken. This patch results in the device working again.
Thanks to Robert DeLuca for sponsoring this work.
Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com
Cc: Robert DeLuca robertdel...@me.com
diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c
b/drivers/media/video/cx231xx/cx231xx-cards.c
index 4b22afe..d02c63a 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -387,6 +387,7 @@ struct cx231xx_board cx231xx_boards[] = {
.norm = V4L2_STD_NTSC,
.no_alt_vanc = 1,
.external_av = 1,
+ .dont_use_port_3 = 1,
.input = {{
.type = CX231XX_VMUX_COMPOSITE1,
.vmux = CX231XX_VIN_2_1,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
