Dear Tabi Timur-B04825,
In message 4d7ea72c.9040...@freescale.com you wrote:
Can this not be turned into generic code, usable for other boards /
systems as well?
Possibly, but I would like to fix one bug at a time.
Agreed, but please not by introducing lots of new, probably later
Wolfgang Denk wrote:
Agreed, but please not by introducing lots of new, probably later
incompatible code.
Fair enough.
Can you point me to the thread or at least tell me the subject line? I
have
no idea what you're talking about.
See
Dear Timur Tabi,
In message 4d7f7cb9.8090...@freescale.com you wrote:
(monitor - video and diubootargs - something else more generic) and
video-mode ?
update the videomodes.c code to parse the same video string that the kernel
uses. I also gathered that no one has chosen to update
Wolfgang Denk wrote:
because the kernel also needs to see console=tty0 on the command line
only if
This may or may not be the case. Frequently we still use a serial
console even when booting with a graphics display enabled.
This is a different option, and does not belong into that
Dear Timur Tabi,
In message 4d7f83ec.4050...@freescale.com you wrote:
NAK. video-mode settings and console settings are two separate things
and must not be mangled into a single variable.
Well, that's why I have two variables. My patch has the ability to set the
kernel command line
Wolfgang Denk wrote:
Well, that's why I have two variables. My patch has the ability to set the
kernel command line appropriately if the video display is configured and
enabled
in U-Boot. The second variable is used to assist in setting the actual
kernel
command-line, because that's
Dear Timur Tabi,
In message 4d7f8b3c.4080...@freescale.com you wrote:
Don't try to be more clever than the user. Instead of helping, you
restrict him. That's bad.
I'm not being more clever. The code is setting a variable (diubootargs) that
is
guaranteed to be the same video mode that
Wolfgang Denk wrote:
You misinterpret what I wrote. Of course we're going to enable the
video display then.
But there is no reason to always and unconditionally put the console
on that device - that is a completely separate and independent
decision.
I still don't understand the point of
Dear Timur Tabi,
In message 4d7fb987.20...@freescale.com you wrote:
But there is no reason to always and unconditionally put the console
on that device - that is a completely separate and independent
decision.
I still don't understand the point of enabling the video display in U-Boot
Wolfgang Denk wrote:
It may be a blank screen, or a (previously loaded) splash screen, or
(a bit later) some graphics application outputting data.
It's up to the user to decide that.
Ok, I think I get it. But I'm going to miss this merge window, because now I
have to rewrite half of my
Dear Timur Tabi,
In message 4d7fc2c5.2020...@freescale.com you wrote:
Ok, I think I get it. But I'm going to miss this merge window, because now I
have to rewrite half of my patch.
You won't. We have a delay of at least 2 weeks.
What is the standard mechanism for enabling the console on
Wolfgang Denk wrote:
What is the standard mechanism for enabling the console on the video
display?
From what I can tell, if video_hw_init() returns non-NULL, then the
console is
set to the video display, regardless as to what the stdout environment
variable says.
That's the
Dear Timur Tabi,
In message 4d7fd08c.2020...@freescale.com you wrote:
Then I'm confused, because video_hw_init() is what configures and enables the
video display. So if that function succeeds (i.e. returns non-NULL), then
U-Boot will put the console onto the video display. You said you
Wolfgang Denk wrote:
Please re-read the conversation then. Mind the context (U-Boot versus
Linux). Mind what I wrote about defaults and users being able to
chose the behaviour they want. And keep in mind what I wrote about
enforcing desicions in the best interest of your users (who may
happen
Update the monitor environment variable (for Freescale chips that have a
DIU display controller) to designate the full video configuration, instead
of just the output monitor.
The old definition of the monitor environment variable only determines
which video port to use for output. This variable
Dear Timur Tabi,
In message 1300133949-1115-1-git-send-email-ti...@freescale.com you wrote:
Update the monitor environment variable (for Freescale chips that have a
DIU display controller) to designate the full video configuration, instead
of just the output monitor.
The old definition of
Wolfgang Denk wrote:
Looks as if this was a Freescale specific implementation?
Yes.
Can this not be turned into generic code, usable for other boards /
systems as well?
Possibly, but I would like to fix one bug at a time.
Please see the discussion we had about video modes for the i.MX
17 matches
Mail list logo
