[U-Boot-Users] request for comments

[U-Boot-Users] request for comments

[Josh Fryman]

hi all,

i've got a set of patches i've been working on to support a new platform.
it's still a work-in-progress, but a couple of issues have come up that
i'd like to ask for input on.

this platform has an LCD panel and a backlight.  both are controllable to
a certain extent.  i'd like to add a set of new commands to support the
features:

   bkon                        backlight on
   bkoff                       backlight off
   bkset percent               set backlight brightness to "percent" of max
   lcdon                       turn lcd on
   lcdoff                      turn lcd off
   lcdtst                      draw a test pattern on the lcd
   lcddraw x0 y0 x1 y1 r g b   draw a rectangle on the lcd, scaling R/G/B
                               values to hardware supported (ie, the cmd
                               values are in 0-255, but the hardware only
                               does RGB565 ... causes "255" to be mapped
                               accordingly)

and accompanying cmd_lcd.c, and cmd_bklite.c files.

of course, i could re-work this to be more like

   bk   {on,off,set percent}
   lcd  {on,off,tst,draw x0 y0 x1 y1 r g b}

to not take up so many command values...

any thoughts?  

-josh

[U-Boot-Users] request for comments

[Wolfgang Denk]

Dear Josh,

in message <20040216222014.23806b93.fryman@cc.gatech.edu> you wrote:
> 
> this platform has an LCD panel and a backlight.  both are controllable to
> a certain extent.  i'd like to add a set of new commands to support the
> features:
> 
>    bkon                        backlight on
>    bkoff                       backlight off
>    bkset percent               set backlight brightness to "percent" of max
>    lcdon                       turn lcd on
>    lcdoff                      turn lcd off
>    lcdtst                      draw a test pattern on the lcd
>    lcddraw x0 y0 x1 y1 r g b   draw a rectangle on the lcd, scaling R/G/B
>                                values to hardware supported (ie, the cmd
>                                values are in 0-255, but the hardware only
>                                does RGB565 ... causes "255" to be mapped
>                                accordingly)
> 
> and accompanying cmd_lcd.c, and cmd_bklite.c files.

Are these indded platform independend files  that  can  go  into  the
common  directory?  My  suspicion is that these might be in fact very
board-specific features that should go into your own board  directory
instead.

> of course, i could re-work this to be more like
> 
>    bk   {on,off,set percent}
>    lcd  {on,off,tst,draw x0 y0 x1 y1 r g b}
> 
> to not take up so many command values...

This sounds much better to me anyway.

Actually I recommend NOT to add graphics  functions  like  "draw"  to
U-Boot.  You might want other stuff soon, and find yourself ending up
integrating microwindows or so. I'm not  sure  if  I'd  like  such  a
development.

Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 17 - 19,  Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
HP had a unique policy of allowing its engineers to take  parts  from
stock  as long as they built something. "They figured that with every
design, they were getting a better engineer. It's a policy I urge all
companies  to  adopt."  -  Apple  co-founder  Steve  Wozniak,   "Will
Wozniak's class give Apple to teacher?" EE Times, June 6, 1988, pg 45

[U-Boot-Users] request for comments

[Josh Fryman]

> Are these indeed platform independend files  that  can  go  into  the
> common  directory?  My  suspicion is that these might be in fact very
> board-specific features that should go into your own board  directory
> instead.

it's kind of hard to say.  i see the lcdon/off, bkon/off much like the
"erase" command.  it's more or less universal for anything that supports
LCDs, but the actual implementation is very board specific.  kind of
like flash.  (noting the large number of specific flash implementations
in board directories.)

> >    bk   {on,off,set percent}
> >    lcd  {on,off,tst,draw x0 y0 x1 y1 r g b}
> > 
> > to not take up so many command values...
> 
> This sounds much better to me anyway.

it's no difference to me either way... i'll go ahead and change my 
implementation.

> Actually I recommend NOT to add graphics  functions  like  "draw"  to
> U-Boot.  You might want other stuff soon, and find yourself ending up
> integrating microwindows or so. I'm not  sure  if  I'd  like  such  a
> development.

in general, that's a policy i understand and agree with.  in specific,
though, i implemented the function when i was trying to debug why the
drawing of the test pattern wasn't working.  directly doing a memory-
modify and having to do the RGB565 encoding mentally was tiresome :)

i guess i'm proposing that this be the only real random drawing function
for just this purpose.  debugging the framebuffer is tedious without it.
if you'd rather not see it, that's fine -- i can keep it sitsang specific
as an additional patch people can apply.  i don't want to bolt in all
the random draw functions you'd expect in a GUI.  just rectangle solid
blobs.

-josh

[U-Boot-Users] request for comments

[Wolfgang Denk]

In message <20040217162255.23793c83.fryman@cc.gatech.edu> you wrote:
> > Are these indeed platform independend files  that  can  go  into  the
> > common  directory?  My  suspicion is that these might be in fact very
> > board-specific features that should go into your own board  directory
> > instead.
> 
> it's kind of hard to say.  i see the lcdon/off, bkon/off much like the
> "erase" command.  it's more or less universal for anything that supports
> LCDs, but the actual implementation is very board specific.  kind of

I tend to disagree. U-Boot already has support for several board with
displays (LCD, TFD). None of these supports any of these commands.

> in general, that's a policy i understand and agree with.  in specific,
> though, i implemented the function when i was trying to debug why the
> drawing of the test pattern wasn't working.  directly doing a memory-
> modify and having to do the RGB565 encoding mentally was tiresome :)

Sure. Please feel free to add a LCD POST test :-)

> i guess i'm proposing that this be the only real random drawing function
> for just this purpose.  debugging the framebuffer is tedious without it.
> if you'd rather not see it, that's fine -- i can keep it sitsang specific
> as an additional patch people can apply.  i don't want to bolt in all

No. This is not what I want. I just think it makes no  sense  to  add
this  to  the  public  code  which  everybody  will get automatically
compiled in when he enables LCD support.  Please  feel  free  to  add
local  test functions as you like in your board directory, or - if of
a general nature - as part of POST.


Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 17 - 19,  Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
There's an old story about the person who wished his computer were as
easy to use as his telephone. That wish has come  true,  since  I  no
longer know how to use my telephone.