Dear Stefano Babic,
In message 4ccfb244.2000...@denx.de you wrote:
Consider this, I do not think the actual computation in lcd_setmem() is
correct. We need to compute the maximum amount of memory to be reserved
to the framebuffer, not the value requested by the current display
interface. We
On 11/02/2010 09:35 AM, Wolfgang Denk wrote:
Dear Stefano Babic,
In message 4ccfb244.2000...@denx.de you wrote:
Consider this, I do not think the actual computation in lcd_setmem() is
correct. We need to compute the maximum amount of memory to be reserved
to the framebuffer, not the value
Hi,
On Tue, 02 Nov 2010 07:40:04 +0100
Stefano Babic sba...@denx.de wrote:
...
There is also a second issue where I would like to know your thoughts. Very
early on system initialization, when LCD is enabled, there is a call to
lcd_setmem from board.c. By that time, the video variables,
Dear Stefano Babic,
In message 4ccfd2fb.6060...@denx.de you wrote:
Why cannot you determine the exact amount needed at runtime?
Agree, we can do it, and it is better - I do not think we need really to
change dinamically (I mean, in the same u-boot session) the LCD
connected to the
On 11/02/2010 10:42 AM, Wolfgang Denk wrote:
Dear Stefano Babic,
Hi Wolfgang,
We could introduce a weak function, that a board maintainer can decide
to implement or not. This maintains the compatibility with the most
drivers where vpanel is static initialized.
In which way is this board
Dear Stefano Babic,
In message 4ccfdeba.2070...@denx.de you wrote:
We could introduce a weak function, that a board maintainer can decide
to implement or not. This maintains the compatibility with the most
drivers where vpanel is static initialized.
In which way is this board
On 11/02/2010 02:34 PM, Wolfgang Denk wrote:
Because each board uses a different LCD with a different resolution, and
this requires a different amount of memory. This is not different as we
see in Linux, because the framebuffer properties are set in the board
file before to be passed to the
Dear Stefano Babic,
In message 4cd035f7.9070...@denx.de you wrote:
And then the calculation depends only on the current setting - which
is _not_ board dependent.
Yes, calculation is not board dependent and must remain in lcd_setmem().
What I meant as board dependent is really the LCD
Hello Stefano Babic,
On Tue, Nov 2, 2010 at 4:40 AM, Stefano Babic sba...@denx.de wrote:
However, it is really better to make the modification for the vision2
inside the same patchset. This guarantees that both boards work when
your patches go to mainline.
Ok! Should I send the patch for
Hello Stefano,
This is my first post to the list, I work as Field Engineer for
Freescale,
based in Brazil.
I'll be submitting couple patches to add support for the wvga lcd on the
mx51evk board, these are based on the work you did for vision2 board.
However, in order to add support for the
Hello Stefano,
This is my first post to the list, I work as Field Engineer for
Freescale,
based in Brazil.
I'll be submitting couple patches to add support for the wvga lcd on the
mx51evk board, these are based on the work you did for vision2 board.
However, in order to add support for the
11 matches
Mail list logo
