On Mon, Jun 13, 2016 at 9:09 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi George,
On Mon, Jun 13, 2016 at 9:09 PM, George McCollister george.mccollister@gmail.com wrote:
On Fri, Jun 10, 2016 at 7:17 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi George,
On Fri, Jun 10, 2016 at 4:57 AM, George McCollister george.mccollister@gmail.com wrote:
I'm looking for feedback on this mock-up of fsp,azalia-config DT before I proceed to writing code. I included everything in fsp for context.
fsp { compatible = "intel,baytrail-fsp"; fsp,mrc-init-tseg-size = <0>; fsp,mrc-init-mmio-size = <0x800>; fsp,mrc-init-spd-addr1 = <0xa0>; fsp,mrc-init-spd-addr2 = <0xa2>; fsp,emmc-boot-mode = <2>; fsp,enable-sdio; fsp,enable-sdcard; fsp,enable-hsuart1; fsp,enable-spi; fsp,enable-sata; fsp,sata-mode = <1>; fsp,enable-azalia; fsp,azalia-config { compatible = "intel,baytrail-fsp-azalia-config";I believe this azalia config is platform-specific, so tagging it with a baytrail-fsp- prefix is OK?
Yes. As far as I can tell there aren't any other platforms with an identical azalia config structure. I plan on putting the code to handle this in arch/x86/cpu/baytrail/fsp_configs.c Do you think we should shorten the name to "intel,baytrail-fsp-ac"? If we leave it as is it will be the longest entry in compat_names[].
How about changing all "intel,baytrail-fsp" to "intel,byt-fsp"? ac does not look straight-forward.
That sounds fine to me, however I've run into a problem that might delay this change. Even with the hard coded verb table data the pin complex pin defaults do not seem to be getting changed.
For example my verb table contains the following for node 0x11: /* Pin Complex (NID 0x11) */ 0x01171cf0, 0x01171d11, 0x01171e11, 0x01171f41,
This should set the pin default to 0x411111f0 however in Linux, /proc/asound/codec#0 shows "Pin Default 0x411110f0" for Node 0x11. I'm assuming the FSP is supposed to go through the verb-table-data and actually run these commands against the codec. Are you aware of anyway to get any feedback from the FSP code? As far as I can tell right now the verb-table-data is doing nothing.
One thing that is a bit confusing is how it even figures out the length of the verb table data. The only way I figure it can be doing it is by assuming (number-of-rear-jacks + number-of-front-jacks) * sizeof(uint32_t) * 4. I took a look at coreboot and EDKII source and as far as I can tell what we're doing should work if coreboot and EDKII actually work (which I haven't verified).
fsp,pme-enable = <1>; fsp,docking-supported = <1>; fsp,docking-attached = <0>; fsp,hdmi-codec-enable = <1>; fsp,azalia-v-ci-enable = <1>; fsp,rsvdbits = <0>; fsp,reset-wait-timer-us = <300>; alc262 { compatible = "fsp,azalia-verb-table";This generic name fsp,azalia-ver-table means it is suitable to all platforms, correct?
No, I was concerned with this name being too long. This will be specific to baytrail-fsp. How about "intel,baytrail-fsp-avt"?
fsp,vendor-device-id = <0x10ec0262>; fsp,sub-system-id = <0>; fsp,revision-id = <0xff>; fsp,front-panel-support = <1>; fsp,number-of-rear-jacks = <11>; fsp,number-of-front-jacks = <2>; fsp,verb-table-data = < /* Pin Complex (NID 0x11) */ 0x01171cf0 0x01171d11 0x01171e11 0x01171f41 /* Pin Complex (NID 0x12) */ 0x01271cf0 0x01271d11 0x01271e11 0x01271f41 /* Pin Complex (NID 0x14) */ 0x01471c10 0x01471d40 0x01471e01 0x01471f01 /* Pin Complex (NID 0x15) */ 0x01571cf0 0x01571d11 0x01571e11 0x01571f41 /* Pin Complex (NID 0x16) */ 0x01671cf0 0x01671d11 0x01671e11 0x01671f41 /* Pin Complex (NID 0x18) */ 0x01871c20 0x01871d98 0x01871ea1 0x01871f01 /* Pin Complex (NID 0x19) */ 0x01971c21 0x01971d98 0x01971ea1 0x01971f02 /* Pin Complex (NID 0x1A) */ 0x01a71c2f 0x01a71d30 0x01a71e81 0x01a71f01 /* Pin Complex */ 0x01b71c1f 0x01b71d40 0x01b71e21 0x01b71f02 /* Pin Complex */ 0x01c71cf0 0x01c71d11 0x01c71e11 0x01c71f41 /* Pin Complex */ 0x01d71c01 0x01d71dc6 0x01d71e14 0x01d71f40 /* Pin Complex */ 0x01e71cf0 0x01e71d11 0x01e71e11 0x01e71f41 /* Pin Complex */ 0x01f71cf0 0x01f71d11 0x01f71e11 0x01f71f41 >; }; };[snip]
Regards, Bin