October 2022 - Alsa-devel - mailman.alsa-project.org

A2B codec chain implementation
by Théo Lebrun 14 Oct '22

14 Oct '22

Hi, Automotive Audio Bus (A2B) is a bus that carries a clock, I2S/TDM, I2C, GPIO and mailboxes over a two wire connection that carries power as well. It has a leader-follower (master-slave in the spec) structure, with no obligation to have all samples going from or to the leader. Analog Devices sells transceivers, that can also decode PDM inputs. Their configuration is register based, with ways of accessing follower registers from the leader. Here is their technical reference: https://www.analog.com/media/en/technical-documentation/user-guides/AD242x_… The goal is to implement support for those, when the host is connected to the leader. The implementation would be done by registering a new bus_type and device_type, with a device for each functionality (on each bus node) provided by the bus. Two issues were faced though: - At runtime, when an PCM stream is started, not only do the CPU and codec need to be configured, but also the leader and follower need some dynamic configuration based on hw_params. We have something resembling a chain, and all 4 devices need to be configured I2S-wise: CPU <-I2S-> leader node <-A2B-> follower node <-I2S-> codec. That does not fit the standard form of a DAI link that only has a CPU and a codec. Is there a way to have a sound card that contains multiple codecs, all actived? - Clocks will have to be handled at the bus level and not at the soundcard level, as the master clock is needed at all times for the bus to be functional. Sadly it's probably not doable to use the clocks provided by the I2S/TDM CPU codec (which would be ideal as they are audio rate, which is what the bus expects), because they only get enabled when a PCM stream is active. On the hardware used for testing (SAMA7G54), we can't use an external (relative to the CPU codec) clock as master clock and use the peripheral to generate the bitclock, it doesn't support it; therefore both have to be handled at the bus level using board specific clocks. So the first point is the main question: how could a codec chain be modeled? I was potentially thinking about a custom soundcard? That could surely help? Would it be the right solution? Any pointers would help. The clock aspect would have been an issue as a codec is either a clock provider or consumer but for this particular use it is not as we'll use the bus and not the soundcard to handle the clock management. Thanks! Théo -- Théo Lebrun, Bootlin Embedded Linux and Kernel engineering https://bootlin.com

2 1

Re: [rft, PATCH v2 00/36] pinctrl: Clean up and add missed headers
by Andy Shevchenko 14 Oct '22

14 Oct '22

On Tue, Oct 11, 2022 at 11:56 PM Florian Fainelli <f.fainelli(a)gmail.com> wrote: > On 10/10/2022 1:14 PM, Andy Shevchenko wrote: > > Currently the header inclusion inside the pinctrl headers seems more arbitrary > > than logical. This series is basically out of two parts: > > - add missed headers to the pin control drivers / users > > - clean up the headers of pin control subsystem > > > > The idea is to have this series to be pulled after -rc1 by the GPIO and > > pin control subsystems, so all new drivers will utilize cleaned up headers > > of the pin control. > > > > Please, review and comment. > > Did you really need to split this on a per-driver basis as opposed to > just a treewide drivers/pinctrl, drivers/media and drivers/gpiolib patch > set? > > 36 patches seems needlessly high when 4 patches could have achieve the > same outcome. I can combine them if maintainers ask for that, nevertheless for Intel pin control and GPIO drivers, which I care more about, I would like to leave as separate changes (easy to see in history what was done). -- With Best Regards, Andy Shevchenko

2 1

[PATCH v2] ASoC: nau8822: add spk boost and spk btl options
by Benjamin Marty 14 Oct '22

14 Oct '22

These two options are required to use the Speaker output on this codec to its full potential, when wiring up the Speaker in an BTL configuration. The Speaker Boost flag is explained in the Datasheet on page 80. The Speaker BTL flag is explained in the Datasheet on page 78. Signed-off-by: Benjamin Marty <info(a)benjaminmarty.ch> --- sound/soc/codecs/nau8822.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/codecs/nau8822.c b/sound/soc/codecs/nau8822.c index 1aef281a9972..812b8254f9a0 100644 --- a/sound/soc/codecs/nau8822.c +++ b/sound/soc/codecs/nau8822.c @@ -379,6 +379,12 @@ static const struct snd_kcontrol_new nau8822_snd_controls[] = { NAU8822_REG_DAC_CONTROL, 5, 1, 0), SOC_SINGLE("ADC 128x Oversampling Switch", NAU8822_REG_ADC_CONTROL, 5, 1, 0), + + SOC_SINGLE("Speaker Gain Boost Control", + NAU8822_REG_OUTPUT_CONTROL, 2, 1, 0), + + SOC_SINGLE("Speaker BTL Configuration", + NAU8822_REG_RIGHT_SPEAKER_CONTROL, 4, 1, 0), }; /* LMAIN and RMAIN Mixer */ -- 2.38.0

