[EMAIL PROTECTED] writes:
> On 27 Feb, Ronald G Minnich wrote:
> > cirrusfb is fixed as of 2.4 release.
> >
> > This stuff is going to get fixed over time.
> >
> > I think I know how to think about this. Linux knows how to turn chipsets
> > on. linux doesn't know mainboard details. So, linuxbios needs to fix
> > things that are mainboard-specific, and linux does the rest.
> >
> > example: motherboard with both via vt82c686a south and a superio.
> > Linuxbios has to know which pieces of which part to turn on, since the 686
> > has some superio functions.
> >
> > example: motherboard with two superios. Linuxbios will probably have to
> > know which pieces of which superios to turn on, since linux will not.
> >
> > So, I'm going to try to figure out an API for BOTH config tool AND C.
> >
> > Configtool might be something like
> >
> > superio ITD/it1235 serial, mouse
> > superio via/vt82c686a flash, ide
> >
> > so I extend superio syntax to say what bits of the superio matter. Then I
> > can generate code to call the right pieces.
> >
> > comments?
>
> Sounds reasonable. However, your example is over simplified.
>
> You need something more like:
>
> superio ITD/it1235 serial pnpaddr=0x3f0 devaddr=0x2f8 irq=C
>
> Note that the superio cares what irq pin it asserts and knows nothing
> of what IRQ on the soutbridge it is connected to.
>
> It gets worse when connecting the TI CardBus bridge. There are
> multiple ways of hooking up the interrupts and the CardBus bridge and
> southbridge must both be configured to agree on this and agree with the
> traces on the circuit board. You can have either "normal" interrupt
> lines and/or serial interrupts.
>
> I'm still suspicous of being able to parameterize the whole thing but
> if we can it would be good.
Hmm. I have been reading up on ACPI which seems to be the alternative
way to handle this. We might want to go in the direction of stupid
ACPI in the future but it looks like royal pain for little gain.
However. I have come off with the conviction that we want to make a
list of the mainboard hardware that is invisible to normal enumeration
methods. Whether we walk this table in linuxBIOS (as we do during PCI
initialization) and call our own setup drivers or pass the table to
the kernel so it can do it the setup is almost less of an issue.
Note: ACPI does pass this information to windows so linux will
probably get the setup capability.
This listing of invisible hard information is a general case of the
PCI irq routing tables we currently construct. As I stabalize and
cleanup my alpha code I'm going to play with this. How to do a clean,
small, and complete hardware description table is interesting.
One thing we also want to consider. A deep sleep mode on portable
computers can turn off the RAM controller. If this is a sane thing to
do this needs some firmware support. Just something to think about,
though I bet having an address in CMOS of which image to boot on power
up would be all we would need to handle this case.
Eric
