All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Stephan Gerhold <stephan@gerhold.net>
Cc: Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	Hans de Goede <hdegoede@redhat.com>,
	alsa-devel@alsa-project.org, Mark Brown <broonie@kernel.org>,
	Jie Yang <yang.jie@linux.intel.com>
Subject: Re: ASoC: Intel: sst: Missing IRQ at index 5 on BYT-T device
Date: Mon, 17 Dec 2018 20:13:36 -0600	[thread overview]
Message-ID: <86b92282-5bc1-b8de-93e7-97e7ee17db4b@linux.intel.com> (raw)
In-Reply-To: <20181217204320.GC10938@gerhold.net>


>>>> The quirks to get sound working with bytcr-rt5640 on that device are:
>>>> BYT_RT5640_SSP0_AIF1 | BYT_RT5640_IN1_MAP | BYT_RT5640_MCLK_EN
>>>>
>>>> I guess this means that SSP0 is being used?
>>> Yes indeed, and that makes me think we should force this device to look like
>>> Baytrail-CR.
>>>
>>> You can do this with a DMI-based quirk (preferably in is_byt_cr directly so
>>> that I can reuse the code when I move it to a helper at some point).
>> Okay - thanks! One last question:
>> I was looking at the ACPI DSDT tables of some similar devices and have
>> found two others that look the same (only one IRQ listed). In this case,
>> the BYT-T acpi_ipc_irq_index = 5 will never work, and we will definitely
>> have a better chances with trying Baytrail-CR.
>>
>> One of them actually had a similar patch proposed at [1] (although they
>> did it in a weird way and also need an extra machine driver).
>>
>> We could also detect this situation in a generic way with something like
>>
>>    if (platform_irq_count(pdev) == 1) {
>>    	*bytcr = true;
>> 	return 0;
>>    }
>>
>> ... instead of a DMI quirk. What do you think?
>>
> To avoid confusion: The existing PMIC-type based is_byt_cr() detection
> would be used in all other cases (i.e. if irq_count != 1), so it won't
> make any difference for the devices that are already working fine.
> (Most BYT-CR devices seem to have 5 IRQs listed)
>
> So it's more like
>
>    if (platform_irq_count(pdev) == 1) {
>    	*bytcr = true;
>    } else {
>    	// pmic-type based detection...
>    }
>
> with platform_irq_count == 1 as condition for the "quirk".

The solution seems appealing but

1) does it really work? I am not sure an index=5 means there are 5 
interrupts.

2) the test would affect all existing devices, and there's so much 
hardware proliferation that proving this change in harmless might be 
difficult. I personally only have one BYT-T (ASus T100) device left and 
it's not very reliable. Hans seems to have a ton of devices but they are 
mostly Byt-Cr?

  reply	other threads:[~2018-12-18  2:13 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-16 18:54 ASoC: Intel: sst: Missing IRQ at index 5 on BYT-T device Stephan Gerhold
2018-12-16 19:07 ` Hans de Goede
2018-12-16 22:03   ` Antonio Ospite
2018-12-17  7:53     ` Hans de Goede
2018-12-17  8:25       ` Antonio Ospite
2018-12-17 18:03   ` Stephan Gerhold
2019-01-09 19:22     ` Mark Brown
2019-01-09 21:10       ` Pierre-Louis Bossart
2019-01-09 21:14         ` Mark Brown
2018-12-17 14:52 ` Pierre-Louis Bossart
2018-12-17 18:17   ` Stephan Gerhold
2018-12-17 18:29     ` Pierre-Louis Bossart
2018-12-17 19:10       ` Stephan Gerhold
2018-12-17 19:39         ` Pierre-Louis Bossart
2018-12-17 20:32           ` Stephan Gerhold
2018-12-17 20:43             ` Stephan Gerhold
2018-12-18  2:13               ` Pierre-Louis Bossart [this message]
2018-12-19 13:07                 ` Stephan Gerhold
2018-12-19 14:04                   ` Pierre-Louis Bossart
2018-12-19 14:23                     ` Hans de Goede
2018-12-19 20:59                       ` Antonio Ospite
2018-12-19 21:51                         ` Hans de Goede
2018-12-19 15:01                     ` Stephan Gerhold
2018-12-19 16:54                       ` Pierre-Louis Bossart
2018-12-19 17:35                         ` Stephan Gerhold
2018-12-19 20:56                           ` Antonio Ospite
2019-01-03 10:04                             ` Antonio Ospite

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=86b92282-5bc1-b8de-93e7-97e7ee17db4b@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.