3 2

[PATCH] ASoC: nau8822: add spk boost and spk btl options
by Benjamin Marty 14 Oct '22

14 Oct '22

These two options are required to use the Speaker output on this codec to its full potential, when wiring up the Speaker in an BTL configuration. The Speaker Boost flag is explained in the Datasheet on page 80. The Speaker BTL flag is explained in the Datasheet on page 78. Signed-off-by: Benjamin Marty <info(a)benjaminmarty.ch> --- sound/soc/codecs/nau8822.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/codecs/nau8822.c b/sound/soc/codecs/nau8822.c index 1aef281a9972..812b8254f9a0 100644 --- a/sound/soc/codecs/nau8822.c +++ b/sound/soc/codecs/nau8822.c @@ -379,6 +379,12 @@ static const struct snd_kcontrol_new nau8822_snd_controls[] = { NAU8822_REG_DAC_CONTROL, 5, 1, 0), SOC_SINGLE("ADC 128x Oversampling Switch", NAU8822_REG_ADC_CONTROL, 5, 1, 0), + + SOC_SINGLE("Speaker Gain Boost Control", + NAU8822_REG_OUTPUT_CONTROL, 2, 1, 0), + + SOC_SINGLE("Speaker BTL Configuration", + NAU8822_REG_RIGHT_SPEAKER_CONTROL, 4, 1, 0), }; /* LMAIN and RMAIN Mixer */ -- 2.37.3

2 3

Re: Buffer overflow in AVS driver
by CoolStar Organization 14 Oct '22

14 Oct '22

Hi Cezary and Alicja, Just chiming in a bit regarding Geminilake since I figured it out on my end. I have been able to get AVS (at least my port anyways) to run on a Geminilake chromebook after re-signing + re-packing the DSP firmware with the community keys and updating my driver's topology generation to look for the correct SSP's on the NHLT. I dug through the older SKL module in Linux and I noticed the topologies for that specify a "mixer" module (I'm noting it creates an output and an input mixer and binds them together in between the HDA and I2S copier modules). Do these mixer modules do any volume adjustment / volume limiting? as I didn't see any configuration for the mixers aside from the audio format. --CoolStar On Mon, Oct 3, 2022 at 9:09 AM <alicja.michalska(a)tutanota.com> wrote: > Hello Cezary, Amadeusz and CoolStar. > > I'm sure you're waiting for update from me, but unfortunately I got really > sick with tonsillitis. Hopefully it clears up a bit tomorrow. > > I did some preliminary testing as CoolStar mentioned, but I would like to > compare results with GeminiLake Refresh board (google/octopus) that should > be arriving tomorrow. It also uses DA7219 + 2x max98357a (max98357a is a > mono amplifier, so there are two amplifiers on the board - one per channel). > > Just from multimeter measurements there's nothing out of ordinary. 5.12v > (so basically 5v) driving max98357a, resulting with 2.7v on speaker output > which is within spec. I'm still learning how to use an oscilloscope, but > I've noticed that Vpp parameter goes up to 2.4v if you set the volume to > 100% (I'm testing on google/reef baseboard which is ApolloLake N3350 with > DA7219 + 2x max98357a). If you set volume to ~66% it stays around 2v and > speakers don't heat up. > > Here you can see that even without any audio playing, left speaker is > significantly warmer than right one. I began playback with volume set to > 25%, then increased it to 65% and then 100%. Once speaker reaches 60*C, > it's permanently damaged. Working speaker has 3.7Ohm resistance, while > damaged one has 3.9Ohm. > You can also see a pair of max98357a's heating up in the background while > playing with volume set to 100% - they reach 40*C. > > https://elly.rocks/tmp/avs_fryingpan.mp4 > Speaking of which, reading trough the code I've noticed that you intend on > supporting GLK platform. We don't have firmware signed with community keys > (GLK doesn't accept Intel-signed keys) so I've been wondering - would it be > possible for you to provide such FW? > > It is really baffling to me, because as far as we both (CoolStar and me) > see, max98357a is a very simple amplifier controlled by setting GPIO pin > low or high. Conclusion would be that the problem lies in how AVS is > driving ADAU7002 or DA7219, but I'm definitely not in shape right now to > read trough AVS code once again. > > > Best regards, > Alicja Michalska > -- > Sent from Tutanota Client for Linux x86_64 > > > > Oct 2, 2022, 00:09 by coolstarorganization(a)gmail.com: > > > Hi Cezary, > > I was able to get a capture streams working. Thanks for the guidance > on the order of operations for that. For the final iteration of my driver > port I'm going to be grabbing data from the NHLT to populate topologies it > generates so that should have less hardcoding. > > > > Regarding the volume problem, Alicja here ran some tests with AVS on > linux with a scope connected to the output pins of the max98357a (we're > testing on various Skylake, Kaby Lake and Apollo Lake chromebooks -- I > unfortunately blew the left speaker on pantheon here during testing (and > Alicja blew a left speaker on snappy). We're using topology files grabbed > from Chrome OS's Apollo Lake image (I edited the virtual bus id to get it > working on Kaby Lake here), and it seems there's nothing referencing DSM > inside either the alsa configs or topology. > > --CoolStar > > > > On Thu, Sep 29, 2022 at 9:41 AM Rojewski, Cezary <> > cezary.rojewski(a)intel.com> > wrote: > > > >> > >> Hello, > >> > >> > >> > >> > >> > >> Indeed, there are means on dealing with volume problem you describe. > Not all of them are free though and we cannot share such to the community > without client’s ACK. > >> > >> > >> Judging by the max98357a, platform of yours is a Chromebook device, > perhaps AML-based, e.g.: Atlas. Said configuration contains the DSM module > which addresses the problem. The DSM topology and the configuration should > be available to public, so filtering google’s public domain should yield > positive results. > >> > >> > >> > >> > >> > >> I advise against hardcoding anything within the driver. Within a week > or two, tools for compiling the topology as well as several dozens of > examples should be present on the upstream, that is on the >> > github.com/thesofproject <http://github.com/thesofproject>>> . > >> > >> > >> But yes, there is a requirement for certain ordering of operations. In > general, you should be creating stuff from input to output (precisely in > that direction). For capture, input stands at BE side while for playback > it’s FE instead. There’s also part about configuring the actual hardware > that is represented in ASoC as a BE. Files: avs/path.c and avs/pcm.c should > provide the pattern you seek. > >> > >> > >> > >> > >> > >> > >> > >> > >> Kind regards, > >> > >> > >> Czarek > >> > >> > >> > >> > >> > >> From:>> CoolStar Organization <>> coolstarorganization(a)gmail.com>> > > >> >> Sent:>> Wednesday, September 28, 2022 11:17 PM > >> >> To:>> Rojewski, Cezary <>> cezary.rojewski(a)intel.com>> > > >> >> Cc:>> >> amadeuszx.slawinski(a)linux.intel.com > >> >> Subject:>> Re: Buffer overflow in AVS driver > >> > >> > >> > >> > >> Hi Czarek, > >> > >> > >> You can mention CoolStar in the Reported-by tag, as that’s the > pseudonym I go by. > >> > >> > >> > >> > >> > >> Also I had 2 questions regarding AVS. > >> > >> > >> > >> > >> > >> A friend and I both noticed on max98357a that increasing the volume in > the OS past 70% can destroy the speakers. Is there a module or something > that could be bound on the speaker path to limit the volume as max98357a > itself just has an on/off switch? (I noticed catpt has volume controls. > Maybe AVS’s updown mix?). > >> > >> > >> > >> > >> > >> Also, I managed to get my AVS port to output sound on another OS (I’m > not using topology files and am hard coding the path). However I noticed > I’ve been unable to record sound. I noticed for output streams the > initialization sequence is: > >> > >> > >> 1. Create pipeline 0 > >> > >> > >> 2. Create i2s link output path on pipeline 0 > >> > >> > >> 3. Grab HDA render stream & program BDL > >> > >> > >> 4. Create pipeline 1 > >> > >> > >> 5. Create HDA output path on pipeline 1 with virtual link address > (HDA stream tag - 1) > >> > >> > >> 6. Bind pipeline 1 to 0 > >> > >> > >> 7. Set pipeline 0 and then 1 to reset & paused > >> > >> > >> 8. Start HDA stream playback > >> > >> > >> 9. Set pipelines 1 and then 0 to running > >> > >> > >> > >> > >> > >> I’ve been attempting to do a similar setup for input (except with i2s > link input path, an HDA capture stream, and HDA input path) but I don’t see > any input. Is there a particular order for input initialization for it to > work? (Similar to how for the output I had to set up the HDA stream before > creating the HDA pipeline before I could get any sound output?) > >> > >> > >> > >> > >> > >> —CoolStar > >> > >> > >> > >> > >> > >> On Wed, Sep 28, 2022 at 1:09 PM Rojewski, Cezary <>> > cezary.rojewski(a)intel.com>> > wrote: > >> > >> > >>> > >>> Hello, > >>> > >>> > >>> > >>> > >>> > >>> Please excuse my delay in response. We appreciate the input – in > future, please do not be afraid to email us with alsa-devel in CC. It’s > easier to not have the mail missed that way. > >>> > >>> > >>> > >>> > >>> > >>> In regard to the actual bug, highly unlikely but indeed you’re > correct. While my response is delayed, patch fixing the problem in our > internal tree was not. Said patch should soon appear on the alsa-devel > mailing list. Are there any names that you would like us to mention in the > relevant commit message (through “Reported-by:” tag)?. > >>> > >>> > >>> > >>> > >>> > >>> Kind regards, > >>> > >>> > >>> Czarek > >>> > >>> > >>> > >>> > >>> > >>> From:>>> CoolStar Organization <>>> coolstarorganization(a)gmail.com>>> > > > >>> >>> Sent:>>> Saturday, September 10, 2022 10:00 PM > >>> >>> To:>>> Rojewski, Cezary <>>> cezary.rojewski(a)intel.com>>> >; > >>> amadeuszx.slawinski(a)linux.intel.com > >>> >>> Subject:>>> Buffer overflow in AVS driver > >>> > >>> > >>> > >>> > >>> Hi, > >>> > >>> > >>> I've been looking at porting the avs driver you've written to another > OS. During the process I noticed a potential buffer overflow issue in ipc.c. > >>> > >>> > >>> > >>> > >>> > >>> I noticed that ipc->rx.data is allocated a buffer of > `AVS_MAILBOX_SIZE` (or 4096 bytes) in the init, and this buffer is not > allocated anywhere else. In avs_dsp_receive_rx, if the msg type is set to a > large config get, it sets the size to the arbitrary value from the msg > struct without any checks, and then immediately does a memcpy to the buffer. > >>> > >>> > >>> > >>> > >>> > >>> I'd highly suggest putting a check to ensure this doesn't go larger > than AVS_MAILBOX_SIZE to avoid a buffer overflow as that could crash the > system (or potentially be a vulnerability to take over the host system if > an attacker somehow gets code execution on the DSP?) > >>> > >>> > >>> --CoolStar > >>> > >>> > >

1 0

Software volume control has very little effect on Behringer UMC204HD
by GitHub issues - edited 13 Oct '22

13 Oct '22

alsa-project/alsa-ucm-conf issue #230 was edited from Spanfile: I'm using a Behringer UMC204HD with its UCM profile and Pipewire. The profile works fine that it properly splits the interface's four output channels into two stereo line outputs, and Pipewire is properly using them. There aren't any issues with audio crackling, latency or the sort, but the software volume control is affecting the actual volume output very little. Only the first few "notches" from 0 to 10 change the volume noticeably, however the lowest volume it allows is still somewhat loud. From there on the rest of the range doesn't change the volume much at all. Using the Direct UCM profile lets the software volume control have much better range, but I need the Line A/B split in my setup so that profile is not an option. I haven't tried disabling UCM and configuring pro audio in Pipewire directly, but that doesn't sound like a proper fix. It may be intentional, however? [There has been a similar issue reported to Pipewire](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2643), but it's not exactly what I'm experiencing. [I've reported this issue to them as well.](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2765) Of course I could set the software volume to something static and control it from the interface, but the interface is physically out of reach from my hands and the software volume is easily controlled from my keyboard ;) Kernel: 6.0.1.arch1-1 Pipewire: 0.3.59 alsa-ucm-conf: 1.2.7.2 Desktop environment: GNOME (w/ GDM) Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/230 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Software volume control has very little effect on Behringer UMC204HD
by GitHub issues - edited 13 Oct '22

13 Oct '22

