[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver - V4L: vpfe capture: header files for ISIF driver - V4L: vpfe capture: source for ISIF driver on DM365 - V4L: vpfe capture: vpss driver enhancements for DM365 - V4L: vpfe_capture: bug fixes and enhancements - V4L: vpfe capture: build environment for isif driver And after the first three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ And after the other four patches are pulled in, then this arch patch should be merged for git: http://patchwork.kernel.org/patch/68876/ I gather that Murali and you have figured out the right order to merge this, so I leave the details to the both of you. Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. I also think it is a good idea if you ask for an account on linuxtv.org so that you can set up your own hg trees and you don't have to wait for me. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/isif.c | 1512 +++ b/linux/drivers/media/video/davinci/isif_regs.h | 269 b/linux/include/media/davinci/isif.h | 531 linux/drivers/media/video/Kconfig| 14 linux/drivers/media/video/davinci/Makefile |1 linux/drivers/media/video/davinci/dm355_ccdc.c | 413 +++--- linux/drivers/media/video/davinci/dm644x_ccdc.c | 362 +++-- linux/drivers/media/video/davinci/vpfe_capture.c | 254 +-- linux/drivers/media/video/davinci/vpss.c | 289 +++- linux/include/media/davinci/vpfe_capture.h | 12 linux/include/media/davinci/vpss.h | 41 11 files changed, 3180 insertions(+), 518 deletions(-) -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans, Thanks for this pull request.. I gather that Murali and you have figured out the right order to merge this, so I leave the details to the both of you. Not really :( I haven't seen a response to my last email on this. Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. Do you suggest creating separate arch part source for hg tree and upstream? (I see you have arch folders in the hg tree, but only few architectures currently supported mx*/px*). If so, how is the upstream merge of arch code handled in your case? My question is when the v4l part is merged, the corresponding arch part has to be merged as well to compile the upstream code base. So this is not going to solve the issue that we are facing currently. May be I am not getting the full picture here. BTW, I am okay to have an account in the hg tree. Is there a quick tutorial to understand the process and tools needed to get me started? Regards, Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, December 30, 2009 8:49 AM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab; Karicheri, Muralidharan; khil...@deeprootsystems.com Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver - V4L: vpfe capture: header files for ISIF driver - V4L: vpfe capture: source for ISIF driver on DM365 - V4L: vpfe capture: vpss driver enhancements for DM365 - V4L: vpfe_capture: bug fixes and enhancements - V4L: vpfe capture: build environment for isif driver And after the first three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ And after the other four patches are pulled in, then this arch patch should be merged for git: http://patchwork.kernel.org/patch/68876/ Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. I also think it is a good idea if you ask for an account on linuxtv.org so that you can set up your own hg trees and you don't have to wait for me. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/isif.c | 1512 +++ b/linux/drivers/media/video/davinci/isif_regs.h | 269 b/linux/include/media/davinci/isif.h | 531 linux/drivers/media/video/Kconfig| 14 linux/drivers/media/video/davinci/Makefile |1 linux/drivers/media/video/davinci/dm355_ccdc.c | 413 +++--- linux/drivers/media/video/davinci/dm644x_ccdc.c | 362 +++-- linux/drivers/media/video/davinci/vpfe_capture.c | 254 +-- linux/drivers/media/video/davinci/vpss.c | 289 +++- linux/include/media/davinci/vpfe_capture.h | 12 linux/include/media/davinci/vpss.h | 41 11 files changed, 3180 insertions(+), 518 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Karicheri, Muralidharan wrote: Hans, Thanks for this pull request.. I gather that Murali and you have figured out the right order to merge this, so I leave the details to the both of you. Not really :( I haven't seen a response to my last email on this. Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. Do you suggest creating separate arch part source for hg tree and upstream? (I see you have arch folders in the hg tree, but only few architectures currently supported mx*/px*). If so, how is the upstream merge of arch code handled in your case? My question is when the v4l part is merged, the corresponding arch part has to be merged as well to compile the upstream code base. So this is not going to solve the issue that we are facing currently. May be I am not getting the full picture here. The issue is that non-v4l platform data changes that happens on the same headers where you have also v4l platform data changes cause lots of merge troubles. This happens with -hg, but this also would happen if I just merge from a -git tree. So, the problem is not about having a different procedure due to -hg, but having a way to avoid having merge conflicts every time an omap driver (or another driver that uses the platform_data stuff) is merged. On my experiences, the non-Intel arch headers used by V4L drivers got renamed, had several api changes and mixed several different subsystems at the same header, causing all sorts of merge conflicts. Since the soc_camera and omap drivers got merged, on every single kernel version, we had some sort of conflict to manage. On several cases, git bisect got broken, and we had even some worse case scenarios where the arch compilation got broken for some time, due to those conflicts. BTW, I am okay to have an account in the hg tree. Is there a quick tutorial to understand the process and tools needed to get me started? I can send you one, but maybe it is a little late for it, since my intention is to start discussing and working to replace -hg to -git at the beginning of 2010, if time allows me to do that. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Mauro, What do you suggest for the existing 2 pull requests from Hans? I had suggested something in my last email to do this in 2 steps based on Kevin's proposal. 1) Merge the patches (including arch patches) to linux-next tree based on Hans's pull request. 2) When upstream merge window opens and Kevin's davinci tree is merged to Linus tree, drop the arch patches from v4l-dvb. We could re-work the dropped patches based on Linus tree and send the same to you. Do you think this is doable? If so, please merge these pull requests to linux-next. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Wednesday, December 30, 2009 5:25 PM To: Karicheri, Muralidharan Cc: Hans Verkuil; linux-media@vger.kernel.org; khil...@deeprootsystems.com Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Karicheri, Muralidharan wrote: Hans, Thanks for this pull request.. I gather that Murali and you have figured out the right order to merge this, so I leave the details to the both of you. Not really :( I haven't seen a response to my last email on this. Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. Do you suggest creating separate arch part source for hg tree and upstream? (I see you have arch folders in the hg tree, but only few architectures currently supported mx*/px*). If so, how is the upstream merge of arch code handled in your case? My question is when the v4l part is merged, the corresponding arch part has to be merged as well to compile the upstream code base. So this is not going to solve the issue that we are facing currently. May be I am not getting the full picture here. The issue is that non-v4l platform data changes that happens on the same headers where you have also v4l platform data changes cause lots of merge troubles. This happens with -hg, but this also would happen if I just merge from a - git tree. So, the problem is not about having a different procedure due to -hg, but having a way to avoid having merge conflicts every time an omap driver (or another driver that uses the platform_data stuff) is merged. On my experiences, the non-Intel arch headers used by V4L drivers got renamed, had several api changes and mixed several different subsystems at the same header, causing all sorts of merge conflicts. Since the soc_camera and omap drivers got merged, on every single kernel version, we had some sort of conflict to manage. On several cases, git bisect got broken, and we had even some worse case scenarios where the arch compilation got broken for some time, due to those conflicts. BTW, I am okay to have an account in the hg tree. Is there a quick tutorial to understand the process and tools needed to get me started? I can send you one, but maybe it is a little late for it, since my intention is to start discussing and working to replace -hg to -git at the beginning of 2010, if time allows me to do that. Cheers, Mauro.
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver And after these three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ Hmm... It seems that git bisect will break if I merge first the conversion and then the platform_data patches. Also, we had some bad merge dependency troubles last time I merged an arch patch on my tree, as those omap arch header files are highly volatile. I bet that, if I merge the patch #67669 on my tree it will cause conflicts when I send it during the next merge window (and it is too late for sending those patches to linux-next, wait for a couple days and send upstream before -rc1). 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver And after these three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ Hmm... It seems that git bisect will break if I merge first the conversion and then the platform_data patches. Murali, what is the correct merge order? I assumed that the order you gave me was 'safe' (as in, it always compiles after each patch). I did compile the v4l patches, but I did not check if there was any breakage if I build the full kernel. Also, we had some bad merge dependency troubles last time I merged an arch patch on my tree, as those omap arch header files are highly volatile. I bet that, if I merge the patch #67669 on my tree it will cause conflicts when I send it during the next merge window (and it is too late for sending those patches to linux-next, wait for a couple days and send upstream before -rc1). Cheers, Mauro. So what do you want me or Murali to do? Wait until rc1 is released and then make sure that the arch patch will apply correctly to what is in rc1? Regards, Hans -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans Verkuil wrote: Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver And after these three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ Hmm... It seems that git bisect will break if I merge first the conversion and then the platform_data patches. Murali, what is the correct merge order? I assumed that the order you gave me was 'safe' (as in, it always compiles after each patch). I did compile the v4l patches, but I did not check if there was any breakage if I build the full kernel. To be safe, it needs not only to compile, but also to not break the driver, otherwise bisecting the affected drivers will not work. So what do you want me or Murali to do? Wait until rc1 is released and then make sure that the arch patch will apply correctly to what is in rc1? This won't solve, since, between 2.6.33-rc1 and the next open window (2.6.34 window), I bet that the *.h file will change enough for the merge to not apply. I see two ways: 1) (if it is safe to apply the platform_data patch without the v4l changes) send the patch to the -arch maintainer, as he'll handle the other changes to the same header file; 2) create a platform_data glue module/file that will handle the arch/platform_data glue for omap drivers and maintain it together with arch. All V4L specific code should be kept maintained on V4L subsystem. (2) is better, but will probably require more time to happen, but IMHO, this is the solution to avoid having troubles like that on all merge windows. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Mauro, Kevin is going to merge the arch part #67669 as we did last time. Please merge only the v4l2 part. I have copied Kevin in this email. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Thursday, December 17, 2009 6:18 AM To: Hans Verkuil Cc: linux-media@vger.kernel.org; Karicheri, Muralidharan Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver And after these three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ Hmm... It seems that git bisect will break if I merge first the conversion and then the platform_data patches. Also, we had some bad merge dependency troubles last time I merged an arch patch on my tree, as those omap arch header files are highly volatile. I bet that, if I merge the patch #67669 on my tree it will cause conflicts when I send it during the next merge window (and it is too late for sending those patches to linux-next, wait for a couple days and send upstream before -rc1). 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans Mauro, I have already replied to Mauro's email. This is what we had followed last time for vpfe capture. Mauro will merge the v4l2 part and Kevin will merge the arch part. These needs be done in sync so that it will compile fine in the upstream. Let me know if this cannot be done this time. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Thursday, December 17, 2009 6:30 AM To: Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org; Karicheri, Muralidharan Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver And after these three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ Hmm... It seems that git bisect will break if I merge first the conversion and then the platform_data patches. Murali, what is the correct merge order? I assumed that the order you gave me was 'safe' (as in, it always compiles after each patch). I did compile the v4l patches, but I did not check if there was any breakage if I build the full kernel. Also, we had some bad merge dependency troubles last time I merged an arch patch on my tree, as those omap arch header files are highly volatile. I bet that, if I merge the patch #67669 on my tree it will cause conflicts when I send it during the next merge window (and it is too late for sending those patches to linux-next, wait for a couple days and send upstream before -rc1). Cheers, Mauro. So what do you want me or Murali to do? Wait until rc1 is released and then make sure that the arch patch will apply correctly to what is in rc1? Regards, Hans -- 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver And after these three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ Thanks, Hans diffstat: p dm355_ccdc.c | 413 +++-- dm644x_ccdc.c | 362 +++-- vpfe_capture.c | 134 ++ 3 files changed, 498 insertions(+), 411 deletions(-) -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans Verkuil escreveu:
On Thursday 23 April 2009 13:35:02 Mauro Carvalho Chehab wrote:
On Sun, 19 Apr 2009 12:46:00 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the
following:
- v4l: TI THS7303 video amplifier driver code
+static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id std)
+{
+ int err = 0;
+ u8 val;
+ struct i2c_client *client;
+
+ client = v4l2_get_subdevdata(sd);
+
+ if ((std V4L2_STD_NTSC) || (std V4L2_STD_PAL)) {
+ val = 0x02;
+ v4l2_dbg(1, debug, sd, setting value for SDTV format\n);
+ } else {
+ val = 0x00;
+ v4l2_dbg(1, debug, sd, disabling all channels\n);
+ }
+
Hmm... Are you sure that the above check is ok? The standards you're allowing
are: PAL/BGDKHI and NTSC (except for NTSC/443). So, standards like PAL/N,
PAL/N', PAL/60, PAL/M will stay away.
If what you want is all standards but SECAM, then the correct syntax would be
something like:
if (std (V4L2_STD_ALL ~V4L2_STD_SECAM))
- Analog Devices ADV7343 video encoder driver
+#define SD_STD_NTSC(0x00)
+#define SD_STD_PAL_BDGHI (0x01)
+#define SD_STD_PAL_M (0x02)
+#define SD_STD_PAL_N (0x03)
Hmm... from the comments at the beginning of the .c file, it seems that the
hardware supports all standards but SECAM. The above register definitions also
specifies PAL/M and PAL/M as supported standards.
However, by looking at the std_into table:
+static const struct adv7343_std_info
+ adv7343_composite_std_info[] = {
+ {
+ SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+ },
+ {
+ SD_STD_PAL_BDGHI, 0xCB, 0x8A, 0x09, 0x2A, V4L2_STD_PAL,
+ },
+};
+
+static const struct adv7343_std_info
+ adv7343_component_std_info[] = {
+ {
+ SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+ },
+ {
+ SD_STD_PAL_BDGHI, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_PAL,
+ },
+};
Hmm.. on the last table, you are using a FSC = 3,579,545.45 Hz for both PAL and
NTSC? This seems wrong to my eyes.
Also, both tables have several supported standards missed.
Mauro,
Are there TVs in Brazil that are unable to handle standard NTSC-M on the
composite or S-Video inputs?
Yes. There are models that only handles PAL-M.
There are no encoders in v4l-dvb that do
something special for PAL-M.
Maybe because nobody tested they and reported an issue? Before I started
working on this,
most drivers were broken with PAL/M: saa7113, cx88, ivtv, ...
All just check against 525 vs 625 line standards.
And I can't imagine that that will cause problems for Brazilian TVs.
If you don't encode with PAL/M, then some TV sets won't work. Also, even
on TV sets that supports multiple standards, sometimes we need to
disable autodetection of NTSC, because this is broken on some TV sets.
I've personally experienced this trouble with two TV sets, including a
brand-new LCD1080p TV set I bought this year. On some conditions, if you
let auto NTSC/PAL-M enabled, it miss-detects the color carrier, and
changes to the other standard (missing the colors) for some seconds, and
then returns back. So, you have moments with colors and moments without.
It should also be noticed that there are several devices (TV sets, DVD
players, etc) manufactured abroad that people assumes that PAL/M color
carrier is equal to NTSC (AFAIK, the same occurs with PAL/Nc). Since the
color carriers are somewhat different, this produces a very annoying
effect: the color image will present a static image as a image with
colors moving, since there will be a frequency shift between the
horizontal frequency rate and the pixel sampling rate (that are derived
from the color carrier on several decoders), causing color detection
misleading at the pixels. So, the pixels at the boundary of a shape have
their colors oscillating.
I think these drivers should just use V4L2_STD_525_60 and V4L2_STD_625_50,
just like saa7127 does.
I have no device here with saa7127, so I'm not sure how this works with
other standards. But, expecially on encoding, you should be able to
produce the right standard. I can't see it producing a right standard if
you just use V4L2_STD_525_60 and V4L2_STD_625_50 with s-video. At least
on one place, you should say to the encoder what should be the color
carrier frequency and if it will encode with PAL, NTSC or SECAM.
By the way, what's the rationale of not allowing the driver to encode on
all supported formats?
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hi Mauro,
Hans Verkuil escreveu:
On Thursday 23 April 2009 13:35:02 Mauro Carvalho Chehab wrote:
On Sun, 19 Apr 2009 12:46:00 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
for the
following:
- v4l: TI THS7303 video amplifier driver code
+static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id std)
+{
+ int err = 0;
+ u8 val;
+ struct i2c_client *client;
+
+ client = v4l2_get_subdevdata(sd);
+
+ if ((std V4L2_STD_NTSC) || (std V4L2_STD_PAL)) {
+ val = 0x02;
+ v4l2_dbg(1, debug, sd, setting value for SDTV
format\n);
+ } else {
+ val = 0x00;
+ v4l2_dbg(1, debug, sd, disabling all channels\n);
+ }
+
Hmm... Are you sure that the above check is ok? The standards you're
allowing
are: PAL/BGDKHI and NTSC (except for NTSC/443). So, standards like
PAL/N,
PAL/N', PAL/60, PAL/M will stay away.
If what you want is all standards but SECAM, then the correct syntax
would be something like:
if (std (V4L2_STD_ALL ~V4L2_STD_SECAM))
- Analog Devices ADV7343 video encoder driver
+#define SD_STD_NTSC(0x00)
+#define SD_STD_PAL_BDGHI (0x01)
+#define SD_STD_PAL_M (0x02)
+#define SD_STD_PAL_N (0x03)
Hmm... from the comments at the beginning of the .c file, it seems that
the
hardware supports all standards but SECAM. The above register
definitions also
specifies PAL/M and PAL/M as supported standards.
However, by looking at the std_into table:
+static const struct adv7343_std_info
+ adv7343_composite_std_info[] = {
+ {
+ SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+ },
+ {
+ SD_STD_PAL_BDGHI, 0xCB, 0x8A, 0x09, 0x2A, V4L2_STD_PAL,
+ },
+};
+
+static const struct adv7343_std_info
+ adv7343_component_std_info[] = {
+ {
+ SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+ },
+ {
+ SD_STD_PAL_BDGHI, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_PAL,
+ },
+};
Hmm.. on the last table, you are using a FSC = 3,579,545.45 Hz for both
PAL and
NTSC? This seems wrong to my eyes.
Also, both tables have several supported standards missed.
Mauro,
Are there TVs in Brazil that are unable to handle standard NTSC-M on the
composite or S-Video inputs?
Yes. There are models that only handles PAL-M.
There are no encoders in v4l-dvb that do
something special for PAL-M.
Maybe because nobody tested they and reported an issue? Before I started
working on this,
most drivers were broken with PAL/M: saa7113, cx88, ivtv, ...
To be fair, it is very hard to implement something you cannot test
yourself, and most people can only test PAL/NTSC.
All just check against 525 vs 625 line standards.
And I can't imagine that that will cause problems for Brazilian TVs.
If you don't encode with PAL/M, then some TV sets won't work. Also, even
on TV sets that supports multiple standards, sometimes we need to
disable autodetection of NTSC, because this is broken on some TV sets.
I've personally experienced this trouble with two TV sets, including a
brand-new LCD1080p TV set I bought this year. On some conditions, if you
let auto NTSC/PAL-M enabled, it miss-detects the color carrier, and
changes to the other standard (missing the colors) for some seconds, and
then returns back. So, you have moments with colors and moments without.
It should also be noticed that there are several devices (TV sets, DVD
players, etc) manufactured abroad that people assumes that PAL/M color
carrier is equal to NTSC (AFAIK, the same occurs with PAL/Nc). Since the
color carriers are somewhat different, this produces a very annoying
effect: the color image will present a static image as a image with
colors moving, since there will be a frequency shift between the
horizontal frequency rate and the pixel sampling rate (that are derived
from the color carrier on several decoders), causing color detection
misleading at the pixels. So, the pixels at the boundary of a shape have
their colors oscillating.
Very interesting. I honestly thought that all TVs everywhere (except
perhaps very old ones) would be able to handle 'standard' PAL or NTSC on
their Composite and S-Video inputs.
I think these drivers should just use V4L2_STD_525_60 and
V4L2_STD_625_50,
just like saa7127 does.
I have no device here with saa7127, so I'm not sure how this works with
other standards.
Currently it does only PAL and NTSC. Although it can do SECAM it is never
actually enabled.
But, expecially on encoding, you should be able to
produce the right standard. I can't see it producing a right standard if
you just use V4L2_STD_525_60 and V4L2_STD_625_50 with s-video. At least
on one place, you should say to the encoder what should be the color
carrier frequency and
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans,
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Tuesday, May 05, 2009 5:41 PM
To: Mauro Carvalho Chehab
Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; Chaithrika U S
Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hi Mauro,
Hans Verkuil escreveu:
On Thursday 23 April 2009 13:35:02 Mauro Carvalho Chehab wrote:
On Sun, 19 Apr 2009 12:46:00 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-
davinci
for the
following:
- v4l: TI THS7303 video amplifier driver code
+static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id
std)
+{
+ int err = 0;
+ u8 val;
+ struct i2c_client *client;
+
+ client = v4l2_get_subdevdata(sd);
+
+ if ((std V4L2_STD_NTSC) || (std V4L2_STD_PAL)) {
+ val = 0x02;
+ v4l2_dbg(1, debug, sd, setting value for SDTV
format\n);
+ } else {
+ val = 0x00;
+ v4l2_dbg(1, debug, sd, disabling all channels\n);
+ }
+
Hmm... Are you sure that the above check is ok? The standards
you're
allowing
are: PAL/BGDKHI and NTSC (except for NTSC/443). So, standards like
PAL/N,
PAL/N', PAL/60, PAL/M will stay away.
If what you want is all standards but SECAM, then the correct
syntax
would be something like:
if (std (V4L2_STD_ALL ~V4L2_STD_SECAM))
- Analog Devices ADV7343 video encoder driver
+#define SD_STD_NTSC(0x00)
+#define SD_STD_PAL_BDGHI (0x01)
+#define SD_STD_PAL_M (0x02)
+#define SD_STD_PAL_N (0x03)
Hmm... from the comments at the beginning of the .c file, it seems
that
the
hardware supports all standards but SECAM. The above register
definitions also
specifies PAL/M and PAL/M as supported standards.
However, by looking at the std_into table:
+static const struct adv7343_std_info
+ adv7343_composite_std_info[] = {
+ {
+ SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+ },
+ {
+ SD_STD_PAL_BDGHI, 0xCB, 0x8A, 0x09, 0x2A,
V4L2_STD_PAL,
+ },
+};
+
+static const struct adv7343_std_info
+ adv7343_component_std_info[] = {
+ {
+ SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+ },
+ {
+ SD_STD_PAL_BDGHI, 0x1F, 0x7C, 0xF0, 0x21,
V4L2_STD_PAL,
+ },
+};
Hmm.. on the last table, you are using a FSC = 3,579,545.45 Hz for
both
PAL and
NTSC? This seems wrong to my eyes.
Also, both tables have several supported standards missed.
Mauro,
Are there TVs in Brazil that are unable to handle standard NTSC-M on
the
composite or S-Video inputs?
Yes. There are models that only handles PAL-M.
There are no encoders in v4l-dvb that do
something special for PAL-M.
Maybe because nobody tested they and reported an issue? Before I
started
working on this,
most drivers were broken with PAL/M: saa7113, cx88, ivtv, ...
To be fair, it is very hard to implement something you cannot test
yourself, and most people can only test PAL/NTSC.
All just check against 525 vs 625 line standards.
And I can't imagine that that will cause problems for Brazilian TVs.
If you don't encode with PAL/M, then some TV sets won't work. Also,
even
on TV sets that supports multiple standards, sometimes we need to
disable autodetection of NTSC, because this is broken on some TV
sets.
I've personally experienced this trouble with two TV sets, including
a
brand-new LCD1080p TV set I bought this year. On some conditions, if
you
let auto NTSC/PAL-M enabled, it miss-detects the color carrier, and
changes to the other standard (missing the colors) for some seconds,
and
then returns back. So, you have moments with colors and moments
without.
It should also be noticed that there are several devices (TV sets,
DVD
players, etc) manufactured abroad that people assumes that PAL/M
color
carrier is equal to NTSC (AFAIK, the same occurs with PAL/Nc). Since
the
color carriers are somewhat different, this produces a very annoying
effect: the color image will present a static image as a image with
colors moving, since there will be a frequency shift between the
horizontal frequency rate and the pixel sampling rate (that are
derived
from the color carrier on several decoders), causing color detection
misleading at the pixels. So, the pixels at the boundary of a shape
have
their colors oscillating.
Very interesting. I honestly thought that all TVs everywhere (except
perhaps very old ones) would be able to handle 'standard' PAL or NTSC
on
their Composite and S-Video inputs.
I think these drivers should just use V4L2_STD_525_60 and
V4L2_STD_625_50,
just like saa7127 does.
I have no device here
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
If you don't encode with PAL/M, then some TV sets won't work. Also, even on TV sets that supports multiple standards, sometimes we need to disable autodetection of NTSC, because this is broken on some TV sets. I've personally experienced this trouble with two TV sets, including a brand-new LCD1080p TV set I bought this year. On some conditions, if you let auto NTSC/PAL-M enabled, it miss-detects the color carrier, and changes to the other standard (missing the colors) for some seconds, and then returns back. So, you have moments with colors and moments without. It should also be noticed that there are several devices (TV sets, DVD players, etc) manufactured abroad that people assumes that PAL/M color carrier is equal to NTSC (AFAIK, the same occurs with PAL/Nc). Since the color carriers are somewhat different, this produces a very annoying effect: the color image will present a static image as a image with colors moving, since there will be a frequency shift between the horizontal frequency rate and the pixel sampling rate (that are derived from the color carrier on several decoders), causing color detection misleading at the pixels. So, the pixels at the boundary of a shape have their colors oscillating. Very interesting. I honestly thought that all TVs everywhere (except perhaps very old ones) would be able to handle 'standard' PAL or NTSC on their Composite and S-Video inputs. The difference between an NTSC-M system and PAL-M system is very slight: http://www.pembers.freeserve.co.uk/World-TV-Standards/Transmission-Systems.html since the 'M' determines most of the parameters. The color burst on the CVBS would be the only difference. I can see how color burst could be detected wrong on CVBS. I'm not sure how the chroma baseband signal in S-Video would get messed up though. Regards, Andy Chaithrika, can you take a look at this based on Mauro's input? Regards, Hans -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
On Sun, 19 Apr 2009 12:46:00 +0200 Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: TI THS7303 video amplifier driver code - Analog Devices ADV7343 video encoder driver - v4l: improve consistency of the config menu. These new drivers for the davinci platform have been reviewed and OKed almost a month ago, so it's time to get these merged. Especially since the davinci display driver is also almost ready. Please, never copy a subscribers only list on pull requests. It is very annoying to receive such emails: From: davinci-linux-open-source-boun...@linux.davincidsp.com To: mche...@infradead.org Subject: Your message to Davinci-linux-open-source awaits moderator approval Date: Thu, 23 Apr 2009 06:35:25 -0500 Sender: davinci-linux-open-source-boun...@linux.davincidsp.com Your mail to 'Davinci-linux-open-source' with the subject Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://linux.davincidsp.com/mailman/confirm/davinci-linux-open-source/cb8519a88f202b29b91bd0944d04b2ef2e67c239 -- 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
