Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

linux: add SOF nocodec mode #112

Closed
wants to merge 1 commit into from

Conversation

plbossart
Copy link
Contributor

This is needed if there is no ACPI codec HID

Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com

@plbossart
Copy link
Contributor Author

@andy-shev @htot I have no idea if this is the 'right' way to fix this, when I compile this somehow my changes are not taken into account.

the main error I see is with this code:

	/* find machine */
	snd_sof_machine_select(sdev);
	if (sof_pdata->machine) {
		snd_sof_set_mach_params(sof_pdata->machine, sdev->dev);
		return 0;
	}

#if !IS_ENABLED(CONFIG_SND_SOC_SOF_NOCODEC)
	dev_err(sdev->dev, "error: no matching ASoC machine driver found - aborting probe\n");
	return -ENODEV;
#endif
#if IS_ENABLED(CONFIG_SND_SOC_SOF_FORCE_NOCODEC_MODE)
nocodec:

We really need to define NOCODEC or the driver assumes there's an ACPI codec configuration issue - which is correct for Edison by default there is no codec connected

@htot
Copy link
Member

htot commented Jun 2, 2020

I have no idea if this is the 'right' way to fix this, when I compile this somehow my changes are not taken into account.

It should be right, by I have struggled in the past too. Instructions are here. When your done, don't forget to clean up.

Anyway I'll try this and otherwise try to generate the fragment myself.

Thanks!

@plbossart
Copy link
Contributor Author

I have no idea if this is the 'right' way to fix this, when I compile this somehow my changes are not taken into account.

It should be right, by I have struggled in the past too. Instructions are here. When your done, don't forget to clean up.

Anyway I'll try this and otherwise try to generate the fragment myself.

Thanks!

never mind, I forgot CONFIG_EXPERT=y is required. re-checking now

@htot
Copy link
Member

htot commented Jun 2, 2020