alsa-project/alsa-ucm-conf issue #230 was edited from Spanfile: I'm using a Behringer UMC204HD with Pipewire and its UCM profile. The profile works fine that it properly splits the interface's four output channels into two stereo line outputs, and Pipewire is properly using them. There aren't any issues with audio crackling, latency or the sort, but the software volume control is affecting the actual volume output very little. Only the first few "notches" from 0 to 10 change the volume noticeably, however the lowest volume it allows is still somewhat loud. From there on the rest of the range doesn't change the volume much at all. Using the Direct UCM profile lets the software volume control have much better range, but I need the Line A/B split in my setup so that profile is not an option. I haven't tried disabling UCM and configuring pro audio in Pipewire directly, but that doesn't sound like a proper fix. It may be intentional, however? [There has been a similar issue reported to Pipewire](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2643), but it's not exactly what I'm experiencing. [I've reported this issue to them as well.](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2765) Of course I could set the software volume to something static and control it from the interface, but the interface is physically out of reach from my hands and the software volume is easily controlled from my keyboard ;) Kernel: 6.0.1.arch1-1 Pipewire: 0.3.59 alsa-ucm-conf: 1.2.7.2 Desktop environment: GNOME (w/ GDM) Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/230 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH] ASoC: rt5682s: Fix the TDM Tx settings
by derek.fang＠realtek.com 13 Oct '22

13 Oct '22

