[U-Boot] [RFC] x86: baytrail: azalia DT configuration mock-up
Bin Meng
bmeng.cn at gmail.com
Fri Jun 17 07:05:43 CEST 2016
Hi George,
On Wed, Jun 15, 2016 at 1:12 AM, George McCollister
<george.mccollister at gmail.com> wrote:
> On Mon, Jun 13, 2016 at 9:09 PM, Bin Meng <bmeng.cn at gmail.com> wrote:
>> Hi George,
>>
>> On Mon, Jun 13, 2016 at 9:09 PM, George McCollister
>> <george.mccollister at gmail.com> wrote:
>>> On Fri, Jun 10, 2016 at 7:17 PM, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>> Hi George,
>>>>
>>>> On Fri, Jun 10, 2016 at 4:57 AM, George McCollister
>>>> <george.mccollister at 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
More information about the U-Boot
mailing list