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;
> }
next prev 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.