From: Derek Fang <derek.fang(a)realtek.com> Complete the missing and correct the TDM Tx settings. Signed-off-by: Derek Fang <derek.fang(a)realtek.com> --- sound/soc/codecs/rt5682s.c | 15 +++++++++++++-- sound/soc/codecs/rt5682s.h | 1 + 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/rt5682s.c b/sound/soc/codecs/rt5682s.c index 3b91a3442c68..5199d3bbaf0b 100644 --- a/sound/soc/codecs/rt5682s.c +++ b/sound/soc/codecs/rt5682s.c @@ -1981,7 +1981,7 @@ static int rt5682s_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask, unsigned int rx_mask, int slots, int slot_width) { struct snd_soc_component *component = dai->component; - unsigned int cl, val = 0; + unsigned int cl, val = 0, tx_slotnum; if (tx_mask || rx_mask) snd_soc_component_update_bits(component, @@ -1990,6 +1990,16 @@ static int rt5682s_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask, snd_soc_component_update_bits(component, RT5682S_TDM_ADDA_CTRL_2, RT5682S_TDM_EN, 0); + /* Tx slot configuration */ + tx_slotnum = hweight_long(tx_mask); + if (tx_slotnum) { + if (tx_slotnum > slots) { + dev_err(component->dev, "Invalid or oversized Tx slots.\n"); + return -EINVAL; + } + val |= (tx_slotnum - 1) << RT5682S_TDM_ADC_DL_SFT; + } + switch (slots) { case 4: val |= RT5682S_TDM_TX_CH_4; @@ -2010,7 +2020,8 @@ static int rt5682s_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask, } snd_soc_component_update_bits(component, RT5682S_TDM_CTRL, - RT5682S_TDM_TX_CH_MASK | RT5682S_TDM_RX_CH_MASK, val); + RT5682S_TDM_TX_CH_MASK | RT5682S_TDM_RX_CH_MASK | + RT5682S_TDM_ADC_DL_MASK, val); switch (slot_width) { case 8: diff --git a/sound/soc/codecs/rt5682s.h b/sound/soc/codecs/rt5682s.h index 824dc6543c18..45464a041765 100644 --- a/sound/soc/codecs/rt5682s.h +++ b/sound/soc/codecs/rt5682s.h @@ -899,6 +899,7 @@ #define RT5682S_TDM_RX_CH_8 (0x3 << 8) #define RT5682S_TDM_ADC_LCA_MASK (0x7 << 4) #define RT5682S_TDM_ADC_LCA_SFT 4 +#define RT5682S_TDM_ADC_DL_MASK (0x3 << 0) #define RT5682S_TDM_ADC_DL_SFT 0 /* TDM control 2 (0x007a) */ -- 2.17.1

2 1

[PATCH] ASoC: rt1019: Fix the TDM settings
by derek.fang＠realtek.com 13 Oct '22

13 Oct '22

From: Derek Fang <derek.fang(a)realtek.com> Complete the missing and correct the TDM settings. Signed-off-by: Derek Fang <derek.fang(a)realtek.com> --- sound/soc/codecs/rt1019.c | 20 +++++++++++--------- sound/soc/codecs/rt1019.h | 6 ++++++ 2 files changed, 17 insertions(+), 9 deletions(-) diff --git a/sound/soc/codecs/rt1019.c b/sound/soc/codecs/rt1019.c index b66bfecbb879..49f527c61a7a 100644 --- a/sound/soc/codecs/rt1019.c +++ b/sound/soc/codecs/rt1019.c @@ -391,18 +391,18 @@ static int rt1019_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask, unsigned int rx_mask, int slots, int slot_width) { struct snd_soc_component *component = dai->component; - unsigned int val = 0, rx_slotnum; + unsigned int cn = 0, cl = 0, rx_slotnum; int ret = 0, first_bit; switch (slots) { case 4: - val |= RT1019_I2S_TX_4CH; + cn = RT1019_I2S_TX_4CH; break; case 6: - val |= RT1019_I2S_TX_6CH; + cn = RT1019_I2S_TX_6CH; break; case 8: - val |= RT1019_I2S_TX_8CH; + cn = RT1019_I2S_TX_8CH; break; case 2: break; @@ -412,16 +412,16 @@ static int rt1019_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask, switch (slot_width) { case 20: - val |= RT1019_I2S_DL_20; + cl = RT1019_TDM_CL_20; break; case 24: - val |= RT1019_I2S_DL_24; + cl = RT1019_TDM_CL_24; break; case 32: - val |= RT1019_I2S_DL_32; + cl = RT1019_TDM_CL_32; break; case 8: - val |= RT1019_I2S_DL_8; + cl = RT1019_TDM_CL_8; break; case 16: break; @@ -470,8 +470,10 @@ static int rt1019_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask, goto _set_tdm_err_; } + snd_soc_component_update_bits(component, RT1019_TDM_1, + RT1019_TDM_CL_MASK, cl); snd_soc_component_update_bits(component, RT1019_TDM_2, - RT1019_I2S_CH_TX_MASK | RT1019_I2S_DF_MASK, val); + RT1019_I2S_CH_TX_MASK, cn); _set_tdm_err_: return ret; diff --git a/sound/soc/codecs/rt1019.h b/sound/soc/codecs/rt1019.h index 64df831eeb72..48ba15efb48d 100644 --- a/sound/soc/codecs/rt1019.h +++ b/sound/soc/codecs/rt1019.h @@ -95,6 +95,12 @@ #define RT1019_TDM_BCLK_MASK (0x1 << 6) #define RT1019_TDM_BCLK_NORM (0x0 << 6) #define RT1019_TDM_BCLK_INV (0x1 << 6) +#define RT1019_TDM_CL_MASK (0x7) +#define RT1019_TDM_CL_8 (0x4) +#define RT1019_TDM_CL_32 (0x3) +#define RT1019_TDM_CL_24 (0x2) +#define RT1019_TDM_CL_20 (0x1) +#define RT1019_TDM_CL_16 (0x0) /* 0x0401 TDM Control-2 */ #define RT1019_I2S_CH_TX_MASK (0x3 << 6) -- 2.17.1

2 1

[PATCH] ASoC: qcom: lpass-cpu: mark HDMI TX registers as volatile
by Srinivasa Rao Mandadapu 13 Oct '22

13 Oct '22

From: Srinivasa Rao Mandadapu <srivasam(a)qualcomm.corp-partner.google.com> Update HDMI volatile registers list as DMA, Channel Selection registers , vbit control registers are being reflected by hardware DP port disconnection. This update is required to fix no display and no sound issue observed after reconnecting TAMA/SANWA DP cables. Once DP cable is unplugged, DMA control registers are being reset by hardware, however at second plugin, new dma control values does not updated to the dma hardware registers since new register value and cached values at the time of first plugin are same. Signed-off-by: Srinivasa Rao Mandadapu <srivasam(a)qualcomm.corp-partner.google.com> --- sound/soc/qcom/lpass-cpu.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c index 8a56f38..99a3b44 100644 --- a/sound/soc/qcom/lpass-cpu.c +++ b/sound/soc/qcom/lpass-cpu.c @@ -782,10 +782,18 @@ static bool lpass_hdmi_regmap_volatile(struct device *dev, unsigned int reg) return true; if (reg == LPASS_HDMI_TX_LEGACY_ADDR(v)) return true; + if (reg == LPASS_HDMI_TX_VBIT_CTL_ADDR(v)) + return true; for (i = 0; i < v->hdmi_rdma_channels; ++i) { if (reg == LPAIF_HDMI_RDMACURR_REG(v, i)) return true; + if (reg == LPASS_HDMI_TX_DMA_ADDR(v, i)) + return true; + if (reg == LPASS_HDMI_TX_CH_LSB_ADDR(v, i)) + return true; + if (reg == LPASS_HDMI_TX_CH_MSB_ADDR(v, i)) + return true; } return false; } -- 2.7.4

3 2