[coreboot] [PATCH] consolidate K8M890 VGA code

[Luc Verhaegen]

On Thu, Oct 29, 2009 at 10:15:07AM +0100, r.marek at assembler.cz wrote:
> >Do you really want to get rid of dynamically being able to set the FB size?
> 
> Well as we agreed? on IRC, I would like to have Kconfig settable  
> default and the
> CMOS option as the most preferred state. Second reason is because as  
> you pointed
> out the CMOS option does not work for M2V SE. Reason was that I never  
> understood
> how it is supposed to be done. Third is I like to have a settable default in
> Kconfig.

I do not agree that kconfig is the way to go. Human nature will then 
make sure that cmos is treated further stepmotherly.

>  > Don't you think that this is a feature that regular users of probably
> >the only fully implemented coreboot motherboards might actually want  
> >to touch?
> 
> Please don't take it as offense. I like the CMOS options but other  
> stuff must be
> fixed here to make CMOS usable for M2V-MX.

The cmos options work, but you need to clear the RTC before it can work 
properly on this board. There are some k8 options in there which should 
never become valid as they will stop the system from booting.

This is what needs to be fixed. Removing the need to touch cmos is not 
fixing things, it's avoiding things.

> >Why is no time being spent on removing the other options that  
> >actually harm booting this device? Why does this feel like more  
> >pointless pedanticity?
> 
> It sounds you are really pissed off - please try no to look like exploded
> supernova ;)

The reason is that i just got pestered with some hyperpedandicity on
a whole wad of flashrom code, all because 1 tiny board enable was not 
deeemed acceptable straight away (and the user acked the original code, 
but now wandered on). Now i am quite sensitive.

Such hyperpedandicity stems progress as it:
* tackles no real issues, even though plenty are around.
* reduces the ability to get real issues tackled. Because patches do not 
  get accepted, the real code in the patches gets ignored and issues 
  with that code will eventually make it anyway, and those willing to do 
  real work are not exactly encouraged.

> I completely agree with you that CMOS is right way. But it 
> never
> worked here, so I changed it back -

Why did cmos never work for you?

The videoram option for this board is absolutely golden. I have spent 
quite some time on verifying that.

I also had an issue with other hardware of the same family (CLE266) 
where i could only use the default value. Change the option and the 
thing would hang when sending some IDE stuff over the bus.

What i wanted then was the ability to be able to toggle the 
videoram_size option from the driver like such (quick pseudocode):

videoram_size = get_option("videoram_size")
if (videoram_size != default)
	set_option("videoram_size", default);

This way, when i change the default in cmos, and the boot fails, it has 
changed the option in cmos already (or rather, invalidated cmos), so i 
am just a reset button away from it booting up normally.

Not useful for average joe user, but great for debugging.

I wasted quite a lot of time on being able to change videoram_size, and 
it is what holds back my sending in of native vga support on the epia-m. 

I ended up moving to the Asus, as it was a very complete and very 
wellbehaved board, and i added the last big gap in this boards support 
with the native VGA code, complete with stable and acceptable 
videoram_size option.

This code works just fine, or you wouldn't even dream of setting up a 
kconfig option. Because the truth is, if you are able to set this 
through kconfig, then you're just as easily able to set this through 
cmos. But one means providing wanted functionality and means tackling 
real code, the other removes wanted functionality and means avoiding 
real code.

> it was not evil intention and I would 
> love
> to see the solution I written above.

I know that this is not evil intention, you were just following Uwes 
changes to other boards. And i know that uwe is not doing this with 
evil intent either, but that does not make the result less detrimental.

I really still have no idea as to why this is needed.

It seems like laziness in unifying cmos usage across more boards, and 
laziness in respect to fixing up existing cmos handling code. Compared 
to that, a KConfig option really is the easy way out.

> To have a Kconfig settable  
> default and CMOS
> option which will be used if CMOS is valid. I think the code I wrote  
> can be used
> for the CMOS option too, just simple change is needed.
> 
> Rudolf

If there is one thing that users definitely want to be able to set as an 
option, then it is the amount of video ram that is being eaten by their 
IGP. Removing this ability is a no-go.

A KConfig option might seem nice, but it is is totally unnecessary. A 
sane default value _and_ a CMOS option is what is needed.

What will a KConfig option lead to:
* developers will bother even less with cmos in future, leaving the crap 
  that is in there for everyone to run into.
* uwe then does not have to do the mental work to restore the cmos 
  options for the other graphics chips.
* users will think we're complete idiots, but we will never be told 
  anyway, as it will be even more obvious that we are living in a world 
  of our own.

Luc Verhaegen.