Re: [alsa-devel] [PATCH 1/2] ASoC: rt5677: Add ACPI device probing
On Tue, 2014-11-25 at 08:01 -0800, Darren Hart wrote: > > On 11/25/14 06:28, Liam Girdwood wrote: > > On Tue, 2014-11-25 at 12:11 +, Grant Likely wrote: > >> On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang wrote: > >>> The rt5677 codec driver looks for ACPI device ID "RT5677CE", > >>> which is specified in coreboot. This patch allows platform > >>> data to be obtained via ACPI > >>> > >>> Signed-off-by: Ben Zhang > >> > >> This looks like an ideal time to talk about shared DT and ACPI driver > >> bindings. This driver /already/ has a firmware binding. It is > >> documented in the kernel under > >> Documentation/bindings/sound/rt5677.txt. We now have a standard method > >> for sharing bindings between DT and ACPI in the _DSD method[1]. > >> Support for DSD is in linux-next and getting merged into v3.19. This > >> is exactly the case that _DSD should be used for passing additional > >> data to the driver, and it should use the existing binding. > >> > >> [1] > >> http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf > >> > >> For a long time we've had the rule on DT that new bindings must be > >> documented before we merge a patch. That rule I think has been a good > >> one, even if it is a little chaoitc. I think when it comes to ACPI > >> drivers that we should be requiring the same: Document the binding, > >> either in the kernel as a DT binding, or point to somewhere else that > >> has the binding documented. > >> > >> Also, since this patch is targeted at v3.19 or later, the > >> device-properties API should be used. Don't create something custom. > >> > > > > My sentiments exactly, there would be little point having bespoke device > > properties for every single device. Btw, we also need to align here with > > Windows too ! > > > > The Windows folks definitely know about _DSD (and helped define it), so > this is a good opportunity to work through that process. Liam, do you > have a good contact to start that discussion? > I do, I've contacted them off-list to align on this with Realtek. Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 1/2] ASoC: rt5677: Add ACPI device probing
On 11/25/14 06:28, Liam Girdwood wrote: > On Tue, 2014-11-25 at 12:11 +, Grant Likely wrote: >> On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang wrote: >>> The rt5677 codec driver looks for ACPI device ID "RT5677CE", >>> which is specified in coreboot. This patch allows platform >>> data to be obtained via ACPI >>> >>> Signed-off-by: Ben Zhang >> >> This looks like an ideal time to talk about shared DT and ACPI driver >> bindings. This driver /already/ has a firmware binding. It is >> documented in the kernel under >> Documentation/bindings/sound/rt5677.txt. We now have a standard method >> for sharing bindings between DT and ACPI in the _DSD method[1]. >> Support for DSD is in linux-next and getting merged into v3.19. This >> is exactly the case that _DSD should be used for passing additional >> data to the driver, and it should use the existing binding. >> >> [1] >> http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf >> >> For a long time we've had the rule on DT that new bindings must be >> documented before we merge a patch. That rule I think has been a good >> one, even if it is a little chaoitc. I think when it comes to ACPI >> drivers that we should be requiring the same: Document the binding, >> either in the kernel as a DT binding, or point to somewhere else that >> has the binding documented. >> >> Also, since this patch is targeted at v3.19 or later, the >> device-properties API should be used. Don't create something custom. >> > > My sentiments exactly, there would be little point having bespoke device > properties for every single device. Btw, we also need to align here with > Windows too ! > The Windows folks definitely know about _DSD (and helped define it), so this is a good opportunity to work through that process. Liam, do you have a good contact to start that discussion? -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 1/2] ASoC: rt5677: Add ACPI device probing
On Tue, 2014-11-25 at 12:11 +, Grant Likely wrote: > On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang wrote: > > The rt5677 codec driver looks for ACPI device ID "RT5677CE", > > which is specified in coreboot. This patch allows platform > > data to be obtained via ACPI > > > > Signed-off-by: Ben Zhang > > This looks like an ideal time to talk about shared DT and ACPI driver > bindings. This driver /already/ has a firmware binding. It is > documented in the kernel under > Documentation/bindings/sound/rt5677.txt. We now have a standard method > for sharing bindings between DT and ACPI in the _DSD method[1]. > Support for DSD is in linux-next and getting merged into v3.19. This > is exactly the case that _DSD should be used for passing additional > data to the driver, and it should use the existing binding. > > [1] > http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf > > For a long time we've had the rule on DT that new bindings must be > documented before we merge a patch. That rule I think has been a good > one, even if it is a little chaoitc. I think when it comes to ACPI > drivers that we should be requiring the same: Document the binding, > either in the kernel as a DT binding, or point to somewhere else that > has the binding documented. > > Also, since this patch is targeted at v3.19 or later, the > device-properties API should be used. Don't create something custom. > My sentiments exactly, there would be little point having bespoke device properties for every single device. Btw, we also need to align here with Windows too ! Liam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 1/2] ASoC: rt5677: Add ACPI device probing
On Tue, 2014-11-25 at 12:11 +, Grant Likely wrote: On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang be...@chromium.org wrote: The rt5677 codec driver looks for ACPI device ID RT5677CE, which is specified in coreboot. This patch allows platform data to be obtained via ACPI Signed-off-by: Ben Zhang be...@chromium.org This looks like an ideal time to talk about shared DT and ACPI driver bindings. This driver /already/ has a firmware binding. It is documented in the kernel under Documentation/bindings/sound/rt5677.txt. We now have a standard method for sharing bindings between DT and ACPI in the _DSD method[1]. Support for DSD is in linux-next and getting merged into v3.19. This is exactly the case that _DSD should be used for passing additional data to the driver, and it should use the existing binding. [1] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf For a long time we've had the rule on DT that new bindings must be documented before we merge a patch. That rule I think has been a good one, even if it is a little chaoitc. I think when it comes to ACPI drivers that we should be requiring the same: Document the binding, either in the kernel as a DT binding, or point to somewhere else that has the binding documented. Also, since this patch is targeted at v3.19 or later, the device-properties API should be used. Don't create something custom. My sentiments exactly, there would be little point having bespoke device properties for every single device. Btw, we also need to align here with Windows too ! Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 1/2] ASoC: rt5677: Add ACPI device probing
On 11/25/14 06:28, Liam Girdwood wrote: On Tue, 2014-11-25 at 12:11 +, Grant Likely wrote: On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang be...@chromium.org wrote: The rt5677 codec driver looks for ACPI device ID RT5677CE, which is specified in coreboot. This patch allows platform data to be obtained via ACPI Signed-off-by: Ben Zhang be...@chromium.org This looks like an ideal time to talk about shared DT and ACPI driver bindings. This driver /already/ has a firmware binding. It is documented in the kernel under Documentation/bindings/sound/rt5677.txt. We now have a standard method for sharing bindings between DT and ACPI in the _DSD method[1]. Support for DSD is in linux-next and getting merged into v3.19. This is exactly the case that _DSD should be used for passing additional data to the driver, and it should use the existing binding. [1] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf For a long time we've had the rule on DT that new bindings must be documented before we merge a patch. That rule I think has been a good one, even if it is a little chaoitc. I think when it comes to ACPI drivers that we should be requiring the same: Document the binding, either in the kernel as a DT binding, or point to somewhere else that has the binding documented. Also, since this patch is targeted at v3.19 or later, the device-properties API should be used. Don't create something custom. My sentiments exactly, there would be little point having bespoke device properties for every single device. Btw, we also need to align here with Windows too ! The Windows folks definitely know about _DSD (and helped define it), so this is a good opportunity to work through that process. Liam, do you have a good contact to start that discussion? -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 1/2] ASoC: rt5677: Add ACPI device probing
On Tue, 2014-11-25 at 08:01 -0800, Darren Hart wrote: On 11/25/14 06:28, Liam Girdwood wrote: On Tue, 2014-11-25 at 12:11 +, Grant Likely wrote: On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang be...@chromium.org wrote: The rt5677 codec driver looks for ACPI device ID RT5677CE, which is specified in coreboot. This patch allows platform data to be obtained via ACPI Signed-off-by: Ben Zhang be...@chromium.org This looks like an ideal time to talk about shared DT and ACPI driver bindings. This driver /already/ has a firmware binding. It is documented in the kernel under Documentation/bindings/sound/rt5677.txt. We now have a standard method for sharing bindings between DT and ACPI in the _DSD method[1]. Support for DSD is in linux-next and getting merged into v3.19. This is exactly the case that _DSD should be used for passing additional data to the driver, and it should use the existing binding. [1] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf For a long time we've had the rule on DT that new bindings must be documented before we merge a patch. That rule I think has been a good one, even if it is a little chaoitc. I think when it comes to ACPI drivers that we should be requiring the same: Document the binding, either in the kernel as a DT binding, or point to somewhere else that has the binding documented. Also, since this patch is targeted at v3.19 or later, the device-properties API should be used. Don't create something custom. My sentiments exactly, there would be little point having bespoke device properties for every single device. Btw, we also need to align here with Windows too ! The Windows folks definitely know about _DSD (and helped define it), so this is a good opportunity to work through that process. Liam, do you have a good contact to start that discussion? I do, I've contacted them off-list to align on this with Realtek. Liam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
