* [U-Boot] [RFC] x86: baytrail: azalia DT configuration mock-up
@ 2016-06-09 20:57 George McCollister
2016-06-11 0:17 ` Bin Meng
0 siblings, 1 reply; 7+ messages in thread
From: George McCollister @ 2016-06-09 20:57 UTC (permalink / raw)
To: u-boot
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";
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";
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
>;
};
};
fsp,lpss-sio-enable-pci-mode;
fsp,enable-dma0;
fsp,enable-dma1;
fsp,enable-i2c0;
fsp,enable-i2c1;
fsp,enable-i2c2;
fsp,enable-i2c3;
fsp,enable-i2c4;
fsp,enable-i2c5;
fsp,enable-i2c6;
fsp,enable-pwm0;
fsp,enable-pwm1;
fsp,igd-dvmt50-pre-alloc = <2>;
fsp,aperture-size = <2>;
fsp,gtt-size = <2>;
fsp,serial-debug-port-address = <0x3f8>;
fsp,serial-debug-port-type = <1>;
fsp,scc-enable-pci-mode;
fsp,os-selection = <4>;
fsp,emmc45-ddr50-enabled;
fsp,emmc45-retune-timer-value = <8>;
fsp,enable-igd;
fsp,enable-memory-down;
fsp,memory-down-params {
compatible = "intel,baytrail-fsp-mdp";
fsp,dram-speed = <1>;
fsp,dram-type = <1>;
fsp,dimm-0-enable;
fsp,dimm-width = <1>;
fsp,dimm-density = <2>;
fsp,dimm-bus-width = <3>;
fsp,dimm-sides = <0>;
fsp,dimm-tcl = <0xb>;
fsp,dimm-trpt-rcd = <0xb>;
fsp,dimm-twr = <0xc>;
fsp,dimm-twtr = <6>;
fsp,dimm-trrd = <6>;
fsp,dimm-trtp = <6>;
fsp,dimm-tfaw = <0x14>;
};
};
Thanks,
George McCollister
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [RFC] x86: baytrail: azalia DT configuration mock-up
2016-06-09 20:57 [U-Boot] [RFC] x86: baytrail: azalia DT configuration mock-up George McCollister
@ 2016-06-11 0:17 ` Bin Meng
2016-06-13 13:09 ` George McCollister
0 siblings, 1 reply; 7+ messages in thread
From: Bin Meng @ 2016-06-11 0:17 UTC (permalink / raw)
To: u-boot
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?
> 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?
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [RFC] x86: baytrail: azalia DT configuration mock-up
2016-06-11 0:17 ` Bin Meng
@ 2016-06-13 13:09 ` George McCollister
2016-06-14 2:09 ` Bin Meng
0 siblings, 1 reply; 7+ messages in thread
From: George McCollister @ 2016-06-13 13:09 UTC (permalink / raw)
To: u-boot
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[].
>
>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [RFC] x86: baytrail: azalia DT configuration mock-up
2016-06-13 13:09 ` George McCollister
@ 2016-06-14 2:09 ` Bin Meng
2016-06-14 17:12 ` George McCollister
0 siblings, 1 reply; 7+ messages in thread
From: Bin Meng @ 2016-06-14 2:09 UTC (permalink / raw)
To: u-boot
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.
>
>>
>>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [RFC] x86: baytrail: azalia DT configuration mock-up
2016-06-14 2:09 ` Bin Meng
@ 2016-06-14 17:12 ` George McCollister
2016-06-17 5:05 ` Bin Meng
0 siblings, 1 reply; 7+ messages in thread
From: George McCollister @ 2016-06-14 17:12 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [RFC] x86: baytrail: azalia DT configuration mock-up
2016-06-14 17:12 ` George McCollister
@ 2016-06-17 5:05 ` Bin Meng
2016-06-17 13:09 ` George McCollister
0 siblings, 1 reply; 7+ messages in thread
From: Bin Meng @ 2016-06-17 5:05 UTC (permalink / raw)
To: u-boot
Hi George,
On Wed, Jun 15, 2016 at 1:12 AM, George McCollister
<george.mccollister@gmail.com> wrote:
> 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.
I have no idea how to feedback FSP related issues to Intel. Maybe Simon knows?
Did you manage to get the HDA working on your board? In your recent
patch about adding a new Advantech board, I see you added HDA pin PADs
configuration. Does that solve the problem?
>
> 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).
>
I have not looked into HDA yet. Do you think it's worth creating a
U-Boot driver for HDA to verify it's working? Or just leave it to
Linux kernel to play some sound?
>>
>>>
>>>>
>>>>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [RFC] x86: baytrail: azalia DT configuration mock-up
2016-06-17 5:05 ` Bin Meng
@ 2016-06-17 13:09 ` George McCollister
0 siblings, 0 replies; 7+ messages in thread
From: George McCollister @ 2016-06-17 13:09 UTC (permalink / raw)
To: u-boot
On Fri, Jun 17, 2016 at 12:05 AM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi George,
>
> On Wed, Jun 15, 2016 at 1:12 AM, George McCollister
> <george.mccollister@gmail.com> wrote:
>> 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.
>
> I have no idea how to feedback FSP related issues to Intel. Maybe Simon knows?
>
> Did you manage to get the HDA working on your board? In your recent
> patch about adding a new Advantech board, I see you added HDA pin PADs
> configuration. Does that solve the problem?
The HDA pad configuration allows the codec to work with Linux but it
is using the hardware pin complex defaults. Ideally I would supply
verb table data to change the pin defaults to do things like disable
channels that aren't populated but the verb table data seems to be
ignored. Linux has a mechanism to override these defaults since it's
pretty common for vendors to ship machines with these settings
incorrect in their BIOS. It would also be possible to send the HDA
commands directly with u-boot.
http://git.alsa-project.org/?p=alsa-tools.git;a=blob;f=hda-verb/README
>
>>
>> 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).
>>
>
> I have not looked into HDA yet. Do you think it's worth creating a
> U-Boot driver for HDA to verify it's working? Or just leave it to
> Linux kernel to play some sound?
It could be useful to have a simple driver which allowed
implementation of a command similar to hda-verb. The driver could also
potentially allow direct codec configuration from device tree (instead
handing verb table data off to FSP which seems to be ignoring it
anyway)
>
>>>
>>>>
>>>>>
>>>>>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-06-17 13:09 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-09 20:57 [U-Boot] [RFC] x86: baytrail: azalia DT configuration mock-up George McCollister
2016-06-11 0:17 ` Bin Meng
2016-06-13 13:09 ` George McCollister
2016-06-14 2:09 ` Bin Meng
2016-06-14 17:12 ` George McCollister
2016-06-17 5:05 ` Bin Meng
2016-06-17 13:09 ` George McCollister
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.