Re: av7110 and budget_av are broken!
Hi, Am Sonntag, den 16.05.2010, 06:21 +0200 schrieb Oliver Endriss: On Sunday 16 May 2010 03:53:48 hermann pitton wrote: Am Samstag, den 15.05.2010, 22:33 -0300 schrieb Douglas Schilling Landgraf: Hello Oliver, On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss o.endr...@gmx.de wrote: On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote: On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote: Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! What about the HG driver? The v4l-dvb HG repository is broken for 7 weeks... Hi guys, we have May 16th, and the HG driver is broken for 10 weeks now! History: - The changeset which caused the mess was applied on March 2nd: http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f - A fix is waiting at fixes.git since March 24th: http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73 Are there any plans to bring v4ldvb HG to an usable state? Yes, Now I will collect patches from devel and fixes tree. At least until we achieve a better approach on it. Sorry the delay. Sounds good? Any other suggestion? Let me work on it. Cheers Douglas Hi, Douglas and Oliver, just as a small comment. I have not been on latest rc1 and such rcs close to a release for some time. But I was for a long time and v4l-dvb can't be a substitute for such. Sorry, I do not want to cope with experimental kernels and their bugs on my systems. I need a stable and reliable platform, so that I can concentrate on 'my' bugs. Usually I update the kernel every 3..4 releases (which causes enough trouble due to changed features, interfaces etc). that is what everyone does prefer and that I call subsystem developer service. In fact, everyone has to be on .rc stuff starting with .rc1 ;) Failing on being there, than blaming the one doing the backports for being in delay, likely without any related hardware in his possession, that can't work. Cheers, Hermann -- 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: av7110 and budget_av are broken!
Hi Douglas, On Sunday 16 May 2010 07:09:21 Douglas Schilling Landgraf wrote: Please hg pull -u, now should include the change that you are looking for. Thanks, now the driver works again. :-) Regards, Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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: av7110 and budget_av are broken!
Oliver Endriss wrote: On Sunday 16 May 2010 03:53:48 hermann pitton wrote: Am Samstag, den 15.05.2010, 22:33 -0300 schrieb Douglas Schilling Landgraf: Hello Oliver, On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss o.endr...@gmx.de wrote: On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote: On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote: Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! What about the HG driver? The v4l-dvb HG repository is broken for 7 weeks... Hi guys, we have May 16th, and the HG driver is broken for 10 weeks now! History: - The changeset which caused the mess was applied on March 2nd: http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f - A fix is waiting at fixes.git since March 24th: http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73 Are there any plans to bring v4ldvb HG to an usable state? Yes, Now I will collect patches from devel and fixes tree. At least until we achieve a better approach on it. Sorry the delay. Sounds good? Any other suggestion? Let me work on it. Cheers Douglas Hi, Douglas and Oliver, just as a small comment. I have not been on latest rc1 and such rcs close to a release for some time. But I was for a long time and v4l-dvb can't be a substitute for such. Sorry, I do not want to cope with experimental kernels and their bugs on my systems. I need a stable and reliable platform, so that I can concentrate on 'my' bugs. Usually I update the kernel every 3..4 releases (which causes enough trouble due to changed features, interfaces etc). I used to do it, but, in fact updating every release and following stable worked better for me, since there are less changes at the features, making easier to compile a new kernel that won't break anything. Anyway, it is up to you to use whatever works better for you. Despite of getting more users for testing, on _that_ front does not happen such much currently, keeping v4l-dvb is mostly a service for developers this time. So, contributing on the backports and helping Douglas with such is really welcome. I confess that I do not know much about the tree handling procedures of the kernel. Imho it sounds crazy to have separate 'fixes' and 'development' trees. I'll change the procedures for 2.6.35. I'll basically opt for having topic branches (for example, having a ngene branch), where all ngene patches will be applied, updating master only after having those patches in kernel. I'll likely create a stable branch, with the latest kernel, plus all patches (like v2.6.34-v4l-dvb), to help people that want to develop using git. The big problem when handling patches upstream is caused by rebasing a patch, and the higher number of patches in a tree, the higher is the probability that a rebase will needed to avoid breaking compilation on a bisect. To give you an example, one big series of patches moved slab.h into each driver that uses malloc. If a new driver or c file that needs this include on our series were added, to avoid breaking bisect, we need to go to the patch that introduced this code, and add the include there. All patches after this one needs to be rebased, when submitting upstream. So, let's say that the original patch has 05a43 has, and the new patch has a0342 (fictional numbers). So, in the development branches, this patch is known as 05a43, where, on upstream, this patch will be known as a0342. If I rebase the development tree, all developers using git would need to rebase their trees. If I don't rebase, after merging from upstream, this patch will appear 2 times at the master branch history: as 05a43 and as a0342. To be worse, on the next time I need to send patches upstream, this patch will appear again on my pile of patches to be submitted, and I'll need to manually drop it. Due to 2.6.33 merge, this problem is already present on our master branch. So, I'll need to drop a big pile of patches on my next upstream pull request. At each new kernel release, things would become worse. With topic branches, things will hopefully become easier, as people can base their trees on a topic branch. Also, we may have some topic branches based on a
Re: av7110 and budget_av are broken!
On Sunday 16 May 2010 14:57:18 Mauro Carvalho Chehab wrote: Oliver Endriss wrote: On Sunday 16 May 2010 03:53:48 hermann pitton wrote: Hi, Douglas and Oliver, just as a small comment. I have not been on latest rc1 and such rcs close to a release for some time. But I was for a long time and v4l-dvb can't be a substitute for such. Sorry, I do not want to cope with experimental kernels and their bugs on my systems. I need a stable and reliable platform, so that I can concentrate on 'my' bugs. Usually I update the kernel every 3..4 releases (which causes enough trouble due to changed features, interfaces etc). I used to do it, but, in fact updating every release and following stable worked better for me, since there are less changes at the features, making easier to compile a new kernel that won't break anything. Anyway, it is up to you to use whatever works better for you. Well, the problem is bug hunting: If you have changes both in the kernel and in the driver, it is harder to identify the problem... Despite of getting more users for testing, on _that_ front does not happen such much currently, keeping v4l-dvb is mostly a service for developers this time. So, contributing on the backports and helping Douglas with such is really welcome. I confess that I do not know much about the tree handling procedures of the kernel. Imho it sounds crazy to have separate 'fixes' and 'development' trees. I'll change the procedures for 2.6.35. I'll basically opt for having topic branches (for example, having a ngene branch), where all ngene patches will be applied, updating master only after having those patches in kernel. How do you handle patches for shared components (frontend drivers, dvb-core etc)? With topic branches, you have to apply those to every topic branch which depends on them. I'll likely create a stable branch, with the latest kernel, plus all patches (like v2.6.34-v4l-dvb), to help people that want to develop using git. The big problem when handling patches upstream is caused by rebasing a patch, and the higher number of patches in a tree, the higher is the probability that a rebase will needed to avoid breaking compilation on a bisect. To give you an example, one big series of patches moved slab.h into each driver that uses malloc. If a new driver or c file that needs this include on our series were added, to avoid breaking bisect, we need to go to the patch that introduced this code, and add the include there. All patches after this one needs to be rebased, when submitting upstream. I would rather break bisect than doing that. In this example one could simply disable the new driver in menuconfig to avoid the problem. So, let's say that the original patch has 05a43 has, and the new patch has a0342 (fictional numbers). So, in the development branches, this patch is known as 05a43, where, on upstream, this patch will be known as a0342. If I rebase the development tree, all developers using git would need to rebase their trees. If I don't rebase, after merging from upstream, this patch will appear 2 times at the master branch history: as 05a43 and as a0342. To be worse, on the next time I need to send patches upstream, this patch will appear again on my pile of patches to be submitted, and I'll need to manually drop it. Due to 2.6.33 merge, this problem is already present on our master branch. So, I'll need to drop a big pile of patches on my next upstream pull request. At each new kernel release, things would become worse. Hm. Imho tree handling is getting way too complicated. ;-( With topic branches, things will hopefully become easier, as people can base their trees on a topic branch. Also, we may have some topic branches based on a stable release, and others based on upstream, but it will require me to maintain separate development branches with all merging patches per kernel release. See above. I doubt that it will make things really easier. A developer's tree (no matter whether HG or GIT) must also include the fixes, otherwise it is unusable. You cannot wait until applied fixes flow back from the kernel. Btw, the v4ldvb HG repositories contain tons of disabled code (marked '#if 0'), which was stripped for submission to the kernel. Even if we would switch to GIT completely, we need a separate GIT repository which would hold the original code. This is due to a policy we had at -hg time: not pollute upstream with dead code garbage. Maybe we may have a topic branch with all those dead code, but I think that, before adding those code on kernel, we need to review what will be added there: there are _lots_ of such #if 0 code that is there for years and were never touched (in a matter of fact, this is the typical case). It seems valuable to do a cleanup first, at -hg, removing the ones that are there for ages and that nobody is interested on working it, and
Re: av7110 and budget_av are broken!
Oliver Endriss wrote: On Sunday 16 May 2010 14:57:18 Mauro Carvalho Chehab wrote: Oliver Endriss wrote: On Sunday 16 May 2010 03:53:48 hermann pitton wrote: Hi, Douglas and Oliver, just as a small comment. I have not been on latest rc1 and such rcs close to a release for some time. But I was for a long time and v4l-dvb can't be a substitute for such. Sorry, I do not want to cope with experimental kernels and their bugs on my systems. I need a stable and reliable platform, so that I can concentrate on 'my' bugs. Usually I update the kernel every 3..4 releases (which causes enough trouble due to changed features, interfaces etc). I used to do it, but, in fact updating every release and following stable worked better for me, since there are less changes at the features, making easier to compile a new kernel that won't break anything. Anyway, it is up to you to use whatever works better for you. Well, the problem is bug hunting: If you have changes both in the kernel and in the driver, it is harder to identify the problem... True, but if you're using an older kernel version, you can miss some bugs that appeared because of some changes that happened upstream. Despite of getting more users for testing, on _that_ front does not happen such much currently, keeping v4l-dvb is mostly a service for developers this time. So, contributing on the backports and helping Douglas with such is really welcome. I confess that I do not know much about the tree handling procedures of the kernel. Imho it sounds crazy to have separate 'fixes' and 'development' trees. I'll change the procedures for 2.6.35. I'll basically opt for having topic branches (for example, having a ngene branch), where all ngene patches will be applied, updating master only after having those patches in kernel. How do you handle patches for shared components (frontend drivers, dvb-core etc)? With topic branches, you have to apply those to every topic branch which depends on them. Yes. x86 is using topic branches and it is working there. So, I'm expecting that the same kind of procedure could work for us. I'll likely create a stable branch, with the latest kernel, plus all patches (like v2.6.34-v4l-dvb), to help people that want to develop using git. The big problem when handling patches upstream is caused by rebasing a patch, and the higher number of patches in a tree, the higher is the probability that a rebase will needed to avoid breaking compilation on a bisect. To give you an example, one big series of patches moved slab.h into each driver that uses malloc. If a new driver or c file that needs this include on our series were added, to avoid breaking bisect, we need to go to the patch that introduced this code, and add the include there. All patches after this one needs to be rebased, when submitting upstream. I would rather break bisect than doing that. In this example one could simply disable the new driver in menuconfig to avoid the problem. If it is a new driver, we can do that, but even moving a patch at the patch series or changing an unrelated patch will change the md5sum for the entire series. Disabling bisect hurts not only us, when seeking for a bug, but any other developer/user that is seeking for what patch broke for him. From one kernel version to the next one, dozens of thousands of patches are applied. With bisect, a broken patch can be identified with about 10 compilations, while, without bisect, you'll need to seek the entire patch series. So, it is not an option to break bisect. So, let's say that the original patch has 05a43 has, and the new patch has a0342 (fictional numbers). So, in the development branches, this patch is known as 05a43, where, on upstream, this patch will be known as a0342. If I rebase the development tree, all developers using git would need to rebase their trees. If I don't rebase, after merging from upstream, this patch will appear 2 times at the master branch history: as 05a43 and as a0342. To be worse, on the next time I need to send patches upstream, this patch will appear again on my pile of patches to be submitted, and I'll need to manually drop it. Due to 2.6.33 merge, this problem is already present on our master branch. So, I'll need to drop a big pile of patches on my next upstream pull request. At each new kernel release, things would become worse. Hm. Imho tree handling is getting way too complicated. ;-( It were always complex, but as we're having much more conflicts with SoC patches, and a much higher number of patches, the old process, where I was fixing the conflicts myself only when sending stuff upstream, weren't working anymore, as the number of troubles were exponentially increasing with a linear grouth of the number of patches. Anyway, I'm open to suggestions to improve the process. With topic branches, things will hopefully become easier, as people can base their trees on a
Re: av7110 and budget_av are broken!
On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote: On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote: Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! What about the HG driver? The v4l-dvb HG repository is broken for 7 weeks... Hi guys, we have May 16th, and the HG driver is broken for 10 weeks now! History: - The changeset which caused the mess was applied on March 2nd: http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f - A fix is waiting at fixes.git since March 24th: http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73 Are there any plans to bring v4ldvb HG to an usable state? CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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: av7110 and budget_av are broken!
Hello Oliver, On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss o.endr...@gmx.de wrote: On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote: On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote: Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! What about the HG driver? The v4l-dvb HG repository is broken for 7 weeks... Hi guys, we have May 16th, and the HG driver is broken for 10 weeks now! History: - The changeset which caused the mess was applied on March 2nd: http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f - A fix is waiting at fixes.git since March 24th: http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73 Are there any plans to bring v4ldvb HG to an usable state? Yes, Now I will collect patches from devel and fixes tree. At least until we achieve a better approach on it. Sorry the delay. Sounds good? Any other suggestion? Let me work on it. Cheers Douglas -- 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: av7110 and budget_av are broken!
Am Samstag, den 15.05.2010, 22:33 -0300 schrieb Douglas Schilling Landgraf: Hello Oliver, On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss o.endr...@gmx.de wrote: On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote: On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote: Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! What about the HG driver? The v4l-dvb HG repository is broken for 7 weeks... Hi guys, we have May 16th, and the HG driver is broken for 10 weeks now! History: - The changeset which caused the mess was applied on March 2nd: http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f - A fix is waiting at fixes.git since March 24th: http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73 Are there any plans to bring v4ldvb HG to an usable state? Yes, Now I will collect patches from devel and fixes tree. At least until we achieve a better approach on it. Sorry the delay. Sounds good? Any other suggestion? Let me work on it. Cheers Douglas Hi, Douglas and Oliver, just as a small comment. I have not been on latest rc1 and such rcs close to a release for some time. But I was for a long time and v4l-dvb can't be a substitute for such. Despite of getting more users for testing, on _that_ front does not happen such much currently, keeping v4l-dvb is mostly a service for developers this time. So, contributing on the backports and helping Douglas with such is really welcome. Cheers, Hermann -- 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: av7110 and budget_av are broken!
On Sunday 16 May 2010 03:53:48 hermann pitton wrote: Am Samstag, den 15.05.2010, 22:33 -0300 schrieb Douglas Schilling Landgraf: Hello Oliver, On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss o.endr...@gmx.de wrote: On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote: On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote: Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! What about the HG driver? The v4l-dvb HG repository is broken for 7 weeks... Hi guys, we have May 16th, and the HG driver is broken for 10 weeks now! History: - The changeset which caused the mess was applied on March 2nd: http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f - A fix is waiting at fixes.git since March 24th: http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73 Are there any plans to bring v4ldvb HG to an usable state? Yes, Now I will collect patches from devel and fixes tree. At least until we achieve a better approach on it. Sorry the delay. Sounds good? Any other suggestion? Let me work on it. Cheers Douglas Hi, Douglas and Oliver, just as a small comment. I have not been on latest rc1 and such rcs close to a release for some time. But I was for a long time and v4l-dvb can't be a substitute for such. Sorry, I do not want to cope with experimental kernels and their bugs on my systems. I need a stable and reliable platform, so that I can concentrate on 'my' bugs. Usually I update the kernel every 3..4 releases (which causes enough trouble due to changed features, interfaces etc). Despite of getting more users for testing, on _that_ front does not happen such much currently, keeping v4l-dvb is mostly a service for developers this time. So, contributing on the backports and helping Douglas with such is really welcome. I confess that I do not know much about the tree handling procedures of the kernel. Imho it sounds crazy to have separate 'fixes' and 'development' trees. A developer's tree (no matter whether HG or GIT) must also include the fixes, otherwise it is unusable. You cannot wait until applied fixes flow back from the kernel. Btw, the v4ldvb HG repositories contain tons of disabled code (marked '#if 0'), which was stripped for submission to the kernel. Even if we would switch to GIT completely, we need a separate GIT repository which would hold the original code. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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: av7110 and budget_av are broken!
On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss o.endr...@gmx.de wrote: On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote: On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote: Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! What about the HG driver? The v4l-dvb HG repository is broken for 7 weeks... Hi guys, we have May 16th, and the HG driver is broken for 10 weeks now! History: - The changeset which caused the mess was applied on March 2nd: http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f - A fix is waiting at fixes.git since March 24th: http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73 Are there any plans to bring v4ldvb HG to an usable state? Please hg pull -u, now should include the change that you are looking for. Cheers Douglas -- 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: av7110 and budget_av are broken!
On Mon, Apr 26, 2010 at 6:35 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: You need to ask Douglas about -hg issues. He is the actual maintainer of that tree. It is probably a good idea to merge also from fixes.git tree, but this may make his sync process more complicated, so, it is up to him to decide how to do it. I still thinking on having a better way to have those fixes patches merged earlier on -git, but I'll need to have some time to do some scripting and test some things. I think any progress to keep these trees in better sync is a good idea. I don't actually know anyone who bothers with the git tree for obvious reasons About half of the developers are submitting git requests, so it seems that there are people using it. I'd expect that a portion of developers prefer git, but I was referring to end-users -- the guys who do the majority of testing imo. I don't know any end-users with any intention of using the git tree. Actually, there are quite a few who stopped updating their hg tree and prefer to use older known working drivers because of the sync problems/broken drivers not being fixed. From a developer standpoint it may be decent but to an end-user it's just turned into a big mess. Oh well, who needs all those testers anyways? ;) Cheers -- 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: av7110 and budget_av are broken!
On Wed, Apr 21, 2010 at 2:44 AM, Oliver Endriss o.endr...@gmx.de wrote: It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! What about the HG driver? The v4l-dvb HG repository is broken for 7 weeks... It doesn't make any sense why someone would break a driver and then leave it that way for such a long period of time. Yes, please fix the HG repository. I don't actually know anyone who bothers with the git tree for obvious reasons, but a whole mess of users continue, of course, to use the mercurial tree... -- 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: av7110 and budget_av are broken!
Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! -- 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: av7110 and budget_av are broken!
Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! Regards, Hans 'still stuck in San Francisco' Verkuil -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: av7110 and budget_av are broken!
On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote: Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! What about the HG driver? The v4l-dvb HG repository is broken for 7 weeks... CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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: av7110 and budget_av are broken!
Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Regards, Hartmut -- 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
av7110 and budget_av are broken! (was: Re: changeset 14351:2eda2bcc8d6f)
e9hack wrote: Am 13.3.2010 17:27, schrieb Hans Verkuil: If there are no further comments, then I'll post a pull request in a few days. Tested with the mxb board. It would be nice if you can verify this with the av7110. Hi hans, it works with my TT-C2300 perfectly. The main problem of your changes was: It wasn't possible to unload the module for the TT-C2300. Guys, when will you finally apply this fix? As Hartmut pointed out, changeset 14351:2eda2bcc8d6f broke the av7110 driver (and also budget-av). It is time to fix it. This bug must not go into the kernel! CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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: av7110 and budget_av are broken! (was: Re: changeset 14351:2eda2bcc8d6f)
On Saturday 20 March 2010 15:07:08 Oliver Endriss wrote: e9hack wrote: Am 13.3.2010 17:27, schrieb Hans Verkuil: If there are no further comments, then I'll post a pull request in a few days. Tested with the mxb board. It would be nice if you can verify this with the av7110. Hi hans, it works with my TT-C2300 perfectly. The main problem of your changes was: It wasn't possible to unload the module for the TT-C2300. Guys, when will you finally apply this fix? Thanks for reminding me, I frankly forgot about this. Hartmut, is the problem with unloading the module something that my patch caused? Or was that there as well before changeset 14351:2eda2bcc8d6f? Are there any kernel messages indicating why it won't unload? Regards, Hans As Hartmut pointed out, changeset 14351:2eda2bcc8d6f broke the av7110 driver (and also budget-av). It is time to fix it. This bug must not go into the kernel! CU Oliver -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: av7110 and budget_av are broken! (was: Re: changeset 14351:2eda2bcc8d6f)
Hans Verkuil wrote:
On Saturday 20 March 2010 15:07:08 Oliver Endriss wrote:
e9hack wrote:
Am 13.3.2010 17:27, schrieb Hans Verkuil:
If there are no further comments, then I'll post a pull request in a
few days.
Tested with the mxb board. It would be nice if you can verify this with
the
av7110.
Hi hans,
it works with my TT-C2300 perfectly. The main problem of your changes
was: It wasn't
possible to unload the module for the TT-C2300.
Guys, when will you finally apply this fix?
Thanks for reminding me, I frankly forgot about this.
Hartmut, is the problem with unloading the module something that my patch
caused? Or was that there as well before changeset 14351:2eda2bcc8d6f?
Are there any kernel messages indicating why it won't unload?
The patch caused the problem.
You moved v4l2_device_register() from saa7146_vv_init() to
saa7146_vv_devinit(), but you did not modify av7110_v4l.c and
budget-av.c accordingly.
$ grep saa7146_vv_init v4l/*c
v4l/av7110_v4l.c: ret = saa7146_vv_init(dev, vv_data);
v4l/budget-av.c:if (0 != saa7146_vv_init(dev, vv_data)) {
v4l/hexium_gemini.c:saa7146_vv_init(dev, vv_data);
v4l/hexium_orion.c: saa7146_vv_init(dev, vv_data);
v4l/mxb.c: saa7146_vv_init(dev, vv_data);
v4l/saa7146_fops.c:int saa7146_vv_init(struct saa7146_dev* dev, struct
saa7146_ext_vv *ext_vv)
v4l/saa7146_fops.c:EXPORT_SYMBOL_GPL(saa7146_vv_init);
v4l/saa7146_fops.c:static int __init saa7146_vv_init_module(void)
v4l/saa7146_fops.c:module_init(saa7146_vv_init_module);
$ grep saa7146_vv_devinit v4l/*c
v4l/hexium_gemini.c:ret = saa7146_vv_devinit(dev);
v4l/hexium_orion.c: err = saa7146_vv_devinit(dev);
v4l/mxb.c: err = saa7146_vv_devinit(dev);
v4l/saa7146_fops.c:int saa7146_vv_devinit(struct saa7146_dev *dev)
v4l/saa7146_fops.c:EXPORT_SYMBOL_GPL(saa7146_vv_devinit);
CU
Oliver
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
--
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: av7110 and budget_av are broken!
On Saturday 20 March 2010 17:03:01 e9hack wrote: Am 20.3.2010 15:20, schrieb Hans Verkuil: Hartmut, is the problem with unloading the module something that my patch caused? Or was that there as well before changeset 14351:2eda2bcc8d6f? Are there any kernel messages indicating why it won't unload? Changset 14351:2eda2bcc8d6f causes a kernel oops during unload of the module for my dvb cards. OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. Regards, Hans The call trace points to dvb_ttpci. I assumed, that the FF card is affected only. It may be possible, that budget-av does crash also, if it is unload as second. -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
