From: Hans de Goede <hdegoede@redhat.com>
To: Antonio Ospite <ao2@ao2.it>
Cc: alsa-devel@alsa-project.org,
Stephan Gerhold <stephan@gerhold.net>,
Jie Yang <yang.jie@linux.intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
Liam Girdwood <liam.r.girdwood@linux.intel.com>,
Mark Brown <broonie@kernel.org>
Subject: Re: ASoC: Intel: sst: Missing IRQ at index 5 on BYT-T device
Date: Wed, 19 Dec 2018 22:51:17 +0100 [thread overview]
Message-ID: <28564095-1b2b-679b-e2ae-e741c23905ba@redhat.com> (raw)
In-Reply-To: <20181219215911.6876b18d44c34318fe01a650@ao2.it>
Hi,
On 19-12-18 21:59, Antonio Ospite wrote:
> On Wed, 19 Dec 2018 15:23:13 +0100
> Hans de Goede <hdegoede@redhat.com> wrote:
>
>> Hi,
>>
>> On 19-12-18 15:04, Pierre-Louis Bossart wrote:
>>> On 12/19/18 7:07 AM, Stephan Gerhold wrote:
> [...]
>>>> I have tested the patch above on my device with:
>>>> - as-is, without any modifications:
>>>> -> "Falling back to Baytrail-CR platform", sound now working
>>>> - a simulated "BYT-T" device: (copied the IRQs from the DSDT of the T100TA)
>>>> -> "BYT-CR not detected" - uses 5th IRQ, sound working
>>>> - a simulated "BYT-CR" device (made is_byt_cr() return "true" and
>>>> copied the IRQs from the DSDT of the T100TAF)
>>>> -> "Detected Baytrail-CR platform" - uses IRQ at index 0, sound working
>>>>
>>>> Let me know what you think!
>>>
>>> Sounds good, playing with resources is what I had in mind rather than an interrupt count which isn't necessarily safe. The only improvement I would suggest is to add this test inside of is_byt_cr(). This routine will be moved as a helper outside of sst_acpi to be reused for SOF, so if we can make this test more self-contained it's more future-proof.
>>
>> AFAICT this will not fix all cases of this, so it might be better to see if
>> we can make is_byt_cr() return true on these devices in some other way.
>>
>> E.g. the "Teclast X98 Air 3G" Antonio reported does list 5 IRQs, but we
>> should still use the first IRQ and not the 5t.
>>
>> Antonio, do you know if your device uses SSP0 ?
>>
>
> TBH I don't remember off the top of my head, I'll check my notes and
> get back on that when I also report back about recent kernels on my
> device.
As Stephan pointed out the kernel has this quirk for your device:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/sound/soc/intel/boards/bytcr_rt5640.c?id=ec1c90e777e5a555632747527fae142aa238e583
Which says it is using SSP0, which indicates it is a Bay Trail CR
(Cost Reduced) device. So it should indeed by using the IRQ at index
0, not at index 5. Chances are when you first tested things the
kernel did not have special handling for the CR variant yet and
things will just work.
In which case we can go with Stephan's solution of checking for
there not being a 5th IRQ to recognize the BYTCR like devices
which are not properly recognized as BYTCR.
Regards,
Hans
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2018-12-19 21:51 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
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 [this message]
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=28564095-1b2b-679b-e2ae-e741c23905ba@redhat.com \
--to=hdegoede@redhat.com \
--cc=alsa-devel@alsa-project.org \
--cc=ao2@ao2.it \
--cc=broonie@kernel.org \
--cc=liam.r.girdwood@linux.intel.com \
--cc=pierre-louis.bossart@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.