Re: [PATCH] Leadtek WinFast DTV-1800H support
Em Mon, 01 Jun 2009 03:58:25 +0200 hermann pitton hermann-pit...@arcor.de escreveu: Am Sonntag, den 31.05.2009, 16:58 -0300 schrieb Mauro Carvalho Chehab: Em Sun, 31 May 2009 19:39:15 +0200 Miroslav Šustek sustmid...@centrum.cz escreveu: Trent Piepho xyzzy at speakeasy.org writes: Instead of raising the reset line here, why not change the gpio settings in the card definition to have it high? Change gpio1 for television to 0x7050 and radio to 0x7010. Personally, I don't know when these .gpioX members are used (before firmware loads or after...). But I assume that adding the high on reset pin shouldn't break anything, so we can do this. And shouldn't we put tuner reset pin to 0 when in composite and s-video mode? These inputs don't use tuner or do they? If I look in dmesg I can see that firmware is loaded into tuner even when these modes are used (I'm using MPlayer to select the input). And due to callbacks issued duting firmware loading, tuner is turned on (reset pin = 1) no matter if it was turned off by .gpioX setting. And shouldn't we use the mask bits [24:16] of MO_GPX_IO in .gpioX members too? I know only few GPIO pins and the other I don't know either what direction they should be. That means GPIO pins which I don't know are set as Hi-Z = inputs... Now, when I think of that, if it works it's safer when the other pins are in Hi-Z mode. Never mind. Then the reset can be done with: case XC2028_TUNER_RESET: /* GPIO 12 (xc3028 tuner reset) */ cx_write(MO_GP1_IO, 0x101000); mdelay(50); cx_write(MO_GP1_IO, 0x101010); mdelay(50); return 0; Earlier I was told to use 'cx_set' and 'cx_clear' because using 'cx_write' is risky. see here: http://www.spinics.net/lists/linux-dvb/msg29777.html And when you are using 'cx_set' and 'cx_clear' you need 3 calls. The first to set the direction bit, the second to set 0 on reset pin and the third to set 1 on reset pin. If you ask me which I think is nicer I'll tell you: that one with 'cx_write'. If you ask me which one I want to use, I'll tell: I don't care. :) Though I have to wonder why each card needs its own xc2028 reset function. Shouldn't they all be the same other than what gpio they change? My English goes lame here. Do you mean that reset function shouldn't use GPIO at all? @@ -2882,6 +2946,16 @@ cx_set(MO_GP0_IO, 0x0080); /* 702 out of reset */ udelay(1000); break; + + case CX88_BOARD_WINFAST_DTV1800H: + /* GPIO 12 (xc3028 tuner reset) */ + cx_set(MO_GP1_IO, 0x1010); + mdelay(50); + cx_clear(MO_GP1_IO, 0x10); + mdelay(50); + cx_set(MO_GP1_IO, 0x10); + mdelay(50); + break; } } Couldn't you replace this with: case CX88_BOARD_WINFAST_DTV1800H: cx88_xc3028_winfast1800h_callback(code, XC2028_TUNER_RESET, 0); break; Yes, this will do the same job. I think that 'cx88_card_setup_pre_i2c' is to be called before any I2C communication. The 'cx88_xc3028_winfast1800h_callback' (cx88_tuner_callback) is meant to be used when tuner code (during firmware loading) needs it. This is probably why others did it this way (these are separated issues even if they do the same thing) and I only obey existing form. I only want to finally add the support for this card. You know many people (not developers) don't care if this function is used or that function is used twice, instead. They just want to install they distro and watch the tv. I classify myself as an programmer rather than ordinary user, so I care how the code looks like. I'm open to the discussion about these things, but this can take long time and I just want the card to be supported asap. There are more cards which has code like this so if linuxtv developers realize eg. to not use callbacks or use only cx_set and cx_clear (instead of cx_write) they'll do it all at once (not every card separately). I attached modified patch: - .gpioX members of inputs which use tuner have reset pin 1 (tuner enabled) - .gpioX members of inputs which don't use tuner have reset pin 0 (tuner disabled) - resets (in callback and the one in pre_i2c) use only two 'cx_write' calls I'm keeping the tested-by lines even if this modified version of patch wasn't tested by those people (the previous version was). I trust this changes can't break the functionality. If you think it's too audacious then drop them. It's on linuxtv developers which of these two patches will be chosen. For the sake of not loosing this patch again, I've applied it as-is. I hope I got the latest version. It is hard to track patches that aren't got by patchwork. I agree with Trent's proposals for optimizing the code: It is better to just call
Re: [PATCH] Leadtek WinFast DTV-1800H support
Am Montag, den 01.06.2009, 06:07 -0300 schrieb Mauro Carvalho Chehab: Em Mon, 01 Jun 2009 03:58:25 +0200 hermann pitton hermann-pit...@arcor.de escreveu: Am Sonntag, den 31.05.2009, 16:58 -0300 schrieb Mauro Carvalho Chehab: Em Sun, 31 May 2009 19:39:15 +0200 Miroslav Šustek sustmid...@centrum.cz escreveu: Trent Piepho xyzzy at speakeasy.org writes: Instead of raising the reset line here, why not change the gpio settings in the card definition to have it high? Change gpio1 for television to 0x7050 and radio to 0x7010. Personally, I don't know when these .gpioX members are used (before firmware loads or after...). But I assume that adding the high on reset pin shouldn't break anything, so we can do this. And shouldn't we put tuner reset pin to 0 when in composite and s-video mode? These inputs don't use tuner or do they? If I look in dmesg I can see that firmware is loaded into tuner even when these modes are used (I'm using MPlayer to select the input). And due to callbacks issued duting firmware loading, tuner is turned on (reset pin = 1) no matter if it was turned off by .gpioX setting. And shouldn't we use the mask bits [24:16] of MO_GPX_IO in .gpioX members too? I know only few GPIO pins and the other I don't know either what direction they should be. That means GPIO pins which I don't know are set as Hi-Z = inputs... Now, when I think of that, if it works it's safer when the other pins are in Hi-Z mode. Never mind. Then the reset can be done with: case XC2028_TUNER_RESET: /* GPIO 12 (xc3028 tuner reset) */ cx_write(MO_GP1_IO, 0x101000); mdelay(50); cx_write(MO_GP1_IO, 0x101010); mdelay(50); return 0; Earlier I was told to use 'cx_set' and 'cx_clear' because using 'cx_write' is risky. see here: http://www.spinics.net/lists/linux-dvb/msg29777.html And when you are using 'cx_set' and 'cx_clear' you need 3 calls. The first to set the direction bit, the second to set 0 on reset pin and the third to set 1 on reset pin. If you ask me which I think is nicer I'll tell you: that one with 'cx_write'. If you ask me which one I want to use, I'll tell: I don't care. :) Though I have to wonder why each card needs its own xc2028 reset function. Shouldn't they all be the same other than what gpio they change? My English goes lame here. Do you mean that reset function shouldn't use GPIO at all? @@ -2882,6 +2946,16 @@ cx_set(MO_GP0_IO, 0x0080); /* 702 out of reset */ udelay(1000); break; + + case CX88_BOARD_WINFAST_DTV1800H: + /* GPIO 12 (xc3028 tuner reset) */ + cx_set(MO_GP1_IO, 0x1010); + mdelay(50); + cx_clear(MO_GP1_IO, 0x10); + mdelay(50); + cx_set(MO_GP1_IO, 0x10); + mdelay(50); + break; } } Couldn't you replace this with: case CX88_BOARD_WINFAST_DTV1800H: cx88_xc3028_winfast1800h_callback(code, XC2028_TUNER_RESET, 0); break; Yes, this will do the same job. I think that 'cx88_card_setup_pre_i2c' is to be called before any I2C communication. The 'cx88_xc3028_winfast1800h_callback' (cx88_tuner_callback) is meant to be used when tuner code (during firmware loading) needs it. This is probably why others did it this way (these are separated issues even if they do the same thing) and I only obey existing form. I only want to finally add the support for this card. You know many people (not developers) don't care if this function is used or that function is used twice, instead. They just want to install they distro and watch the tv. I classify myself as an programmer rather than ordinary user, so I care how the code looks like. I'm open to the discussion about these things, but this can take long time and I just want the card to be supported asap. There are more cards which has code like this so if linuxtv developers realize eg. to not use callbacks or use only cx_set and cx_clear (instead of cx_write) they'll do it all at once (not every card separately). I attached modified patch: - .gpioX members of inputs which use tuner have reset pin 1 (tuner enabled) - .gpioX members of inputs which don't use tuner have reset pin 0 (tuner disabled) - resets (in callback and the one in pre_i2c) use only two 'cx_write' calls I'm keeping the tested-by lines even if this modified version of patch wasn't tested by those people (the previous version was). I trust this changes can't break the functionality. If you think it's too audacious then drop them. It's on linuxtv developers which of these two patches will be chosen. For the sake of not loosing this patch again, I've
Re: [PATCH] Leadtek WinFast DTV-1800H support
Trent Piepho xyzzy at speakeasy.org writes: Instead of raising the reset line here, why not change the gpio settings in the card definition to have it high? Change gpio1 for television to 0x7050 and radio to 0x7010. Personally, I don't know when these .gpioX members are used (before firmware loads or after...). But I assume that adding the high on reset pin shouldn't break anything, so we can do this. And shouldn't we put tuner reset pin to 0 when in composite and s-video mode? These inputs don't use tuner or do they? If I look in dmesg I can see that firmware is loaded into tuner even when these modes are used (I'm using MPlayer to select the input). And due to callbacks issued duting firmware loading, tuner is turned on (reset pin = 1) no matter if it was turned off by .gpioX setting. And shouldn't we use the mask bits [24:16] of MO_GPX_IO in .gpioX members too? I know only few GPIO pins and the other I don't know either what direction they should be. That means GPIO pins which I don't know are set as Hi-Z = inputs... Now, when I think of that, if it works it's safer when the other pins are in Hi-Z mode. Never mind. Then the reset can be done with: case XC2028_TUNER_RESET: /* GPIO 12 (xc3028 tuner reset) */ cx_write(MO_GP1_IO, 0x101000); mdelay(50); cx_write(MO_GP1_IO, 0x101010); mdelay(50); return 0; Earlier I was told to use 'cx_set' and 'cx_clear' because using 'cx_write' is risky. see here: http://www.spinics.net/lists/linux-dvb/msg29777.html And when you are using 'cx_set' and 'cx_clear' you need 3 calls. The first to set the direction bit, the second to set 0 on reset pin and the third to set 1 on reset pin. If you ask me which I think is nicer I'll tell you: that one with 'cx_write'. If you ask me which one I want to use, I'll tell: I don't care. :) Though I have to wonder why each card needs its own xc2028 reset function. Shouldn't they all be the same other than what gpio they change? My English goes lame here. Do you mean that reset function shouldn't use GPIO at all? @@ -2882,6 +2946,16 @@ cx_set(MO_GP0_IO, 0x0080); /* 702 out of reset */ udelay(1000); break; + + case CX88_BOARD_WINFAST_DTV1800H: + /* GPIO 12 (xc3028 tuner reset) */ + cx_set(MO_GP1_IO, 0x1010); + mdelay(50); + cx_clear(MO_GP1_IO, 0x10); + mdelay(50); + cx_set(MO_GP1_IO, 0x10); + mdelay(50); + break; } } Couldn't you replace this with: case CX88_BOARD_WINFAST_DTV1800H: cx88_xc3028_winfast1800h_callback(code, XC2028_TUNER_RESET, 0); break; Yes, this will do the same job. I think that 'cx88_card_setup_pre_i2c' is to be called before any I2C communication. The 'cx88_xc3028_winfast1800h_callback' (cx88_tuner_callback) is meant to be used when tuner code (during firmware loading) needs it. This is probably why others did it this way (these are separated issues even if they do the same thing) and I only obey existing form. I only want to finally add the support for this card. You know many people (not developers) don't care if this function is used or that function is used twice, instead. They just want to install they distro and watch the tv. I classify myself as an programmer rather than ordinary user, so I care how the code looks like. I'm open to the discussion about these things, but this can take long time and I just want the card to be supported asap. There are more cards which has code like this so if linuxtv developers realize eg. to not use callbacks or use only cx_set and cx_clear (instead of cx_write) they'll do it all at once (not every card separately). I attached modified patch: - .gpioX members of inputs which use tuner have reset pin 1 (tuner enabled) - .gpioX members of inputs which don't use tuner have reset pin 0 (tuner disabled) - resets (in callback and the one in pre_i2c) use only two 'cx_write' calls I'm keeping the tested-by lines even if this modified version of patch wasn't tested by those people (the previous version was). I trust this changes can't break the functionality. If you think it's too audacious then drop them. It's on linuxtv developers which of these two patches will be chosen. - Miroslav Šustek leadtek_winfast_dtv1800h_v2.patch Description: Binary data
Re: [PATCH] Leadtek WinFast DTV-1800H support
Miroslav Šustek wrote: Any problem with this patch? I'm trying to get WinFast DTV-1800H support into repository for seven months. (see: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/1125/match=1800h Hi Miro, Its unfortunate that the patch hasn't been added yet, but I do see a problem (in its current form) that explains why it hasn't been picked up. For the sake of thoroughness, here's an audit trail of the entire history: 1) http://linuxtv.org/pipermail/linux-dvb/2008-October/029859.html - Steve picked up some style flaws - (Although it is more desirable to include patches inline as opposed to as attachments, I note that the attached patch is of type text/x-patch, which is fine) 2) http://linuxtv.org/pipermail/linux-dvb/2008-November/030362.html - I noticed your missing SOB - (Again, I note that the attached patch is of type text/x-patch, which is fine) 3) http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/1125/match=1800h - You note in your message that your prior patch didn't get picked up possibly because of the switch of mail lists. That is quite possible, but whatever the case, your patch was, indeed, lost. - Herman responded with some suggestions, as well as noting that your SOB was absent again with the attached patches (though, I know you had resubmitted back in Nov with a SOB) - But here starts the most recent problem: unfortunately, the attached patches where of type application/octet-stream, which the patchwork tool will NOT pick up. Please see: http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches This is a summary explanation of the submitting process (which includes links to several of the documents you've undoubtedly already read) and touches upon attachments. 4) http://www.mail-archive.com/linux-media@vger.kernel.org/msg05856.html - in Hermann's follow up, he correctly notes that the patches never made it onto the patchwork queue (see my explanation directly above for why they were not). 5) http://www.mail-archive.com/linux-media@vger.kernel.org/msg05888.html Nobody noticed the previous post(s). - Ha, I beg to differ! -- at the very least, Steve, myself and Hermann have all spotted your prior patches and have commented. - Unfortunately, the attached patch is again of the type application/octet-stream and will NOT be automatically picked up by patchwork 6) http://www.mail-archive.com/linux-media@vger.kernel.org/msg05890.html (Shoot me! Now it's correct.) - Nope. The attached patch is still a type application/octet-stream, and that is why it is not showing up on the patchwork queue list - I have also just noticed that Trent has also now commented on the patches (so add another to the list!) /End of audit trail I understand your frustration and I don't mean to be bureaucratic (I have zero say in what patches get picked up), but I hope I have shed some light upon what has gone wrong over the last several months. Although I'd rather suspect that Mauro is now well aware of the issue, I'd urge you to resubmit (following the recommendations from the link I provided above) so that it gets picked up and placed upon the patchwork list. -- 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] Leadtek WinFast DTV-1800H support
Trent Piepho píše v Ne 31. 05. 2009 v 06:34 -0700: Instead of raising the reset line here, why not change the gpio settings in the card definition to have it high? Change gpio1 for television to 0x7050 and radio to 0x7010. Personally, I don't know when these .gpioX members are used (before firmware loads or after...). But I assume that adding the high on reset pin shouldn't break anything, so we can do this. Then the reset can be done with: case XC2028_TUNER_RESET: /* GPIO 12 (xc3028 tuner reset) */ cx_write(MO_GP1_IO, 0x101000); mdelay(50); cx_write(MO_GP1_IO, 0x101010); mdelay(50); return 0; Though I have to wonder why each card needs its own xc2028 reset function. Shouldn't they all be the same other than what gpio they change? @@ -2882,6 +2946,16 @@ cx_set(MO_GP0_IO, 0x0080); /* 702 out of reset */ udelay(1000); break; + + case CX88_BOARD_WINFAST_DTV1800H: + /* GPIO 12 (xc3028 tuner reset) */ + cx_set(MO_GP1_IO, 0x1010); + mdelay(50); + cx_clear(MO_GP1_IO, 0x10); + mdelay(50); + cx_set(MO_GP1_IO, 0x10); + mdelay(50); + break; } } Couldn't you replace this with: case CX88_BOARD_WINFAST_DTV1800H: cx88_xc3028_winfast1800h_callback(code, XC2028_TUNER_RESET, 0); break; -- 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] Leadtek WinFast DTV-1800H support
Em Sun, 31 May 2009 19:39:15 +0200 Miroslav Šustek sustmid...@centrum.cz escreveu: Trent Piepho xyzzy at speakeasy.org writes: Instead of raising the reset line here, why not change the gpio settings in the card definition to have it high? Change gpio1 for television to 0x7050 and radio to 0x7010. Personally, I don't know when these .gpioX members are used (before firmware loads or after...). But I assume that adding the high on reset pin shouldn't break anything, so we can do this. And shouldn't we put tuner reset pin to 0 when in composite and s-video mode? These inputs don't use tuner or do they? If I look in dmesg I can see that firmware is loaded into tuner even when these modes are used (I'm using MPlayer to select the input). And due to callbacks issued duting firmware loading, tuner is turned on (reset pin = 1) no matter if it was turned off by .gpioX setting. And shouldn't we use the mask bits [24:16] of MO_GPX_IO in .gpioX members too? I know only few GPIO pins and the other I don't know either what direction they should be. That means GPIO pins which I don't know are set as Hi-Z = inputs... Now, when I think of that, if it works it's safer when the other pins are in Hi-Z mode. Never mind. Then the reset can be done with: case XC2028_TUNER_RESET: /* GPIO 12 (xc3028 tuner reset) */ cx_write(MO_GP1_IO, 0x101000); mdelay(50); cx_write(MO_GP1_IO, 0x101010); mdelay(50); return 0; Earlier I was told to use 'cx_set' and 'cx_clear' because using 'cx_write' is risky. see here: http://www.spinics.net/lists/linux-dvb/msg29777.html And when you are using 'cx_set' and 'cx_clear' you need 3 calls. The first to set the direction bit, the second to set 0 on reset pin and the third to set 1 on reset pin. If you ask me which I think is nicer I'll tell you: that one with 'cx_write'. If you ask me which one I want to use, I'll tell: I don't care. :) Though I have to wonder why each card needs its own xc2028 reset function. Shouldn't they all be the same other than what gpio they change? My English goes lame here. Do you mean that reset function shouldn't use GPIO at all? @@ -2882,6 +2946,16 @@ cx_set(MO_GP0_IO, 0x0080); /* 702 out of reset */ udelay(1000); break; + + case CX88_BOARD_WINFAST_DTV1800H: + /* GPIO 12 (xc3028 tuner reset) */ + cx_set(MO_GP1_IO, 0x1010); + mdelay(50); + cx_clear(MO_GP1_IO, 0x10); + mdelay(50); + cx_set(MO_GP1_IO, 0x10); + mdelay(50); + break; } } Couldn't you replace this with: case CX88_BOARD_WINFAST_DTV1800H: cx88_xc3028_winfast1800h_callback(code, XC2028_TUNER_RESET, 0); break; Yes, this will do the same job. I think that 'cx88_card_setup_pre_i2c' is to be called before any I2C communication. The 'cx88_xc3028_winfast1800h_callback' (cx88_tuner_callback) is meant to be used when tuner code (during firmware loading) needs it. This is probably why others did it this way (these are separated issues even if they do the same thing) and I only obey existing form. I only want to finally add the support for this card. You know many people (not developers) don't care if this function is used or that function is used twice, instead. They just want to install they distro and watch the tv. I classify myself as an programmer rather than ordinary user, so I care how the code looks like. I'm open to the discussion about these things, but this can take long time and I just want the card to be supported asap. There are more cards which has code like this so if linuxtv developers realize eg. to not use callbacks or use only cx_set and cx_clear (instead of cx_write) they'll do it all at once (not every card separately). I attached modified patch: - .gpioX members of inputs which use tuner have reset pin 1 (tuner enabled) - .gpioX members of inputs which don't use tuner have reset pin 0 (tuner disabled) - resets (in callback and the one in pre_i2c) use only two 'cx_write' calls I'm keeping the tested-by lines even if this modified version of patch wasn't tested by those people (the previous version was). I trust this changes can't break the functionality. If you think it's too audacious then drop them. It's on linuxtv developers which of these two patches will be chosen. For the sake of not loosing this patch again, I've applied it as-is. I hope I got the latest version. It is hard to track patches that aren't got by patchwork. I agree with Trent's proposals for optimizing the code: It is better to just call xc3028_winfast1800h_callback() if you ever need to reset xc3028 before the tuner driver. I suspect, however, that you don't need to do such reset, since the tuner driver will do it during its initialization, especially if you've properly initialized the gpio lines. Cheers, 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
Re: [PATCH] Leadtek WinFast DTV-1800H support
On Sun, 31 May 2009, Miroslav [UTF-8] ??ustek wrote: Trent Piepho xyzzy at speakeasy.org writes: Instead of raising the reset line here, why not change the gpio settings in the card definition to have it high? Change gpio1 for television to 0x7050 and radio to 0x7010. Personally, I don't know when these .gpioX members are used (before firmware loads or after...). But I assume that adding the high on reset pin shouldn't break anything, so we can do this. They are used whenever the video mux is set. That will happen when changing inputs and when the cx8800 driver first initializes the card. Opening the radio device does an implicit change to the radio input. It looks like firmware is loaded when needed as part of setting the tuner frequency. I think that makes it safe to assume that the gpios will be set before firmware is loaded. Though it might be possible if the cx8802 driver is loaded before the cx8800 driver. Since you have the hardware, it would be easy to check. Add printk's in the reset callback code you wrote so you'll know when it's called. Then set video_debug to 1 and look for video_mux: lines, which indicate the card gpio values are being set. It seems clear that the xc2028 has an active low reset line. To reset, the line must be lowered for some time period (probably very short) and then raised to enable the chip, at which point there should be a delay (probably longer) while waiting for the chip to come out of reset. If you think about it, it does not matter what state the reset line is in before we lower it. It can be high, it can be low, the chip be reset either way. And shouldn't we put tuner reset pin to 0 when in composite and s-video mode? These inputs don't use tuner or do they? It should be unnecessary to do that, but might help with power consumption. To do it, change the composite and s-video gpio1 values to 0x7060. If I look in dmesg I can see that firmware is loaded into tuner even when these modes are used (I'm using MPlayer to select the input). And due to callbacks issued duting firmware loading, tuner is turned on (reset pin = 1) no matter if it was turned off by .gpioX setting. It seems like firmware loaded should only happen on frequency change. And shouldn't we use the mask bits [24:16] of MO_GPX_IO in .gpioX members too? I know only few GPIO pins and the other I don't know either what direction they should be. That means GPIO pins which I don't know are set as Hi-Z = inputs... Now, when I think of that, if it works it's safer when the other pins are in Hi-Z mode. Never mind. Normally all the unused gpio lines are just set as inputs. Then the reset can be done with: case XC2028_TUNER_RESET: /* GPIO 12 (xc3028 tuner reset) */ cx_write(MO_GP1_IO, 0x101000); mdelay(50); cx_write(MO_GP1_IO, 0x101010); mdelay(50); return 0; Earlier I was told to use 'cx_set' and 'cx_clear' because using 'cx_write' is risky. see here: http://www.spinics.net/lists/linux-dvb/msg29777.html Steven is wrong there and you are right. The cx88 gpio lines have the mask bits in the 3rd byte, which allow changing a gpio without modifying the others with a single write. It is better to use this than to do a read-modify-write. That is actually less safe, since it's not an atomic operation. And when you are using 'cx_set' and 'cx_clear' you need 3 calls. The first to set the direction bit, the second to set 0 on reset pin and the third to set 1 on reset pin. You could use cx_andor() to set the direction bit and lower the reset pin in one call. cx_set/cx_clear are just calls to cx_andor(). But using the mask bit and cx_write is best. Though I have to wonder why each card needs its own xc2028 reset function. Shouldn't they all be the same other than what gpio they change? My English goes lame here. Do you mean that reset function shouldn't use GPIO at all? There is other code for xc2028 reset for different cards, e.g. cx88_dvico_xc2028_callback, cx88_xc3028_geniatech_tuner_callback, cx88_xc2028_tuner_callback, cx88_pv_8000gt_callback, and even cx88_xc5000_tuner_callback. Shouldn't these functions all do the same thing other than what gpio line they change? @@ -2882,6 +2946,16 @@ cx_set(MO_GP0_IO, 0x0080); /* 702 out of reset */ udelay(1000); break; + + case CX88_BOARD_WINFAST_DTV1800H: + /* GPIO 12 (xc3028 tuner reset) */ + cx_set(MO_GP1_IO, 0x1010); + mdelay(50); + cx_clear(MO_GP1_IO, 0x10); + mdelay(50); + cx_set(MO_GP1_IO, 0x10); + mdelay(50); + break; } } Couldn't you replace this with: case CX88_BOARD_WINFAST_DTV1800H: cx88_xc3028_winfast1800h_callback(code, XC2028_TUNER_RESET, 0); break; Yes,
[PATCH] Leadtek WinFast DTV-1800H support
Hello, this patch adds support for Leadtek WinFast DTV-1800H hybrid card. It enables analog/digital tv, radio and remote control trough GPIO. Input GPIO values are extracted from INF file which is included in winxp driver. Analog audio works both through cx88-alsa and through internal cable from tv-card to sound card. Tested by me and the people listed in patch (works well). - Miroslav Šustek (Sorry for double-post, but I was told to do it so. Nobody noticed the previous post(s).) -- 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] Leadtek WinFast DTV-1800H support
Hello, this patch adds support for Leadtek WinFast DTV-1800H hybrid card. It enables analog/digital tv, radio and remote control trough GPIO. Input GPIO values are extracted from INF file which is included in winxp driver. Analog audio works both through cx88-alsa and through internal cable from tv-card to sound card. Tested by me and the people listed in patch (works well). - Miroslav Šustek (Shoot me! Now it's correct.) leadtek_winfast_dtv1800h.patch Description: Binary data
Re: [PATCH] Leadtek WinFast DTV-1800H support
Any problem with this patch? I'm trying to get WinFast DTV-1800H support into repository for seven months. (see: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/1125/match=1800h ) -- 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] Leadtek WinFast DTV-1800H support
Hello, this patch adds support for Leadtek WinFast DTV-1800H hybrid card. It enables analog/digital tv, radio and remote control trough GPIO. Input GPIO values are extracted from INF file which is included in winxp driver. Analog audio works both through cx88-alsa and through internal cable from tv-card to sound card. Tested by me and the people listed in patch (works well). - Miroslav leadtek_winfast_dtv1800h.patch Description: Binary data
