From: Cezary Rojewski <cezary.rojewski@intel.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
alsa-devel@alsa-project.org
Cc: broonie@kernel.org, tiwai@suse.com, lgirdwood@gmail.com
Subject: Re: [PATCH 1/4] ASoC: Intel: Haswell: Adjust machine device private context
Date: Thu, 22 Aug 2019 17:11:02 +0200 [thread overview]
Message-ID: <32051c24-45f7-d4f0-9912-9c93fcf08733@intel.com> (raw)
In-Reply-To: <dbde72dc-9b41-f1a8-001a-5674f5af3b61@linux.intel.com>
On 2019-08-22 16:07, Pierre-Louis Bossart wrote:
> On 8/22/19 6:36 AM, Cezary Rojewski wrote:
>> Apart from Haswell machines, all other devices have their private data
>> set to snd_soc_acpi_mach instance.
>>
>> Changes for HSW/ BDW boards introduced with series:
>> https://patchwork.kernel.org/cover/10782035/
>>
>> added support for dai_link platform_name adjustments within card probe
>> routines. These take for granted private_data points to
>> snd_soc_acpi_mach whereas for Haswell, it's sst_pdata instead. Change
>> private context of platform_device - representing machine board - to
>> address this.
>
> Cezary, see the comments of the initial series:
>
> "Note that byt-max98080, byt-rt5640 were not modified since they are
> deprecated. bytcht-nocodec and the Skylake/Kabylake machine drivers
> changes were not changed since SOF does not support them. There may be
> additional changes if and when Skylake/Kabylake are supported by SOF
> (largely a firmware authentication issue, not technical difficulty)."
>
> I intentionally did not touch the Haswell and Baytrail legacy since both
> drivers do not update the platform name, this is only done for cases
> where SOF is used.
>
> So while I don't mind a change, it's got to come with tests for each
> variant, and if you do the changes for Haswell then you want to change
> Baytrail legacy machine drivers as well. And are we going to change the
> SKL/KBL machine drivers to allow for this platform name rewrite?
>
> Also the information below is misleading: nothing is broken in the
> current solution and -stable kernels do not need to pick this patchset.
> This is a code alignment and the behavior is identical.
>
> Or as an alternative we leave the code as is...
>
Guess I wasn't clear enough:
- this code fixes panic generated by series found under link above.
Following code added within machine probe for broadwell.c:
/* override plaform name, if required */
mach = (&pdev->dev)->platform_data;
pdata = (&pdev->dev)->platform_data;
if (mach) /* extra check since legacy does not pass parameters */ {
platform_name = mach->mach_params.platform;
dev_warn(&pdev->dev, "Broadwell platform_name: %s, %s, %s, %s\n",
mach->id, mach->drv_name, mach->fw_filename, platform_name);
dev_warn(&pdev->dev, "Broadwell id and res_idx: %x, %d\n", pdata->id,
pdata->resindex_dma_base);
}
Generates:
[ 25.982151] broadwell-audio broadwell-audio: Broadwell platform_name:
, (null), (efault), (null)
[ 25.982157] broadwell-audio broadwell-audio: Broadwell id and
res_idx: 3438, 1040384
Conslusion:
0x3438 == BDW_ID
1040384 -> 0x0FE000 -> WPT_DSP_DMA_ADDR_OFFSET
confirms the claim.
As stated, during cleanups and moving stuff around, code you've added
generates panics. Right now it works only because of offsets of
miscasted object pointing to uninitialized variable (luckily).
platform_name is initialized as NULL for all SKL+ and legacy platforms
and thus the snd_soc_fixup_dai_links_platform_name returns immediately.
So by all means, change is not only save, but required.
Code is being tested on 2x BDW-Y which live now a happy live in our lab
with the rest of the platforms.
Czarek
>> Fixes: e87055d732e3 ("ASoC: Intel: haswell: platform name fixup support")
>> Fixes: 7e40ddcf974a ("ASoC: Intel: bdw-rt5677: platform name fixup
>> support")
>> Fixes: 2d067b2807f9 ("ASoC: Intel: broadwell: platform name fixup
>> support")
>> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
>> ---
>> sound/soc/intel/common/sst-acpi.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/sound/soc/intel/common/sst-acpi.c
>> b/sound/soc/intel/common/sst-acpi.c
>> index 15f2b27e643f..c34f628c7987 100644
>> --- a/sound/soc/intel/common/sst-acpi.c
>> +++ b/sound/soc/intel/common/sst-acpi.c
>> @@ -109,11 +109,12 @@ int sst_acpi_probe(struct platform_device *pdev)
>> }
>> platform_set_drvdata(pdev, sst_acpi);
>> + mach->pdata = sst_pdata;
>> /* register machine driver */
>> sst_acpi->pdev_mach =
>> platform_device_register_data(dev, mach->drv_name, -1,
>> - sst_pdata, sizeof(*sst_pdata));
>> + mach, sizeof(*mach));
>> if (IS_ERR(sst_acpi->pdev_mach))
>> return PTR_ERR(sst_acpi->pdev_mach);
>>
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2019-08-22 15:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-22 11:36 [PATCH 0/4] ASoC: Intel: Haswell: Adjust machine device private Cezary Rojewski
2019-08-22 11:36 ` [PATCH 1/4] ASoC: Intel: Haswell: Adjust machine device private context Cezary Rojewski
2019-08-22 14:07 ` Pierre-Louis Bossart
2019-08-22 15:11 ` Cezary Rojewski [this message]
2019-08-22 15:58 ` Pierre-Louis Bossart
2019-08-22 16:05 ` Cezary Rojewski
2019-08-22 16:42 ` Pierre-Louis Bossart
2019-08-22 17:14 ` Cezary Rojewski
2019-08-22 18:44 ` Pierre-Louis Bossart
2019-08-22 19:02 ` Cezary Rojewski
2019-08-22 20:44 ` Pierre-Louis Bossart
2019-08-23 7:27 ` Cezary Rojewski
2019-08-28 9:38 ` Cezary Rojewski
2019-08-29 22:31 ` Pierre-Louis Bossart
2019-08-30 11:45 ` Applied "ASoC: Intel: Haswell: Adjust machine device private context" to the asoc tree Mark Brown
2019-08-30 11:45 ` [alsa-devel] " Mark Brown
2019-08-22 11:36 ` [PATCH 2/4] ASoC: Intel: haswell: Simplify device probe Cezary Rojewski
2019-08-30 11:45 ` Applied "ASoC: Intel: haswell: Simplify device probe" to the asoc tree Mark Brown
2019-08-30 11:45 ` [alsa-devel] " Mark Brown
2019-08-22 11:36 ` [PATCH 3/4] ASoC: Intel: bdw-rt5677: Simplify device probe Cezary Rojewski
2019-08-30 11:45 ` Applied "ASoC: Intel: bdw-rt5677: Simplify device probe" to the asoc tree Mark Brown
2019-08-30 11:45 ` [alsa-devel] " Mark Brown
2019-08-22 11:36 ` [PATCH 4/4] ASoC: Intel: broadwell: Simplify device probe Cezary Rojewski
2019-08-30 11:45 ` Applied "ASoC: Intel: broadwell: Simplify device probe" to the asoc tree Mark Brown
2019-08-30 11:45 ` [alsa-devel] " Mark Brown
2019-08-29 22:45 ` [PATCH 0/4] ASoC: Intel: Haswell: Adjust machine device private Pierre-Louis Bossart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=32051c24-45f7-d4f0-9912-9c93fcf08733@intel.com \
--to=cezary.rojewski@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox