2.6.28rc3 with s-video testing uImage

Showing 1-19 of 19 messages
2.6.28rc3 with s-video testing uImage Koen Kooi 11/8/08 12:51 AM
Hi,

Could the s-video crowd please test

http://dominion.thruhere.net/koen/OE/uImage-2.6.27+2.6.28-rc3+r0+gitrf7429fd378a29cf6947c2613e0fd6e6e36165167-r0-beagleboard.bin

And report back about any issues they have. The new DSS lib has some
initialization problems that need to get hunted down and fixed.

regards,

Koen
Re: [beagleboard] 2.6.28rc3 with s-video testing uImage Robert Kuhn 11/9/08 11:08 PM
2008/11/8 Koen Kooi <koen...@gmail.com>:

> http://dominion.thruhere.net/koen/OE/uImage-2.6.27+2.6.28-rc3+r0+gitrf7429fd378a29cf6947c2613e0fd6e6e36165167-r0-beagleboard.bin
>
> And report back about any issues they have. The new DSS lib has some

I tested it and activated s-video with

 tvline=`cat /sys/devices/platform/omapfb/displays |grep tv`
 w=`echo $tvline | cut -d " " -f 2 | cut -d ":" -f 2`
 h=`echo $tvline | cut -d " " -f 3 | cut -d ":" -f 2`

 echo "1 t:none" > omapfb/framebuffers
 echo "0 t:gfx,vid1" > omapfb/framebuffers
 echo "gfx e:1" > omapfb/overlays
 echo "vid1 t:tv w:$w h:$h e:1" > omapfb/overlays
 echo "tv e:1" > omapfb/displays

and got the same display on DVI and s-video. The only issue is that
the dvi has 1024x768@51Hz! So the pixel clock values seems to be
wrong. I attach the bootlog.

Robert

Re: [beagleboard] Re: 2.6.28rc3 with s-video testing uImage Robert Kuhn 11/10/08 12:06 AM
>>> http://dominion.thruhere.net/koen/OE/uImage-2.6.27+2.6.28-rc3+r0+gitrf7429fd378a29cf6947c2613e0fd6e6e36165167-r0-beagleboard.bin

>> and got the same display on DVI and s-video. The only issue is that
>> the dvi has 1024x768@51Hz! So the pixel clock values seems to be
>> wrong. I attach the bootlog.
>
> Unfortunately it is not possible to get exact pixel clocks with normal DSS
...
> However, you can get much more accurate pixel clocks when using the DSI DPLL
> to create the DSS function clock. You can try that kernel option also, but
> it's a bit experimental at the moment (but works for me).

Sorry for asking the perhaps stupid question: Which kernel option (or
where can I find the documentation about it)?

Robert

Re: [beagleboard] 2.6.28rc3 with s-video testing uImage Robert Kuhn 11/10/08 1:04 AM
2008/11/10 Robert Kuhn <rowk...@googlemail.com>:

> I tested it and activated s-video with
> ...

Sorry for asking but I do have problems to understand the
documentation. How can I direct fb0 to dvi and fb1 to s-video?

Robert

Re: [beagleboard] Re: 2.6.28rc3 with s-video testing uImage Tomi Valkeinen 11/10/08 1:11 AM
On Mon, 2008-11-10 at 10:06 +0200, ext Robert Kuhn wrote:
>
> >>> http://dominion.thruhere.net/koen/OE/uImage-2.6.27+2.6.28-rc3+r0

> +gitrf7429fd378a29cf6947c2613e0fd6e6e36165167-r0-beagleboard.bin
>
> >> and got the same display on DVI and s-video. The only issue is that
> >> the dvi has 1024x768@51Hz! So the pixel clock values seems to be
> >> wrong. I attach the bootlog.
> >
> > Unfortunately it is not possible to get exact pixel clocks with
> normal DSS
> ...
> > However, you can get much more accurate pixel clocks when using the
> DSI DPLL
> > to create the DSS function clock. You can try that kernel option
> also, but
> > it's a bit experimental at the moment (but works for me).
>
> Sorry for asking the perhaps stupid question: Which kernel option (or
> where can I find the documentation about it)?

In kernel compilation options, under OMAP2/3 Display subsystem support:

OMAP2_DSS_DSI
OMAP2_DSS_USE_DSI_PLL

 Tomi


