Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37705 )
Change subject: mainboard/intel/common: Add config for intel common mainboard support ......................................................................
Patch Set 6:
Patch Set 6:
Patch Set 6:
Patch Set 6:
When you want to make such changes to general tree topology, please announce your ideas on the mailing list first. Some things are wired in strange ways and hooked up into automatic generation of tables that used to be presented in the (now obsoleted) wiki.
There is rarely the need to have something tied to "mainboard vendor". These things usually end up being so generic others will want them too, making mb/intel/common somewhat awkward to use. I need to say I did not do thorough review of this, but I am speculating drivers/ might suite us better.
Or even a library in vendorcode? If it really is just related to intel mainboards, why a lib in vendorcode can't serve the needs?
I had put it in mainboard with a thought that the code added to intel/mb/common would be used by the intel mainboards and in future we can pull in more common pieces from Intel mainboards in common directy , like fmap files, hda verb tables , spd files for common codec and memory modules commonly used on Intel RVPs. Which could make it more Intel mb specific, the vendorcode might be very generic location to hold these mb specific pieces.
SPD files aren't specific to Intel mainboards. I would suggest having all SPD files in a common folder structure, so that each mainboard's Makefile.inc can pull in the ones it needs from there. What's more: this common folder can be categorized by memory type, module size and vendor! I like ordered things :)
About HDA codec verb tables, I think codec drivers would make sense. That way, verb tables could be replaced with a device on the devicetree. In addition, the devicetree could contain high-level settings instead of raw verbs:
device pci 1b.0 on # HDA controller chip codec/realtek/alc269 # Codec pin configurations would go here. For example: # - Port D (0x14): Internal Speaker # - Port A (0x21): Headphone (SenseA) # - Port F (0x19): Mic2 (SenseB) # - Port E (0x1b): Line2 (internal Mic) # PCBeep is enabled end end
Note that this is just an idea. Before implementing anything, I would bring this up on the mailing list so that we can all brainstorm and choose the best approach.
About fmap files, I'm afraid I don't know enough about them to say.