[v13] ASoc: rt711-sdca/rt1316: Add RT1316/RT711 SDCA vendor-specific driver by shumingfan · Pull Request #2298 · thesofproject/linux

shumingfan · 2020-07-20T10:21:55Z

Update v12 version:

rt711-sdca: fix no button response after plug/unplug the jack many times
rt1316: fix RX channel select not working

Update v13:

rt711-sdca: use devm_regmap_init_sdw_mbq instead
rt1316: add IV tag controls

plbossart

this looks quite good @shumingfan
I added a number of comments, most cosmetic. I think the part where I am in the dark a bit is with the jack detected/selected mode.

plbossart · 2020-07-20T18:04:01Z

 	tristate "Realtek RT711 Codec - SDW"
 	depends on SOUNDWIRE
 	select SND_SOC_RT711
+	select SND_SOC_RT711_SDCA


Does the RT711-SDCA support an HDaudio mode?
I would err on the side of creating a different codec, e.g. SND_SOC_RT711_SDCA_SDW, since in the Makefile you don't actually refer to rt711.c

Does the RT711-SDCA support an HDaudio mode?
I would err on the side of creating a different codec, e.g. SND_SOC_RT711_SDCA_SDW, since in the Makefile you don't actually refer to rt711.c

RT711-SDCA only supports the Soundwire interface.
Thanks for your comments and I checked all. I will send the third version later.

plbossart · 2020-07-20T18:04:30Z

@@ -0,0 +1,431 @@
+// SPDX-License-Identifier: GPL-2.0


GPL-2.0-only is recommended for new contributions.

plbossart · 2020-07-20T18:06:43Z

+}
+
+static int rt711_sdca_sdw_read(void *context,
+	unsigned int reg, unsigned int *val)


100 characters now, can this fit on one line?

plbossart · 2020-07-20T18:09:19Z

+#define ENT_OT1 0x06
+#define ENT_LINE1 0x09
+#define ENT_LINE2 0x31
+#define ENT_PDELINE2 0x36


Add RT711_SDCA_ prefix?

plbossart · 2020-07-20T18:19:18Z

+		rt711->jack_type = SND_JACK_HEADPHONE;
+		break;
+	case 0x05:
+		rt711->jack_type = SND_JACK_HEADSET;


in SDCA the detected mode can be 'unknown' - e.g. some OEMs may want to let a user select headset or headphone, and the user can confirm with selected mode.

in SDCA the detected mode can be 'unknown' - e.g. some OEMs may want to let a user select headset or headphone, and the user can confirm with selected mode.

Do you mean that some kind of feature like UAJ? There is a pop-menu that a user could select headphone or headset, right?
If yes, the pop-menu is controlled by libgnome-volume-control.
Please check the function below.
https://github.com/GNOME/libgnome-volume-control/blob/e2be83ee4a47da9c4c4fbf302a63f04b8d5683b9/gvc-mixer-control.c#L2345
It needs a certain Jack control name, therefore, do we need another Jack control to report when the detected mode is 'unknown'?

it's my understanding that there are already two controls in the GE (section 7.2.10.4 of SDCA v.06-r04), one for Detected Mode (RO) and Selected Mode (RW). The device can mirror Detected Mode and Selected Mode, but software has the ability to override any default. In case the detected mode is 'unknown" then indeed the selected mode needs to be selected by the user with a UI pop-up.

OK, I understood. However, there are some application cases for GE in the RT711 SDCA.
I prefer using HW CBJ detection (one kind of auto-update mode) in the vendor-specific driver.
In this mode, the detected_mode could report HP/Headset/Unplug, not including the unknown.

I need to check if this is the expected behavior with SDCA, stay tuned.

plbossart · 2020-07-20T18:19:40Z

+	if (!rt711->component->card->instantiated)
+		return;
+
+	/* SDW_SCP_SDCA_INT_SDCA_0 uses for jack detection */