Re: [beagleboard] Re: 2.6.28rc3 with s-video testing uImage Robert Kuhn 11/10/08 1:14 AM
>> Sorry for asking the perhaps stupid question: Which kernel option (or
>> where can I find the documentation about it)?
>
> In kernel compilation options, under OMAP2/3 Display subsystem support:

Ah, okay, sorry. I thought you meant a kernel command line option.
Okay, I got it.

Robert.

Re: [beagleboard] Re: 2.6.28rc3 with s-video testing uImage Tomi Valkeinen 11/10/08 1:27 AM

Try this:

tvline=`cat /sys/devices/platform/omapfb/displays |grep tv`
w=`echo $tvline | cut -d " " -f 2 | cut -d ":" -f 2`
h=`echo $tvline | cut -d " " -f 3 | cut -d ":" -f 2`

echo "vid1 t:none" > /sys/devices/platform/omapfb/overlays
fbset -fb /dev/fb1 -xres $w -vxres $w -yres $h -vyres $h
echo "vid1 t:tv w:$w h:$h e:1" > /sys/devices/platform/omapfb/overlays
echo "tv e:1" > /sys/devices/platform/omapfb/displays

What it does is:
1. disconnect vid1 overlay, so that we can change it freely
2. set the framebuffer fb1 to correct size (it is already connected to
vid1, by default, so we don't need to connect it)
3. set vid1 output to tv overlay manager, and set output size to tv's
size
4. enable tv display

 Tomi


Re: [beagleboard] Re: 2.6.28rc3 with s-video testing uImage Tomi Valkeinen 11/9/08 11:39 PM
Hi,

Unfortunately it is not possible to get exact pixel clocks with normal DSS
clocking, especially for higher pixel clocks. The code tries to find a
pixel clock that would produce 60Hz refresh rate, but the closest it can
find is 51Hz.

However, you can get much more accurate pixel clocks when using the DSI
DPLL to create the DSS function clock. You can try that kernel option
also, but it's a bit experimental at the moment (but works for me).

> Robert

  Tomi

Re: 2.6.28rc3 with s-video testing uImage Koen Kooi 11/10/08 8:54 AM
On 10 nov, 08:39, Tomi Valkeinen <to...@bat.org> wrote:
> On Mon, 10 Nov 2008, Robert Kuhn wrote:
> > 2008/11/8 Koen Kooi <koen.k...@gmail.com>:
>
> >>http://dominion.thruhere.net/koen/OE/uImage-2.6.27+2.6.28-rc3+r0+gitr...
>
> >> And report back about any issues they have. The new DSS lib has some
>
> > I tested it and activated s-video with
>
> > tvline=`cat /sys/devices/platform/omapfb/displays |grep tv`
> > w=`echo $tvline | cut -d " " -f 2 | cut -d ":" -f 2`
> > h=`echo $tvline | cut -d " " -f 3 | cut -d ":" -f 2`
>
> > echo "1 t:none" > omapfb/framebuffers
> > echo "0 t:gfx,vid1" > omapfb/framebuffers
> > echo "gfx e:1" > omapfb/overlays
> > echo "vid1 t:tv w:$w h:$h e:1" > omapfb/overlays
> > echo "tv e:1" > omapfb/displays
>
> > and got the same display on DVI and s-video. The only issue is that
> > the dvi has 1024x768@51Hz! So the pixel clock values seems to be
> > wrong. I attach the bootlog.
>
> Unfortunately it is not possible to get exact pixel clocks with normal DSS
> clocking, especially for higher pixel clocks. The code tries to find a
> pixel clock that would produce 60Hz refresh rate, but the closest it can
> find is 51Hz.
>
> However, you can get much more accurate pixel clocks when using the DSI
> DPLL to create the DSS function clock. You can try that kernel option
> also, but it's a bit experimental at the moment (but works for me).

This kernel should have DSI_PLL enabled:

http://dominion.thruhere.net/koen/OE/uImage-2.6.27+2.6.28-rc3+r2+gitrf7429fd378a29cf6947c2613e0fd6e6e36165167-r2-beagleboard.bin

regards,

Koen
Re: [beagleboard] Re: 2.6.28rc3 with s-video testing uImage Tomi Valkeinen 11/10/08 4:56 AM
On Mon, 10 Nov 2008, ext Tomi Valkeinen wrote:

>
> Hi,
>
> On Mon, 10 Nov 2008, Robert Kuhn wrote:
>
>> and got the same display on DVI and s-video. The only issue is that
>> the dvi has 1024x768@51Hz! So the pixel clock values seems to be
>> wrong. I attach the bootlog.
>
> Unfortunately it is not possible to get exact pixel clocks with normal DSS
> clocking, especially for higher pixel clocks. The code tries to find a
> pixel clock that would produce 60Hz refresh rate, but the closest it can
> find is 51Hz.

Actually, this was not quite right. You can't get exact pixel clocks, but
you can get better than that 51Hz. The MIN_FCK_PER_PCK Kconfig option
causes this behavior and the current version didn't try disabling that
option, if it couldn't find a good match with it. I'm fixing this problem
for the next release.

  Tomi

Re: [beagleboard] Re: 2.6.28rc3 with s-video testing uImage Robert Kuhn 11/10/08 11:24 PM
2008/11/10 Koen Kooi <koen...@gmail.com>:

> This kernel should have DSI_PLL enabled:
>
> http://dominion.thruhere.net/koen/OE/uImage-2.6.27+2.6.28-rc3+r2+gitrf7429fd378a29cf6947c2613e0fd6e6e36165167-r2-beagleboard.bin

Unfortuneatly it panics. Log is attached.

Robert

Re: [beagleboard] Re: 2.6.28rc3 with s-video testing uImage Robert Kuhn 11/11/08 11:31 PM
2008/11/10 Tomi Valkeinen <tomi.va...@nokia.com>:

> Try this:
>
> tvline=`cat /sys/devices/platform/omapfb/displays |grep tv`
> w=`echo $tvline | cut -d " " -f 2 | cut -d ":" -f 2`
> h=`echo $tvline | cut -d " " -f 3 | cut -d ":" -f 2`
>
> echo "vid1 t:none" > /sys/devices/platform/omapfb/overlays
> fbset -fb /dev/fb1 -xres $w -vxres $w -yres $h -vyres $h
> echo "vid1 t:tv w:$w h:$h e:1" > /sys/devices/platform/omapfb/overlays
> echo "tv e:1" > /sys/devices/platform/omapfb/displays
>
> What it does is:
> 1. disconnect vid1 overlay, so that we can change it freely
> 2. set the framebuffer fb1 to correct size (it is already connected to
> vid1, by default, so we don't need to connect it)
> 3. set vid1 output to tv overlay manager, and set output size to tv's
> size
> 4. enable tv display

Just to give a feedback: it works great, thank you very much!
I will write an entry for the wiki.

Robert

Re: [beagleboard] Re: 2.6.28rc3 with s-video testing uImage Robert Kuhn 11/12/08 12:18 AM
2008/11/12 Robert Kuhn <rowk...@googlemail.com>:

> Just to give a feedback: it works great, thank you very much!

I just realised: It is possible to have a 32bpp with the
"s-video-framebuffer". Great! As far as I see this was not possible
with the v4l-interface.

Robert

Re: [beagleboard] Re: 2.6.28rc3 with s-video testing uImage Tomi Valkeinen 11/12/08 1:11 AM

Yep, the new DSS supports currently:
RGB565 (fbset -depth 16)
RGB24 packed (fbset -depth 24)
RGB24 unpacked (fbset -depth 32)
YUV422 (fbset -nonstd 1) (only for video overlays)
YUY422 (fbset -nonstd 8) (only for video overlays)

 Tomi


Re: [beagleboard] Re: 2.6.28rc3 with s-video testing uImage Dan 11/13/08 11:14 AM
I tried this and just get static on my s-video display.

After typing in all the suggested commands, if I type $tvline, the
console reads out:

dvi w:1024 h:768 e:1 u:1 t:0
tv w:720 h:574 e:1 u:-1 t:0
cat: can't open '|grep': No such file or directory
cat: can't open 'tv': No such file or directory

Also, when I try the "fbset -fb /dev/fb1 -xres $w -vxres $w -yres $h
-vyres $h", it says:
fbset: invalid number 'echo'

Any ideas?

Dan
Re: [beagleboard] Re: 2.6.28rc3 with s-video testing uImage Tomi Valkeinen 11/13/08 11:34 AM

On Thu, 13 Nov 2008, Dan wrote:

>
> I tried this and just get static on my s-video display.
>
> After typing in all the suggested commands, if I type $tvline, the
> console reads out:
>
> dvi w:1024 h:768 e:1 u:1 t:0
> tv w:720 h:574 e:1 u:-1 t:0
> cat: can't open '|grep': No such file or directory
> cat: can't open 'tv': No such file or directory
>
> Also, when I try the "fbset -fb /dev/fb1 -xres $w -vxres $w -yres $h
> -vyres $h", it says:
> fbset: invalid number 'echo'
>
> Any ideas?

You are writing it somehow wrong =). Did you try copy pasting it? Or
alternatively you have some very strange shell.

But the whole point of those first three lines is to find out the
dimensions is tv out. You can get that data manually and fill the numbers
in the fbset line.

  Tomi
This message has been hidden because it was flagged for abuse.
Re: 2.6.28rc3 with s-video testing uImage Hu Liang 1/8/09 3:15 AM
Hi All,

i test it and its OK!
Can you tell me how to make the uImage?

Thanks a lot.
Liahoo
> > >> 2008/11/10 Tomi Valkeinen <tomi.valkei...@nokia.com>:
>
> > >>> Try this:
>
> > >>> tvline=`cat /sys/devices/platform/omapfb/displays |grep tv`
> > >>> w=`echo $tvline | cut -d " " -f 2 | cut -d ":" -f 2`
> > >>> h=`echo $tvline | cut -d " " -f 3 | cut -d ":" -f 2`
>
> > >>> echo "vid1 t:none" > /sys/devices/platform/omapfb/overlays
> > >>> fbset -fb /dev/fb1 -xres $w -vxres $w -yres $h -vyres $h
> > >>> echo "vid1 t:tv w:$w h:$h e:1" > /sys/devices/platform/omapfb/overlays
> > >>> echo "tv e:1" > /sys/devices/platform/omapfb/displays
>
> > >>> What it does is:
> > >>> 1. disconnect vid1 overlay, so that we can change it freely
> > >>> 2. set the framebuffer fb1 to correct size (it is already connected to
> > >>> vid1, by default, so we don't need to connect it)
> > >>> 3. set vid1 output to tv overlay manager, and set output size to tv's
> > >>> size
> > >>> 4. enable tv display
>
> > >> Just to give a feedback: it works great, thank you very much!
> > >> I will write an entry for the wiki.
>
> > >> Robert- 引用テキストを表示しない -
>
> - 引用テキストを表示 -
Re: 2.6.28rc3 with s-video testing uImage Hu Liang 1/8/09 6:54 PM
Hi All,

I am trying to get the S-video output with the Android Rootfs in BB.
But I cant patch S-VIDEO to the recent Linux kernel.
Can someone tell me which kernel the S-VIDEO "diff" file should patch
into?

Thanks a lot!
Hu Liang.

On  2008年11月17日, 午後2:49, "Kiran Murari" <kiranmur...@gmail.com> wrote:
> > >> 2008/11/10 Tomi Valkeinen <tomi.valkei...@nokia.com>:
>
> > >>> Try this:
>
> > >>> tvline=`cat /sys/devices/platform/omapfb/displays |grep tv`
> > >>> w=`echo $tvline | cut -d " " -f 2 | cut -d ":" -f 2`
> > >>> h=`echo $tvline | cut -d " " -f 3 | cut -d ":" -f 2`
>
> > >>> echo "vid1 t:none" > /sys/devices/platform/omapfb/overlays
> > >>> fbset -fb /dev/fb1 -xres $w -vxres $w -yres $h -vyres $h
> > >>> echo "vid1 t:tv w:$w h:$h e:1" > /sys/devices/platform/omapfb/overlays
> > >>> echo "tv e:1" > /sys/devices/platform/omapfb/displays
>
> > >>> What it does is:
> > >>> 1. disconnect vid1 overlay, so that we can change it freely
> > >>> 2. set the framebuffer fb1 to correct size (it is already connected to
> > >>> vid1, by default, so we don't need to connect it)
> > >>> 3. set vid1 output to tv overlay manager, and set output size to tv's
> > >>> size
> > >>> 4. enable tv display
>
> > >> Just to give a feedback: it works great, thank you very much!
> > >> I will write an entry for the wiki.
>