Re: [linux-dvb] XC4000 patches for kernel 2.6.37.2
Em 02-06-2011 22:41, Dmitri Belimov escreveu: > On Thu, 02 Jun 2011 11:41:53 -0300 > Mauro Carvalho Chehab wrote: > One of our TV card has this tuner. It works in analog mode. I try get right > firmware > cleanup and test. > > Can I use > git://linuxtv.org/mchehab/experimental.git branch xc4000 > for do it? Sure. Feel free to use it. I'll be adding there the xc4000-related patches until they're ok for review. Thanks, 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: [linux-dvb] XC4000 patches for kernel 2.6.37.2
Thank you for the comments and pointers. I am happy, at least there are peoples who want to see the xc4000 driver alive. On 2011-06-02, Mauro Carvalho Chehab wrote: > Em 02-06-2011 12:53, Mohammad Bahathir Hashim escreveu: >> Now I understood how thing works here, and it clear to me, why the >> xc4000 driver is not being included in mainline V4L2. >> >> It will be lots of commitments and hard work to be the maintainer, and >> I respect Mr. Devin's choice and decisions. There are several peoples >> that are interested in this driver, such as Mr. Istvan. I realized >> this driver does not have huge users/audiences, but still there are >> peoples who really need it. But, yeah, not everybody can 'port' the >> driver each time Linux kernel or V4L2 version being updated. >> >> In this case, IF no one is able to maintains the driver, how others >> can benefit the 'updated' driver or patches for the new V4L2 or Linux >> releases? >> > > Out of tree drivers tend to become obsolete on a few kernel releases, as the > internal kernel API's were not designed to be stable, as we want innovation > inside the kernel. So, people are free to change the internal APIs when > needed. > > That's why the best way is to submit patches upstream as they're ready > for it. > >> At the moment I still be able to port and test it for my private use. >> Sometime I sent the patches to Mr. Istvan to be included in his >> xc4000 driver's website, for other users to use it. >> >> BTW, I am not a programmer. I am just a system administrator, who only >> like to use shell scripts, awk, sed and grep. I only know how 'read' C, >> and can do SIMPLE 'porting' and testing tasks :). Still I really hope >> other developers able to include the analog TV/FM tuning and S-Video input >> feature to PCTV-340e. >> >> Anyway, if this driver is not elligible to be included in V4L2 >> mainline, I know where to 'push' my patches. :) > > Almost all drivers are eligible to be included, but the author needs to > submit them, or someone on their behalf. If the driver doesn't have enough > quality or needs some fixes, the submitter may need to fix it or, eventually, > move it to staging. > > With respect to xc4000, we need someone to test if the driver works after > the backports. Please test it and answer to us with a "Tested-by" tag. > > After the tests, it would be great to apply any pending patches for xc4000 > before cleaning it, as if we do the reverse, existing patches won't apply. > > 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 http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] XC4000 patches for kernel 2.6.37.2
On Thu, 02 Jun 2011 11:41:53 -0300 Mauro Carvalho Chehab wrote: > Em 02-06-2011 07:52, Devin Heitmueller escreveu: > > 2011/5/31 Dmitri Belimov : > >> Is it possible make some patches and add support xc4000 into > >> kernel? > >> > >> With my best regards, Dmitry. > > > > What needs to happen here is somebody needs to prepare a patch > > series which contains all the relevant patches, including the > > SOBs. This is entirely an janitorial task which can be done by > > anyone and frankly I don't have time for this sort of crap anymore. > > > > Any volunteers? > > > > All my patches have my SOB attached. I explicitly got Davide's > > permission to add his SOB to his original patch, but it's not in the > > HG tree since I got the permission after I committed his change to > > my repo. I can forward the email with his SOB so the person > > constructing the tree can add it on (as well as my SOB to preserve > > the chain of custody). > > > > Secondly, we need to build a firmware image which is based off of > > the *actual* xceive firmware sources, so that we can be confident > > that all the blobs are from the same firmware revision and so that > > we can maintain them going forward. I can provide them off-list to > > someone willing to do this work and testing. Istann_v's firmware > > image is based off of i2c dumps and extracted by hand from > > disassembled firmware, which is less than ideal from an ongoing > > maintenance perspective. > > > > And of course it's worth mentioning that the driver itself still > > needs a ton of cleanup, doesn't meet the coding standards, and > > wouldn't be accepted upstream in its current state. Somebody will > > need to do the work to clean up the driver, as well as testing to > > make sure he/she didn't cause any regressions. > > > > In summary, here are the four things that need to happen: > > > > 1. Assemble tree with current patches > > It is probably easier for me to do this step, as I have my hg import > scripts. However, as I don't have the PCTV devices added at dib0700, > I can't test. > > OK, I did this work, as it just took me a few minutes to rebase > patches 1 and 2. I didn't apply the patches that started with "djh" > since they seemed to be a few hacks during the development time. > > The tree is at: > > git://linuxtv.org/mchehab/experimental.git branch xc4000 > > There are two warnings there that needs to be fixed: > > drivers/media/common/tuners/xc4000.c:1293: warning: > ‘xc4000_is_firmware_loaded’ defined but not used > drivers/media/common/tuners/xc4000.c: In function > ‘check_firmware.clone.0’: drivers/media/common/tuners/xc4000.c:1107: > warning: ‘version’ may be used uninitialized in this function > > Both seems to be trivial. > > A disclaimer notice here: I didn't make any cleanup at the code, > (except by running a whitespace cleanup script) nor I've reviewed it. > > IMO, the next step is to test the rebases against a real hardware, > and adding a few patches fixing it, if the rebases broke. > > The next step would be fix the CodingStyle, and run checkpatch.pl. > There aren't many CodingStyle warnings/errors (13 errors, 28 > warnings). Most of the errors are due to the excess usage of printk's > for debug, and due to some obsolete code commented with //. > > > 2. Construct valid firmware image off of current sources > > 3. Cleanup/coding style > > 4. Testing > > > > Now that we've got a bunch of people who are interested in seeing > > this upstream, who is going to volunteer to do which items in the > > above list? > > > > Devin > > > One of our TV card has this tuner. It works in analog mode. I try get right firmware cleanup and test. Can I use git://linuxtv.org/mchehab/experimental.git branch xc4000 for do it? With my best regards, Dmitry. -- 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: [linux-dvb] XC4000 patches for kernel 2.6.37.2
Em 02-06-2011 12:53, Mohammad Bahathir Hashim escreveu: > Now I understood how thing works here, and it clear to me, why the > xc4000 driver is not being included in mainline V4L2. > > It will be lots of commitments and hard work to be the maintainer, and > I respect Mr. Devin's choice and decisions. There are several peoples > that are interested in this driver, such as Mr. Istvan. I realized > this driver does not have huge users/audiences, but still there are > peoples who really need it. But, yeah, not everybody can 'port' the > driver each time Linux kernel or V4L2 version being updated. > > In this case, IF no one is able to maintains the driver, how others > can benefit the 'updated' driver or patches for the new V4L2 or Linux > releases? > Out of tree drivers tend to become obsolete on a few kernel releases, as the internal kernel API's were not designed to be stable, as we want innovation inside the kernel. So, people are free to change the internal APIs when needed. That's why the best way is to submit patches upstream as they're ready for it. > At the moment I still be able to port and test it for my private use. > Sometime I sent the patches to Mr. Istvan to be included in his > xc4000 driver's website, for other users to use it. > > BTW, I am not a programmer. I am just a system administrator, who only > like to use shell scripts, awk, sed and grep. I only know how 'read' C, > and can do SIMPLE 'porting' and testing tasks :). Still I really hope > other developers able to include the analog TV/FM tuning and S-Video input > feature to PCTV-340e. > > Anyway, if this driver is not elligible to be included in V4L2 > mainline, I know where to 'push' my patches. :) Almost all drivers are eligible to be included, but the author needs to submit them, or someone on their behalf. If the driver doesn't have enough quality or needs some fixes, the submitter may need to fix it or, eventually, move it to staging. With respect to xc4000, we need someone to test if the driver works after the backports. Please test it and answer to us with a "Tested-by" tag. After the tests, it would be great to apply any pending patches for xc4000 before cleaning it, as if we do the reverse, existing patches won't apply. 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 http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] XC4000 patches for kernel 2.6.37.2
Em 02-06-2011 12:17, Devin Heitmueller escreveu:
> On Thu, Jun 2, 2011 at 10:41 AM, Mauro Carvalho Chehab
> wrote:
>>> 1. Assemble tree with current patches
>>
>> It is probably easier for me to do this step, as I have my hg import
>> scripts. However, as I don't have the PCTV devices added at dib0700,
>> I can't test.
>>
>> OK, I did this work, as it just took me a few minutes to rebase patches
>> 1 and 2. I didn't apply the patches that started with "djh" since they
>> seemed to be a few hacks during the development time.
>>
>> The tree is at:
>>
>> git://linuxtv.org/mchehab/experimental.git branch xc4000
>>
>> There are two warnings there that needs to be fixed:
>>
>> drivers/media/common/tuners/xc4000.c:1293: warning:
>> ‘xc4000_is_firmware_loaded’ defined but not used
>> drivers/media/common/tuners/xc4000.c: In function ‘check_firmware.clone.0’:
>> drivers/media/common/tuners/xc4000.c:1107: warning: ‘version’ may be used
>> uninitialized in this function
>>
>> Both seems to be trivial.
>>
>> A disclaimer notice here: I didn't make any cleanup at the code,
>> (except by running a whitespace cleanup script) nor I've reviewed it.
>>
>> IMO, the next step is to test the rebases against a real hardware,
>> and adding a few patches fixing it, if the rebases broke.
>>
>> The next step would be fix the CodingStyle, and run checkpatch.pl.
>> There aren't many CodingStyle warnings/errors (13 errors, 28 warnings).
>> Most of the errors are due to the excess usage of printk's for debug,
>> and due to some obsolete code commented with //.
>
> Hi Mauro,
>
> Thanks for taking this on. The tree you posted looks like a pretty
> reasonable start. I agree that the "djh - " commits probably aren't
> required as they are most just from rebasing the tree. We'll find out
> from testing though whether this is true. There's one patch with
> subject "djh - more debugging" might actually be needed, but we'll see
> when users try the tree.
I was in doubt and I almost backported that one too, but it seemed better
to not add it to just remove it at the end.
Btw, it seems that a latter patch on your tree removed it. The only difference
between the git tree and your tree at xc4000.c/xc4000.h is:
$ diff -uprBw drivers/media/common/tuners/xc4000.c
/home/v4l/tmp/linux/drivers/media/common/tuners/xc4000.c
--- drivers/media/common/tuners/xc4000.c2011-06-02 11:36:19.0
-0300
+++ /home/v4l/tmp/linux/drivers/media/common/tuners/xc4000.c2011-06-02
10:48:34.0 -0300
@@ -1272,7 +1272,8 @@ static int xc4000_set_params(struct dvb_
XC4000_Standard[priv->video_standard].AudioMode);
if (ret != XC_RESULT_SUCCESS) {
printk(KERN_ERR "xc4000: xc_SetTVStandard failed\n");
- return -EREMOTEIO;
+ /* DJH - do not return when it fails... */
+ //return -EREMOTEIO;
}
#ifdef DJH_DEBUG
ret = xc_set_IF_frequency(priv, priv->if_khz);
So, maybe the above patch also needs to be added there.
> This provides a pretty good base for istan_v to work off of, since he
> did a rather large amount of refactoring to get analog to work - which
> I was unable to even try given the two devices I had can't do analog
> support due to limitations in the dvb-usb framework.
>
> Mohammad, it would be great if you could try out Mauro's tree, since
> it should work as-is for the 340e.
If it doesn't, please try to apply the above patch.
Thanks,
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: [linux-dvb] XC4000 patches for kernel 2.6.37.2
Now I understood how thing works here, and it clear to me, why the xc4000 driver is not being included in mainline V4L2. It will be lots of commitments and hard work to be the maintainer, and I respect Mr. Devin's choice and decisions. There are several peoples that are interested in this driver, such as Mr. Istvan. I realized this driver does not have huge users/audiences, but still there are peoples who really need it. But, yeah, not everybody can 'port' the driver each time Linux kernel or V4L2 version being updated. In this case, IF no one is able to maintains the driver, how others can benefit the 'updated' driver or patches for the new V4L2 or Linux releases? At the moment I still be able to port and test it for my private use. Sometime I sent the patches to Mr. Istvan to be included in his xc4000 driver's website, for other users to use it. BTW, I am not a programmer. I am just a system administrator, who only like to use shell scripts, awk, sed and grep. I only know how 'read' C, and can do SIMPLE 'porting' and testing tasks :). Still I really hope other developers able to include the analog TV/FM tuning and S-Video input feature to PCTV-340e. Anyway, if this driver is not elligible to be included in V4L2 mainline, I know where to 'push' my patches. :) Thank you. On 2011-06-02, Devin Heitmueller wrote: > 2011/5/31 Dmitri Belimov : >> Is it possible make some patches and add support xc4000 into kernel? >> >> With my best regards, Dmitry. > > What needs to happen here is somebody needs to prepare a patch series > which contains all the relevant patches, including the SOBs. This is > entirely an janitorial task which can be done by anyone and frankly I > don't have time for this sort of crap anymore. > > Any volunteers? > > All my patches have my SOB attached. I explicitly got Davide's > permission to add his SOB to his original patch, but it's not in the > HG tree since I got the permission after I committed his change to my > repo. I can forward the email with his SOB so the person constructing > the tree can add it on (as well as my SOB to preserve the chain of > custody). > > Secondly, we need to build a firmware image which is based off of the > *actual* xceive firmware sources, so that we can be confident that all > the blobs are from the same firmware revision and so that we can > maintain them going forward. I can provide them off-list to someone > willing to do this work and testing. Istann_v's firmware image is > based off of i2c dumps and extracted by hand from disassembled > firmware, which is less than ideal from an ongoing maintenance > perspective. > > And of course it's worth mentioning that the driver itself still needs > a ton of cleanup, doesn't meet the coding standards, and wouldn't be > accepted upstream in its current state. Somebody will need to do the > work to clean up the driver, as well as testing to make sure he/she > didn't cause any regressions. > > In summary, here are the four things that need to happen: > > 1. Assemble tree with current patches > 2. Construct valid firmware image off of current sources > 3. Cleanup/coding style > 4. Testing > > Now that we've got a bunch of people who are interested in seeing this > upstream, who is going to volunteer to do which items in the above > list? > > Devin > -- 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: [linux-dvb] XC4000 patches for kernel 2.6.37.2
On Thu, Jun 2, 2011 at 10:41 AM, Mauro Carvalho Chehab wrote: >> 1. Assemble tree with current patches > > It is probably easier for me to do this step, as I have my hg import > scripts. However, as I don't have the PCTV devices added at dib0700, > I can't test. > > OK, I did this work, as it just took me a few minutes to rebase patches > 1 and 2. I didn't apply the patches that started with "djh" since they > seemed to be a few hacks during the development time. > > The tree is at: > > git://linuxtv.org/mchehab/experimental.git branch xc4000 > > There are two warnings there that needs to be fixed: > > drivers/media/common/tuners/xc4000.c:1293: warning: > ‘xc4000_is_firmware_loaded’ defined but not used > drivers/media/common/tuners/xc4000.c: In function ‘check_firmware.clone.0’: > drivers/media/common/tuners/xc4000.c:1107: warning: ‘version’ may be used > uninitialized in this function > > Both seems to be trivial. > > A disclaimer notice here: I didn't make any cleanup at the code, > (except by running a whitespace cleanup script) nor I've reviewed it. > > IMO, the next step is to test the rebases against a real hardware, > and adding a few patches fixing it, if the rebases broke. > > The next step would be fix the CodingStyle, and run checkpatch.pl. > There aren't many CodingStyle warnings/errors (13 errors, 28 warnings). > Most of the errors are due to the excess usage of printk's for debug, > and due to some obsolete code commented with //. Hi Mauro, Thanks for taking this on. The tree you posted looks like a pretty reasonable start. I agree that the "djh - " commits probably aren't required as they are most just from rebasing the tree. We'll find out from testing though whether this is true. There's one patch with subject "djh - more debugging" might actually be needed, but we'll see when users try the tree. This provides a pretty good base for istan_v to work off of, since he did a rather large amount of refactoring to get analog to work - which I was unable to even try given the two devices I had can't do analog support due to limitations in the dvb-usb framework. Mohammad, it would be great if you could try out Mauro's tree, since it should work as-is for the 340e. Devin -- Devin J. Heitmueller - 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: [linux-dvb] XC4000 patches for kernel 2.6.37.2
Em 02-06-2011 07:52, Devin Heitmueller escreveu: > 2011/5/31 Dmitri Belimov : >> Is it possible make some patches and add support xc4000 into kernel? >> >> With my best regards, Dmitry. > > What needs to happen here is somebody needs to prepare a patch series > which contains all the relevant patches, including the SOBs. This is > entirely an janitorial task which can be done by anyone and frankly I > don't have time for this sort of crap anymore. > > Any volunteers? > > All my patches have my SOB attached. I explicitly got Davide's > permission to add his SOB to his original patch, but it's not in the > HG tree since I got the permission after I committed his change to my > repo. I can forward the email with his SOB so the person constructing > the tree can add it on (as well as my SOB to preserve the chain of > custody). > > Secondly, we need to build a firmware image which is based off of the > *actual* xceive firmware sources, so that we can be confident that all > the blobs are from the same firmware revision and so that we can > maintain them going forward. I can provide them off-list to someone > willing to do this work and testing. Istann_v's firmware image is > based off of i2c dumps and extracted by hand from disassembled > firmware, which is less than ideal from an ongoing maintenance > perspective. > > And of course it's worth mentioning that the driver itself still needs > a ton of cleanup, doesn't meet the coding standards, and wouldn't be > accepted upstream in its current state. Somebody will need to do the > work to clean up the driver, as well as testing to make sure he/she > didn't cause any regressions. > > In summary, here are the four things that need to happen: > > 1. Assemble tree with current patches It is probably easier for me to do this step, as I have my hg import scripts. However, as I don't have the PCTV devices added at dib0700, I can't test. OK, I did this work, as it just took me a few minutes to rebase patches 1 and 2. I didn't apply the patches that started with "djh" since they seemed to be a few hacks during the development time. The tree is at: git://linuxtv.org/mchehab/experimental.git branch xc4000 There are two warnings there that needs to be fixed: drivers/media/common/tuners/xc4000.c:1293: warning: ‘xc4000_is_firmware_loaded’ defined but not used drivers/media/common/tuners/xc4000.c: In function ‘check_firmware.clone.0’: drivers/media/common/tuners/xc4000.c:1107: warning: ‘version’ may be used uninitialized in this function Both seems to be trivial. A disclaimer notice here: I didn't make any cleanup at the code, (except by running a whitespace cleanup script) nor I've reviewed it. IMO, the next step is to test the rebases against a real hardware, and adding a few patches fixing it, if the rebases broke. The next step would be fix the CodingStyle, and run checkpatch.pl. There aren't many CodingStyle warnings/errors (13 errors, 28 warnings). Most of the errors are due to the excess usage of printk's for debug, and due to some obsolete code commented with //. > 2. Construct valid firmware image off of current sources > 3. Cleanup/coding style > 4. Testing > > Now that we've got a bunch of people who are interested in seeing this > upstream, who is going to volunteer to do which items in the above > list? > > Devin > -- 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: [linux-dvb] XC4000 patches for kernel 2.6.37.2
2011/5/31 Dmitri Belimov : > Is it possible make some patches and add support xc4000 into kernel? > > With my best regards, Dmitry. What needs to happen here is somebody needs to prepare a patch series which contains all the relevant patches, including the SOBs. This is entirely an janitorial task which can be done by anyone and frankly I don't have time for this sort of crap anymore. Any volunteers? All my patches have my SOB attached. I explicitly got Davide's permission to add his SOB to his original patch, but it's not in the HG tree since I got the permission after I committed his change to my repo. I can forward the email with his SOB so the person constructing the tree can add it on (as well as my SOB to preserve the chain of custody). Secondly, we need to build a firmware image which is based off of the *actual* xceive firmware sources, so that we can be confident that all the blobs are from the same firmware revision and so that we can maintain them going forward. I can provide them off-list to someone willing to do this work and testing. Istann_v's firmware image is based off of i2c dumps and extracted by hand from disassembled firmware, which is less than ideal from an ongoing maintenance perspective. And of course it's worth mentioning that the driver itself still needs a ton of cleanup, doesn't meet the coding standards, and wouldn't be accepted upstream in its current state. Somebody will need to do the work to clean up the driver, as well as testing to make sure he/she didn't cause any regressions. In summary, here are the four things that need to happen: 1. Assemble tree with current patches 2. Construct valid firmware image off of current sources 3. Cleanup/coding style 4. Testing Now that we've got a bunch of people who are interested in seeing this upstream, who is going to volunteer to do which items in the above list? Devin -- Devin J. Heitmueller - 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: [linux-dvb] XC4000 patches for kernel 2.6.37.2
I am a Pinnacle PCTV 340e user for 2 years. Since the release of
"Christmast Gift" in kernellabs.org, I privately made patches to ports
the driver until the latest vanilla 2.6.39. I have no problem using
the driver for my daily DVB-T viewing usage.
Since it is open sourced, I also want to publish my patches here too.
Please consider to incluge it in main-line V4L2. It is up to users or
maintainers to acceept it or not.
Anyway, thank you Devin for your initial driver.
TQ
###
### thi patch is NOT includes the xv4000.[ch].
diff -urw a/drivers/media/common/tuners/Kconfig
b/drivers/media/common/tuners/Kconfig
--- a/drivers/media/common/tuners/Kconfig 2011-05-19 12:06:34.0
+0800
+++ b/drivers/media/common/tuners/Kconfig 2011-05-20 16:53:26.900999684
+0800
@@ -23,6 +23,7 @@
depends on VIDEO_MEDIA && I2C
select MEDIA_TUNER_XC2028 if !MEDIA_TUNER_CUSTOMISE
select MEDIA_TUNER_XC5000 if !MEDIA_TUNER_CUSTOMISE
+ select MEDIA_TUNER_XC4000 if !MEDIA_TUNER_CUSTOMISE
select MEDIA_TUNER_MT20XX if !MEDIA_TUNER_CUSTOMISE
select MEDIA_TUNER_TDA8290 if !MEDIA_TUNER_CUSTOMISE
select MEDIA_TUNER_TEA5761 if !MEDIA_TUNER_CUSTOMISE
@@ -152,6 +153,15 @@
This device is only used inside a SiP called together with a
demodulator for now.
+config MEDIA_TUNER_XC4000
+ tristate "Xceive XC4000 silicon tuner"
+ depends on VIDEO_MEDIA && I2C
+ default m if MEDIA_TUNER_CUSTOMISE
+ help
+ A driver for the silicon tuner XC4000 from Xceive.
+ This device is only used inside a SiP called together with a
+ demodulator for now.
+
config MEDIA_TUNER_MXL5005S
tristate "MaxLinear MSL5005S silicon tuner"
depends on VIDEO_MEDIA && I2C
diff -urw a/drivers/media/common/tuners/Makefile
b/drivers/media/common/tuners/Makefile
--- a/drivers/media/common/tuners/Makefile 2011-05-19 12:06:34.0
+0800
+++ b/drivers/media/common/tuners/Makefile 2011-05-20 17:28:57.357999207
+0800
@@ -16,6 +16,7 @@
obj-$(CONFIG_MEDIA_TUNER_TDA827X) += tda827x.o
obj-$(CONFIG_MEDIA_TUNER_TDA18271) += tda18271.o
obj-$(CONFIG_MEDIA_TUNER_XC5000) += xc5000.o
+obj-$(CONFIG_MEDIA_TUNER_XC4000) += xc4000.o
obj-$(CONFIG_MEDIA_TUNER_MT2060) += mt2060.o
obj-$(CONFIG_MEDIA_TUNER_MT2266) += mt2266.o
obj-$(CONFIG_MEDIA_TUNER_QT1010) += qt1010.o
diff -urw a/drivers/media/common/tuners/tuner-types.c
b/drivers/media/common/tuners/tuner-types.c
--- a/drivers/media/common/tuners/tuner-types.c 2011-05-19 12:06:34.0
+0800
+++ b/drivers/media/common/tuners/tuner-types.c 2011-05-20 16:53:26.923999684
+0800
@@ -1805,6 +1805,10 @@
.name = "Xceive 5000 tuner",
/* see xc5000.c for details */
},
+ [TUNER_XC4000] = { /* Xceive 4000 */
+ .name = "Xceive 4000 tuner",
+ /* see xc4000.c for details */
+ },
[TUNER_TCL_MF02GIP_5N] = { /* TCL tuner MF02GIP-5N-E */
.name = "TCL tuner MF02GIP-5N-E",
.params = tuner_tcl_mf02gip_5n_params,
diff -urw a/drivers/media/dvb/dvb-usb/Kconfig
b/drivers/media/dvb/dvb-usb/Kconfig
--- a/drivers/media/dvb/dvb-usb/Kconfig 2011-05-19 12:06:34.0 +0800
+++ b/drivers/media/dvb/dvb-usb/Kconfig 2011-05-20 16:53:26.936999686 +0800
@@ -81,6 +81,7 @@
select MEDIA_TUNER_MT2266 if !MEDIA_TUNER_CUSTOMISE
select MEDIA_TUNER_XC2028 if !MEDIA_TUNER_CUSTOMISE
select MEDIA_TUNER_XC5000 if !MEDIA_TUNER_CUSTOMISE
+ select MEDIA_TUNER_XC4000 if !MEDIA_TUNER_CUSTOMISE
select MEDIA_TUNER_MXL5007T if !MEDIA_TUNER_CUSTOMISE
help
Support for USB2.0/1.1 DVB receivers based on the DiB0700 USB bridge.
The
diff -urw a/drivers/media/dvb/dvb-usb/dib0700_devices.c
b/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c 2011-05-19
12:06:34.0 +0800
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c 2011-05-20
22:25:28.653000410 +0800
@@ -17,6 +17,7 @@
#include "mt2266.h"
#include "tuner-xc2028.h"
#include "xc5000.h"
+#include "xc4000.h"
#include "s5h1411.h"
#include "dib0070.h"
#include "dib0090.h"
@@ -2656,6 +2657,146 @@
== NULL ? -ENODEV : 0;
}
+static int dib0700_xc4000_tuner_callback(void *priv, int component,
+int command, int arg)
+{
+ struct dvb_usb_adapter *adap = priv;
+
+ if (command == XC4000_TUNER_RESET) {
+ /* Reset the tuner */
+ dib7000p_set_gpio(adap->fe, 8, 0, 0);
+ msleep(10);
+ dib7000p_set_gpio(adap->fe, 8, 0, 1);
+ } else {
+ err("xc4000: unknown tuner callback command: %d\n", command);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct dibx000_agc_config stk7700p_7000p_xc4000_agc_config = {
+ .band_caps = BAND_UHF | BAND_VHF,
+ .setup = 0x64,
+
Re: [linux-dvb] XC4000 patches for kernel 2.6.37.2
Hi Devin > On Mon, May 30, 2011 at 10:48 PM, Dmitri Belimov > wrote: > > Hi > > > >> Hi Istvan > >> > >> I am sending you modified patches for kernel 2.6.37.2, they > >> works as expected. > >> > >> First apply kernel_xc4000.diff (your patch) then > >> kernel_dtv3200h.diff for Leadtek DTV3200 XC4000 support. > > > > Can you resend your patches with right Signed-Off string for commit > > into kernel? > > > > With my best regards, Dmitry. > > He cannot offer a Signed-off-by for the entire patch - it's not his > code. The patches are based on the work that Davide Ferri and I did > about 17 months ago: > > http://kernellabs.com/hg/~dheitmueller/pctv-340e-2/shortlog > > I'm not against seeing the xc4000 support going in, but the history > needs to be preserved, which means it needs to be broken in to a patch > series that properly credits my and Davide's work. Is it possible make some patches and add support xc4000 into kernel? With my best regards, Dmitry. > Devin > > -- > Devin J. Heitmueller - 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: [linux-dvb] XC4000 patches for kernel 2.6.37.2
On Mon, May 30, 2011 at 10:48 PM, Dmitri Belimov wrote: > Hi > >> Hi Istvan >> >> I am sending you modified patches for kernel 2.6.37.2, they >> works as expected. >> >> First apply kernel_xc4000.diff (your patch) then kernel_dtv3200h.diff >> for Leadtek DTV3200 XC4000 support. > > Can you resend your patches with right Signed-Off string for commit into > kernel? > > With my best regards, Dmitry. He cannot offer a Signed-off-by for the entire patch - it's not his code. The patches are based on the work that Davide Ferri and I did about 17 months ago: http://kernellabs.com/hg/~dheitmueller/pctv-340e-2/shortlog I'm not against seeing the xc4000 support going in, but the history needs to be preserved, which means it needs to be broken in to a patch series that properly credits my and Davide's work. Devin -- Devin J. Heitmueller - 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: [linux-dvb] XC4000 patches for kernel 2.6.37.2
Hi > Hi Istvan > > I am sending you modified patches for kernel 2.6.37.2, they > works as expected. > > First apply kernel_xc4000.diff (your patch) then kernel_dtv3200h.diff > for Leadtek DTV3200 XC4000 support. Can you resend your patches with right Signed-Off string for commit into kernel? With my best regards, Dmitry. -- 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