plbossart · 2020-07-20T18:19:57Z

+			return;
+	}
+
+	/* SDW_SCP_SDCA_INT_SDCA_8 uses for button detection */


plbossart · 2020-07-20T18:24:08Z

+static int rt711_sdca_parse_dt(struct rt711_priv *rt711, struct device *dev)
+{
+	device_property_read_u32(dev, "realtek,jd-src",
+		&rt711->jd_src);


we may need to update DT bindings then, and explain they apply for the RT711 SDCA case.

plbossart · 2020-07-20T18:26:23Z

+		0x09);
+	regmap_write(rt711->regmap,
+		SDW_SDCA_CTL(FUN_MIC_ARRAY, ENT_CS1F, CTL_SAMPLE_FREQ_INDEX, 0),
+		0x09);


do we need macros for the frequency encoding? 0x09 is a bit weird.

lyakh

Thanks for addressing most of the comments! A couple more left.

lyakh · 2020-07-21T09:08:33Z

+	}
+	if (loop == 500) {
+		dev_err(dev, "%s, RC calibration time-out!\n", __func__);
+		ret = -ETIMEDOUT;


but you still want to proceed with the calibration? Why do you even set the ret then, it will anyway be overwritten below.

yes, I still want to process the calibration. I added two loop counts for RC and HP calibration. I will check these loop counts at the end of the function.

lyakh · 2020-07-21T09:10:19Z

+	}
+	if (loop == 500) {
+		dev_err(dev, "%s, calibration time-out!\n", __func__);
+		ret = -ETIMEDOUT;


and with this error you do return an error code from this function, but you still execute the register write below?

If the calibration failed, it will affect the headphone performance. The function of playback and capture still works.

ok, got it, thanks. Another question: 500 cycles of 10ms is 5s, so, if both these loops fail you'll spend 10s on the total in them. Are you sure you need that much time to check the failures?

lyakh · 2020-07-21T09:13:55Z

+	if (owner == 0)
+		/* set owener to device */
+		regmap_write(rt711->regmap,
+			SDW_SDCA_CTL(FUN_HID, RT711_SDCA_ENT_HID01, RT711_SDCA_CTL_HIDTX_SET_OWNER_TO_DEVICE, 0),


that line is 113 characters long. I know that it was me who suggested splitting lines (where feasible) differently, and 80 characters has been cancelled, but the new recommendation is 100 characters, and 113 might indeed be a bit too much?

lyakh · 2020-07-21T09:19:56Z

+		if (read_r == gain_r_val && read_l == gain_l_val)
+			break;
+		else if (i == 2)
+			return -EIO;


mmh, the loop will terminate anyway, it seems redundant - having a loop until 3 and checking again at the end of its body for the last iteration. How about just return i == 3 ? -EIO : 0; right after the loop?

lyakh · 2020-07-21T10:51:52Z

+	if (change)
+		rt711_sdca_index_update_bits(rt711, RT711_VENDOR_HDA_CTL,
+			RT711_HDA_LEGACY_MUX_CTL1, (0x7 << mask_sft),
+			(val << mask_sft));


still superfluous parentheses around the last two function parameters

lyakh · 2020-07-21T10:53:46Z

+	val = snd_soc_enum_item_to_val(e, item[0]) << e->shift_l;
+
+	rt711_sdca_index_read(rt711, RT711_VENDOR_HDA_CTL,
+		RT711_HDA_LEGACY_MUX_CTL1, &val2);


I actually don't know what's a good practice to handle all register IO failures. I see many drivers never checking return code of regmap register read / write functions, but checking such return codes sometimes seems strange too - either we check it everywhere or nowhere, or we have to explain why only some of them are checked.

lyakh · 2020-07-21T10:54:57Z

+	stream_config.direction = direction;
+
+	num_channels = params_channels(params);
+	port_config.ch_mask = (1 << (num_channels)) - 1;


as suggested last time: GENMASK(num_channels, 0);

plbossart

Need to check how the jack detection should be handled, and if the interrupts are handled in the right way.

plbossart · 2020-07-23T20:07:23Z

+		"%s control_port_stat=%x, sdca_cascade=%x", __func__,
+		status->control_port, status->sdca_cascade);
+
+	if (status->control_port & 0x4 || status->sdca_cascade)


use define instead of magic 0x4?

do you actually need to use the imp-def interrupt to deal with the jack detection? Isn't the second part of the logical OR enough?
You haven't enabled the imp-def interrupt in the scp_instat1 case at line 243

plbossart · 2020-07-23T21:00:09Z

+_end_btn_det_:
+	/* Host is owner, so set back to device */
+	if (owner == 0)
+		/* set owener to device */


typo: owner

plbossart · 2020-07-23T21:00:57Z

+		rt711->jack_type = SND_JACK_HEADPHONE;
+		break;
+	case 0x05:
+		rt711->jack_type = SND_JACK_HEADSET;


I need to check if this is the expected behavior with SDCA, stay tuned.

plbossart · 2020-07-23T21:07:23Z

+	if (ret < 0)
+		goto io_error;
+	if (sdca_stat0) {
+		ret = regmap_write(rt711->regmap, SDW_SCP_SDCA_INT1, sdca_stat0);


that clears the SDCA interrupt, yes?

I am wondering if this is the right thing to do. The expectation was that the interrupt was cleared in the interrupt callback, but here this happens in a work queue, so it could be that the interrupt callback is called multiple times because the interrupt is still not cleared.

Actually now that I write this I realize the SDCA code is not good enough, we need to re-read the SDCA bit in the bus loop before checking if there are SDCA interrupts left

linux/drivers/soundwire/bus.c

Line 1571 in e1a2507

/* Make sure no interrupts are pending */

What we have now is not good enough, there's a risk of losing interrupts (known SoundWire 'feature')

plbossart · 2020-07-23T21:09:22Z

+	if (ret < 0)
+		goto io_error;
+	if (sdca_stat8) {
+		ret = regmap_write(rt711->regmap, SDW_SCP_SDCA_INT2, sdca_stat8);


I really think you should read the SDCA_INTx registers that you need in the interrupt callback, memorise their values, clear the interrupts and use these values in the workqueue. It's confusing to clear such interrupts at a later point.

Sure, you are right. I will move this part to the interrupt callback.

plbossart · 2020-07-23T21:12:45Z

+		RT711_SDCA_RATE_48000HZ);
+	regmap_write(rt711->regmap,
+		SDW_SDCA_CTL(FUN_MIC_ARRAY, RT711_SDCA_ENT_CS1F, RT711_SDCA_CTL_SAMPLE_FREQ_INDEX, 0),
+		RT711_SDCA_RATE_48000HZ);


shouldn't we convert hw_params->rate to register values?

RanderWang · 2020-07-24T08:02:59Z

+		return retval;
+	}
+
+	return retval;


retval == 0 ? so just return 0 ?

RanderWang · 2020-07-24T08:05:00Z

+		return -EINVAL;
+
+	rt1316_sdw_init(&slave->dev, regmap, slave);
+


to check status of rt1316_sdw_init ?

RanderWang · 2020-07-24T08:12:51Z

+		if (ret < 0)
+			return ret;
+	}
+


