public inbox for alsa-devel@alsa-project.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Stephan Gerhold <stephan@gerhold.net>, Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	Hans de Goede <hdegoede@redhat.com>,
	alsa-devel@alsa-project.org, Jie Yang <yang.jie@linux.intel.com>
Subject: Re: [PATCH 1/2] ASoC: Intel: sst: Fallback to BYT-CR if IRQ 5 is missing
Date: Mon, 31 Dec 2018 09:38:21 -0600	[thread overview]
Message-ID: <42aa8bbb-433e-6eb7-e3ff-a52c14d87b61@linux.intel.com> (raw)
In-Reply-To: <20181222144708.121732-1-stephan@gerhold.net>


On 12/22/18 8:47 AM, Stephan Gerhold wrote:
> Some devices detected as BYT-T by the PMIC-type based detection
> have only a single IRQ listed in the 80860F28 ACPI device. This
> causes -ENXIO later when attempting to get the IRQ at index 5.
> It turns out these devices behave more like BYT-CR devices,
> and using the IRQ at index 0 makes sound work correctly.
>
> This patch adds a fallback for these devices to is_byt_cr():
> If there is no IRQ resource at index 5, treating the device
> as BYT-T is guaranteed to fail later, so we can safely treat
> these devices as BYT-CR without breaking any working device.
>
> Link: http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/143176.html
> Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
> ---
> Moved the "Detected Baytrail-CR platform" message to is_byt_cr()
> so we can log a different message if the fallback is used.
>
> Tested this on my device as-is, and simulated a "normal"
> BYT-T and BYT-CR device (copied their IRQs to a custom DSDT).
>
>   sound/soc/intel/atom/sst/sst_acpi.c | 24 ++++++++++++++++++------
>   1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/sound/soc/intel/atom/sst/sst_acpi.c b/sound/soc/intel/atom/sst/sst_acpi.c
> index 3a95ebbfc45d..755a396121ff 100644
> --- a/sound/soc/intel/atom/sst/sst_acpi.c
> +++ b/sound/soc/intel/atom/sst/sst_acpi.c
> @@ -255,10 +255,22 @@ static int is_byt(void)
>   	return status;
>   }
>   
> -static int is_byt_cr(struct device *dev, bool *bytcr)
> +static int is_byt_cr(struct platform_device *pdev, bool *bytcr)
>   {
> +	struct device *dev = &pdev->dev;
>   	int status = 0;
>   
> +	if (platform_get_resource(pdev, IORESOURCE_IRQ, 5) == NULL) {
> +		/*
> +		 * Some devices detected as BYT-T have only a single IRQ listed,
> +		 * causing platform_get_irq with index 5 to return -ENXIO.
> +		 * The correct IRQ in this case is at index 0, as used on BYT-CR.
> +		 */
> +		dev_info(dev, "Falling back to Baytrail-CR platform\n");
> +		*bytcr = true;
> +		return status;
> +	}
> +

Isn't this going to bypass the PMIC-based detection on all BYT-CR 
devices? Maybe move this code as a fallback used when the PMIC-based 
detection isn't positive?


>   	if (IS_ENABLED(CONFIG_IOSF_MBI)) {
>   		u32 bios_status;
>   
> @@ -278,10 +290,12 @@ static int is_byt_cr(struct device *dev, bool *bytcr)
>   			/* bits 26:27 mirror PMIC options */
>   			bios_status = (bios_status >> 26) & 3;
>   
> -			if ((bios_status == 1) || (bios_status == 3))
> +			if ((bios_status == 1) || (bios_status == 3)) {
> +				dev_info(dev, "Detected Baytrail-CR platform\n");
>   				*bytcr = true;
> -			else
> +			} else {
>   				dev_info(dev, "BYT-CR not detected\n");
> +			}
>   		}
>   	} else {
>   		dev_info(dev, "IOSF_MBI not enabled, no BYT-CR detection\n");
> @@ -333,10 +347,8 @@ static int sst_acpi_probe(struct platform_device *pdev)
>   	if (ret < 0)
>   		return ret;
>   
> -	ret = is_byt_cr(dev, &bytcr);
> +	ret = is_byt_cr(pdev, &bytcr);
>   	if (!(ret < 0 || !bytcr)) {
> -		dev_info(dev, "Detected Baytrail-CR platform\n");
> -
>   		/* override resource info */
>   		byt_rvp_platform_data.res_info = &bytcr_res_info;
>   	}

  parent reply	other threads:[~2018-12-31 15:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-22 14:47 [PATCH 1/2] ASoC: Intel: sst: Fallback to BYT-CR if IRQ 5 is missing Stephan Gerhold
2018-12-22 14:47 ` [PATCH 2/2] ASoC: Intel: bytcr_rt5640: Add quirks for ASUS MeMO Pad 7 (ME176C) Stephan Gerhold
2018-12-22 14:59   ` Stephan Gerhold
2018-12-24  9:01     ` Hans de Goede
2018-12-24  9:53       ` Stephan Gerhold
2018-12-24 10:36         ` Hans de Goede
2018-12-31 15:38 ` Pierre-Louis Bossart [this message]
2018-12-31 16:30   ` [PATCH 1/2] ASoC: Intel: sst: Fallback to BYT-CR if IRQ 5 is missing Stephan Gerhold
2018-12-31 20:44     ` Pierre-Louis Bossart
2019-01-01 21:11       ` Stephan Gerhold
2019-01-02 16:39         ` 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=42aa8bbb-433e-6eb7-e3ff-a52c14d87b61@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=stephan@gerhold.net \
    --cc=yang.jie@linux.intel.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