>
> The code is looks fine, but Jack Yu added a separate patch that makes
> RTL1019 equivalent to RTL1015, so should this patch also handle the
> RTL1019 case?
The topology used by this machine driver is using 48k, 64fs I2S format.
RT1019 needs to support this configuration. Not sure if RT1019 co
> > +/*
> > + * rt1015: i2c mode driver for ALC1015 and ALC1015Q
> > + * rt1015p: auto-mode driver for ALC1015, ALC1015Q, and ALC1015Q-VB
> > +*/ static const struct snd_soc_dapm_route rt1015p_1dev_dapm_routes[]
> > += {
> > + /* speaker */
> > + { "Left Spk", NULL, "Speaker" },
> > + { "Rig
>
> could we not handle this quirk inside one of the two dai_link or codec_conf
> functions above?
> The machine driver does not care about this RT1015P_SHARE_EN_SPK quirk,
> it's only used in those two functions so should be set in this scope.
> There's no need to make it visible to the machine d
>
> This patch adds jsl_rt5682_rt1015p which supports the
> RT5682 headset codec and RT1015P speaker amplifier combination on
> JasperLake platform.
>
> Signed-off-by: Brent Lu
> ---
> sound/soc/codecs/rt1015p.c| 10 ++
> sound/soc/intel/boards/Kconfig| 1 +
> > +struct {
> > + unsigned int tx;
> > + unsigned int rx;
> > +} rt1011_tdm_mask[] = {
> > + {.tx = 0x4, .rx = 0x1},
> > + {.tx = 0x8, .rx = 0x2},
> > +};
>
> as noted in the GitHub review this should be static and possibly const.
Will fix in v2. Also add const to structures in soc-acpi
, Brent Lu wrote:
> > This DMI product family string of this board is "Google_Hatch" so the
> > DMI quirk will take place. However, this board is using rt1015 speaker
> > amp instead of max98357a specified in the quirk. Therefore, we need an
> > new DMI quirk for this board.
>
> Do you actually ne
>
> That setting is not wrong, but is it sufficient?
>
> see e.g. what we set for existing platforms which need 24 Mhz in this
> driver:
>
> DMI quirks:
>
> {
> .callback = sof_rt5682_quirk_cb,
> .matches = {
> DMI_MATCH(DMI_PRODUCT_FAMILY
>
> Please don't send new patches in the middle of existing threads, it makes it
> hard to keep track fo what is going on.
Sorry for the problem. Does it mean I should avoid using " --in-reply-to=" when
sending new patch set?
Regards,
Brent
>
> This is a bit iffy part. If same PCM is connected to multiple receivers, you
> return ELD data for the first one and ignore the rest. OTOH, this is inline
> with
> comment in hdac_hdmi_get_port_from_cvt() in that this pcm-to-many
> routing is not really supported by the driver now. But jack s
> > + /* add control for ELD Bytes */
> > + err = hdac_hdmi_create_eld_ctl(component, pcm);
> > + if (err < 0) {
> > + dev_err(&hdev->dev,
> > + "eld control add failed with err: %d for pcm: %d\n",
> > + err, device);
> > + kfree(pcm);
>
> > >
> > > CRAS calls snd_pcm_hw_params_set_buffer_size_max() to use as large
> > > buffer as possible. So the period size is an arbitrary number in
> > > different platforms. Atom SST platform happens to be 256, and CML
> > > SOF platform is 1056 for example.
> >
> > ok, but earlier in this threa
> >
> > I also wonder what's really missing, too :)
> >
> > BTW, I took a look back at the thread, and CRAS seems using a very
> > large buffer, namely:
> > [ 52.434791] sound pcmC1D0p: PERIOD_SIZE [240:240]
> > [ 52.434802] sound pcmC1D0p: BUFFER_SIZE [204480:204480]
>
> yes, that's 852 p
>
> Sorry for the late reply. CRAS does not set the period size when using it.
> The default period size is 256, which consumes the samples quickly(about 49627
> fps when the rate is 48000 fps) at the beginning of the playback.
> Since CRAS write samples with the fixed frequency, it triggers under
>
> I don't get this. If the platform driver already stated 240 and 960 samples
> why
> would 432 be chosen? Doesn't this mean the constraint is not applied?
Hi Pierre,
Sorry for late reply. I used following constraints in V3 patch so any period
which
aligns 1ms would be accepted.
+ /*
>
> For avoid further misunderstanding: it's fine that CRAS *uses* such a short
> period. It's often required for achieving a short latency.
>
> However, the question is whether the driver can set *only* this value for
> making it working. IOW, if we don't have this constraint, what actually
>
> > Hi Takashi,
> >
> > I've double checked with google. It's a must for Chromebooks due to
> > low latency use case.
>
> I wonder if there's a misunderstanding here?
>
> I believe Takashi's question was "is this a must to ONLY accept 240 samples
> for the period size", there was no pushback on t
> > >
> > > Again, is this fixed 240 is a must? Or is this also an alignment issue?
> > Hi Takashi,
> >
> > I think it's a must for Chromebooks. Google found this value works
> > best with their CRAS server running on their BSW products. They
> > offered this patch for their own Chromebooks.
>
>
>
> Again, is this fixed 240 is a must? Or is this also an alignment issue?
Hi Takashi,
I think it's a must for Chromebooks. Google found this value works best
with their CRAS server running on their BSW products. They offered this
patch for their own Chromebooks.
>
>
> thanks,
>
> Takashi
>
> If the 1ms alignment is the condition, it can be better with a different
> hw_params constraint. We can use
> snd_pcm_hw_constraint_step() for such a purpose.
Will fix. Thanks.
Regards,
Brent
>
>
> thanks,
>
> Takashi
> >>
> >> Yes or alsa will select 320 as default period size for it.
> >
> > ok, then that's a miss in your patch1. 320 samples is a multiple of
> > 1ms
>
> typo: is NOT
>
> > for 48kHz rates. I think it was valid only for the 16kHz VoIP paths
> > used in some versions of Android, but that we don
> >
> > Two different constraints are implemented: one is in platform's CPU
> > DAI to enforce period sizes which are already used in Android BSP. The
> > other is in Atom Chromebook's machine driver to use 240 as period size.
> >
> > Changes since v1:
> > -Add comma at the end of media_period_size
> On Thu, Jul 30, 2020 at 04:13:35PM +0800, Brent Lu wrote:
> > From: Yu-Hsuan Hsu
> >
> > The CRAS server does not set the period size in hw_param so ALSA will
> > calculate a value for period size which is based on the buffer size
> > and other parameters. The value may not always be aligned wit
>
> Is this patch required if you've already constrained the period sizes for the
> platform driver in patch1?
Yes or alsa will select 320 as default period size for it.
Regards,
Brent
>
> So if there are already quirks in atom machine drivers to change the period
> size, why is this patch necessary?
>
The story is: google implemented the constraint but doesn't know why it works
so asked us to explain. After checking the two counters I realized the increase
of
ring buffer poi
>
> All the Atom firmware assumes data chunks in multiples of 1ms (typically 5,
> 10 or 20ms). I have never seen anyone use 256 frames, that's asking for
> trouble really.
>
> it's actually the same with Skylake and SOF in most cases.
>
> Is this a 'real' problem or a problem detected by the Chr
> A deadlock is identified when there are three contexts running at the same
> time:
> - a HDMI jack work which is calling snd_soc_dapm_sync().
> - user space is calling snd_pcm_release() to close pcm device.
> - pm is calling runtime suspend function of HDMI codec driver.
>
> By removing the clea
>
> this doesn't look too good, the only difference is the addition of
> MAX98090 which should be added in
> SND_SOC_INTEL_DA7219_MAX98357A_GENERIC
> above.
Will do
>
> i don't think you need a different top-level config, just extend the existing
> one to say MAX98357A or MAX98390.
>
> [...]
>
>
> Support MAX98390 speaker amplifier on cometlake platform. Driver now
> detects amplifier type in the probe function and installs corresponding
> controls and DAPM widgets/routes in the late_probe function.
>
> Signed-off-by: Brent Lu
This patch is from Chrome-v4.19 branch to support the com
>
> better to align the logic, so I'm ok to take this patch to SOF.
> Can you fix the summary though:
>
> - ASoC: SOF: Intel: hda: unsolicited RIRB response
> + ASoC: SOF: Intel: hda: Clear RIRB status before reading WP
>
> Br, Kai
A v3 patch is uploaded. Thanks for review.
Regards,
Brent
>
> Now I noticed that the legacy driver already addressed it recently via commit
> 6d011d5057ff
> ALSA: hda: Clear RIRB status before reading WP
>
> We should have checked SOF at the same time, too...
>
>
> thanks,
>
> Takashi
Hi Takashi-san,
Yes you are correct. I tested Chrome v5.4 on
>
> IIRC we added this loop before merging all interrupt handling in one thread,
> somehow the MSI mode never worked reliably without this change, so
> maybe we don't need this loop any longer.
>
> I'd really prefer it if we didn't tie the RIRB handing change to this loop
> change,
> removing th
> Hi Brent,
>
> Thanks for the patch. Is this fix for a specific issue you're seeing?
> If so, could you please give us some details about it?
>
> Thanks,
> Ranjani
Hi Ranjani,
It's reported to happen on GLK Chromebook 'Fleex' that sometimes it
cannot output the audio stream to external display
>
> I tried to imagine a negative impact for this hw_ptr_jiffies update when the
> DMA position is not updated from the driver and I haven't found any so far.
>
> Let's apply this and we'll see in future :-)
>
> And yes, the patch description should be improved (DMA ptr is not updated /
> stream
>
> Updating hw_ptr_jiffies at that code path looks correct, but it still leaves
> the
> question why this condition happens. It means that the actual hwptr isn't
> changed and yet only jiffies increase significantly; it means that the
> hardware
> can't report proper pointer, and it should hav
>
> Is this a bugfix needed for older kernels as well? When did this issue show
> up?
>
> thanks,
>
> greg k-h
It happens when DMA stop moving data from host to DSP/DAI for a long time
(> half of buffer time). I know host driver should do something about it. But if
not, the HWSYNC will keep in
>
> Looks there is race between the previous stream stop and the current
> stream start here. Can you help try changing the
> sst_byt_stream_start/stop() from 'nowait' mode to 'wait' mode, and see if
> the issue can be reproduced with it?
Hi Keyon,
Kernel panic if the mode is changed. The defect
>
> Hi,
>
> That's why I would suggest trying with readq, it should also generate one
> instruction read x86_64 platforms, I looked a bit more and there is fallback
> to
> generate two 32 bit reads on 32bit platforms, so my previous concern about
> having to write separate handling for those pla
>
> Hi,
> yes that seems bit weird. It is bit better as it does not modify common code,
> but still... Maybe going back to your original idea of replacing memcpy, try
> replacing it with readq? It should generate one instruction read (although it
> is
> only for x64_64, for 32 bit kernel we would
>
> I've looked at the code and byt_is_dsp_busy seems suspicious to me.
> Can you check if following change fixes problem for you:
>
> diff --git a/sound/soc/intel/baytrail/sst-baytrail-ipc.c
> b/sound/soc/intel/baytrail/sst-baytrail-ipc.c
> index 74274bd38f7a..34746fd871b0 100644
> --- a/sound/s
> Subject: [PATCH] ASoC: bdw-rt5677: enable runtime channel merge
>
> In the DAI link "Capture PCM", the FE DAI "Capture Pin" supports 4-channel
> capture but the BE DAI supports only 2-channel capture. To fix the channel
> mismatch, we need to enable the runtime channel merge for this DAI link.
>
> >
> > It's not only the mismatch but also the design limitation. According
> > to the information from google, the board (samus) only uses two
> > microphone so
> > 3 or 4 channel recording are not supported. That's the reason we
> > leverage the constraint from other machine driver (like
> > kbl
> >
> > The story is Chrome has a tool called alsa_conformance_test which runs
> > capture or playback against a PCM port with all possible
> > configurations (channel, format, rate) then measure if the sample rate
> > is correct. Since the channel max number reported is 4, it tests the
> > 4-chann
> -Original Message-
> From: Pierre-Louis Bossart [mailto:pierre-louis.boss...@linux.intel.com]
> Sent: Tuesday, September 10, 2019 1:53 AM
> To: Lu, Brent ; alsa-de...@alsa-project.org
> Cc: Rojewski, Cezary ;
> kuninori.morimoto...@renesas.com; linux-kernel@vger.
,
Brent Lu
-Original Message-
From: Pierre-Louis Bossart [mailto:pierre-louis.boss...@linux.intel.com]
Sent: Friday, September 6, 2019 10:21 PM
To: Lu, Brent ; alsa-de...@alsa-project.org
Cc: Rojewski, Cezary ;
liam.r.girdw...@linux.intel.com; yang@linux.intel.com; broo...@kernel
44 matches
Mail list logo
