On 22.12.2009 13:52, Luc Verhaegen wrote:
On Tue, Dec 22, 2009 at 03:48:38AM +0100, Carl-Daniel Hailfinger wrote:
On 16.12.2009 12:14, Luc Verhaegen wrote:
Chipset/Board: vt8237: Set All mem cycles to LPC in chipset enable.
I don't have the datasheet, so I can't cross-check. I'm very interested why this would be needed, though. If mem cycles don't go to LPC and we have flash on LPC, the board won't boot anyway. If we force mem cycles to LPC although we have parallel ROM, this will break. Does VT8237R support parallel ROMs?
We need this, otherwise we wouldn't be changing this many board enables now.
Ah hm. I thought most board enables were created by imitating the behaviour of the in-memory board enable code, not by checking for the necessity of each step in there. If there are VT8237R straps which select the ROM type, we should check them and warn very loudly if a board strapped to parallel gets all memory accesses redirected to LPC. That will make sure users know WTF went wrong (if something went wrong).
About parallel roms, no idea, but if we apply this patch, we should soon find out.
Side note: Should we read the ROMCS# strap on VT8235 to check whether the ROM is LPC or Parallel? Does this strap exist for other VT823x as well?
The strap reading is IMHO very desirable because it can reduce the number of probed chips roughly by half.
If you have a good explanation for the mem cycle question and if you'll add the removed boards to the known good list either as followup patch or right now, this is Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
First part: not sure we should look for an explanation first, or just wait for the reports to roll in. The VT8237R is very popular, it will be a matter of wait and see.
Second part, ok.
A bugfix for the GPIO function would be appreciated, but that's a separate issue. I don't have VT8237* datasheets, so I can't do that myself.
Ok, will have a look too.
Deal. Go ahead and commit.
Regards, Carl-Daniel