write-after-read, clear irq ?

RanderWang · 2020-07-24T08:20:24Z

+	if (IS_ERR(regmap))
+		return PTR_ERR(regmap);
+
+	rt711_sdca_init(&slave->dev, sdw_regmap, regmap, slave);


check result of rt711_sdca_init ?

lyakh · 2020-07-24T09:19:58Z

+	}
+	if (loop == 500) {
+		dev_err(dev, "%s, calibration time-out!\n", __func__);
+		ret = -ETIMEDOUT;


ok, got it, thanks. Another question: 500 cycles of 10ms is 5s, so, if both these loops fail you'll spend 10s on the total in them. Are you sure you need that much time to check the failures?

lyakh · 2020-07-24T09:29:15Z

+		/* set owner to device */
+		regmap_write(rt711->regmap,
+			SDW_SDCA_CTL(FUN_HID, RT711_SDCA_ENT_HID01,
+			RT711_SDCA_CTL_HIDTX_SET_OWNER_TO_DEVICE, 0), 0x01);


it would be better to indent this last line more since it's now an argument of SDW_SDCA_CTL(), not of regmap_write()

Thanks for your suggestions. The calibration time of RT711 SDCA is much faster than the previous hardware version.
I will reduce the delay time.

plbossart

the regmap part is unclear to me, some values are 8 bits and some 16 bits, I don't get how it works.

plbossart · 2020-07-28T21:01:13Z

+		ret = regmap_read(rt711->sdw_regmap, reg, &sdw_data_0);
+		if (ret < 0)
+			return ret;
+		ret = regmap_read(rt711->sdw_regmap, RT711_SDCA_MBQ_CTL(reg), &sdw_data_1);


I added SDW_SDCA_MBQ_CTL in the sdw_registers.h file.

plbossart · 2020-07-28T21:01:43Z

+		if (ret < 0)
+			return ret;
+	}
+


yes we should explain why we clear without checking the results.

plbossart · 2020-07-28T21:07:33Z

+	if (rt711->scp_sdca_stat1) {
+		ret = regmap_write(rt711->regmap, SDW_SCP_SDCA_INT1, rt711->scp_sdca_stat1);
+		if (ret < 0)
+			return ret;


when you clear an interrupt, you're supposed to re-read the status again, otherwise you have a risk of losing an interrupt. see how the code works in bus.c

lyakh · 2020-07-29T07:31:13Z

+					struct sdw_slave_intr_status *status)
+{
+	struct rt711_sdca_priv *rt711 = dev_get_drvdata(&slave->dev);
+	int ret = 0, stat, count = 0, retry = 10;


superfluous initialisation of ret. Optionally, if you use a for loop as proposed below, you could remove retry completely and count's initialisation too.

plbossart

See below @shumingfan @bardliao I wonder if we have a conceptual bug with the use of regmap.

plbossart · 2020-08-13T20:38:25Z

+	case SDW_SDCA_CTL(FUN_MIC_ARRAY, RT711_SDCA_ENT_PLATFORM_FU15, RT711_SDCA_CTL_FU_CH_GAIN, CH_L):
+	case SDW_SDCA_CTL(FUN_MIC_ARRAY, RT711_SDCA_ENT_PLATFORM_FU15, RT711_SDCA_CTL_FU_CH_GAIN, CH_R):
+		regmap_write(rt711->sdw_regmap, SDW_SDCA_MBQ_CTL(reg), ((val >> 8) & 0xff));
+		regmap_write(rt711->sdw_regmap, reg, (val & 0xff));


@shumingfan I wonder if this solution actually works for the suspend/resume parts, where we use regmap_sync() functions to restore the state. Here you manually issue two regmap_write(), but on a resume the sync() would not use the MBQ bit, so would all these volumes be restored after a system suspend where the power might be turned off?

See suggested solution in #2364

The regcache_sync() will restore the settings, let me show you.
The regmap_config (rt711_sdca_regmap) has own .reg_write/.reg_read callback funcitons.
The codec driver will use this register map to access registers.
The callback functions will check the register address to decide the access method using MBQ bit or not.

There are test logs below. The regcache_sync() operation can restore the settings.
root@Ice-Lake:~# amixer -c0 cset numid=7 87
numid=7,iface=MIXER,name='rt711 FU05 Playback Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=87,step=0
: values=87,87
| dBscale-min=-65.25dB,step=0.75dB,mute=0

[ 204.388758] rt711-sdca sdw:2:25d:711:1: 40402291 <= 0
[ 204.389198] rt711-sdca sdw:2:25d:711:1: 40400291 <= 0
[ 204.389612] rt711-sdca sdw:2:25d:711:1: [rt711_sdca_sdw_write] 40400291 <= 0000
[ 204.389614] rt711-sdca sdw:2:25d:711:1: 40402292 <= 0
[ 204.390045] rt711-sdca sdw:2:25d:711:1: 40400292 <= 0
[ 204.390597] rt711-sdca sdw:2:25d:711:1: [rt711_sdca_sdw_write] 40400292 <= 0000

After the run-time suspend, I changed the volume settings.
root@Ice-Lake:~# amixer -c0 cset numid=7 50
numid=7,iface=MIXER,name='rt711 FU05 Playback Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=87,step=0
: values=50,50
| dBscale-min=-65.25dB,step=0.75dB,mute=0

[ 371.980822] rt711_sdca_dev_resume, start to reg sync
...
[ 372.009651] rt711-sdca sdw:2:25d:711:1: 40400291 <= e440
[ 372.009651] rt711-sdca sdw:2:25d:711:1: 40402291 <= e4
[ 372.010070] rt711-sdca sdw:2:25d:711:1: 40400291 <= 40
[ 372.010484] rt711-sdca sdw:2:25d:711:1: [rt711_sdca_sdw_write] 40400291 <= e440
[ 372.010485] rt711-sdca sdw:2:25d:711:1: 40400292 <= e440
[ 372.010486] rt711-sdca sdw:2:25d:711:1: 40402292 <= e4
[ 372.010859] rt711-sdca sdw:2:25d:711:1: 40400292 <= 40
[ 372.011290] rt711-sdca sdw:2:25d:711:1: [rt711_sdca_sdw_write] 40400292 <= e440
...
[ 372.021935] rt711_sdca_dev_resume, reg sync done

My point was that it forces you to declare each control twice, and then have a test on the address to force the second byte to be updated - essentially preventing the second byte from actually being managed by regmap.

it's really a manual way of managing these registers and it makes every codec driver a bit more complicated than it needs to be.

I agree with Pierre. We should support MBQ on regmap. It is not only for Realtek codecs but also for all codecs which support SDCA.

@plbossart @bardliao Sure, I will update the codec driver and test with #2364.

bardliao

Thanks @shumingfan It looks good to me. Few minor comments from me.

bardliao · 2020-10-16T02:47:28Z

+		regmap_write(rt1316->regmap,
+			SDW_SDCA_CTL(FUN_SMART_AMP, RT1316_SDCA_ENT_PDE23, RT1316_SDCA_CTL_REQ_POWER_STATE, 0), PS0);
+		regmap_write(rt1316->regmap,
+			SDW_SDCA_CTL(FUN_SMART_AMP, RT1316_SDCA_ENT_PDE27, RT1316_SDCA_CTL_REQ_POWER_STATE, 0), PS0);


This exceeds 100 columns

ok, will fix

shumingfan · 2020-10-16T04:33:08Z

Looks good @shumingfan, can you just update the part on the devm_ comment I missed earlier and we should be able to merge this into the SOF tree.

Thanks a lot for your work!

shumingfan · 2020-10-16T04:33:50Z

Looks good @shumingfan, can you just update the part on the devm_ comment I missed earlier and we should be able to merge this into the SOF tree.

Thanks a lot for your work!

@plbossart OK, will send another commit in this PR.

bardliao

Thanks @shumingfan LGTM. Some lines exceeds 100 columns, but I think it is fine.

plbossart · 2020-10-16T13:47:09Z

I think it'd be a bit more readable if the power state was not after the 100 col limit

Maybe a multi-line formatting like this would be more clear? GitHub messes with alignment, just look at the line splits

SDW_SDCA_CTL(FUN_SMART_AMP, RT1316_SDCA_ENT_PDE24,
RT1316_SDCA_CTL_REQ_POWER_STATE, 0),
PS3);

Also you added the devm_ stuff on the wrong branch, this needs to be rebased now.

shumingfan · 2020-10-19T10:59:23Z

I think it'd be a bit more readable if the power state was not after the 100 col limit

Maybe a multi-line formatting like this would be more clear? GitHub messes with alignment, just look at the line splits

SDW_SDCA_CTL(FUN_SMART_AMP, RT1316_SDCA_ENT_PDE24,
RT1316_SDCA_CTL_REQ_POWER_STATE, 0),
PS3);

Also you added the devm_ stuff on the wrong branch, this needs to be rebased now.

@bardliao @plbossart The branch had rebased. I also fix some longer lines with the suggestion above.

plbossart

Thanks @shumingfan
I think this is good enough to merge now, I will let @bardliao and @RanderWang review and merge if this is fine.

Time to work on the integration with machine driver/UCM and close all bugs!

plbossart · 2020-10-19T16:03:05Z

+	tristate "Realtek RT1316 Codec - SDW"
+	depends on SOUNDWIRE
+	select REGMAP_SOUNDWIRE
+	select REGMAP_SOUNDWIRE_MBQ


@shumingfan one more comment though: I don't see any MBQ usage in this patch?

I will remove "select REGMAP_SOUNDWIRE_MBQ" for RT1316.

plbossart · 2020-10-19T16:05:20Z

+	case 0x202d ... 0x202f: /* BRA */
+	case 0x2200 ... 0x2212: /* i2c debug */
+	case RT711_RC_CAL_STATUS:
+	case 0x40600490:


can this value be converted with the SDW_SDCA_CTL macro?

ok, will fix

bardliao

It looks good to me. I will merge it now and we can send follow-up patches to address comments if needed.

This is the initial amplifier driver for rt1316 SDCA version. Signed-off-by: Shuming Fan <[email protected]>

This is the initial codec driver for rt711 SDCA version. Signed-off-by: Shuming Fan <[email protected]>

plbossart

thanks @shumingfan

shumingfan requested review from RanderWang, bardliao, dbaluta, jack-cy-yu, kv2019i, lgirdwood, oder-chiou, plbossart and ranj063 as code owners July 20, 2020 10:21

plbossart requested changes Jul 20, 2020

View reviewed changes

shumingfan force-pushed the topic/sof-dev branch 2 times, most recently from 0aae575 to 9ee5b7a Compare July 21, 2020 06:47

shumingfan changed the title ~~[v2] ASoc: rt711-sdca/rt1316: Add RT1316/RT711 SDCA vendor-specific driver~~ [v3] ASoc: rt711-sdca/rt1316: Add RT1316/RT711 SDCA vendor-specific driver Jul 21, 2020

lyakh requested changes Jul 21, 2020

View reviewed changes

shumingfan force-pushed the topic/sof-dev branch from 9ee5b7a to 4314223 Compare July 23, 2020 06:15

shumingfan changed the title ~~[v3] ASoc: rt711-sdca/rt1316: Add RT1316/RT711 SDCA vendor-specific driver~~ [v4] ASoc: rt711-sdca/rt1316: Add RT1316/RT711 SDCA vendor-specific driver Jul 23, 2020

plbossart reviewed Jul 23, 2020

View reviewed changes

shumingfan force-pushed the topic/sof-dev branch from 4314223 to 4283c8b Compare July 24, 2020 05:25

shumingfan changed the title ~~[v4] ASoc: rt711-sdca/rt1316: Add RT1316/RT711 SDCA vendor-specific driver~~ [v5] ASoc: rt711-sdca/rt1316: Add RT1316/RT711 SDCA vendor-specific driver Jul 24, 2020

RanderWang reviewed Jul 24, 2020

View reviewed changes

Comment thread sound/soc/codecs/rt1316-sdw.c Outdated

return retval;

}

return retval;

Copy link
Copy Markdown

RanderWang Jul 24, 2020

Choose a reason for hiding this comment

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

retval == 0 ? so just return 0 ?

RanderWang reviewed Jul 24, 2020

View reviewed changes

Comment thread sound/soc/codecs/rt711-sdca-sdw.c

if (ret < 0)

return ret;

}

Copy link
Copy Markdown

RanderWang Jul 24, 2020

Choose a reason for hiding this comment

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

write-after-read, clear irq ?

RanderWang reviewed Jul 24, 2020

View reviewed changes

lyakh reviewed Jul 24, 2020

View reviewed changes

plbossart requested changes Jul 28, 2020

View reviewed changes

shumingfan force-pushed the topic/sof-dev branch from 4283c8b to bd18d4c Compare July 29, 2020 07:08

shumingfan changed the title ~~[v5] ASoc: rt711-sdca/rt1316: Add RT1316/RT711 SDCA vendor-specific driver~~ [v6] ASoc: rt711-sdca/rt1316: Add RT1316/RT711 SDCA vendor-specific driver Jul 29, 2020

lyakh requested changes Jul 29, 2020

View reviewed changes

plbossart reviewed Aug 13, 2020

View reviewed changes

shumingfan force-pushed the topic/sof-dev branch from bd18d4c to e655fbe Compare August 18, 2020 06:08

bardliao reviewed Oct 16, 2020

View reviewed changes

shumingfan closed this Oct 16, 2020

shumingfan reopened this Oct 16, 2020

shumingfan force-pushed the topic/sof-dev branch from 430431a to 3507a96 Compare October 16, 2020 06:58

shumingfan changed the title ~~[v12] ASoc: rt711-sdca/rt1316: Add RT1316/RT711 SDCA vendor-specific driver~~ [v13] ASoc: rt711-sdca/rt1316: Add RT1316/RT711 SDCA vendor-specific driver Oct 16, 2020

shumingfan force-pushed the topic/sof-dev branch from 3507a96 to 25cdd6b Compare October 16, 2020 09:51

bardliao previously approved these changes Oct 16, 2020

View reviewed changes

RanderWang previously approved these changes Oct 19, 2020

View reviewed changes

shumingfan dismissed stale reviews from RanderWang and bardliao via 74e8f89 October 19, 2020 10:55

shumingfan force-pushed the topic/sof-dev branch from 25cdd6b to 74e8f89 Compare October 19, 2020 10:55

plbossart previously approved these changes Oct 19, 2020

View reviewed changes

plbossart reviewed Oct 19, 2020

View reviewed changes

bardliao previously approved these changes Oct 20, 2020

View reviewed changes

shumingfan added 2 commits October 20, 2020 10:49

ASoC: rt1316: Add RT1316 SDCA vendor-specific driver

032fa85

This is the initial amplifier driver for rt1316 SDCA version. Signed-off-by: Shuming Fan <[email protected]>

ASoC: rt711-sdca: Add RT711 SDCA vendor-specific driver

70c9402

This is the initial codec driver for rt711 SDCA version. Signed-off-by: Shuming Fan <[email protected]>

shumingfan dismissed stale reviews from bardliao and plbossart via 70c9402 October 20, 2020 02:51

shumingfan force-pushed the topic/sof-dev branch from 74e8f89 to 70c9402 Compare October 20, 2020 02:51

bardliao requested review from RanderWang, lyakh and plbossart October 20, 2020 02:56

bardliao approved these changes Oct 20, 2020

View reviewed changes

plbossart approved these changes Oct 20, 2020

View reviewed changes

plbossart merged commit f8922c9 into thesofproject:topic/sof-dev Oct 20, 2020

Conversation

shumingfan commented Jul 20, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lyakh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lyakh Jul 21, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shumingfan commented Jul 20, 2020 •

edited

Loading

lyakh Jul 21, 2020 •

edited

Loading