There is quite a bit turned on by default (by Andy's kernel). When I go into menuconfig and turn additional on as you suggest and off what I think is not needed the following fragment is generated:

CONFIG_EXPERT=y
# CONFIG_DEBUG_RSEQ is not set
# CONFIG_PC104 is not set
# CONFIG_SLOB is not set
# CONFIG_PROCESSOR_SELECT is not set
# CONFIG_SUSPEND_SKIP_SYNC is not set
# CONFIG_ACPI_REDUCED_HARDWARE_ONLY is not set
# CONFIG_PCI_CNB20LE_QUIRK is not set
# CONFIG_ISA_BUS is not set
CONFIG_KVM_WERROR=y
# CONFIG_CFG80211_CERTIFICATION_ONUS is not set
# CONFIG_RFKILL_INPUT is not set
# CONFIG_PATA_PLATFORM is not set
# CONFIG_WIRELESS_WDS is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_DRM_DEBUG_DP_MST_TOPOLOGY_REFS is not set
# CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
# CONFIG_FB_INTEL is not set
CONFIG_SND_SOC_SOF_DEVELOPER_SUPPORT=y
CONFIG_SND_SOC_SOF_NOCODEC=m
CONFIG_SND_SOC_SOF_NOCODEC_SUPPORT=y
# CONFIG_SND_SOC_SOF_STRICT_ABI_CHECKS is not set
# CONFIG_SND_SOC_SOF_DEBUG is not set
# CONFIG_SND_SOC_SOF_BROADWELL_SUPPORT is not set
# CONFIG_SND_SOC_SOF_APOLLOLAKE_SUPPORT is not set
# CONFIG_SND_SOC_SOF_GEMINILAKE_SUPPORT is not set
# CONFIG_SND_SOC_SOF_CANNONLAKE_SUPPORT is not set
# CONFIG_SND_SOC_SOF_COFFEELAKE_SUPPORT is not set
# CONFIG_SND_SOC_SOF_ICELAKE_SUPPORT is not set
# CONFIG_SND_SOC_SOF_COMETLAKE_LP_SUPPORT is not set
# CONFIG_SND_SOC_SOF_COMETLAKE_H_SUPPORT is not set
# CONFIG_SND_SOC_SOF_TIGERLAKE_SUPPORT is not set
# CONFIG_SND_SOC_SOF_ELKHARTLAKE_SUPPORT is not set
# CONFIG_SND_SOC_SOF_JASPERLAKE_SUPPORT is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_UNWINDER_GUESS is not set

@plbossart
Copy link
Contributor Author

I have no idea if this is the 'right' way to fix this, when I compile this somehow my changes are not taken into account.

It should be right, by I have struggled in the past too. Instructions are here. When your done, don't forget to clean up.
Anyway I'll try this and otherwise try to generate the fragment myself.
Thanks!

never mind, I forgot CONFIG_EXPERT=y is required. re-checking now

yep, this works now:
[ 10.676854] sof-audio-pci 0000:00:0d.0: error: request firmware intel/sof/sof-byt.ri failed err: -2

And after adding the firmware I can see the data being consumed at the right pace:

root@edison:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sofnocodec [sof-nocodec], device 0: Low Latency (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofnocodec [sof-nocodec], device 1: Media Playback 1 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
root@edison:~# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: sofnocodec [sof-nocodec], device 0: Low Latency (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
root@edison:~# time aplay -Dhw:0,0 -c2 -r48000 -f dat chirp_5s.pcm 
Playing raw data 'chirp_5s.pcm' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

real	0m5.054s
user	0m0.011s
sys	0m0.014s

The nocodec mode is required if there is no ACPI codec HID, otherwise
the kernel will throw an error such as

[    9.612127] sof-audio-pci 0000:00:0d.0: error: no matching ASoC
machine driver found - aborting probe
[    9.621634] sof-audio-pci 0000:00:0d.0: error: failed to get
machine info -19
[    9.629027] sof-audio-pci 0000:00:0d.0: error: failed to probe DSP
hardware!

Note that /lib/firmware/intel/sof/sof-byt.ri and
/lib/firmware/intel/sof-tplg/sof-byt.tplg files need to be present for
the probe to succeed, the nocodec mode depends on them

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
@plbossart
Copy link
Contributor Author

@htot @andy-shev updated the fragment, with the attached file unzipped to /lib/firmware/intel an audio card is created.
lib-firmware-intel.tar.gz

Now we need to configure the SSP2 pins to see if there's actually data coming out :-)

@andy-shev
Copy link
Contributor

andy-shev commented Jun 3, 2020

@plbossart

@htot @andy-shev updated the fragment, with the attached file unzipped to /lib/firmware/intel an audio card is created.
lib-firmware-intel.tar.gz

Now we need to configure the SSP2 pins to see if there's actually data coming out :-)

Thank you for very good news! I have just sent you various instructions how it can be achieved.

Additional Qs, though:
1/ Btw, do we have firmware in Linux firmware package? Or do we always need to build it?
2/ How can we make driver support dynamically loaded ACPI codec descriptions?

Copy link
Contributor

@andy-shev andy-shev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@plbossart
Copy link
Contributor Author

@plbossart

@htot @andy-shev updated the fragment, with the attached file unzipped to /lib/firmware/intel an audio card is created.
lib-firmware-intel.tar.gz
Now we need to configure the SSP2 pins to see if there's actually data coming out :-)

Thank you for very good news! I have just sent you various instructions how it can be achieved.

I was just reading all this and it's a bit beyond my reach and workload...

Additional Qs, though:
1/ Btw, do we have firmware in Linux firmware package? Or do we always need to build it?

the plan was initially to push SOF firmware through the linux-firmware tree, but then Jaroslav objected that some of the topology and utilities don't belong there so we created a separate repo.

https://github.com/thesofproject/sof-bin/tree/stable-v1.5/

we will need to figure out how we propagate the firmware into a Yocto or Buildroot image. For Edison you only need /lib/firmware/intel/sof/sof-byt.ri and /lib/firmware/intel/sof-tplg/sof-byt.tplg files.

if you have any suggestions we are all ears.

2/ How can we make driver support dynamically loaded ACPI codec descriptions?

If you have an I2C codec HID already and probe it sucessfully, then all we need is an entry in a table, as e.g. done here:

https://github.com/thesofproject/linux/blob/16d98cd5aad79e1c808d77e66b808e02789d2ff6/sound/soc/intel/common/soc-acpi-intel-bxt-match.c#L57

For simple drivers this can be as simple as:

{
		.id = "1AEC8804",
		.drv_name = "sof-wm8804",
		.sof_fw_filename = "sof-apl.ri",
		.sof_tplg_filename = "sof-apl-wm8804.tplg",
},

and the matching ASL snippet is at https://github.com/thesofproject/acpi-scripts/blob/master/Up2/WM8804.asl

@andy-shev
Copy link
Contributor

@plbossart

Thank you for very good news! I have just sent you various instructions how it can be achieved.

I was just reading all this and it's a bit beyond my reach and workload...

I can help with a HACK approach, but I also need a bit of time to find.
Do I understand correctly the only thing what we need is to mux I2S correctly?

Additional Qs, though:
1/ Btw, do we have firmware in Linux firmware package? Or do we always need to build it?

the plan was initially to push SOF firmware through the linux-firmware tree, but then Jaroslav objected that some of the topology and utilities don't belong there so we created a separate repo.

https://github.com/thesofproject/sof-bin/tree/stable-v1.5/

we will need to figure out how we propagate the firmware into a Yocto or Buildroot image. For Edison you only need /lib/firmware/intel/sof/sof-byt.ri and /lib/firmware/intel/sof-tplg/sof-byt.tplg files.

There are no such files. I see sof-byt-v1.5.ri and sof-byt-nocodec.tplg. That's what you meant?

if you have any suggestions we are all ears.

Easiest way is to provide BuildRoot package. At least for my development.
I think what you need is some kind of Makefile there.

2/ How can we make driver support dynamically loaded ACPI codec descriptions?

If you have an I2C codec HID already and probe it sucessfully, then all we need is an entry in a table, as e.g. done here:

https://github.com/thesofproject/linux/blob/16d98cd5aad79e1c808d77e66b808e02789d2ff6/sound/soc/intel/common/soc-acpi-intel-bxt-match.c#L57

For simple drivers this can be as simple as:

{
		.id = "1AEC8804",
		.drv_name = "sof-wm8804",
		.sof_fw_filename = "sof-apl.ri",
		.sof_tplg_filename = "sof-apl-wm8804.tplg",
},

and the matching ASL snippet is at https://github.com/thesofproject/acpi-scripts/blob/master/Up2/WM8804.asl

A-ha! Thanks for the pointers! I'll look at them when will have time for SOF.

@plbossart
Copy link
Contributor Author

@plbossart

Thank you for very good news! I have just sent you various instructions how it can be achieved.

I was just reading all this and it's a bit beyond my reach and workload...

I can help with a HACK approach, but I also need a bit of time to find.
Do I understand correctly the only thing what we need is to mux I2S correctly?

yes, I want to grab the SSP signals with a LogicPro analyzer and check the waveforms are correct. I have some doubts since the registers should be different from Baytrail to configure the SSP root frequency.

we will need to figure out how we propagate the firmware into a Yocto or Buildroot image. For Edison you only need /lib/firmware/intel/sof/sof-byt.ri and /lib/firmware/intel/sof-tplg/sof-byt.tplg files.

There are no such files. I see sof-byt-v1.5.ri and sof-byt-nocodec.tplg. That's what you meant?

yes, sorry. what you found was their names in the repo, and what I listed is the target names so that the kernel finds them.

Easiest way is to provide BuildRoot package. At least for my development.
I think what you need is some kind of Makefile there.

I started with Yocto, last year I think I was successful with BuildRoot but I forgot absolutely everything. The ClearLinux folks used a Makefile, I need to ask Auke again if he's got something turn-key.

@htot
Copy link
Member

htot commented Jun 4, 2020

I'm trying to figure out what we can do new with this? Sorry, new to playing sound with edison.

We have edison-intel/my/edison-morty/meta-intel-edison/meta-intel-edison-bsp/recipes-support/edison-sst/sst-fw-bin_0.1.bb, should we drop that? It provides fw_sst_119a.bin.

and the matching ASL snippet is at https://github.com/thesofproject/acpi-scripts/blob/master/Up2/WM8804.asl

Do I understand correctly: we need to modify kernel to tell which firmware files to use, or that is only for new drivers?

I had a look in soc-acpi-intel-byt-match.c and don't see sof-byt.tplg there (provided in your gz). Is that correct?

For now I can write a simple recipe to clone sof-bin repo and take sof-byt-v1.5.ri and sof-byt-nocodec.tplg and install using the target names. Is that correct?

@plbossart
Copy link
Contributor Author

plbossart commented Jun 4, 2020

I'm trying to figure out what we can do new with this? Sorry, new to playing sound with edison.

We have edison-intel/my/edison-morty/meta-intel-edison/meta-intel-edison-bsp/recipes-support/edison-sst/sst-fw-bin_0.1.bb, should we drop that? It provides fw_sst_119a.bin.

and the matching ASL snippet is at https://github.com/thesofproject/acpi-scripts/blob/master/Up2/WM8804.asl

Do I understand correctly: we need to modify kernel to tell which firmware files to use, or that is only for new drivers?

The drivers know what firmware then needed, they all use request_firmware(name).
But if we enable the SOF driver in the edison kernel, then there's no need for this recipe to include the closed-source firmware used by the legacy driver. It's no longer needed.

What you need is a similar recipe for the SOF firmware + topology (the topology did not exist back in the 2015 days).

I had a look in soc-acpi-intel-byt-match.c and don't see sof-byt.tplg there (provided in your gz). Is that correct?

For the nocodec case, it's taken from sound/soc/sof/sof-pci-dev.c. The soc-acpi*-match.c files are only used if there is a codec HID in the ACPI tables.

For now I can write a simple recipe to clone sof-bin repo and take sof-byt-v1.5.ri and sof-byt-nocodec.tplg and install using the target names. Is that correct?

Yep. I don't know if you can fetch it from sof-bin directly, that would help change versions with just a variable name.

@htot
Copy link
Member

htot commented Jun 4, 2020

What I did for now is PR #113

As is we need to add firmwares 1 by 1 and rename as fit. Maybe not to bad, as we also need to bring in acpi table for each.

I built this, but haven't tested yet (that will be tomorrow).

@htot
Copy link
Member

htot commented Jun 6, 2020

Found a type in my PR, fixed it. So now I have:

root@edison:~# journalctl -b | grep sof
Jun 06 12:55:31 edison kernel: xor: measuring software checksum speed
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: Mapped GSI24 to IRQ30
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warning: No matching ASoC machine driver found
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: Using nocodec machine driver
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: Firmware info: version 1:5:0-7e6cd
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: Firmware: ABI 3:16:0 Kernel ABI 3:12:0
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warn: FW ABI is more recent than kernel
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warning: unknown ext header type 3 size 0x1c
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warning: unknown ext header type 4 size 0x10
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: firmware boot complete
Jun 06 12:55:33 edison kernel: sof-nocodec sof-nocodec: info: override BE DAI link NoCodec-0
Jun 06 12:55:33 edison kernel: sof-nocodec sof-nocodec: info: override BE DAI link NoCodec-1
Jun 06 12:55:33 edison kernel: sof-nocodec sof-nocodec: info: override BE DAI link NoCodec-2
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: Topology: ABI 3:16:0 Kernel ABI 3:12:0
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warn: topology ABI is more recent than kernel
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warning: widget type 1 name codec_out0 not handled
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warning: widget type 1 name codec_out1 not handled
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warning: widget type 0 name codec_in0 not handled
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warning: widget type 0 name codec_in1 not handled
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warning: widget type 0 name ssp2 Rx not handled
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warning: widget type 1 name ssp2 Tx not handled
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warning: widget type 1 name ssp0 Tx not handled
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warning: widget type 0 name ssp0 Rx not handled
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warning: widget type 1 name modem_out not handled
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: warning: widget type 0 name modem_in not handled
Jun 06 12:55:33 edison kernel: sof-audio-pci 0000:00:0d.0: ASoC: Parent card not yet available, widget card binding deferred
Jun 06 12:55:33 edison kernel: sof-nocodec sof-nocodec: snd-soc-dummy-dai <-> ssp0-port mapping ok
Jun 06 12:55:33 edison kernel: sof-nocodec sof-nocodec: snd-soc-dummy-dai <-> ssp1-port mapping ok
Jun 06 12:55:33 edison kernel: sof-nocodec sof-nocodec: snd-soc-dummy-dai <-> ssp2-port mapping ok
Jun 06 12:55:33 edison kernel: sof-nocodec sof-nocodec: snd-soc-dummy-dai <-> Low Latency 0 mapping ok
Jun 06 12:55:33 edison kernel: sof-nocodec sof-nocodec: snd-soc-dummy-dai <-> Media Playback 1 mapping ok

and

root@edison:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sofnocodec [sof-nocodec], device 0: Low Latency (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofnocodec [sof-nocodec], device 1: Media Playback 1 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

So, without any ADC connected to Edison, can I play sound? I the past it was supported of usb or bluetooth (doc).
I can probably add uac gadget to play over usb to a host, but does that require sof?

@plbossart
Copy link
Contributor Author

I can probably add uac gadget to play over usb to a host, but does that require sof?

No. For now all you can do is configure the SSP pins, possibly I2C as well, and connect a DAC board.

@htot
Copy link
Member

htot commented Jun 8, 2020

Oh, that's too bad.
Uac2 gadget seems to be working well, but then without assistance from the DSP?

I got the idea from the dumbed down block diagram form the Edison Audio Setup guide:
afbeelding
Would SOF work with the Bluetooth?

@andy-shev Where do you want to go from here?

@plbossart
Copy link
Contributor Author

@htot yes if we can connect SSP2 using SSP1 is no issue for SOF, the main issue is how to set-up BlueZ and all the stacks, that's a bit beyond my area of expertise.

My short-term plan was to try and turn on the SSP2 pins with custom debugfs commands. I'd like to verify that all the patterns are fine (possible clock issue I'd like to rule-out). I tried to update some patches @andy-shev pointed me to, wondering if this is indeed the right direction.

@htot
Copy link
Member

htot commented Jun 8, 2020

Bluez is already setup, so maybe we are not far from the target.

@htot
Copy link
Member

htot commented Jun 12, 2020

Merged as part of PR #113 thanks

@htot htot closed this Jun 12, 2020
@andy-shev
Copy link
Contributor

andy-shev commented Jun 29, 2020

@plbossart
So, I have found some time to check I²S output. I have added muxing stuff in ASL (there is now arduino-audio-no-codec.asl), updated BuildRoot and meta-acpi accordingly. Also I have updated configuration in kernel and thus eds-acpi branch.

I run speaker test with oscilloscope connected and see 96.15 kHz output on the pins. Clock of I²S seems 2.4 MHz.

UPDATE: 96.15 kHz is the frequency of the first two pulses from speaker-test output. So, it varies depends on the sample I have got.

@plbossart
Copy link
Contributor Author

@plbossart
So, I have found some time to check I²S output. I have added muxing stuff in ASL (there is now arduino-audio-no-codec.asl), updated BuildRoot and meta-acpi accordingly. Also I have updated configuration in kernel and thus eds-acpi branch.

I run speaker test with oscilloscope connected and see 96.15 kHz output on the pins. Clock of I²S seems 2.4 MHz.

UPDATE: 96.15 kHz is the frequency of the first two pulses from speaker-test output. So, it varies depends on the sample I have got.

maybe try 'speaker-test -Dhw:0,0 -c2 -r48000'

you should see the fsync with a 48kHz frequency as well?

@andy-shev
Copy link
Contributor

@plbossart

I run speaker test with oscilloscope connected and see 96.15 kHz output on the pins. Clock of I²S seems 2.4 MHz.
UPDATE: 96.15 kHz is the frequency of the first two pulses from speaker-test output. So, it varies depends on the sample I have got.

maybe try 'speaker-test -Dhw:0,0 -c2 -r48000'

you should see the fsync with a 48kHz frequency as well?

I already returned oscilloscope to the lab. Sorry, can't test it in nearest future (the oscilloscope is used by others as well).

@plbossart
Copy link
Contributor Author

@plbossart

I run speaker test with oscilloscope connected and see 96.15 kHz output on the pins. Clock of I²S seems 2.4 MHz.
UPDATE: 96.15 kHz is the frequency of the first two pulses from speaker-test output. So, it varies depends on the sample I have got.

maybe try 'speaker-test -Dhw:0,0 -c2 -r48000'
you should see the fsync with a 48kHz frequency as well?

I already returned oscilloscope to the lab. Sorry, can't test it in nearest future (the oscilloscope is used by others as well).

That's why I have my own LogicPro8. USB puck the size of half a credit card, it shows me all audio/I2C patterns. best toy ever and well worth the money.

I'll take this for a spin, do I get this right that if I take all the latest code from the yocto recipes things should just work?

@htot
Copy link
Member

htot commented Jun 30, 2020

We are not yet loading the acpi table that @andy-shev created for this.

You might want to try the skiptables option from here. And then manually build the table and load through configfs.

@plbossart
Copy link
Contributor Author

We are not yet loading the acpi table that @andy-shev created for this.

You might want to try the skiptables option from here. And then manually build the table and load through configfs.

wow, I had no idea all of this even existing. Given my bandwidth, it's unlikely I'll find the time to look into this... Oh well.

@htot
Copy link
Member

htot commented Jun 30, 2020

Or we just configure meta-intel-edison to build and load it for you from the initramfs. I could make a branch for you?

@plbossart
Copy link
Contributor Author

Or we just configure meta-intel-edison to build and load it for you from the initramfs. I could make a branch for you?

that would be wonderful :-)

@htot
Copy link
Member

htot commented Jun 30, 2020

Ah wait, I see it has even been made easier for us by @andy-shev arduino-audio-no-codec.asl has only a define

#define MUX_I2S

and includes arduino.asli.
We already include arduino.asli through arduino.asl in meta-intel-edison-bsp/conf/machine/edison.conf. All we need to do is pass the define on the command line while building. That feature is set by:

-ACPI_FEATURES_edison ?= "uart_2w i2c"
+ACPI_FEATURES_edison ?= "uart_2w i2c i2s"

@andy-shev is it correct that I don't need to update kernel right now, as we already have enabled sof through the 5.6.0 kernel recipe?

BTW I have an oscilloscope right here. How would you like me to test?

@andy-shev
Copy link
Contributor

@htot, if you have correct firmware and driver available, yes, nothing is needed on top.

@htot
Copy link
Member

htot commented Jul 5, 2020

maybe try 'speaker-test -Dhw:0,0 -c2 -r48000'

Where can I find speaker-test?

@andy-shev
Copy link
Contributor

andy-shev commented Jul 6, 2020

maybe try 'speaker-test -Dhw:0,0 -c2 -r48000'

Where can I find speaker-test?

It's a part of alsa-utils or so.

https://alsa.opensrc.org/Speaker-test
https://linux.die.net/man/1/speaker-test

@htot htot mentioned this pull request Jul 12, 2020
@htot
Copy link
Member

htot commented Jul 12, 2020

@plbossart please checkout PR #115

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants