Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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