On Wed, Aug 23, 2017 at 11:47:52PM +0100, Mark Brown wrote:
On Wed, Aug 23, 2017 at 06:35:24PM -0400, Tom Rini wrote:
After looking at 89128534f925 (which introduced the above line, and thus
Please include human readable descriptions of things like commits and issues being discussed in e-mail in your mails, this makes them much easier for humans to read especially when they have no internet access. I do frequently catch up on my mail on flights or while otherwise travelling so this is even more pressing for me than just being about making things a bit easier to read.
Sorry, let me re-phrase. The commit: commit 89128534f925711eea1653c264683b7d14a46530 Author: John Keeping john@metanate.com Date: Wed Aug 24 22:06:35 2016 +0100
ASoC: rt5677: Add ACPI support
The Chromebook Pixel 2015 uses this codec with the ACPI ID RT5677CE, but does not use the standard DT property names so add a new function to parse the codec properties from these ACPI properties.
Also, the GPIOs are only available by index, so we need to register a mapping to allow machine drivers to access the GPIOs by name.
Adds all of the code which "ASoC: rt5677: Move platform code to board file" and "ASoC: rt5677: Introduce proper table for ACPI enumeration" move around and re-work.
support for the Chromebook), I think that 36afb0ab648 and 55e59aa0525a are wrong and should be reverted. It seems like they're an attempt to make 89128534f925 be done 'properly' but it also seems like the
Please be more specific. The only obvious issue with the original patch "ASoC: rt5677: Add ACPI support" is that it adds an I2C ID instead of an ACPI ID. I don't have 36afb0ab648 so I've no idea what it is and 55e59aa0525a is "ASoC: rt5677: Move platform code to board file" which is a code motion patch and looks more like stylistic faff around the shambles that is ACPI than anything else.
Ugh, typo on my part proving your point :) I meant _a_36afb... which is "ASoC: rt5677: Introduce proper table for ACPI enumeration". My gut feeling (and I'd be happy to be told how to poke ACPI to confirm this..) is that the ACPI table is in fact not including some information that the code expects and that's why the original patch added an I2C ID not an ACPI ID.