Howto to change the tv standart output of svideo output to PAL
ReveI...@gmail.com
John Beetem
hardware supports both NTSC and PAL.
I don't know if any software supports this yet.
On Aug 8, 4:10 pm, ReveInt...@gmail.com wrote:
> Its possible ?
Jason Kridner
On Aug 9, 2008, at 8:04 PM, John Beetem wrote:
> According to the Beagle Hardware Reference Manual (page 17), the
> hardware supports both NTSC and PAL.
>
> I don't know if any software supports this yet.
>
I cannot find the S-Video code in the git kernel. I'm a bit confused
by that. In the "Diagnostic" kernel, you can do this:
*** arch/arm/plat-omap/display.c.orig Sun Aug 10 11:58:17 2008
--- arch/arm/plat-omap/display.c Sun Aug 10 11:58:49 2008
***************
*** 44,48 ****
static int disp_usage;
#ifndef CONFIG_ARCH_OMAP3410
! static int omap2_current_tvstandard = NTSC_M;
#endif
static spinlock_t dss_lock;
--- 44,48 ----
static int disp_usage;
#ifndef CONFIG_ARCH_OMAP3410
! static int omap2_current_tvstandard = PAL_M;
#endif
static spinlock_t dss_lock;
Jason Kridner
On Aug 10, 12:02 pm, Jason Kridner <jkrid...@gmail.com> wrote:
> On Aug 9, 2008, at 8:04 PM, John Beetem wrote:
>
> > According to the Beagle Hardware Reference Manual (page 17), the
> > hardware supports both NTSC and PAL.
>
> > I don't know if any software supports this yet.
>
> I cannot find the S-Video code in the git kernel. I'm a bit confused
> by that.
patch to the git kernel on this mailing list:
http://groups.google.com/group/beagleboard/browse_thread/thread/9c0e0e1d168fb791/ce24750bcc6e3d33#ce24750bcc6e3d33
Someone would need to revise, submit, and review it on the linux-omap
mailing list to get it put onto the git.
Hunyue Yau
>
>
>
> On Aug 10, 12:02 pm, Jason Kridner <jkrid...@gmail.com> wrote:
> > On Aug 9, 2008, at 8:04 PM, John Beetem wrote:
> >
> > > According to the Beagle Hardware Reference Manual (page 17), the
> > > hardware supports both NTSC and PAL.
> >
> > > I don't know if any software supports this yet.
> >
> > I cannot find the S-Video code in the git kernel. I'm a bit confused
> > by that.
>
> Koen pointed out on the IRC channel that Hunyue has already provide a
> patch to the git kernel on this mailing list:
>
> http://groups.google.com/group/beagleboard/browse_thread/thread/9c0e0e1d168fb791/ce24750bcc6e3d33#ce24750bcc6e3d33
>
> Someone would need to revise, submit, and review it on the linux-omap
> mailing list to get it put onto the git.
Simply put, the reason I am asking is the current code is a mess.
There are several paths we could go on this. One is to clean the
code up. Another is to try to get the functionality into the limited
driver on the linux-omap tree. The long term solution, IMO, is to go
with a cleaned up unified driver through the efforts that Khasim
started.
I have seen an attempt to cleanup this code but that seems to have lead
to a bigger mess where it broke a lot of things and that took some
effort to even get to that point.
This driver should work okay with the OMAP3 and OMAP2 families but I
have no idea about the OMAP1 or other code. The reason I posted this
code is I am was interested in having TV out and this was a quick
way of doing it.
If there is a strong interest in trying to get this driver into the
l-o git tree, I can ask on there. Things off the top of my head that
should be cleaned up are -
1. The Makefile/Kconfig should probally allow a choice of
drivers. Right now it does a giant if/else clause depending on if OMAP3
is enabled or not.
2. The lcd/clock definitions should be modularized like it is
in the current l-o git tree.
3. The location of the display lib might have to be moved.
4. The usual checkpatch.pl coding style clean ups.
There will certainly be others.
-- Hunyue
Jason Kridner
On Aug 11, 2008, at 4:14 PM, Hunyue Yau wrote:
>> On Aug 10, 12:02 pm, Jason Kridner <jkrid...@gmail.com> wrote:
>>> On Aug 9, 2008, at 8:04 PM, John Beetem wrote:
>>>
>>>> According to the Beagle Hardware Reference Manual (page 17), the
>>>> hardware supports both NTSC and PAL.
>>>
>>>> I don't know if any software supports this yet.
>>>
>>> I cannot find the S-Video code in the git kernel. I'm a bit
>>> confused
>>> by that.
>>
>> Koen pointed out on the IRC channel that Hunyue has already provide a
>> patch to the git kernel on this mailing list:
>>
>> http://groups.google.com/group/beagleboard/browse_thread/thread/9c0e0e1d168fb791/ce24750bcc6e3d33#ce24750bcc6e3d33
>>
>> Someone would need to revise, submit, and review it on the linux-omap
>> mailing list to get it put onto the git.
>
> How strong is the desire to get this into the linux-omap tree?
S-Video code needs to get upstream at some point.
> Simply put, the reason I am asking is the current code is a mess.
> There are several paths we could go on this. One is to clean the
> code up. Another is to try to get the functionality into the limited
> driver on the linux-omap tree. The long term solution, IMO, is to go
> with a cleaned up unified driver through the efforts that Khasim
> started.
We can go long-term. Let's see if a cleaner solution emerges if
everyone feels that this code is too poor right now. Just want to
make sure it is highlighted for those people who need something short-
term.
> I have seen an attempt to cleanup this code but that seems to have
> lead
> to a bigger mess where it broke a lot of things and that took some
> effort to even get to that point.
>
> This driver should work okay with the OMAP3 and OMAP2 families but I
> have no idea about the OMAP1 or other code. The reason I posted this
> code is I am was interested in having TV out and this was a quick
> way of doing it.
Understood. Thanks for that!
> If there is a strong interest in trying to get this driver into the
> l-o git tree, I can ask on there. Things off the top of my head that
> should be cleaned up are -
> 1. The Makefile/Kconfig should probally allow a choice of
> drivers. Right now it does a giant if/else clause depending on if
> OMAP3
> is enabled or not.
Isn't the current trend for Kconfig option to completely disable *and*
an if statement for OMAP3 to allow dynamic support (building a single
kernel that supports multiple devices)?
> 2. The lcd/clock definitions should be modularized like it is
> in the current l-o git tree.
> 3. The location of the display lib might have to be moved.
> 4. The usual checkpatch.pl coding style clean ups.
>
> There will certainly be others.
>
> -- Hunyue
>
<snip>
Hunyue Yau
> > l-o git tree, I can ask on there. Things off the top of my head that
> > should be cleaned up are -
> > 1. The Makefile/Kconfig should probally allow a choice of
> > drivers. Right now it does a giant if/else clause depending on if
> > OMAP3
> > is enabled or not.
>
> Isn't the current trend for Kconfig option to completely disable *and*
> an if statement for OMAP3 to allow dynamic support (building a single
> kernel that supports multiple devices)?
Yes, but the current code isn't that flexible. In theory, one could
build an OMAP3 board that isn't supported by that driver and requires
the current driver (i.e. kind of like what Nokia did on the N800).
The current code precludes building of anything other then that one
driver if CONFIG_ARCH_OMAP3 is defined. So it isn't even possible to
build the two different frame buffer drivers as modules and load them
at run time.
From the Makefile -
ifeq ($(CONFIG_ARCH_OMAP3),y)
obj-$(CONFIG_FB_OMAP) += omap_disp_out.o
obj-$(CONFIG_FB_OMAP) += omap_fb.o
else
obj-$(CONFIG_FB_OMAP) += omapfb.o
objs-yy := omapfb_main.o
objs-y$(CONFIG_ARCH_OMAP1) += lcdc.o
objs-y$(CONFIG_ARCH_OMAP2) += dispc.o
objs-$(CONFIG_ARCH_OMAP1)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += sossi.o
objs-$(CONFIG_ARCH_OMAP2)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += rfbi.o
....
endif
Unfortunately, a quick experiment suggests there is another problem
to unravel due to the display lib grabbing conflict resources.
-- Hunyue