Hi Timur,
> Detlev Zundel wrote:
>> Ok, then why not always define CONFIG_VIDEO for this configuration and
>> let U-Boot initialize _and_ use it? Actually I fail to see why U-Boot
>> shouldn't use it if the support is there or what am I missing?
>
> How can U-Boot know whether a monitor is actual
Detlev Zundel wrote:
> Ok, then why not always define CONFIG_VIDEO for this configuration and
> let U-Boot initialize _and_ use it? Actually I fail to see why U-Boot
> shouldn't use it if the support is there or what am I missing?
How can U-Boot know whether a monitor is actually connected to the
Hi,
> On Wed, 2010-09-22 at 10:10 -0500, Timur Tabi wrote:
>> > Is there a technical reason why the initialization has to be in U-Boot?
>>
>> I'll have to re-examine the code. There may be a way to eliminate any such
>> initialization.
>>
> There is a technical reason. The DIU driver needs init
On Wed, 2010-09-22 at 10:10 -0500, Timur Tabi wrote:
> > Is there a technical reason why the initialization has to be in U-Boot?
>
> I'll have to re-examine the code. There may be a way to eliminate any such
> initialization.
>
There is a technical reason. The DIU driver needs initialize DVI enc
Hi Timur,
> Detlev Zundel wrote:
>> This "but there are other examples doing just the same!" arguing is
>> getting tiresome. Please accept that this is not an argument capable of
>> convincing people - the opposite is true.
>
> It's also very frustrating when developers look at the way U-Boot doe
Detlev Zundel wrote:
> This "but there are other examples doing just the same!" arguing is
> getting tiresome. Please accept that this is not an argument capable of
> convincing people - the opposite is true.
It's also very frustrating when developers look at the way U-Boot does things,
then spen
Hi Timur,
> Anatolij Gustschin wrote:
>>> Also, I thought it would be better to provide some sort of completeness for
>>> the
>>> > bits I am using.
>> We do not add unused code.
>
> Well, I don't see how macros are "unused code", but I'll delete those lines.
>
> > CONFIG_VIDEO definition sh
Anatolij Gustschin wrote:
>> Also, I thought it would be better to provide some sort of completeness for
>> the
>> > bits I am using.
> We do not add unused code.
Well, I don't see how macros are "unused code", but I'll delete those lines.
>>> > > CONFIG_VIDEO definition should depend on CONFIG_
On Tue, 21 Sep 2010 17:00:19 -0500
Timur Tabi wrote:
> Anatolij Gustschin wrote:
>
> >> +#define AD_BYTE_F 0x1000
> >> +#define AD_ALPHA_C_MASK 0x0E00
> >> +#define AD_ALPHA_C_SHIFT 25
> >> +#define AD_BLUE_C_MASK0x0180
> >> +#define AD_BLUE_C_SHIFT
Anatolij Gustschin wrote:
>> +#define AD_BYTE_F 0x1000
>> +#define AD_ALPHA_C_MASK 0x0E00
>> +#define AD_ALPHA_C_SHIFT25
>> +#define AD_BLUE_C_MASK 0x0180
>> +#define AD_BLUE_C_SHIFT 23
>> +#define AD_GREEN_C_MASK 0x006
Hi Timur,
On Thu, 2 Sep 2010 15:35:19 -0500
Timur Tabi wrote:
...
> +#include
> +#include
> +#include
> +
> +#ifdef CONFIG_FSL_DIU_FB
Please drop the #ifdef above. Conditional compilation is
already handled by Makefile.
...
> +#define PX_BRDCFG1_DDCEN 0x10
This one is not used, please d
Add support for the DIU controller. If CONFIG_VIDEO is defined, then the
console will appear on a DVI monitor instead of the serial port.
Signed-off-by: Timur Tabi
---
This patch depends on:
[v3] fsl: refactor MPC8610 and MPC5121 DIU code to use existing bitmap and logo
features
board/frees
12 matches
Mail list logo
