Patchwork use Kconfig for both options on Lippert boards

Good morning Peter,

> > It is simply not feasible to make _everything_ configurable,
> I'm not sure I agree about feasible.

I mean that no matter how hard you try, there will _always_ be one
application left which needs something changed that no one had foreseen.
But that's exactly the strong point of an open source BIOS. The source
adds the last, ultimate layer of configurability.

> from my experience with embedded customers, more configurability
> is better. :)

Absolutely!!

> > Or moving PCI INT A-D or legacy devices to a different IRQ line.
> I guess you already know that PCI interrupts are locked to whatever
> the VSA blob configures for the virtualized devices.

I meant the mapping INT A --> IRQ 10 etc. I already had a patch for this
(attached) but also decided against it, because this should be generic
and _not_ done individually at the board level and the device tree is a
better place for it anyway.

> > you'd have to start with devicetree.cb,

> A first step would be interrupt routing.

I agree 100%!

Regards,
Jens
NACKed-by: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>

Am 01.09.2010 11:31, schrieb Jens Rottmann:
> I meant the mapping INT A -->  IRQ 10 etc. I already had a patch for this
> (attached) but also decided against it, because this should be generic
> and _not_ done individually at the board level and the device tree is a
> better place for it anyway.
That data doesn't belong in code, yes. Unfortunately we don't have a 
very good place for it at all, at the moment.
The plan is to fix that, but I can't give a schedule, so _any_ support 
you provide will (very likely) need to be rewritten at some point (once 
we have a framework for that), so don't waste too much time to make it 
pretty.


Patrick

On 9/1/10 1:22 PM, Patrick Georgi wrote:
> Am 01.09.2010 11:31, schrieb Jens Rottmann:
>> I meant the mapping INT A --> IRQ 10 etc. I already had a patch for this
>> (attached) but also decided against it, because this should be generic
>> and _not_ done individually at the board level and the device tree is a
>> better place for it anyway.
> That data doesn't belong in code, yes. Unfortunately we don't have a
> very good place for it at all, at the moment.
> The plan is to fix that, but I can't give a schedule, so _any_ support
> you provide will (very likely) need to be rewritten at some point
> (once we have a framework for that), so don't waste too much time to
> make it pretty.
Actually, I think for the mapping we do have a mechanism in some
mainboards already, and it's stored in the device tree.

http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/mainboard/kontron/986lcd-m/devicetree.cb

In addition, the IRQ routing information itself should also be stored in
the device tree, and that, unfortunately, lacks a framework to do so.

Stefan